The evolution of test

( In this SmartBits,  Srinivasan Desikan outlines “The evolution of test“.  The video is at the end of this blog)

Earlier days we used to have three different teams – configuration management team to build the product, development that develops and hacks in software and test team that tests the system. The configuration management team will make the build, do whatever checks that are necessary, build it and then give only the binary version to the testing team. This was called as the build ball, they roll with it, then test it and report problems.

Earlier days 30% of the problems were mainly because of the configuration management itself. It was not the developers who were introducing the defects. It was the configuration management team, which was introducing defects by wrong builds. The build was not validated properly, build validation evolution started from the testing team. Configuration management team asked the test team to test whether the build was correct or wrong? The testing team gave them a suite which was called a sanity suite or build verification test and the build team used it, validated the build and gave it to the testing team which resulted in quality improvement.

Whenever there are boundaries there will be more problems lurking around the boundaries. Always the problems occur because of the intersection between the development and configuration management, configuration management and testing and also the boundary between development and testing.

These problems brought a thought process about a new evolution which is called DevOps. Which means starting from the development all the way to the operations, everything should be automated so that there are no boundaries left. If one has to automate something it has to start with test automation, again the evolution started with the test engineers. The build got automated scripts, the binary ball they got automated, the testing that ensures the build is done properly was automated and the functional testing as well as the build of the developers also got automated. Good amount of code that is coming nowadays are auto-created code. Here they check the return values and add more exceptions code to it. Eventually that also got automated.

We are entering the DevOps model where good amount of that is automated and people are really needed only when it breaks and only when more value needs to be added to the automation. We do not deliver any more to code or we do not deliver any more to build. We don’t deliver any more to testing but we really deliver to the purpose of the whole thing, which is the end result. That’s where DevOps is taking us to.