Software Testing in the Age of DevOps
Waterfall to Agile to Dev/Ops, software development from concept to finished product has changed more than software organizations from two or three decades ago could possibly have imagined. Nonetheless, the days of eighteen-month release cycles with the rigid separation of development and quality are gone.
The Software QA Environment Has Changed
The whole concept of DevOps/Continuous Delivery mandates a flow of system updates moving to deployment in a continuous stream. The idea of development tossing the latest release over the wall to QA to test for months before throwing it back with a bug list has joined the dust of the ages.
The point of Agile implementation was an improvement in the rate of feature/bug fix releases. To achieve this, software quality and project risk control required that testing be integrated into development, and performed early and often. DevOps is a natural extension of Agile that extends Agile principles across delivery and operations. Theoretically, this leads to integration of all the processes from development through integration, testing and deployment.
Test Automation Becomes Necessary
Continuous Delivery means that these quickly developed and tested features are deployed rapidly to a production environment, with as little delay as possible. DevOps and Continuous Delivery essentially mandate the use of test automation. Automation is thus viewed as a foundation element of DevOps. It predicates automating every test that can be automated specifically including regression and functional testing.
This requires building the code on a prepared Development environment to be deployed to a standardized Test environment to go to Acceptance testing for final Production deployment. DevOps expects this to be done on a cross-discipline, integrated array of systems commonly called a ready-to-use DTAP street.
Quality and Testing Must Adapt
Obviously, the foregoing means that quality must adapt from being a stand-alone entity to an integral aspect of the entire product development chain. The traditional detect and report function of SQA often vastly outweighed its participation in process improvement. For Agile and especially DevOps to work, that must change.
A long-term fix/test loop required that massive test regimes be run on successive iterations of fully integrated software system versions. DevOps and Continuous Delivery require the merger of testing with development, acceptance and deployment such that it becomes a part of these processes. Most importantly, the quality perspective must permeate and inform the development process.
To support the DevOps product pipeline, code quality must improve from its inception and that means test and development personnel working side by side with deep insight into each other’s domains. Simply looking for bugs after modules are written and integrated will not support the kind of feature/fix velocity that DevOps strives to achieve.
This also means a reality check for test automation. For too long, it has swung between being considered the panacea for all of testing’s ills and a joke in bad taste. DevOps and Continuous Delivery make test automation an imperative if the value of software code is ever to keep up with its generation.
How Software QA Makes the Transition
Any organization facing a change of this magnitude needs all the help and insight it can get. While the strident demand for DevOps and Continuous Delivery call for a rapid change over to their widespread employment, there must still be an orderly transition lest Agile turn into chaos. Well established third-party quality organizations can be a valuable resource for easing these changes.
A testing company must hire seasoned testers and test engineers. These are the people who have seen the development process first hand and seen it from the quality perspective of what can and will go wrong. That is exactly the set of insights that a development organization needs to introduce to its staff for a successful DevOps implementation.
These are also the people who can bring up the test automation frameworks and work with the on-site staff to put automation to its best use. They can tell which test tasks are prime candidates for being at the front of the automation queue and which ones need to be parsed more thoroughly before they are worked into the test script arrays. They can also perform script maintenance until this function can be fully staffed.
Bringing in tried and true test personnel from a software quality organization that has earned trust and respect will go a long way toward mounting a successful change-over to DevOps.