QA collaborating as part of a team, rather than working against it

QA as Part of a Team

I still remember when I started working my first job at a software development company. I was just a student and the first Quality Assurance Engineer in the company.

After meeting my new colleagues on the first day, all I could hear were comments like, “Oh, are you the new QA Engineer? I don’t think you’re going to be liked.”

It was a surprising thing to hear, especially on your first day of your first job (even as a joke).

Naturally, I didn’t take it personally; it didn’t even bother me at all, but something about it was just surprising and incomprehensible. I was happy to work, to get to know the profession, new projects, and new colleagues, and was ready to demystify the whole notion.

I remember being introduced on my very first project and being told what I needed to do. I felt incredibly happy because I got the opportunity to analyze, try new technologies, check if everything is good, check if everything looks true to design, ask myself as many ‘what if’ questions as I could come up with, and look how to optimize every step of the process - everything sounded like my dream job, which I didn't even know existed.

Funnily enough, the colleague who told me that no one was going to like me on my first day was the team lead on the project I just started working on. We had a great relationship as friends and as colleagues. At some point, he told me that I was the first QA Engineer that he did not hate, and it was a compliment I was willing to take.

I talked to him a few times about it and he indulged my curiosity with an explanation. I could completely understand where he was coming from after sharing all his experiences with previous QA Engineers he had worked with.

He was telling me how many of them took the approach of working against developers instead of with them.

Many of them were mocking or pointing fingers when reporting bugs, even bragging about it.

Honestly, with the way he was describing them, I wouldn't have liked them either.

Way of Communication is Important

I have heard or read motivational quotes about how communication in any type of relationship is important, but I believe that the way of communication is even more so, especially for a QA Engineer.

Looking at a job description superficially, it can be said that a QA Engineer looks for and reports developers' mistakes, something no one really wants to hear.

That is definitely the wrong approach, the wrong way of looking at it, and a completely wrong way of communicating within a team.

That’s why it’s a priority and the first thing that I look for in a potential new member of the QA team. It is also the first thing I tell new colleagues in my team - a QA Engineer is a part of a team and not someone who works against the team.

A QA Engineer is a person who works together with Developers to produce the best possible product for clients and users. That is how all team members should communicate and approach the project.

How Do We Accomplish That?

As I mentioned before, personality goes a long way in achieving this type of communication among team members, most notably QA and Developers. Additionally, here at Pixion, we encourage QA Engineers and Developers to be included in all parts of software development process - from design and client meetings, all the way to the implementation.

This way, all team members are treated as equals, with no big hierarchy, and no need for one person to oversee multiple team members just so they would be able to have a say in anything or get information from someone.

Additionally, as a QA Team Lead, I always encourage my team members to do everything in their power to help developers and designers when in need and to support them every step of the way.

This includes standardizing the way bug reports are written, trying to debug an issue we ran into, writing as much useful information about the issue as possible to speed up the process and help developers fix the issue as easily as possible.

The last thing is probably the most important one - being intelligent about rejecting implemented tasks, always being sure that we are rejecting them for the right reason, the correct reason, and being gentle while reporting those.

This way, we are building trust and equality between all team members to build a culture where all of us want to deliver the best possible product end users, and for it to be something we can all be proud of.