I started my QA journey five years ago as a Junior Manual QA. Before joining Newage, I was working in a CRM integration business where I have managed to grow to a Tech Lead position. I took part in many different projects, and I was a member of multiple teams, and each of them had their own engineering approach. There were some attempts to create a single QA Team, but the challenge was that the QA engineers worked on different projects and in different teams, so it was difficult to implement a single QA approach.

This is how I’ve got interested in improving the interaction between QA and developers, understanding the QA team composition, and whether the QA processes should be separate from the development ones.

Last year, I joined Newage, and I have started investigating and experimenting with building QA workflows. In my project, the QA engineers are an integral part of the development process and work as part of the development teams. The first thing that struck me at Newage was that all my colleagues (QA, developers, BA, PM) were clearly understanding the product’s functionality, were able to answer any questions related to the product, were taking an equal part in discussing ideas and supporting any initiative. There was an obvious difference in approach with my previous employer that made me run a comparison of product vs. outsourcing QA approaches.

The role of QA in a product company

Unlike outsourcing and outstaffing companies, product teams work on one project and have a common goal – the product must be of high quality. This motivates and encourages the interaction of all departments. In my opinion, QA is the centre of this interaction because they have to learn and explore the product from all sides to understand its functionality, capabilities, and goals.

QA engineers need to communicate not only with the developers. They should understand the overall strategic goal of the product and the main development goals for the near future and therefore be in touch with business analysts or project managers. Also, QA engineers need to look at the product through users’ eyes, and thus they need to communicate a lot with the support team for user feedback.

Necessary skills for professional QA engineers

The QA engineer is a multifunctional specialist. And the more he or she is the expert of the product, the more efficient the work is. It is necessary to check various test cases and be sure to document everything. In general, the QA engineer should:

  • understand the overall product’s technical part, not only related to their part of the project. I’m working with the backend now, so my must-haves are knowledge of databases and all the principles of testing, the ability to use JIRA, Jenkins, TestRail, Grafana, Swagger, Postman, Dev Tools, ELK, Bitbucket, DataGrip. And the list is not exhaustive – something new appears every day;
  • clearly understand the structure of the company, areas of responsibility, and tasks performed by other teams that work on product development. It is good when a QA engineer is curious about the product functionality and knows who to address them to. Ideally, in a product company, all QA engineers should understand who does what and who is the contact person for various cases;
  • participate in general communication, and not be afraid to ask questions, even if it is not directly related to the technical part of the product. At Newage, we have sessions with Business Analysts where we discuss new tasks and functionality. Everyone participates in the discussion, ensuring that we are all on the same page about the task.

Interaction of QA function and business

The work of the QA engineer is built on a deductive method: from a general idea of the product to a detailed understanding of it. At the moment, I am learning a lot about the business component of the product, so I have less contact with developers and more with BAs. This allows me to understand in detail how the product should work and what is the purpose of each function. This way I understand why the business requests the particular functionality. Often in outsourcing businesses, QA specialists just get a task, do their part, check if it works – and that’s it.

It is important to have a comprehensive view since it helps to review the tasks correctly. QA engineers should be aware of the product news, its development direction, and fresh ideas, so participation in general meetings is necessary. Along with business analysts, QA engineers can address questions to project managers.
To summarise, the QA engineer must understand the following:

  • why the product was created and the user problems it solves;
  • for whom it is designed and what functions it performs;
  • what the business wants to get from this product.

When QA engineers, BAs, and developers work as a single team, the work result will be stunning compared to when everyone is working on their own.

Interaction between QA engineers and developers

At Newage, QA engineers and developers are united in teams developing certain services inside the product. Such teams often have a couple of QA engineers. We are all gathering at regular scrum meetings. And, of course, we have daily meetings. Therefore, QA engineers know what tasks developers are working on in general and at a particular moment, and vice versa.

In my past experience, usually, QA engineers were fixing bugs, but no one was checking if they were all fixed. Those bugs were moving into the next sprint and were forgotten about, and after a while, it turned out that something still wasn’t working.

If you approach development from a business perspective, everyone in the team understands that there is no point in postponing something – you work on one product and improve it together. I often see another approach in other companies: “We fix a bug only if the QA engineer officially reports a bug”. If you focus on business results, you have a different attitude to interaction and bug fixing: “hey, it looks like we’ve made something wrong here; let’s fix it.”

What mistakes can be made in the interaction between QA engineers and the engineering team? First of all, QA engineers can’t rush. They need to work calmly and attentively. For example, monitor the environment in which they are testing so tests are not run on the production environment. QA engineers need to look carefully at what they are doing and where they are sending the request and avoid being distracted.
Secondly, QA engineers should not be afraid to ask again. Otherwise, they risk thinking that everything is simple, understand the task in their own way, and then test incorrectly.

