Agile Quality Assurance
From MIKE2.0 Methodology
-> You are here: Agile Quality Assurance
This article on Agile Quality Assurance will describe the process and the practices used by QA Analysts on agile development teams. QA Analysts typically, unlike in normal IT development project teams, are not measured against how many defects they raise and instead focus on improving the quality of the application by engaging very early in an interation's process, often teaming with analysts during the analysis phase.
Since agile is an adaptive methodology, the practices and the process described in the article should be used as a good starting point to be later tuned, improved and evolved in any way that adheres to the agile values and improves team's productivity, collaboration and communication.
This article is a part of the Agile Business Transformation article series and as explained the ABT practices enable feedback and hence continuous improvement, and the Agile QA Analyst's should be very involved in these feedback practices so to give their input into how the QA team and the overall project team can improve and perform better - hence via the ABT practices such as retrospectives and stand-ups the Agile QA process is continuously adpated and improved.
Fundamental Differences between Agile QA and usual 'Software Testing'
Agile QA Process
The diagram above shows the Agile QA Process in relation to the overall iteration cycle. One thing should stand out, the testing (Acceptance and Regression Testing) happens during development unlike in more waterfall, incremental or spiral development methodologies. While developers write the code to complete a user story, the testers write the acceptance tests to test the user story. When developers are finished the testers carry out the acceptance test on the story. Finally when all acceptance tests are completed the testers update the regression test suite (only a subset of all the end-to-end tests) if necessary and after they always execute the regression tests (which should be automated) hence to finish when the development finishes. Also notice the QA Analyst's involvement in Business Analysis for the following iteration.
Agile QA Practices
Writing Acceptance Tests
Acceptance tests must:
Automated vs. Manual
In author's opinion acceptance tests should always be executed manually at first as the QA Analyst is the best for testing the quality aspects of the user story which testing tools can't test. After the acceptance test are carried out manually at first and the QA Analyst identifies it as a core end-to-end test (e.g. publishing an article in a CMS) then this test should be automated and made part of the regression suite of tests. Hence all the acceptance tests that are automated become the regression suite of tests.
From a quality assurance perspective, regression tests are integration tests that ensure the system is still doing what it used to do with the new functionality upgrade that came with the completion of the last iteration. They should be completely automated as they are of very repetitive nature.
Ideally all acceptance tests after an initial manual execution should be automated and become part of the regression test suite. However this ideal scenario is not usually done because:
Therefore good regression tests should:
Business Analysis and Requirements Audit
The QA Analyst on the agile team is, just like the whole team, focused on the team's goal - to develop a high quality application. The business analysts analyse what it needs to do, developers question what it needs to do and then write the code to do that, the QA Analysts/testers then have to assure the business stakeholders that the application does what it needs to do but they also have to question what it needs to do and help define what it needs to do.
The justification for the QA Analysts involvement in analysis, as a requirements auditor, is because of the vast and usually superior knowledge they develop of the application to anyone else on the team. The QA Analyst is always, during testing, being reminded of what the application does, how it does it and why it does it - the QA Analyst is always during regression test and end-to-end acceptance tests being reminded of existing functionality, relationships and dependencies. The business analysts don't have this knowledge reinforcement and are always pushing forward for defining new requirements which they remember but don't revisit again unless things change around the existing functionality. Hence the QA Analyst is a requirements auditor, whose superior input of what the application does now in the analysis phase will help define the least costly approach to delivering new functionality and ensure the requirements are also being assertively viewed early.
Testing Automation Tools
There are two approaches to automated functional testing: graphical user interface testing or code-driven testing. The testing tool that uses GUI testing automates the GUI interaction and testing validation is done on the responses of the GUI. The testing tool that uses code-driven testing calls public methods from libraries of the software application being build and then validates the returning values of the methods against what they should be.
Selenium (GUI driven) and FIT (code and script driven?) are two widely used automated functional testing tools. There is also the IBM's Rational Robot which is a heavyweight but extremely exhaustive testing tool. For performance testing there is also JMeter.
Regression testing should involve both functional and performance automated testing as regression tests will be repeated many times, every iteration, so this process must be automated.
Wiki asset search