Transcripted Summary
There are some challenges I've heard over and over again from different teams. One of the biggest problems are bottlenecks.
Some roles seem to be prone for that, like product owners, or UX specialists. Or if you only have one frontend developer in your team and in our case, it's often us as testers.
If only one person knows how to do something, you have a bottleneck. This is often the case if you only have one tester on the team and the developers don't want to test. If your work flow includes a "gate" and only one person can solve it, you have a bottleneck.
Even if you have a team of full-stack developers, well they might pull new tickets on free capacity and, in the end, these tickets will pile up. This is just adding to work in progress and therefore waste. Doesn't help anybody. Instead of starting lots of things, it's about delivering value to the customer in the end.
Now, if you're acting as a gate and you're working on more than one team, the situation gets even worse. If your infrastructure is limited, for example if you can only deploy to a common staging system to test the change, you have a bottleneck as well.
Let me tell you a personal story…
Sometimes teams have to feel the biggest pain before they try something new. I experienced this case of being a gate myself and the situation became even worse when I started on my second team. I soon discovered these are two full-time jobs and, in addition, I substituted our product owner during his five-week vacation. Now the bottlenecks became really obvious and really painful for both teams. The consequence was I was only rushing after tickets. The quality decreased, there was no time to think, no time left for creativity or innovation. No time to work on company topics as well. To contribute in a different way.
When the teams felt the greatest pain, it made everyone realize that our way of working did not work out.
We were not able to deliver value to our users quickly anymore. Just created more useless inventory, increased waiting times and so on. Everything took longer. Both teams admitted that we needed to adapt. Now let's take one step back and have a look at definitions first.
# How is agile testing actually defined?
Here's what Lisa Crispin and Janet Gregory write, based on feedback from the community:
Quote
Collaborative testing practices that occur continuously, from inception to delivery and beyond, supporting frequent delivery of value for our customers. Testing activities focus on building quality into the product, using fast feedback loops to validate our understanding. The practices strengthen and support the idea of whole team responsibility for quality
The definition is expanded by the following points to illustrate this meaning:
Building quality in, means teams focus on preventing misunderstandings about feature behavior, as well as preventing defects in the code.
Guiding development with concrete examples, means using practices like ATDD (acceptance test driven development, BDD (behaviour driven development) or SBE (specification by example).
Testing activities include, but are not limited to: conversations to build shared understanding, asking questions to test ideas and assumptions, automating tests, performing exploratory testing, testing for quality attributes like performance, reliability, security, and learning from production usage.
The whole team uses retrospectives and small experiments to continually improve testing and quality and find what works in their context.
Sounds familiar to what we learned about continuous testing? Well, indeed it is.
The whole team approach says that your responsibility and ownership for quality and testing should be shared.
Lisa Crispin and Janet Gregory promote that idea a lot. In their book Agile Testing, they describe the whole team approach as one of the biggest differences in agile development, versus traditional development. They say:
Quote
The focus of agile development is producing high-quality software in a time frame that maximizes its value to the business. This is the job of the whole team, not just testers or designated quality assurance professionals. Everyone on an agile team gets ‘test-infected.’
They continue:
Quote
An agile team must possess all the skills needed to produce quality code that delivers the features required by the organization. While this might mean including specialists on the team, such as expert testers, it doesn’t limit particular tasks to particular team members. Any task might be completed by any team member, or a pair of team members. This means that the team takes responsibility for all kinds of testing tasks, such as automating tests and manual exploratory testing. It also means that the whole team thinks constantly about designing code for testability.
They sum it up, saying that:
Quote
Everyone involved with delivering software is responsible for delivering high-quality software.
Quality and testing is a shared responsibility — the whole team is responsible for the end product.
To do so, you need to let go of being a quality gate. Don't let fear hold you back here, because you might fear losing the unique reason you are on the team. Why you get paid, right? You might think that if you cannot be replaced then you cannot be fired. But let me tell you this, your job is to enable the whole team to deliver a quality product, which is a valuable product.
To apply a whole team approach you also have to get the buy-in of the whole team and sometimes this does not work. You have to pick those people with whom it works. If you find these allies, they might then trigger others as well. You can start a movement.
Another benefit of the whole team approach is that this way you can increase the "lottery factor". Because think of it, what if a person won the lottery and quit working? What's the minimum number of team members so that the show can go on?
Thinking this way really fosters team spirit. It's easy and stress-free to go on vacation like that because imagine when you return to work you can pick things up where they are, not where you left them. Sounds great, doesn't it?
Have everybody contribute - where they provide value and support other's actions for a team approach as well. Like a programmer asking great questions upfront. Or asking for support regarding unit testing. They might also review test automation code for quality. Or a product owner might ask a tester regarding a new feature idea. That's great!
Let me continue my personal story…
When everyone felt the biggest pain, we agreed to try the lean approach of "stop starting, start finishing".
We implemented a rule. We agreed that it was not allowed to pull any new tickets in, before you really were not able to contribute to items in progress anymore. And sometimes not even then — just to not increase the workload and make it worse.
What happened was that everybody swarmed to help out and to support, no matter what their original roles were. We all did testing, code review, supported our product owner, supporting another developer…
This really established a whole team approach to testing as well — not only quality shared by the team. This whole team approach to testing works out very well. Everybody actively asks if they can support anybody and they readily provided that support until the related ticket had been finished. You can imagine how this improved team morale as well.
For this whole team approach to work, you have to share your knowledge with the team.
Testing might not become their expertise. Automation might not become their expertise. But they are able to help out and resolve bottlenecks. And in the end, we can then really stop starting and start finishing.
In the case of my personal story, here's what we did…
We agreed on a certain procedure for stories. A developer would sit together with me as a tester and we would discuss what they would test, what are the biggest risks in that story and so on. Then they would go back, test and document their findings, and when they're done, we would sit together again to debrief, discuss results, and decide whether more testing was required.
We also created a generic guideline for testing. This provided hints of what else to test or things to consider in our context like performance, security, usability, and it also included links to heuristic cheat sheets, like the one of Elisabeth Hendrickson (link provided below in resources). We created a mind map, showing how product features would work together and what might be affected in case something in the different areas changed.
Overall, you need to share your testing prospective. Help the team see the product from a different viewpoint.
# Now, what can you do to coach your teams?
First, understand that this is part of your role in an agile team. There are many formats to choose from. You know your context and your team best, so just try things out and see what's working for you and your team, and your environment. You can give workshops or talks. Sometimes it's best to just coach hands-on, on the job. In any case, make testing work visible. And vacation replacement guidelines might help as well.
Consider sharing your knowledge across teams as well, because other teams might not have dedicated testers. You can offer your knowledge for those teams too.
You can start a testing community at your company and invite all people interested in testing, so you have other allies in your other teams as well. This way there is no central testing team, but you can still support the whole team approach. You only share knowledge, not product teams.
# Who Does Automation in the Team?
Now, your team might have agreed to have test automation as a safety net. Angie Jones asks some very important questions in her Test Automation University course Setting a Foundation for Successful Test Automation.
Who is writing automated tests?
Who maintains them?
And, what in case one fails?
Maybe you do have an automation specialist, an expert, and they do automation. Fair enough. They know most about automation, right? According to the whole team approach, they would definitely need to share the knowledge with the rest of the team.
Automation might be done by developers. *Well they are very experienced and skilled at programming, right? This way any dedicated tester could focus on exploration. Now, according to the whole team approach, the knowledge would be shared amongst developers, however they would need to make an active effort to get any other dedicated roles up to speed. Especially as developers might miss aspects of testing. Knowledge they might not have or simply where the biggest risk is for your product.
Automation might also be done by a dedicated tester, having the developers focus on implementation. This kind of tester would make deliberate decision when to do what, otherwise the pile of work will probably be overwhelming. According to the whole team approach again they would definitely need to share their knowledge with the rest of the team and have everyone help out.
Now here's the case of my current team…
We don't have any automation specialists. What we have, are the skills everyone brings in. And what everyone learns every day. According to the whole team approach, the responsibility for testing and quality should be owned by the whole team. And the same applies to the responsibility for automation. The important point here is that everyone is enabled and empowered to drive automation further.
Your context will differ from the ones I've experienced so far. There are many other situations you can find yourself in and the whole team approach might not be easily applicable in all of them.
For example, you might be in a rather traditional environment. Maybe you're in the transition to becoming more agile. Or you might be in a cutting-edge environment living CI/CD to the extreme, which might be uncharted land to explore.
To learn more about what you can do in different environments, check out the following books which can also find in the resources for this chapter. More Agile Testing by Lisa Crispin and Janet Gregory includes lots of case studies you can learn from. And Testing in Devops by Katrina Clokie is another great resource to check out.
Resources
Setting a Foundation for Successful Test Automation with Angie Jones
Our ever-evolving, never set-in-stone definition of ‘agile testing’
Agile Testing Essentials — A Whole Team Approach to Building Quality In
