Best Practices for Integrating QA into Agile Development Teams

Making Your QA as Agile as Your Development

As the old saying goes, I’ve seen a thing or two while working with more companies than I can reasonably count. There is a perpetual struggle with integrating QA into agile development, and the struggle is real.

The notion of agile development is far from new, and I am sure that anyone who has spent any time moving between companies has seen “agile” being interpreted to suit the needs of each business. One thing often remains true though, and that the quality assurance component often feels like it doesn’t fit in well.

What do I mean by that?

Well, we have a fairly well-established process where sprints are planned, stories and tasks are pointed, the tickets are refined, and then the sprint is off and running.This is all pretty standard fare in the Agile SDLC.

Where I see things go wrong in many cases, is what happens to the QA.

In a two-week cycle, QA often doesn’t see much happen in the first week of a sprint, as very little code gets dropped for feature testing. The second week happens, issues start to trickle in, and then that trickle becomes a downpour. We see the QA team being placed under pressure to get testing done and push code out the door in two or three days of the cycle.

The net result of this state of affairs is a stressed and pressured QA team, and stressed and pressured people are going to struggle to turn in their best work. Bugs can be missed, issues get into the production code, and suddenly customers and product owners are facing the woes of a rollback or hotfixes.

QA Doesn’t Have to Be a Fire Drill

With some decent structure and some pragmatic planning, things can be quite different. I’ve helped teams craft a different strategy that serves their QA needs and has a net result of better products with higher customer satisfaction.

Let me be clear, though: Some of the strategies I’m going to suggest will need some fine-tuning to suit your SDLC. As I mentioned previously, various companies nuance what “agile” means, which means improvements in your QA integration might need their own refinement. We can help with that, of course, but let’s get on with some practical hints.

Agile Kanban

This SDLC type is often attractive to folks who are trying for true CI/CD, and we might as well knock it out first because it is the simplest form of agile to tune for QA. First and foremost, the entire team needs to get on the same page about the net result: The practical order includes QA from the beginning.

Here is the basic outline of a solid integration of Agile into QA:

• A business analyst or product owner defines a feature, task, or story
• QA should immediately review the ticket to assess the acceptance criteria (you may get tired of hearing me talk about acceptance criteria, I warn you now)
• QA and business analysts refine the acceptance criteria to remove ambiguity
• Development reviews the ticket and works with QA and the business analyst if they need clarity
• Developers begin writing code, while QA creates the test cases based on the acceptance criteria
• If test automation is in use, the developers and QA engineers can work collaboratively so that the automation test is developed as a parallel track to the development code
• Developers drop code and QA tests the functionality in a controlled environment
• Developers and QA iterate this process to remediate bugs and finalize any test automation
• QA and the developers demo the code to the business analysts and product owners
• On approval, the code is deployed and validated in production
• As can be seen from this process, QA is working in harmony with the developers, and all of the stakeholders are in a continuous communication loop to ensure the feature goes out the door with thorough testing pre and post-release.

The key here is communication. The biggest thing that I’ve seen go wrong for QA is for them to be blindsided by the ticket being assigned to them.

When QA arrives late to the party, the dev may already have put in significant code and potentially introduced bugs that would have been avoided had the QA team worked out those pesky acceptance criteria before code was written. This is pretty easy to solve, like many things, with proper and timely communication!

Agile Scrum

I’m going to use this one as a bucket for every flavor of Agile development that isn’t Kanban. In the intro, I talked about the problems with typical Agile. The biggest deal here is giving the QA the time they need to do their work. I’ve got some practical strategies to solve this, so let’s go over them.

The first solution, and likely the most obvious one, is to have QA run an offset sprint cycle. Essentially, QA runs regression testing in the first week of the development sprint. This frees up QA to feature test and finalize test cases for features in development in the second week of the development sprint. They then run through the regression test after all the code has been dropped.

This can be optimal when we are looking at complicated integration testing that individual feature testing might not expose. This method is also highly effective for products that have a large amount of legacy code that is a little more fragile than anyone would care to admit!

This method tends to give QA plenty of time to test, refine ticket acceptance criteria (yes, I said it again), and test without being rushed or compressed. There is the negative aspect that to get this going, you might not be able to release at the end of the development sprint, but I’d argue that it is infinitely better than having to deal with hotfixes and rollbacks.

The second approach is going to be around the use of test automation. Yep, I know some of you saw that coming from the back of the field.

The cost for automation is high, but if your team likes getting feedback fast from QA, and you like having confidence when you release, there really is no substitute. Through the use of test automation, we can free up manual QA from the bulk of tedious (and essential) regression testing. We can take those agile minds and apply them into the SDLC where fresh minds can produce excellent results.

People who aren’t stressed can apply all of their brainpower to focus on those (here we go again) acceptance criteria, writing detailed tests, and hammering those new features in detail.

Automation engineers are constantly fed from the backlog of development tickets as they are produced. If you have enough of those engineers, your test automation coverage doesn’t have to lag more than a sprint behind the development sprint.
If you’ve got the budget, the investment can be rewarding.

Need Some Help Integrating QA into Agile Development Teams?

Some of this can be overwhelming to implement, and sometimes you need an advocate and help to get your team sorted out. We can be that advocate and support. I said this earlier, but I’ve been around this company a long time, and my team and I have refined more QA processes than a typical QA manager would handle in 10 lifetimes. That isn’t bragging, it’s just a fact about what we do.

If you need that help, we’re here for you. Let’s chat.