Separate testing scrum team vs tester in each scrum team
We have been practicing scrum for around 4 years now.
We have 8 scrum teams, each working on separate but related domains of a product.
We make 2 scheduled releases to our product every week(Tuesday & Thursday).
Considering the point that each team should be self-reliant to deliver stories, initially, we had a tester in each of these teams.
But we soon realized that there were some problems with this approach:
1. There was a single point of failure at the tester level. e.g: What if the tester went on an abrupt leave?
Hence we realized that testing is not only a tester's responsibility but that of the entire team.
So, we migrated to a different approach, we trained our developers to do functional testing as suggested here in the forum.
And we created a separate team for testing(currently 5 members), they now follow their own scrum process and their responsibility is to write E2E tests and do regression testing for each release, manually or via scripts.
Each team's product backlog is attended by one of the testers to gain upcoming product knowledge.
In this approach, they can also innovate more freely as they are not bound by a specific team.
They also have good knowledge sharing happening now, which removes the dependency on one tester.
One possible improvement that I can think of is that even though testers are disjoint from developers' team, they should act as a testing coach for teams so that developers can write better scenarios and handle problems as early as possible.
I would like to know if what we are doing is the best approach that others are following?
In this approach, they can also innovate more freely as they are not bound by a specific team.
Who is now accountable for creating the Done, finished work that is necessary for innovation to happen?
For one of my clients, I advocated to eliminate "testers." We went with a team full of software engineers who could do all the work needed to produce a done product increment. This way, your customer becomes the ultimate QA.
@Ian Mitchell
I did not understand your question completely but let me elaborate a bit more on the below point
In this approach, they can also innovate more freely as they are not bound by a specific team.
They also have good knowledge sharing happening now, which removes the dependency on one tester.
Here I am talking about the testing scrum team. So testing team is now free to pick new things like recently they picked up a new framework for E2E testing to reduce their manual regression testing efforts.
The testing team along with their TL(with inputs from TLs of developer teams) decide on what stories to pick for further automation. Then they only execute and deliver these stories. There are weekly and monthly reviews with senior people from the company to track the overall progress of automation
Testing team members share the knowledge of different domains among themselves so that they can share the overall load of regression testing and pick up other tester's work in case one of them is not available.
My current company had 1-2 embedded QA in every Scrum Team for years. We had success but there were occassionaly problems where one product team would release something that would break another product because our architecture is somewhat of a mess. Recently we eliminated all QA from our organization. Now every product team, i.e. Scrum Team, is responsible for validating their own work. This means that the developers have to test their own product changes. It has introduced another set of issues as well retained a few of the old ones. Guess what I'm trying to say is that there is no right answer.
In regards to your approach, it seems to me that you have introduced a release gate by making a separate team responsible for the testing. I am not going to say this is wrong because I've worked in the same configuration. However, you will need to be aware that problems will arise from it. Here are a few that I have encountered.
- Development Teams deliver a "done" increment to the Test Team. It can sit in the Product Backlog for the Test Team for an undetermined amount of time because that one team is responsible for work being provided by multiple Development Teams.
- The Test Team will uncover issues during testing that require the Development Team to correct. Does this go back to the Development Teams Product Backlog or is their current Sprint interrupted to fix the issue that they created multiple Sprints back?
- An issue found by the Test Team in an item that Development Team A finished 3 Sprints ago will have impact to the work done in all of the following Sprints due to an interative delivery of a feature.
- Product Owners no longer have full control of the work being done on their product. And who is the Product Owner for the Test Team's Product Backlog?
- Increase in delivery time based upon all of the above.
The approach I have found best is to have the validation of all work done occur during the same Sprint in which the work is done. Whether that means having a dedicated individual(s) on each team to do the work or if the entire team does the work isn't relevant. The relevant part is that the work completed in the Sprint is not "done" until it has been validated to be valuable and useful.
If like in Vicky Lund post there is a Scrum team where all developers are QA (lets think there are manual QA who test for another teams in Nexus) - what should be an increment in this QA team?
If like in Vicky Lund post there is a Scrum team where all developers are QA (lets think there are manual QA who test for another teams in Nexus) - what should be an increment in this QA team?
This scenario is an impediment and wouldn't make sense, because all of the other Scrum Teams wouldn't have a valuable, useful, done Increment. Nor would the other teams be cross-functional, and this would result in handoffs.
A better approach would be for all the teams to have QA members. Scrum requires us to think differently and be change agents, rather than accept the status quo.
From my observation, time-consuming release testing is one of the biggest challenges when applying Scrum. The general advice is to work towards reducing it through improved automation, better quality of development processes, better architecture, decoupling, etc. and keep it as part of the definition of Done. However, sometimes there are regulatory requirements, safety, and other things, that need long manual testing and documentation and it is very hard to plan the Sprint with those included.
If those are excluded from the Sprint, it is important to be transparent and clear about what is included in the DoD and what is not. What is the Done Increment?
If we pull certain testing out of the Sprint due to various reasons and there is a team for that purpose, that team is becoming the external stakeholder and not the part of the Scrum Team (or Nexus for example).
Heaving that external testing should not be an excuse for the lower quality of the Increment delivered by the Scrum Team to its stakeholders. If release-blocking bugs are coming from that external stakeholder testing we need to figure out how to prevent them within the Scrum Teams.
Test team sounds very problematic and smells like handover, delay and friction.
Sounds like you've tried the right things with tester in the team and devs doing some of the testing themselves.
One step further maybe making the tester a test coach of sorts, letting the devs do all of the testing under the guidance of the tester.
Automated testing is obviously the ideal process with devs writing the tests as code and it's just part of the coding process and DoD. The tester would be on the code reviews and guide the devs.
i would see no delay or bottleneck here.
There is a hurdle to get over and that's convincing developers that testing is part of their responsibility, automated tests much easier to swallow than manual tests. Possibly make it interesting by inviting the devs to learn new approaches and design their own automation framework with the latest tech, CICD etc.