Within software development there are X roles that specialize in different stages (regardless of whether you work in agile or waterfall). But there are 3, that in my opinion you should be very close to if you want your work as a Quality Engineer to shine.

1. Product Owner

Quality engineers and product owners play complementary roles, as the product owner is responsible for defining and prioritizing product features and requirements, while the quality engineer is responsible for ensuring that the software meets those requirements and functions properly from the user’s point of view. Some of the reasons I would highlight are as follows:

• Better understanding of the customer’s needs: Working closely with the product owner, the quality engineer can ensure that the product meets those needs by including and detailing them in the test strategy.
• Acceptance criteria: Although the product owner is responsible for defining the acceptance criteria, when audited by the quality engineer it ensures that they are clearly defined and can be used to measure product quality.
• Early defect detection: The quality engineer helps make requirements clear and understandable, reducing the risk of misunderstandings that can lead to defects, allowing them to be addressed before they become more difficult and expensive to fix it.

2. Developer

When I was starting in the quality world I enjoyed so much to stop some release at the last moment or communicate the defects found at the end of the day (especially on the weekend), my thought was something like “if they torture me with application full of defects where no matter how much or how well I test I always find a ton of defects then I would make them suffer my way” over the years I understood that this is not the Junior’s attitude, but of someone who does not know how to work in a team, selfish and immature, no matter what seniority you are.

The absurd enmity that exists between the developer and a quality engineer is one of the most expensive things a technology area has to face.

Having a respectful, and if you want friendly, relationship between the two, opens the door to many good things, for example:

• Faster defect resolution: They will no longer try to reject a defect the first time you report it, because they understand your job is to avoid a hassle with a real customer on production environment and you are not doing it just to see if they have the ability to correct it.
• Help in automations: Surely it has happened to you that some element is impossible to cache or you had to do a lot of movements to get it, wouldn’t you love to have a special attribute for the element?
• Promote a quality culture: By collaborating closely, it is possible to more easily and effectively promote a culture of quality throughout the development process. This can range from sharing best practices to collaborating on testing strategies in a way that ensures that quality is prioritized throughout the development lifecycle.

3. Customer Support

Depending on how your company is structured, customer support may be divided into several levels (one, two, three, etc). Where level one is the first contact with customers, and level two is the one in charge of releasing hot fixes that resolve the problems reported by level one.

My advice is, talk to both levels, don’t focus only to the ones in level two (which are the ones we usually live with on a daily basis). Level one will give you a better guide to what the customer expects, this guide serves as a basis for more realistic test scenarios, while being a business expert as every quality engineer is supposed to be, it is a big plus to have test cases linked to reality prevents you from any future eventuality, also in meetings such as planning you can make observations to designs or requirements that could give more value.

Now, level two is also very important because releasing hot fixes constantly may cause some major error in the platform, remember that hot fixes are only validated with a sanity and some regression tests (you can not invest a lot of time in testing due to we have affected customers), if you have access to the code and technical knowledge just open the pull request and understand what was changed to focus your tests on it, but if you don’t have either of these two things you can ask the team what was changed and have the correct information first hand, making your tests fast and not sacrificing any other aspect of the platform.

To conclude…

If a quality engineer does not interact with roles such as the product owner, developers, and customer support, several negative consequences can arise:

• Misunderstood requirements: the quality engineer may not have a clear understanding of the requirements, resulting in a product that does not meet the customer’s needs.
• Delayed bug identification and resolution: the quality engineer may not identify bugs early in the development process, resulting in delayed bug resolution and increased costs.
• Inability to address customer feedback: the quality engineer may not be aware of customer feedback, leading to a product that does not meet the customer’s expectations.

In general, if a quality engineer does not collaborating closely with the roles I mentioned or other roles involved in the software development process can result in poor quality software that does not meet customer needs/expectations, costly rework, delays and poor communication.