DevOps is a strategy to increase communication and co-ordination between development and infrastructure/build operations, as there was a disconnect between the two teams which lead to miscommunication, inefficiency, and effectiveness in the product development and delivery. DevOps sped up delivery cycles, as the feedback loop on failures and mistakes was faster, which enabled development to fix issues quickly and resubmit them for re-build. So far, so good. But what about Software Testing?
The challenge came when, in the need for speed, an important component that lies between development and the release, got affected – ‘Software Testing‘. In Software Development, Testing falls between development and the release. As the time to deliver became shorter and shorter, the pressure to test the rebuild faster increased, and there are unrealistic expectations on how soon the new build should be tested, which led to demean human thinking activity related to Testing as “exploratory testing”. Note that human-done tests are not just ‘checks’). The problem has turned unbelievable these days, that people are thinking of replacing Testing with just DevOps-based automation. There is a LinkedIn post that asked this question.
The clear answer is ‘No, DevOps is NOT the “New Test”‘. Because, irrespective of the no. of automated checks that you add to the DevOps cycle, the need for human Testing is paramount, and that effort cannot be replaced. Testing is a human-led activity in which automation assists in repetitive checks that can create fatigue for a human being. The Test Orchestration is, and should be, done by a human. The automated checks to be run should be selected by a human (not that the same checks should be run in every run; the checks have to be selected based on the problem at hand). The thought process of doing additional checks which are not already thought about is human.
It is sad to note how a convenience for faster feedback loops has started to undermine the need for Testing. In this rush, we just hope that Quality (that is still dependent on code that is written for implementation) is not sacrificed.
Please feel free to reach out to me on advice on Software Testing and Software Quality through the Contact form.