It is not easy to be a quality analyst. When you raise a bug, developers might react as if you were personally attacking their job. Even though everyone on the team has the same goal, and you see yourself as an important team member, you still have to tell other people that what they did has to be corrected.

In big teams, you can expect many types of behaviors. But it is even more difficult if you are starting a new QA team, where you will work with developers, business analysts, and product owners who have never had the quality assurance component.

This was my experience, so I have some advice for ways you can be effective when you’re starting on a team that has never worked with quality analysts before.

Starting a QA Team from Scratch

I arrived to a dev team that didn’t have any documentation or procedure. Developers were used to working in their own way without any input from QA. I introduced myself as the new quality analyst, and they seemed happy about having me on the team. But when I went to work understanding the application and providing my input about it, problems started to arise.

Whenever I asked any question that only devs, business analysts, or product owners knew the answer to, everyone acted as if I didn't exist. Nobody wanted to help me. They had started to see me as the evil QA guy who wanted to criticize their work and make them look like fools, because that’s what quality analysts do, right?

What do we do in this situation?

I think of the character Andy Dufresne from the movie The Shawshank Redemption. Andy was a banker who was sentenced to life in Shawshank State Penitentiary. He wanted funds to improve the prison’s decaying library, but nobody listened to him. He started sending weekly letters to the governor, and nobody replied. Still, he was not discouraged, and he continued sending letters for over a year until he obtained a reply.

I felt like that on my new team. We had daily meetings in which nobody cared about what I said. Nobody seemed to understand why I needed valuable information. We were working on a banking project, and everybody was mentioning specific banking terms that they knew because they had been on the project for a long time. I had a lot of questions that anyone new to an application and a business would have: What is an issuer, and why are we showing it only in some parts of the application? Why are some fields mandatory in specific conditions? What do each of the sections of the application mean, and why do some new options come up when doing a specific combination? How does the cancellation workflow work?

Every time I asked questions that would help me see the bigger picture, they took for granted that I knew everything, acted like I was trying to replace them, and got very defensive if, for example, I raised a bug with no specific business background. They did not want to share any piece of information I requested, which severely hampered my job. I felt like I was not being helpful at all, because with no information, there is nothing to test.

In every meeting, I said the same things and asked the same questions, and they acted like I did not exist. So I started individually contacting everyone I knew: developers, business analysts, and product owners. I did not have to wait for over a year to get a reply like Andy Dufresne, but persistence was the key.

Apart from asking questions, I also documented everything I could, and defended myself from devs and other team members.

Thinking as the User

One way I tried to defend myself and my role was by comparing our software development to the process of making a movie. I told the team that I am not a movie critic, who is not involved in making the movie but only reviews it afterward; I am the film editor. I am as worried as the movie’s director about the final result. I am involved in the production.

What happens if every scene in the movie is shot beautifully but then these pieces are poorly cut and put together in a way that doesn’t make sense? Everyone will say that the movie is bad. Directing, execution, and editing are all tied together and all affect what people will think of the film. 

I told my teammates that the same happens with a release to production. If the client is not satisfied with the final result, we are all to blame. Everyone has to understand that we are all a team, and that the quality of the product is everyone's responsibility.

With that explanation, my other team members started to understand why I raised a bug, why I implemented defect discussion meetings, and why everyone needs to be listened to.

Even though we like to think that everyone should take into account what QA says, most of the time devs think that our input is too drastic and that our suggestions will never happen. I was often rushed and encouraged to accept that something wrong could be moved to the production environment, even though I did not agree.

How can we get the rest of the team to understand why this is the wrong approach?

First of all, try to calm down. Quality analysts tend to be stressed when a feature is going to be moved to production, so we may not communicate what we are thinking well.

Then, start a discussion with the developers so they can explain why they think the application can be moved to production. In one situation I experienced, they insisted that a bug that could be easily identified by the client was not a high priority. In that case, I explained to them that we need to think with a client mindset.

I explained my daily work and showed them what a real user would do in the application, highlighting how the defect would be experienced and why it needed to be fixed as soon as possible. It took several discussions, but I let the evidence speak for itself, and the rest of the team realized why this bug was actually a big deal.

When it comes to QA, we always need to be thinking as the client.

Keep the Goal in Mind

Even though I let the evidence speak for itself, many times, the developers, business analysts, or product owners would not understand. I had to change my mind. I could not think that I was always right and that my misguided team member was always wrong; I could not “win” every time.

To maintain a good work environment, remember that you are part of a team. Everyone has the same goal: to create a great product that delivers value. As long as each person is keeping that goal in mind, you should fulfill the client’s requirements.