The Indispensable QA Engineer

There are times when Quality Analysts feel like they are not valued enough or that their efforts are not visible. This may be influenced by wrong feedback or perceptions other team members have of the role or what they do. Some team members think because there is no tangible output produced for the user by the QA, they may not be so relevant. While some other stakeholders may perceive them as bottlenecks.

Whatever the case may be, we know that the QA role is a very unique and important one to software development and might only take some time and deliberate effort to exhibit one’s relevance and value to the team.

Reiterating the value of a QA

Creating awareness of the role and its importance to software development and the overall business goal of the company is a great place to start. 

• User Research: One of the very salient responsibilities that you are saddled with as a QA is to represent the end-user or customer in the SDLC. No one captures the many scenarios a user can be faced with while using the system the way you do. Your depth of user empathy is a good way to demonstrate this value by showing how you are keen on seeing things from the user’s perspective. When you speak from a wealth of knowledge gathered from deliberate user research and study, you affirm this empathy. When armed with knowledge and facts on user behaviour and interaction, you can advocate confidently for those customers/users. This alone establishes you as a subject matter expert who represents the end-user because you are equipped with information that is very useful to the team.

• Much more than defects: Don’t restrict your attention and contribution to situations when there is a deviation in the expected behaviour. Maaret Pyhajarvi, the Lead Quality Engineer at F-Secure once said that her definition of a bug is,
  
  “anything relevant that might bug anyone ‘relevant’ ”
  
  She focuses more on opportunities to build great products than functionality errors. You can broaden your horizon by contributing and asking relevant questions during refinement meetings, requirement gatherings or discussions etc. making sure that no scenario or user type is omitted. This way you are not warming the bench until it is time to test.

• Make experience your best teacher: When working on a system over time, you are exposed to bugs or issues found in the production environment. This can give you an insight as to scenarios you need to call your team’s attention to when building new features that are similar or related. This is a good way to guide the team into not repeating mistakes made previously and this is always appreciated.

The Value of Trust

Trust is a fundamental ingredient in fostering your relationship with developers and other team members. Building trust starts with being trustworthy. Being trustworthy as a QA means you are completely reliable and so also are your recommendations. This requires that you:

• Limit the number of cases of false-positives. A false-positive occurs when your test report indicates the presence of a bug in a feature when in fact there isn’t. To avoid this happening frequently, confirm if you are using the right data, and ensure that you are in the right environment. Also, be sure of the scope of software testing or development.
• Avoid only giving cosmetic bugs, proffer functional bugs also.
• Provide facts, documents and/or relevant evidence when filing bugs. This is not only useful when there is a debate about the presence of a bug but also helps developers debug or investigate root causes. 
• Build trust through effective communication with stakeholders. This includes talking politely to team members and listening attentively to them because effective communication is a two-way street. This also involves giving positive feedback to team members, not just negative feedback when things go wrong. 

Value Visibility

Sometimes, we assume that developers and or other stakeholders are aware of what we are up to, how we test, or what we look out for. One’s efforts cannot be appreciated if the other stakeholders are not aware of what we do. To avoid this, create visibility into your activities by;

• Reviewing what you’re planning to test with the developer.
• Discussing learnings and lessons from customers or users with the team.
• Publish results of certain tests executed such as security and performance tests
• Carry team along with new tools being learnt and adopted as well as self-improvement plans being achieved. Also, keep them acquainted with the little automation tools and ideas you have come up with to improve repetitive tasks being done by the team.

Happy testing and be the best QA you can be!