Test Everywhere: A Journey into DevOps and Continuous Testing (Anastasios Daskalopoulos)
Test Everywhere: A Journey into DevOps and Continuous Testing
A move to DevOps creates an opportunity to shift the testing process to the left. But what if you went further? DevOps supports continuous testing, so you can advocate for a constant focus on quality, with testing permeating the entire software development process. Here's how you can actually have a faster testing process when the software is tested throughout the lifecycle, by developers, testers, and automation alike. It’s a constant challenge to remove the concept that testing is a financial drain and time bottleneck that is a threat to product delivery. My counterargument has always been that post-release bug fixes from poorly tested (or even untested) software are more expensive and damaging to the company reputation, and properly planned and executed testing processes do not cause delays or excess costs.
My goal was to have testing and development work in parallel and act in conjunction for their mutual benefit. Instead of the usual practice of banging out the code for a list of features for every sprint, a prioritized list of features is recorded in descending order in a TESTME.md file, a short, markdown-language file that uses the Gherkin syntax. This list focuses both the developer and tester on the simultaneous coding and test creation for each feature by importance. Following the creation and execution of unit tests, the TESTME.md-based tests are then created and executed using Behat, and is followed by Functional test sets. The purpose of this approach is to create and execute tests during each stage of development as part of the Development process.
A move to DevOps creates an opportunity to shift the testing process to the left. But what if you went further? DevOps supports continuous testing, so you can advocate for a constant focus on quality, with testing permeating the entire software development process. Here's how you can actually have a faster testing process when the software is tested throughout the lifecycle, by developers, testers, and automation alike. It’s a constant challenge to remove the concept that testing is a financial drain and time bottleneck that is a threat to product delivery. My counterargument has always been that post-release bug fixes from poorly tested (or even untested) software are more expensive and damaging to the company reputation, and properly planned and executed testing processes do not cause delays or excess costs.
My goal was to have testing and development work in parallel and act in conjunction for their mutual benefit. Instead of the usual practice of banging out the code for a list of features for every sprint, a prioritized list of features is recorded in descending order in a TESTME.md file, a short, markdown-language file that uses the Gherkin syntax. This list focuses both the developer and tester on the simultaneous coding and test creation for each feature by importance. Following the creation and execution of unit tests, the TESTME.md-based tests are then created and executed using Behat, and is followed by Functional test sets. The purpose of this approach is to create and execute tests during each stage of development as part of the Development process.