You may have seen the term “continuous testing” and thought it was just the DevOps flavor of the month. Some might even think it isn’t part of DevOps or isn’t for cloud or hybrid cloud applications.
Well, think again.
As it turns out, there are a few more fallacies around the idea of continuous testing floating around the application development community.
Here are a few to ponder:
Continuous testing is only about executing test scripts
Limiting the term “testing” to only the execution of test scripts is a misnomer. As my co-author, Allan Wagner and I point out, testing and checking application functionality are not equal. There’s a long list of testing items to check off one’s list, the least of which is collaborating.
Continuous testing is merely a buzzword
It’s a core part of that essential DevOps practice, continuous delivery. And, with customers demanding higher quality software faster, it isn’t going anywhere soon. In short, invest in continuous testing.
Only agile teams do continuous testing
This is false.
Some or all parts of continuous testing are critical for any type of team as well as all players. This includes test automation, production-like test environments and realistic test data. A related myth—only testers contribute to testing—is also not true at all. The idea of continuous testing includes all team members. The book describes the roles everybody has to play. For example, did you know that designers can improve testing? They can work with testers to help them understand where the fragile parts of the application are.
Automating tests means we need fewer tests
No, the machines are not taking over. Automating tests does not mean cutting back on testing jobs. To the contrary, automation is reducing testers’ needs to act like cyborgs and spend more time doing what they do best: learn and experiment.
Continuous testing isn’t for large, complex systems
The best thing you can do for large or complex systems is leverage continuous testing practices and tools such as service virtualization to conduct end-to-end testing earlier and more frequently, rather than having each subsystem do all its own testing in isolation until just before deployment to production.
To read more myths about continuous testing, check out the free eBook, “Continuous Testing for Dummies.”