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 themselves as the guardians of quality. While, on the other hand, developers do not take quality testers seriously and do not hold them in high regard.
Missed opportunities to drive improvements in delivering value
The rift between developers and quality testers create a tense environment at the workplace. Such perceptions within teams create silos to store IT wastes such as useless exchange of handoffs, unnecessary waiting, defective inventory, and much more.
Which results in slow time-to-market, overrun costs, loss of customers and revenue, rise in morale issues, and talent erosion.
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.
Your role is a relationship
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.
What actually is testing?
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.
The quality formula
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 to 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 technical 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.
Disclaimer — The views expressed here are of the guest contributor and doesn’t necessarily reflect the views of TechJuice editorial staff.
