Quality Assurance & Agile Projects: Why Quality Assurance Engineers Aren’t Safety Nets
The principles of Agile Software Development require all team members to take collective responsibility for the different roles needed to successfully deliver a project from concept to completion. This, however, is merely the ideal scenario. In reality—and more often than not—we tend to see specialized roles within an Agile Team such as Back-end Engineer, Front-end Engineer, UI/UX Designer, Database Engineer, Quality Assurance Engineer and so on. This, in turn, leads to a complex process to plan and execute each iteration since not every team member is then able to pick and task any aspect along the process. Thus, collective responsibility is not always possible in this context.
In this article I will explore the function of a Quality Assurance Engineer (QAE) and how specifically their role and responsibility on an Agile Project can be harnessed to deliver greater value, while not needing to deviate from its core principles at any point.
Let’s begin by exploring the core principles of Agile Development: Agile methodologies are built around quality at the centre while everything else is defined around it. This means that delivering quality software is at the core of the process, and each member practising Agile methodologies must take ownership of delivering quality work at the end. To achieve this, Agile principles emphasize the need for Test Driven Development (TDD) and Test First Development (TFD) and encourage automated testing and test coverages at each step of the process.
If testing is automated, one may wonder if there is an actual need for QAEs in the first place. There are many factors and reasons for this conundrum: one being that software engineers themselves are not scientifically trained to do comprehensive quality checks. Further, most software engineers don’t want to put in the time and effort required to master QA since they are more inclined to focus on their core skill of software engineering. This doesn’t mean that engineers are unable to or don’t know how to implement a testing procedure—they simply don’t want to do it. This doesn’t mean software engineers don’t engage in any testing at all. For instance, engineers do unit and integration testing and a lot of the manual testing required during the development phase of a piece of code. But this testing is not likely to be as extensive as it could be if it was implemented by a professional QAE. This is because software engineers need to meet development timelines and need to weigh off the time taken to do comprehensive testing.
There are times when a QAE may not be required. For instance, if the software is not complex, or the software is in a standardized domain, or the engineers are experienced enough to walk a mile in the shoes of their customers, then the projects could function and be completed without a QAE. In my years of experience, I have personally worked with many teams where we successfully delivered large software to customers without the need for QAEs. When the circumstances are different however, it is necessary to know when the Agile team needs to include QAE resources.
When a QAE is present within the Agile team, their actual work testing software only begins after it has been built by the engineers. If we zoom in on that to an iteration/sprint level, it means that within a given iteration the developer needs to complete the code and release the software to the QAE to test it so that the QAEs have adequate time to complete testing before the iteration’s end date. This adequate time must include allocation for any bug fixes as well. The next issue is: how do we keep the development engineers productive while the QAE is testing the current iteration?
I have seen a few strategies used in this regard. For one, at the time of iteration/sprint planning, the team can pick a low priority set of tasks from a future iteration to work on during the time the QAE is testing their current iteration. These secondary tasks are not part of the original iteration so they would code it in a new code branch and not confuse it with the iteration being tested. Another strategy is that the developers spend the testing time to update technical documents such as design documents, technical specs, diagrams, and deployment documents. Spending time on technically grooming the product backlog is also another strategy I’ve seen some engineers implement in order to keep the product backlog 100% clarified and groomed and ready for the next iteration planning.
Whatever the strategy might be, it tends to violate the basic principles of Agile where the resources must spend their entire effort to deliver the committed work within the iteration and without any time to slack off. To overcome this, I have successfully practised setting the expectations of the entire Agile team to not depend on QAEs for the verification of one’s own work. In other words, the team must be confident enough to release the software for a customer review or demo with zero testing by the QAEs. This puts the Agile principles as the guiding force of each team member where they focus on quality in everything they do.
Does this mean the role of the QAE is made redundant in an Agile Project? Certainly not. The purpose of the QAE must be to deliver an added value to the customer by way of testing and finding issues in average-quality software developed and delivered by the development engineers to a level of high-quality software. This means that the QAE will no longer focus on finding faults or mistakes and will instead spend more time on exploratory testing to unearth hidden bugs, especially in corner cases or gaps in the software, or to unearth improvements for processes and interfaces. The most effective way to deliver this value addition has been to let the QAEs test the software one iteration/sprint behind the development. That is, they would focus their exploratory testing on the work that was released in the previous iteration during the current iteration’s coding while also spending time preparing test cases and documents for the next set of features to be tested in the coming iteration. By employing such a QA strategy in your Agile practice, you will be able to deliver greater value through the Agile team. Additionally, this enables the creation of a working culture where each person takes ownership of the quality of their own work to the best of their ability. This will also eliminate the notion among team members that there are other members hired to check anything that the developer may have missed, thus enabling them to be less accurate. Further, from a client’s standpoint, it makes sense to pay for QA resources since they know the resources will deliver value additions to the software rather than merely checking whether the development engineers did the work right. While there are specialized hires within an Agile team, it is essential that each player understands the subtle differences in their roles to enable total quality in the final output.