Adapt and adopt a tester, a (r)evolutionary story

This year, I had a great chance to take part in DevTest Conference North with Miro Barsocchi, talking about the evolution of the role of a QA engineer working in a big company going through a transition period. The presentation title was “Adapt and Adopt a tester, a (r)evolutionary story”, a joke to underline that it was the story both of the evolution and revolution from a QA engineer point of view, with pro and cons.

How the story begins…

We started in 2012 in Expedia Inc. working on the platform. It was quite a small company, organised in scrum teams, and each of them was responsible for a part of the website: a team for the homepage, a team for the booking part, a team for SEO and sem, and so on. Teams were made of developers, QA engineers, ui-ux, a product owner and a scrum master.

From a human point of view, it was a great place to work in, we were more or less 60 people in a technology department, divided into more or less 10 teams.

When I arrived there, I was young, with some experience in other much more rigid contexts, but I felt part of the company since the first day.

Everybody was there to support you, to help you, to teach you new things, and to ask their opinion; there was a real team feeling.

And from a technological point of view, people were always ready to experiment and to understand if there were new ways to do things with new approaches. I found that a challenging environment that made me happy on both a personal and a professional level.

But perfection does not exist! In this great place, the problem was the release management. In fact, teams could not develop a feature and release it directly in production because they had to pass through another step: the integration team.

The problem

The integration team was made of two or three QA engineers. They were responsible for taking all the feature branches that the teams developed during the sprint and merge them to trunk (we were using SVN) to perform all integration tests and to check that all the branches were compatible with each other and with the production. It was also their role to check for the absence of bugs.

Also, the way in which that team performed tests was nice, because they used a big excel file which contained all the possible manual test scenarios to perform on the website (i.e. open a browser, go to the homepage, check if the forms are visible, click the red button, and so on).

So, imagine that each week, each team prepared a document to send to the integration team with the list of the SVN branches and Jira tickets they would like to release. The integration team took these documents and, with a lot of patience, merged them to the trunk and performed all the necessary tests.

Everything was manual, wasted time. and frankly, it was boring.

Improving quality

In terms of bugs, the integration team had to understand which branch was the responsible one and had to remove that specific branch from the trunk. That specific branch was returned to the developer team who would have fixed the problem in the next sprint.

The consequences? The responsible team felt very guilty, and integration teams were considered as evil even if it was only made of poor QAs performing tons of manual, repetitive and super boring activities.

After a couple of years came the first big change. The integration team started its evolution introducing an automation test platform. This represented a big step also for the developer teams because, during the sprint, QA engineers in teams prepared the automated tests related to their specific features, releasing them with the dev branch, so the integration team collected all the new tests and used them for the trunk. All automated tests from the previous sprints were used as regression.

The quality level improved because automation is less focused on errors and the regression test collection was improved during each sprint.

QA engineers had to develop code. They started feeling more similar to their developer colleagues. They started communicating with each other and started exchanging more and more opinions.

The outcome

In 2016 moved to platform. Things were no more the same. First of all, the integration team was not more present and all the teams were more responsible for what they were releasing. Teams were not yet released into production by themselves but with the help of some operation teams whose role was to help and support dev teams with activities related to prod release and some other particular checks on the system.

Then, we felt the strong need for more and more knowledge on what operation teams did, so we created a new role called “the expert” and put one in each team so that the knowledge was spread in an efficient way. This new approach was more effective and the responsibility level was increasing in the teams and, in particular, in the QA engineer’s souls.

Currently, we are still working on a platform, and the knowledge has increased so much that operation teams are no more an essential part of the release process. They are there to help and support us in case of particular issues, but now we are all “experts”.

Now we don’t have to wait anymore until the end of a scrum sprint to release something because we can do it every day or more than once a day. The DevOps culture has increased a lot and teams are involved in a lot of other things, rather than only development, so they are somehow forced to find new solutions in terms of testing, automation, release tools, and so on.  This is CREATIVITY.

This is what I call freedom. Teams, developers and QA engineers are part of something bigger in which what they say is always valuable and they feel the strong need to contribute to improving the platform and their work.

Maintaining the trend

Moreover, we have some best practices to follow to maintain this trend.

The first one is our “tech radar’.  This is a real radar with all technologies and tools to use and to forget. This is maintained by architects but ideas are collected also from all the teams. A good way to suggest a new solution for the tech radar is our innovation time, which is 4 hours per week, during which we can experiment with something new, creating a POC and demo to other interested people.

Another fundamental thing is the hiring process. We search for smart people who don’t focus only on their own code but who are curious about what is behind and around them. We want to attract smart people going to school events, conferences, meetups, writing articles on blogs, taking an active part in the open-source community, and so on.

Somebody important, some years ago, said Nothing endures but change (Heraclitus). I like to think we can trust him.

Written by Annarita De Biase, Software Engineer in Test II presso at



Related Posts