Defining the Role of the Agile Quality Analyst
The third installment of the agile roles series looks at differences in the work of the Quality Analyst in an Agile environment.
The Quality Analyst (QA) role in an Agile environment has significant importance. In Agile, the QA is part of the development team and included from the start of the project. QA is expected to be as up-to-date on requirements and system state as any developer. QA is also continuously reviewing completed tasks and stories to near real-time feedback. If there is one concept in Agile it is fast and continuous feedback on all fronts, QA is essential for this to become reality.
When running a mixed Agile/Waterfall development environment it can be difficult to engage the QA resources at the correct moment. Generally QA is accustomed to having some large period of time, say six weeks, at the end of development where they test the entire system. The argument for this type of testing is that at this point the code is “locked down” and thus they can test the system in peace (not pieces) without worrying about pesky developers changing things on them. While this is a fine notion, it rarely happens and development often runs over the QA cycle. Or, more importantly, QA finds issues that simply must be fixed. In standard QA parlance, the QA team should start their testing from scratch after the changes are made to the code.
Agile QA
Agile has the idea of production ready functionality at the end of every iteration. To do that, QA must be involved at the iteration level and be testing functionality as it develops. If done correctly, at the end of the iteration the stories and components are ready to deploy to production. Thus, unless major changes occur, these items only need regression testing from this point forward.
Embedded QA
Since QA is part of the development team, they are often co-located with the development team as well. This gives the QA person a significant advantage, they are present when requirements changes are taking place and can express their opinions in real-time rather than after the fact. The QA person can also help refine requirements by providing the customer’s view of the application.
Automated Testing
Once components are production ready, automated test scripts are created to compile a full suite of regression tests. These automated tests combined with the developers Unit and Integration tests help ensure that any changes made during the current and future iterations do not adversely affect the previously tested code.
Deployment to Production
As with any project, the final push to production is often a hectic and hurried endeavor. QA is usually under pressure to certify that the application works. While Agile projects are sometimes (but hopefully not) just as frenzied, the existence of thoroughly tested components, automated QA test and development unit tests help ease the burden on the QA team. While a full system test is still advisable before deploying to production, since QA has been involved from the beginning and is aware of all requirements modifications that have occurred throughout the life of the project, this task is not as onerous as in non-Agile environments. There is not a lot of back and forth between QA, development and BAs about requirements changes that were not adequately documented.
Often times the true QA cycle, where code is “frozen”, can be cut down to one to two weeks as the QA team feels very comfortable with where the application is at when the cycle begins.
