It can be easy to assume that a QA’s role is always the same, no matter what sort of project they’re working on. But as it transpires, as dev teams transition towards Agile working practices, the role of the QA undergoes some important shifts. In this blog, I’ll explore those shifts and demonstrate how the QA can continue to add value to their projects as the team becomes more Agile.
One of the most common features of anAgile transformation or adoption, is the pursuit of shorter delivery loops. However, this not only changes the development process and technical tools in the team, it also changes the role recognition and work responsibilities.
In this article, we are going to describe a typical transformation path and explore together how the quality roles evolve from the traditional test engineers and are continuously evolving during Agile transformation.
Role recognition
For a team that’s yet to adopt agile practices,, you might expect them to follow models of software development such as Capability Maturity Model Integration (CMMI). With such models, the quality function might fall under a number of roles, such as:
Manual test engineer
Automation test engineer
Special test engineer (ex: security, performance or accessibility test engineer)
Test manager
One of the big changes you’ll see as the team begins its agile transformation is the shift from being a functional team to becoming a product one. Like any new team, you can expect to experience a sequence of changes outlined in the Tuckman team development model. The sequence is: forming, storming, norming, etc. Let’s analyze these periods from the perspective of quality. You’ll see that there are QA roles associated with each stage — although each is subtly different. We’ll explore those differences in the next section.
Forming
During this period, manual testers and automated testers are mostly separated, even special testers participate part-time. Although the team’s delivery cycle may be shortened to two or three weeks, the overall delivery is in essence a small waterfall, and the time taken is slow. Manual testers and automated testers are not able to collaborate seamlessly because they have different goals: one might look for the number of defects and the other for high automation coverage. Under such circumstances, it is imperative to unify quality control into one role. This is where the role of Quality Assurance gets created.
Storming
With technical optimization and team collaboration, team efficiency should increase. The QA role is responsible for quality and the testing scope is greatly expanded. A QA may worry that cards which are “ready for QA” stack up quickly and then testing becomes a bottleneck — i’ve seen this happen regularly where teams have six-plus developers but only one QA.
This then raises a few questions:
How can we design our tests more accurately?
How can the team learn from existing defects?
How can we proactively prevent defects from occurring?
Thinking about these questions and driving them down to solutions and practices gradually makes QA evolve to a new layer: Quality Analysis.
Norming
Agile teams are all about continuous improvement. How can we better realize the pursuit of quality? How can we further shorten the project feedback cycle? The norming period is not only to optimize the development process, software tools and team communication, but also to simplify complexity. Less is more and, in terms of quality, we highly recommend that the team looks to gather quick feedback on each output gain from activities in the middle of iterations before the releasable code is produced. This is the standard set by the more mature QA — Quality Advocate.
Work responsibilities
Some people may think that no matter what kind of QA, those letters don’t really matter, we could even consider QA to mean ‘question’ and ‘answer’, since QA’s do a lot of this!
However, to get a better understanding of the differences, we can think of QA as wearing three hats.
Quality Assurance
This is the unification of traditional quality roles. This type of role thinks about quality from the "point" of a specific test execution up to the "layer" of test design and execution. Below, we can see how a Quality Assurance is expected to behave:
Test case design
Testing execution
Bug tracking
Cross functional testing
Test coverage
Test strategy design
Test efficiency improvement
Quality Analysis
On the basis of quality assurance, let’s add some dialectic thinking: how can we improve quality more effectively based on business value, and drive the direction of QA work from quality detection to quality improvement? In this way, the QA role moves out of the scope of an independent role and rises to the layer of team influence, as described below:
Business-value-driven testing
Precise testing
Layered automation implementation
Bug statistic analysis
Delivery efficiency improvement
Project risk foresee
Quality Advocate
When it comes to Quality Advocate, QA has a more prominent impact in the team comparing other hats, just like a quality evangelist, encouraging all roles to think about quality throughout all activities in work, quantifying the team’s continuous improvement in quality management, committing to transforming built-in quality into the team’s genes, and incubating new quality practices to adopt at the right time. Detailed work items described below:
Process improvement
Shift-left testing
Shift-right testing
Quality built-in mindset promotion
Quality management maturity evaluation
New innovation over project quality
Conclusion
From above, we know how the quality role is evolving as a team becomes more agile and how quality members identify their position in QA work.
You may think that the three hats of QA have a gradual relationship, actually they do not. They are three different hats (like peaked caps, top hats, and helmets), and Agile QA chooses a suitable hat to wear on different occasions. Only by treating automation testing as the cornerstone of efficiency, broadening the test coverage of quality assurance, precisely optimizing with quality analysis, advocating the quality in culture, and then we create a mature agile QA.
To end, the take-away of this article is, by running a quality role in an agile transformation project, you can adjust the quality work focus based on agile maturity of the team and be active to wear a proper QA hat in various occasions to contribute more in project quality and efficiency, assisting the team to achieve a shorter delivery loop.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
