Quality assurance (QA) has always been a vital part of software development. Without a tester or two (or someone who will be doing the testing but doesn’t like labels), there can be no software development team.
QA is quite different in the Agile environment than it's in the traditional one. With that in mind, let's have a look at QA in Agile project management and exactly how tricky it can actually be.
How QA differs in both methods?
Traditionally, QA role in software development has little to do with involvement in the project itself. Testing teams are separated from the development teams and they perform their tasks at the very end of the project.
In other words, once all the coding has been completed by the development team, the testers get the code and the requirements documentation so that they can build and execute test cases that will ensure that the code itself is performing as stated in the requirements document. If any serious bugs are found during the testing, the code is sent back to the development team and the process starts all over again.
On the other hand, within the Agile environment, QA teams get an entirely new set of responsibilities and roles. As an example, Agile QA teams are self-organizing and cross-functional, which means they work closely together with the development teams. QA teams work together with everyone else on every aspect of the project development cycle ranging from conversing with the clients and analyzing their stories to ensuring that the best possible product is delivered to the client at the end.
What are the roles of QA in Agile?
As mentioned before, QA has a wide variety of new roles and responsibilities in the Agile software development and project management. These roles are not assigned to QA members by anyone. Instead, everyone does a bit of everything, in order to contribute to the greater good, i.e., the successful completion of a project in every sense.
Simply put, if you're wondering where do QA members fit in, the answer is in the entire process. In other words, QA members are not just responsible for writing test cases and testing the code. In fact, the scope of their role goes far beyond that. Therefore, here are a few examples of QA roles and responsibilities in the Agile project management.
- Analyzing inputs from clients, stakeholders, end-users and everyone else involved in the project.
- Revising user stories, such as requirement generation, out of scope stories, missing stories, etc.
- Consulting on functionality aspects with the developers.
- Viewing the product from both user and client point of view.
- Building automated test cases, regression testing and acceptance criteria.
- Consulting on sprint development, duration, requirement development, especially in Scrum project management.
- Ensuring that functionality features do not impact other features in a negative way.
- Minimize and mitigate risks.
In retrospect, QA members are more focused on ensuring that bugs don't even get to the development process, to begin with. In order to ensure the best quality product is developed, QA members must be involved in each and every aspect of the project.
Where's the tricky part?
The tricky part is where QA members divert from their traditional roles towards Agile practices. As mentioned before, QA had a specifically designed role in the waterfall method whereas, in the Agile environment, their roles and responsibilities exponentially increase, oftentimes tenfold.
It can be tricky for QA members that have worked in the traditional environment for a prolonged time to adjust to their new environment. In most cases, this adjustment period involves learning new skills and changing the very mindset of a person.
This process is challenging to say the least. The adaptation would involve new communication skills, involvement in-so-far unknown process and practices, developing collaborative thinking and many more. Traditionally isolated QA teams have a lot on their plate when changing to Agile methodology. In other words, Agile environment expects from QA members to know ins and outs of an entire project quite well, which can be daunting most of the times.
How to make it seamless?
The main reason QA members in Agile project management have so many roles and responsibilities is that the entire purpose of the Agile methodology is to deliver the best product possible to the client or user. Therefore, QA members that are initially responsible for ensuring that the product itself matches the quality that needs to be delivered, must understand the product, its requirements and its architecture quite well. That's why QA members are involved in each aspect of the project and they work closely together with everyone to make proper recommendations and test features accordingly.
However, you simply cannot drop a load of responsibilities onto a person and expect them to perform exceptionally. As a matter of fact, you need to implement a training process that will enable either new QA members or those that have worked in a traditional environment for too long to learn new skills and adopt the Agile mindset. That's the only way to make the entire process less tricky and more seamless.
Still, that begs the question of why must QA do all of that in the first place? The Agile environment doesn't assign roles. Teams have the liberty to govern themselves and organize themselves to get the job done. On the other hand, project managers still have to oversee the project and the teams to give them the best possible conditions to work with while also focusing on other tasks, such as budgeting, attending meetings, prioritizing backlogs and so on. While developers could test their own code, they oftentimes choose a "happy path" and focus on writing the code exceptionally. That leaves QA members to pick up the pace and ensure that the product is being developed with the client or user's best interest in mind.
Although the roles of QA in Agile project management may seem demanding and tricky to put it mildly, they are, however, vital to the success of the project. Without QA members, the Agile software development would resemble anything it does today.