Dear MoT community,
Do you have any experience with “Spotify Model” as a QA or similiar approaches to development?
What risks do you see in that approach?
What benefits do you see in that approach?
What are challenges for QA in your opinion?
Any other thoughts on the matter?
I’m currently researching the topic but thought having opinion of fellow MoT testers would be super valuable : ) Thanks for your input!
Well, when I first saw the “Spotify model”, I thought “That’s the same as the ‘matrix management’ model I was told was the latest thing back in the 1970s!”.
What goes around comes around, only with new clothes and a funky new name.
If by Spotify Model you mean the autonomous teams then here is my experience regarding that.
Your role shifts from “Tester” to “Test Coach” to some capacity. Lets look at the situation a little more closely. So the Spotify squads and how we worked with autonomous teams means that the team have more responsibilities, like deployment, monitoring on top of delivering features. It also to some limited extent means that your team will go and change other parts of the product / or that other teams will change your part of the product. We also did Continuous Delivery (roughly 3 deploys per week or so). This means that you will easily be overburdened in testing if you try to do all of the new things yourself. Instead you need to transition into enabling the rest of the team to be part of the testing process. Both in developing tools but also in testing. We did that in three different ways I think (for the 3 teams that I was mainly involved with). In one they did mob programming and the tester was part of the mob which meant that all testing related things got handled by the entire team. In another team the tester started to help with the development of things like monitoring, the operational side of things and we introduced testing tours to enable everyone to be part of the testing of the product. In the third the tester was working a lot with automation together with the developers. Hence they all to some degree coached the rest of the team more in testing than being responsible for all of it themselves.
Now to your questions.
Risks: As with any approach if you “copy someone else” without thinking what suits you, you are likely to fail.
Benefits: Testers and the entire team get a way better understanding of the true usage of the system which enables them to stop making stupid mistakes which to me is what most bugs are about.
Challenge: To get overburdened by doing it all yourself and developing your skills as a tester.
For this to work the infrastructure around the team needs to be solved. They talk about it as the alignment. All teams need to run in the same direction etc. If that is not in place you will not see much productivity.
For research on the topic of autonomy apart from Spotify, Valve and Zalando have some good material on the matter.
Good Luck!