How to kill UI regression testing: git source control (zagorski software tester)

On October 22, 2016, in Syndicated, by Association for Software Testing

TL;DR This is third part in series how to kill UI regression testing. It is about git source control system and its web application part, github, bitbucket or gitlab. I have already wrote about this topic in Product moving parts as a source for test strategy, and Micro tracking changes for regression test. In this post, … Continue reading How to kill UI regression testing: git source control

Making Fünf Myself (Hiccupps)

On October 22, 2016, in Syndicated, by Association for Software Testing

The first post on Hiccupps was published five years ago this week. It’s called Sign Language and, reading it back now, although I might not write it the same way today, I’m not especially unhappy with it. The closing sentence still feels like a us…

He Said Captain (Hiccupps)

On October 21, 2016, in Syndicated, by Association for Software Testing

A few months ago, as I was walking my two daughters to school, one of their classmates gave me the thumbs up and shouted “heeeyyy, Captain!”Young as the lad was, I congratulated myself that someone had clearly recognised my innate leadership capabiliti…

Interview with Olof Svedström, QA Chapter Lead at Spotify (Nicky Tests Software)

On October 19, 2016, in Syndicated, by Association for Software Testing

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.

REACT to Bugs (Assert.This)

On October 18, 2016, in Syndicated, by Association for Software Testing

The most common artifact that testers produce are bug reports. So what do you do when you actually find a bug? You react, here’s a mnemonic that may help your process… R eproduce The cornerstone of proving a bugs existence is if you can track down steps to reproduce it. Like ghosts, bigfoot, or aliens … [Read more…]

Leetspeak: My First Developer Conference – An Experience Report (Nicky Tests Software)

On October 16, 2016, in Syndicated, by Association for Software Testing

Up until yesterday, I had only gone to testing conferences – for me these were a safe familiar place. I was with my “own kind”.  So when my boyfriend asked me a few months ago if I wanted to go to Leetspeak, I surprised myself a bit by saying yes….

How to kill UI regression testing: development framework tests (zagorski software tester)

On October 15, 2016, in Syndicated, by Association for Software Testing

TL;DR This is second post about idea how to kill UI regression testing. In first post I described symptoms for UI regression testing that I would like to kill. I will describe development framework tests that are precondition for killing UI regression testing. Development framework tests (DEFRATE) are automated tests that are written by developers. … Continue reading How to kill UI regression testing: development framework tests

And Now Repeat (Hiccupps)

On October 15, 2016, in Syndicated, by Association for Software Testing

As we were triaging that day’s bug reports, the Dev Manager and me, we reached one that I’d filed. After skimming it to remind himself of the contents, the Dev Manager commented “ah yes, here’s one of your favourite M.O.s …” In this case I’d created …

Start Making Sense with Sensemaking – a #TheTestingShow Follow-up (TESTHEAD)

On October 13, 2016, in Syndicated, by Association for Software Testing

One of the primary reasons that my blog is not as frequently updated as in the past is that I have been putting time into producing The Testing Show. Granted, I could do a quick edit, post the audio and be done with it, but we as a team made the decisi…

How to check font size on a web page? (zagorski software tester)

On October 13, 2016, in Syndicated, by Association for Software Testing

TL;DR In this short blog post I will share with you a tool that could help you in checking font size on a web page. I had to check application change that involved changing font sizes on application web page. In BBST foundations course I learned how to create test strategy. My test strategy was that … Continue reading How to check font size on a web page?

Page 1 of 3123

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!