IT world is predominantly under the impression that software testing is the engine that drives software quality. Developers often feel intimidated by testers as they boast of themselves as the guardians of quality. While developers perceive testers as muggles, the ones who anyway know how to scrape the crust. Even worse, developers too often ‘go for the jugular’ when dealing with testers.


Such perceptions within teams create silos to store IT wastes such as useless exchange of handoffs, unnecessary waiting, defect inventory, and many more. As a result, these wastes build negative impact of the brand, cause slow time-to-market, overrun costs, lose customers and revenue, give rise to morale issues, and drive talent erosion. There are no prima donnas in a team. A team should be a system with a single job of adding value to the project as well as to the process, being used to complete the project.


I have roughly four years of experience in software quality assurance now. I have worked with software architects, developers, testers, technical geeks, business analyst, and system administrators mostly from different cultural and national backgrounds. Working with such a varied breed taught me that in any kind of work you do, you actually play a role. To me, a role is a relationship which essentially means you don’t control it but you nurture it just like your personal relationships.


Testing is also a role but the beauty of this role is that it is a supporting role. In this role, you support many clients – you support the project manager by reporting your status on demand, reporting important issue fast, and not being a bottleneck to the project; you support the programmer by providing good bug reports not frivolous ones; you support the technical writer, the sales and marketing, the top management, every stockholder and eventually the user. All these people you support have their own needs, desires, and interests. Your job is to collaborate with them to achieve the best possible final product.


Many will argue that quality is equivalent to customer satisfaction. To me, it depends on many factors though customer satisfaction is one of them. If I am asked to add all those factors which I have experienced throughout my tenure, quality would boil down to a single equation – called quality formula.

In light of the above formula, it is vital to understand for testers that quality comes from the people who actually build the product. It is a challenging task for them to keep the balance between functionality and system qualities. A big part of your mission is help them and keep them from adding new functionality before the system quality is right.

In the end, I would like to highlight that:

  • Learn soft skills as effectively as you learn hard skills
  • Never fall into the trap that you “break the product”; the truth is it may come to you already broken
  • You will not find all bugs; it is better you work with developers to fend them off
  • In essence, your job is to find information that can add value in any way possible
  • Question everything in your role. However, take them like a strong medicine – best asked in low doses or taken with a meal (i.e., in meetings, calls, informal chitchat, etc.)
  • Don’t give the impression that you’re the only one on the project who cares about shipping a quality product.

If your team is called “quality assurance”, don’t let that get to your head. Make sure that your test results and bug reports provide information that facilitates the assurance of quality on the project, which is the effort of the entire team.

Please follow and like us:

Enjoy this blog? Please spread the word :)