Is your “QA process” ready for Agile?

The growing popularity of utilizing the Agile Development methodology to develop systems has changed the way software is tested.

However, you also have to ask yourself the question? Are you ready from a QA perspective?

Let’s think about QA as it relates to Agile the questions you need to answer for yourself. If you say ‘no’ to any of these questions then you do really have to consider whether your ready.

• Do you have a ‘automatic’ regression test that can be run on a night basis?
• Is your build process automated and then tested against?
• Have you developed an “integrated” testing team that can lead and test successfully during a sprint?
• Have you looked at your current QA Tools and will they work in an Agile methodology?
• Are your ‘QA artifacts” right weighted for Agile?
• What important QA Metrics are important and operational for successful Agile sprints?
• Is your team makeup right for Agile?

These are just some of the things to consider. If you said “NO” to only few of these questions then you probably will not be successful.

There are lots of Software Development Lifecycles (SDLCs) out there. The selected SDLC affects everything from requirements gathering to QA and testing. So just how does the selected SDLC affect what you do for QA?

In the article by Eric Mumford titled “How is QA different for Waterfall, Agile, and XP?”, the author looks at each of the methodologies and expresses his opinion on how QA works. I have included excerpts of his opinions below. We encourage you to read the full article.

Waterfall: “The QA cycle involves authoring manual tests to match and cover the product requirements, authoring automated scripts to test the product features, updating regression scripts to test the defects that were found in past builds, and to run performance analysis on the build.  … It [sic]  requires larger toolsets to track test cases, testing results, performance testing, and automated scripting.  Waterfall … requires a heavy investment in tools to get the job done because of the copious amount of work that needs to be tracked.”

Agile: “QA focuses on writing automated scripts, usually using an open source test framework, against the software product as the features are being built.  QA prepares a performance test and adjusts the navigation scripts and virtual user balance ratio as necessary based on their estimation of the features in that iteration. When the software is delivered, QA often has only a few days to complete testing rather than weeks or months.”

XP (Extreme Programming): “Only the most technical QA Managers and QA staff members will survive in XP.  QA staff must have a working knowledge of shell script, Ruby/Python, and the deployment process, as well as SEO and ad-ops for web software.  QA will usually work entirely open-source in these environments, implementing tools in a “fast and loose” manner as needed.  Changing direction completely is common.  QA must write the minimal set of functions required to provide an automated test bed, code coverage metrics, manual cross-browser testing, and performance analysis and be able to do so in hours rather than days.”

What are your experiences? Have you been locked into a particular SDLC, and how has the QA used matched or deviated from Eric’s perceptions? Leave your thoughts and comments on our blog.