Agile, agile, agile. In the software development world, the word’s becoming impossible to ignore. Every day sees another dev team decide to "go Agile," and technology research and advisory companies are placing "agile development practices" as one of the four key components in their analysis.
Often, this leaves testers and managers in a traditional "QA" department looking around wondering just what their new role will be. Right after "Agile means no documentation," one of the next most-frequently seen myths is that Agile teams only need to include a product owner and some developers — no testers required — the developers will use Unit Tests and then ship a perfect, bug-free application.
First of all, let’s remember that "Agile" by itself specifies none of this – it’s a statement of philosophy, not a set of proscribed practices. When deciding to "go Agile," a team should look at several of the agile software development methods and strive to understand how each of them would (or would not) work in their organization. Many organizations mix and match practices that have the best chance to succeed in their unique environments.
Most of the common methodologies focus on incremental development of smaller feature sets with tight feedback loops. Skimping on documentation and testing are tempting ways to reduce development time, but both are long-term risks. Documentation and testing are still needed though their form will likely be much different than was seen in traditional software development practices.
In a well-structured and productive Agile team, all the stakeholders are involved and actively collaborating in all phases: planning, development, testing and a retrospective — this includes product owner, developers and testers. Each iteration becomes a set of parallel development and testing tasks; rapid feedback loops keep the information flowing, leading to issues quickly-discovered and resolved. Testing moves from an all-manual task done at the end of a long development cycle to various levels of automation done throughout the feature's development. Simultaneously, developers cease "throwing code over the wall" and work with testers to use Unit Tests, Test Driven Development and the like to build quality into the product from the get-go. The lines between departments and between individuals, formerly hard and fast, begin to blur as testers and developers both grow in skills and the organization grows in maturity.
Is Agile important? Yes; see what’s going on at your local user groups and conferences; see what Gartner has to say on the subject. Also, find out how to make key disruptors work for you by reading a whitepaper on "Four trends reshaping the software quality testing market".
Is there a place for testers in an Agile shop? Absolutely. We need only recognize the opportunity for professional growth – and for the growth of our profession – and embrace it.
is an Evangelist for Telerik's Test Studio.
He has worked in software support and testing for the better part of two decades, and enjoys exploring ways to make software easier to use.
He is a fan of movies and music, and can often be found on Twitter as @StevenJV.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.