Over the years we have seen so many different ways to work with quality in Agile Teams. We realised that teams design is really important. So, start from the ground and please design your teams with as many Feature Teams, Value Stream Aligned Teams or whatever you want to call them as possible.

Why is this important? We saw people having waterfall processes right after the Sprints with a lot of testers in the teams themselves and across teams. If your teams are mainly component teams then there is no way around end-to-end testing strategies or the like. All these things bring a bunch of anti-patterns and funny questions that do not stop to puzzle us again and again. So, in this post, we will present our take on what could be the best practices for Agile Testing in a program with around 150 people and around 12-15 teams. Let’s discuss later how to deal with the small number of components, platforms or enabling teams.

So let’s start with the Feature Teams and focus on the culture we want to have. If we really want our engineers to take end-to-end responsibility then we need to enable them to do that. I am not saying that testers are not necessary but I love the idea of testers becoming Testing Coaches. We borrow this from Atlassian and since then I saw it implemented in a couple of the companies that we have worked with. I have to say that this approach is the best that I saw so far.

So, how do we deal with end-to-end testing and how do we cover the boundaries in the edges between the domains of the teams. Well, a practical approach that we tried is that we extended our 2 weeks Sprints to 3 weeks to give 2 days extra buffer to include variability and 3 days for merging, integrating, end-to-end testing, etc. So, yes the engineers take care of the quality of each Sprint with the support of the testers to refine the process, to make it better, to automatise as much as possible and in essence make it as least complex as possible.

Days were testers were opening bug after the other one, we spent hours and hours triaging piles of bugs, prioritising them, etc are gone. And, what do we do with the other type of teams? Well, the same apply and especially platform teams focus even more on automation so that’s where the testing coaches support the teams with the last frameworks and tools that can help in this direction. It is also important to mention Agile Testing Quadrants as a great tool to define different types of tests in the teams and across the program and when it is better to use them based on the context. Last but not least, even if your teams are great with everything we suggested here, some bugs will come from Production. What do you do with them? Before you start to pile them up again, do triages, etc. I would love to suggest you to have a look to the Zero Bugs Policy which we used successfully in somany different setups.

So, how do you do testing in your Agile Teams? Please share any good experiences you had on the topics. I will love to learn more form them… :-)