Sometimes developers make mistakes due to a lack of attention to the technical task. Typical situations: a developer did not read to the end, did not understand, but did not ask again and did it. And then, like an avalanche: the QA engineer points out a new bug, switches to another task, and when the developer returns with the finalised task, the QA engineer does not remember what happened there.

Sometimes developers do not understand why they are “complicating” their work by interacting with QA engineers. In this situation, the team members must explain their actions and find common ground.

When interacting with developers, the QA engineers should:

  • understand what the team is doing and what functionality it is responsible for at each stage;
  • understand who is responsible for which parts;
  • adhere to a convenient communication system and bug notifications;
  • work in a structured and attentive manner.

Interaction between QA engineers and support function

When a user informs that something is not working in the product, the support team is the first to process this feedback. If there is really something wrong, the task of fixing it is addressed to the appropriate team. I’ve seen a common problem in many IT projects – the project team launched a new functionality and moved it to production but did not inform the support team about it. The support team should clearly understand how the product works and what functionality is launched.

Our interaction process with the support team looks this way: a support team creates a new task and contacts the team with a request to review it. If it’s an error made by our team, we fix it; if it’s a problem on the client’s side, we clarify what it is.

Ideally, the support team could pass the requests directly to QA engineers to check and send them further to the engineering team. We are still on our way to implement this approach. In addition, the support team and the QA engineers can collect statistics on the most common user problems, and this will be super useful data for BA and PM.

At Newage, we are now experimenting with the interaction between QA engineers and the support team. Together with the BA, we educate the support team about the product: the BA is doing this in general terms, and I cover the application part with a demo of the functionality.

When working with the support team, it is important for QA engineers to:

  • have constant communication with support team and report changes in the product and functionality;
  • be interested in what problems users most often have, and analyse the problem areas of the product.

Development management with the help of QA engineers

I believe that the QA team should be an integral part of the development team to have a full view of the product and processes.

Some companies not only keep statistics of bugs but also punish the developer for each, and after a certain percentage of bugs, the developer is fired. Of course, this does not lead to anything good.

It is important to collect bug statistics since this is an important part of product development analytics. But the QA engineer is not a tool for punishing developers – this doesn’t improve the atmosphere in the team, motivation, or, ultimately, the product itself. QA engineers also want the product to function better and perform all functions as intended.

In short:

  • management should not arrange “hunger games” between QA engineers and the developers or make QA part of the team the “bug police”;
  • the key to success is a motivated and friendly team that understands the value of each colleague and works together.

So how do you build the efficient QA work in the company?

It is impossible to develop a single approach to QA work – each project is unique, and depends much on the business specifics. However, the general rule that applies everywhere is the structuring of work processes.

We have determined for Newage that efficient work is possible if all team interactions are established and processes are clear to everyone from the very beginning of the project. Therefore, we paid special attention to the onboarding of QA engineers on the project and created a detailed onboarding path. It covers everything – from preparing documents during employment to a guide on whom to contact with what questions related to the product. Thus, we hope that new team members’ adaptation process becomes easier and clearer.

We are also working on creating a common knowledge base of use cases. It is much easier for a QA engineer to do their job with such a base. We are planning the same approach for test cases as so far, only some colleagues record them, but we plan to create documentation that will help everyone to work more efficiently and quickly.

To summarise, the basis for efficient work, which should be implemented in every QA team, looks like this:

  • the company’s management must know the product and the area of responsibility of all specialists;
  • there should be a clear onboarding path for new QA specialists, as well as for all other specialists;
  • it is necessary to create a common knowledge base about the product (test documentation: use cases and test cases, as well as technical documentation);
  • QA engineers should always go from the main thing – what they are working on. Therefore, each team should take into account the objectives of the product.

Useful resources for QA engineers

This may sound like my bias, but I see a big difference in the QA work approaches between outsourcing and product companies. Working on a product, as a QA engineer I have more ways for self-development, and I definitely have a supportive environment. I learn a lot during my work on a product. Apart from practical experience, I always try to read and watch more on the QA topic.
Some useful resources:
Telegram channels. You can keep abreast with them; there are interesting articles, collections of materials for self-study, webinars, events for QA engineers, etc. I am following this channel.

Websites:
qalight.ua (the “Knowledge Base’’ section with useful theory),
medium.com/tag/qa (stories, thinking, and expertise from writers),
ibm.com (Tutorials),
guru99 (Tutorials),
gurock.com (TestRail User Guide),
Postman Learning Center.