Team as a Key to “Agile” Quality

I remember we once had a feature we needed to release “yesterday”. It felt impossible to me — I knew we won’t have enough time to perform proper testing. I practically dreamed of having one more QA engineer that day on the team. We did have a rather mature testing process that on many occasions saved us from many bugs in production. But our team was committed to release on a specific date, so following a good process was a lower priority.

After some time we did hire one more QA. Was it easier now to release urgent features like that? Yes. Was it good enough to do all of the planned activities? Still no.

Eventually we found out that the problem is never about having more resources on demand, but about training current employees to adjust to a needed velocity. So we decided to build a team approach to quality.

Why should you care even if you don’t release 10 times a day?

There are multiple benefits:

1. Avoid making QA a bottleneck
2. Being able to quickly adapt to needed velocity
3. Finding bugs early

We can often see a trend — the earlier you start your QA, the less bugs you will eventually have. And my main point here is that if you want to “shift quality left” (perform testing earlier in the lifecycle) it doesn’t mean you need your QA engineer to do everything — test requirements, test early with dev, write automation, etc. You will never have enough time and it will become an even bigger bottleneck.

Instead, you can approach the whole team to contribute to quality within their own responsibilities and eventually move faster. I want to show you how we did it in my team in 6 steps.

Step 1: List all the human resources you currently have

All teams are different and have their own specifics. In Wix, for instance within the same company (Wix is structured to have separate companies within one business) we can have: a 1:10 QA/Dev ratio team, Dev only team, or a team supported by “service” QA(s) on demand.

And it is not only about Dev & QA, you might also have UI/UX designer, BA, Support, Localization team, and many other useful people adding to your product.

All of the above can be meaningful pieces of your product quality. So let’s start by drawing all of them.

Picture 1: Human/Team resources

Step 2: Brainstorm quality activities you want to have

Imagine your perfect day — you have infinite time and resources to do everything you need for assuring high quality of your product. What would you do? You can think of missing phases in your dev cycles, test types you’ve always wanted, some tech debts or “back burner wishes” in your backlog. Try to brainstorm those things with your team — a small trick to start involving them into your future process.

Here are few examples:

1. Requirements testing
2. Functional feature testing
3. Exploratory testing
4. Cross Browser tests
5. Unit tests coverage
6. Support tickets investigation

Another place to find ideas is to analyse current issues. You can get them from team meetings, like retrospectives, and from production data (i.e. analytics, support tickets users reported, etc).

Examples:

• Devs sent features to QA that were found to be buggy? -> Lack of early testing by developers
• You always have localization bugs users complain about? -> You need to perform proper localization testing
• Questions around requirements appear as you’re already doing testing? -> You need to “challenge” your requirements very early

Eventually you will have a complete list of actions needed to be done to assure quality of your product.

Step 3: Visualise what every role will do

In my experience, people with various roles can take part in assuring quality even without learning testing best practices. Developers can test agreed scenarios, UI/UX designers can easily test UI on most important resolutions, and the localization team can make sure all links on, say, an Italian page lead to relevant italian resources.

So now, let’s map quality activities from the previous step to your team resources.

Things to keep in mind:

1. Some of the activities can/should be done in collaboration
2. Amount of resources matters, don’t put all the stickers to the “half of a designer” you have available.

Picture 2: Mapping quality activities to team resources

I must admit that I totally understand the difficulty of convincing developers to test their code, or UI/UX designer to do a cross browser check. Or to explain to the manager that quality now is not just QA’s responsibility. Especially if they don’t feel the problem like you do after you’ve tested at night at the end of a sprint.

Moving to a new process is a matter of change management, which is a bigger topic I plan to cover in detail in my future articles, but for now I want to give a few tips that can help:

1. First of all, don’t be afraid to say “we have a problem here” and be ready to elaborate on it
2. Best way to convince your manager is to show how process issue affect the “money and business” side of your product
3. Use numbers as arguments, i.e. “I’ve spent 10 extra hours testing & returning builds with blocker issues that devs could identify in 2 minutes of them testing”
4. Find a few people in your team that support your idea, the best bet would be to pick “influencers”
5. Start from tiny changes that bring big value and show what impact they would have to prove your idea
6. Do not forget about celebrating small wins to build stronger acknowledgement

Step 4: Pick a person to monitor

Once you’re done designing your approach, you’ll need to select a person to keep an eye on it. This person’s focus will be on coordinating, rather than executing, and for sure the most natural choice is your QA engineer.

It doesn’t mean they will stop doing their tasks, definitely not, they are still the most qualified and skilled person in the class. But they will need to make sure that all activities selected are actually done, measure that your approach really works, and constantly improve/adopt it for future features.

Step 5: Test your approach on an upcoming feature

I would suggest one more step to make sure you don’t have a bottleneck. Pick your current or upcoming feature, draw SDLC for it, and put your quality activities there. Remember to keep the balance and don’t try to shift left too much, because you might create another bottleneck.

Picture 3: Quality activities mapping to SDLC

Step 6: Review and improve

Cities are not built in a day. And it is extremely difficult to build a good process on the first try. We tried to iteratively do analysis and work on improvements. Be ready to work on it continuously and your effort will pay off in product quality.

Picture 4: Quality process review & improvement

Results:

I want to be honest, it is hard to convince people that they need to spend their time on “not their responsibility” — it is a matter of change management practices to switch their opinion. But once you do change their minds you see it was all worth it.

In my team it gave us more than just less bugs in production. Nice free of charge side effects we’ve gotten with such approach include:

• Quality-oriented culture across the team
• More trust between people
• Your only QA can easily go on vacation and sleep well there
• You stop blaming a specific person for bugs in production
• Every team member is more involved with the product

The last thing I want to add is that you don’t need to be a “Top Manager” to move your team to this process. Start from small changes on your end and in a few months you will be surprised in a good way.