olly - Fotolia
I've come to notice over the many years I’ve worked in an Agile development team that I end up duplicating test efforts two, three or even four times. In other words, in the Agile testing process I'm using I test the same thing multiple times in a series of similar, related, but yet different server environments. These aren’t different platforms or versions -- they are simply different servers that accommodate continuous deployment and integration. The final test server may resemble a production server, but resemble is as close as it gets. Production servers are rarely ever tested even with automated tests. The reason I've been given for all this repeat testing is the accumulation of "junk" test data affects performance and/or application functionality.
Shouldn't we test for that? The worst I've ever had is testing across three servers in approximately three days or less. Yet, the failures didn't occur on any of those three servers but often occurred immediately in production. I fail to understand why a duplicate production server setup and data construction is not possible for QA testing. It would eliminate the need to unnecessarily repeat tests across servers as it continuously deploys and integrates. I really shouldn't need to test more than twice -- once in QA, and once in production or an exact production representative.
Is it Agile to repeat test execution multiple times? If I repeatedly test on servers that are not production, is it worth the duplication of work, time, stress and energy? I'd say no to both questions.
Reducing work task duplication
I truly believe production is testable in a safe, effective manner. We could use an Agile testing process on the actual production server and then we should be able to test an exact, data-scrubbed replica. In this manner, QA testers test once in QA and then once in the production replica. Why not reduce QA testing to once only? Then, in the production replica, have development scripts to verify that the expected code is in place and intact after the final deploy.
The Agile testing process shouldn't include duplicate work. It reduces productivity, overall effectiveness and quality. People resent repeating work constantly and their enthusiasm declines over time. Quality doesn’t improve when resources repeat tasks in a hurry, ineffectively or repeatedly.
Agile teams and development organizations need focused, diligent resources. Reduce duplicated work tasks to improve quality and effectiveness. Test on real systems, or exact replicas of actual production to increase code quality and test execution results.
Shampoo, rinse and repeat is only a good way to make you use and then buy more product. It should not be part of the Agile testing process.
Think you know all about the testing profession? Think again
Should testers learn to code? Maybe
When your first job is as a tester…it might be tricky
Dig Deeper on Topics Archive
Related Q&A from Amy Reichert
Let's explore the importance of result analysis, the right measurements and test design for application performance testing. Continue Reading
QA needs to reiterate its value to the business side of the organization. Use this tried-and-true advice to leverage documentation and automation to ... Continue Reading
Vendors have inched toward automated application testing for a long time, yet there is still room for growth. Software tester Amy Reichert offers her... Continue Reading