Interview with Olof Svedström
Olof Svedström has worked as an engineering lead within software testing and quality at Spotify for 5 years, during a period when he has been part of the journey where they have grown from 5 to 100 million active users and from 150 to 2000+ employees. Before Spotify he spent some years as a tester in a spectrum of companies, ranging from small product ones to international giants.
What does your role as QA Team Lead at Spotify involve?
Being a chapter lead (team lead) at Spotify is a people manager position and not e.g. a test lead position. I do very little to none test leading as the development is done in small development teams, each owning the responsibility for the quality of what they produce, with a QA in each dev-team. QA at Spotify stands for “Quality Assistance” and not “Quality Assurance”, we are there to help the dev team (as a part of it) to deliver.
The role of the QA is more of a coach and inspirer than a quality police/toll gate. My role in this, as a people manager of QA’s, is to grow the team. Both by helping the people we have onboard grow professionally as individuals, but also hiring. I also work with explaining and teaching the view we have on Quality work to stakeholders in our vicinity when needed. As a side show I also spend some (limited) time as an individual QA-contributor in a dev-team, both because I can help, but also to have an ear to the ground and understand the real issues, problems and challenges we face.
Spotify engineering model is fairly well known in the tech community, what’s it like, working as a tester, under this model?
We strongly believe that developers care and should care about quality. Delivering high-quality products is a team sport. As a QA (being a tester is a part of what you do as a QA) you help the team with quality, but you don’t own it (more than anyone else in the team). This means that you can’t be the quality control-gate.
Leaving that role behind can be harder to do than it might sound like. It takes some effort as a QA to not have full control of what goes out to the end-user, but to try to have that would be detrimental to true engagement from the others in the dev-team, and also slow all of you down immensely.
As most of our teams deliver full-stack products the tech-stack you will need to know is vast and deep. Finding a level of knowledge you feel comfortable with might be hard, but keeping up a 100% with 6-8 world class developers within backend/frontend/mobile/data at the same time is impossible, so you need to accept to not know and understand everything. At the same time you need to know enough to help, so finding a balance is potentially tough.
I would say that the role is very much up to you as an individual, only you will be fully able to see and understand what is your most important task at hand, how can you help the best at this point in time? It might not be (most often isn’t) pure testing, but could be process, stakeholder management, help with deploy and integration chains etc.
Did joining Spotify change your perspective of testing in terms of how it can be done?
I had worked in similar ways before joining Spotify, but the pace of change (software, organisation and process wise) was clearly higher here. To some extent the difference I have noticed over the years is how the model kind of works (sic!): have few but some QA and the rest of the org is forced/given a lot of the responsibility for quality and actually embraces it. Not everyone, and definitely not from day 1, but it definitely beats more traditional “quality police”-models.
Spotify is one of the most used apps I’ve seen here in Sweden, seems like everyone has an account. Does being an actual user of Spotify change how you test? If so, how?
It gives a sense of purpose, knowing you yourself really care about the product and so does your friends and family. At the same time you need to acknowledge that you are in some sense a superuser (and will complain about small issues that really isn’t a problem) but also don’t fool your self into thinking what you fully cover true user behaviour. Being a 40-year old Swedish suburb-living middle class man, I probably use and expect very different things from Spotify compared to a 15-year old teenager in Mexico City.
What advice would you give to someone who is starting out their testing career?
Do it, and try to tweak it! Don’t focus too much on learning the latest cool tools (they won’t be cool anyway in two years time), or try to grasp and write everything from unit to end-to-end system tests and all the things in between.
Instead take the chance to try to understand as much as possible about how a development team (large or small) actually works, what are their impediments and how does it affect the quality of what they produce? Then, what can be done about it, and how do I as a QA do that?
It takes much more people- and social skills to have an impact than one might think from the start, but “just more testing” will too often only result in more issues reported somewhere in a tracker system (that no-one will care about, rather those reports will only slow everyone down). Just don’t do it as a “this is a way to become a “real” developer”, and then do a half-dedicated effort.
Give it a chance in it self, you will learn so much about software development in general, things developers actually learn less about early in their career, experiences you will have immense use of when you two years down the line again evaluate what you want to do the coming years. Done right, you will have a great foundation to build on, knowing so much more about the true, full, life-cycle of a product.