QA Challenge #7: QA's Role in an Agile Environment

 Email Article  

Tweet  

  

Are you a QA analyst/tester and feeling unclear about your role on an Agile team?  Are you doing less than what you might expect? Or are you being asked to do more in less time?

If you answered yes to any of the above questions, your experience is not unique. The impact of Agile on any team is huge. An Agile environment requires you to shift into a new role—a new way of doing things. As a QA tester, your role is extremely important to an Agile team and a misunderstanding of this role—or any role, in fact—in an Agile team could lead to failure or less than optimal results (or low ROI).

One key difference is that Agile focuses on communication and collaboration more so than processes and tools. It doesn’t mean there isn’t inherent value in processes and tools– Agile has its own tools, but they are less formal. For example, as a test deliverable, I would recommend using simple scorecards as a communication tool instead of detailed test plans and test reports.

Second, if you are feeling pushed to deliver and you are unsure if you should be focusing your priority on quality or time, then you should know that Agile teams generally focus on the quality of the released product—not just faster delivery.

So as a tester you need to get actively involved in planning meetings, estimation and daily meetings to help the team build the right expectations, understand what can be done in what amount of time and then share your daily accomplishment, plan and obstacles. The planning and estimation is done by the doers (designers, developers and testers) in a less formal way as opposed to management who would do formal plan and dictate the terms in traditional project. (The management plays a different role in an Agile environment)

Another key difference you will find in an agile environment relates to unit testing and test-driven development. Perhaps the most common complaint I hear from testers is that unit testing is not being done by the development team.

Why is this a problem? Well, it quickly becomes a source of frustration when a tester feels he or she is continuously testing builds that do not have some quality built in.

So what’s the solution? I suggest helping your developers unit test their code—create checklists, a simple metrics to know how much is done, and then help them think of other tests that they could use as scenarios to handle in their tests. This will force you to think of tests other than what developers have covered (removing duplication) and allow you to automate your acceptance or smoke tests or regression tests that you use for each release or build to test. Remember, automation is key in Agile, whether it’s build process or your own tests.

The idea of Agile development (in sprints) is developing working software–defining what it means is extremely important. What are the criteria to say what we planned is done (e.g. complete stand-alone functionality, zero critical defects, etc.)? A tester can play a key role by bringing in the customer perspective.

All this requires you to be dynamic and flexible. New skills will need to be developed over time. Agile is iterative and incremental with a focus on continuous improvement of processes and methods. I would suggest taking a lead here as well. Work with your scrum master and focus on how you can optimize your job—communicate, collaborate and automate.