(508) 250-0159
The focus of Agile developers tends to be delivering “customer-ready” software by the end of every sprint.
I’m all for that of course. Delivering usable software by the end of a sprint is one of the core differences between Agile and waterfall processes.
With that said, bringing usable software to a sprint review is quite different than delivering a complete product to the customer.
How Does QA Fit Within Agile?
Looking at the overall development process, the real question is this: where do the quality folks fit within an Agile framework?
When we think of Quality Assurance (QA), we’re used to “throw it over the wall” testing in a waterfall process. Typically, QA is a separate organization kept in the dark until it gets close to shipping time. Then, they are in the spotlight and everyone asks, “When’s it going to be done?”
In my experience, waterfall-style QA is inefficient, has longer turnaround times or worse (and quite common), it risks releasing unfinished products just to make the dates. This happens for the same reasons that waterfall is inefficient in general:
- It’s easy to have miscommunications when a product is handed off between teams.
- It tends to cause unplanned rework for the development team, who have often moved on to other projects.
- It causes teams to have longer wait times on dependencies from others.
- It creates silos and discourages open communication between teams.
Reframing the Problem: Quality Engineering (QE)
The way to resolve these issues is to embed quality engineers on your scrum teams.
Embedded quality engineers can still report to supervisors in an official quality organization, department or community, but their daily work will happen side-by-side with developers and the other scrum team members.
The Benefits of Embedding QE on Your Scrum Teams
The job of an embedded quality engineer is quite different than traditional QA positions.
Quality engineers act as internal police officers, helping the developers stay focused on making software that meets the needs of their customers and will run well in their customers’ environments.
Quality engineers’ most important jobs are:
- Guide the team on feature and acceptance test strategies, and proper use of the test automation framework.
- Develop and maintain test automation, APIs, framework and infrastructure, which includes coaching developers to write automated test cases that fit within the pre-established guidelines.
- Help prevent “scope creep,” and ensure developers stay aware of limits, scale, performance, security, environmental constraints, testability, and all serviceability criteria.
The development of automated testing tools is perhaps the biggest difference between embedded QE and traditional QA roles.
For example, if part of your software includes a field where a user types his or her name, the QE team member’s job is to write a tool that will test every possible variation that might be typed into that box.
The test will need to look at American names, Japanese names, middle names, names with unusual characters or number of characters, hyphenated last names, upper/lower cases, etc.
By doing these tests within the sprints, and re-running these tests on subsequent sprints, the embedded QE team members empower everyone to prevent defects from making their way downstream, significantly reducing 1st and 2nd order defects, especially regressions.
Bonus: When the embedded QE folks are doing their job correctly, they help keep both quality and velocity high.
Embedding QE Doesn’t Mean You Completely Scrap Your Old QA Department
At some point, someone needs to run the finished product through a series of tests in a customer-like environment.
This is the traditional role of QA, and it’s a role that doesn’t go away, even in an Agile framework.
The most successful product releases, with respect to quality and timeliness, are the ones where the quality engineers are embedded on Scrum teams and a separate QA team—using a Kanban approach has thoroughly tested the product in a customer-like environment.
A New Job Description for Embedded Quality Engineers
As you can see by now, the role of “embedded QE professional” is actually a completely new role within our companies. QE professionals may report to a QA manager, but these quality engineers need different skills than traditional QA employees to be successful.
In the past, QA employees worked in their own department, reporting to their own managers, and mostly used “manual” testing to validate software.
Embedded quality engineers must be more collaborative and work hand-in-hand with developers. They also need strong coding skills, since a major part of their job is creating tools for automated testing.
Unfortunately, many QA professionals have never developed these skills. They’ve never needed them before.
In most cases, you’ll need to train your current QA staff, or—where that’s not possible—hire new employees to fill in the gaps.
The Old QA/Developer Ratios Are Meaningless
For years, business consultants have made a living determining ratios that told us how many QA employees we needed for every developer we had on staff. Some advocated for a 2-to-1 ratio of Developers to QA professionals. Others argued for 3-to-1 or 4-to-1.
As I hope you can see, this is antiquated, waterfall thinking, and meaningless now.
It’s not about ratios anymore. It’s about keeping quality and velocity high. If your overall cost of doing business is still too high, then maybe you should look elsewhere for your cost-cutting savings, including possibly rethinking your market or business model.
The End Goal
For whatever reason, QA within Agile is a topic that doesn’t get enough attention until either something painful happens or the Monday morning quarterback shows up with the latest article on why QA teams are not needed. Good intentions, highly idealistic, and too far from reality.
You’ll need strong leadership and good metrics to make changes like the ones I’ve outlined here.
Have an story to tell about QA in an Agile environment? Send me your thoughts and stories.