Harnessing Your Development Team for Quality Assurance: A Strategic Guide to Effective Inquiry
Questions you need answers to before starting to test. Understand the product for smarter questions and better testing speed.
After successfully completing 100 tickets in Jira (although I’m unsure if this is the right metric to evaluate my testing journey), I’ve identified a major problem that is often overlooked by QA professionals, or perhaps many of them are simply accepting the issue.
Ambiguity: the mother of creativity, confusion, and diverse perspectives.
The first time I heard about this word was when I was in my Bachelor’s.
My computer teacher who had experience working in IT was stressing about ambiguity. He mentioned ambiguity 10000 times staring at every one of our eyes instilling an important lesson for life.
“Avoid ambiguity at all costs when you become a part of the workforce and also in your daily life” still rings as a reminder to make sure whatever I do is clear and explicit. But we cannot expect the same from our fellow developers as well.
Therefore I have devised a framework that guarantees a better understanding of the features added or the bug rectified when the developer gives you KT (Knowledge Transfer).
This framework goes hand in hand with deep knowledge of the product you are working on stonks the quality of the product you are testing.
Question 1: What happened earlier and why are we doing this in the first place?
The answer to this may not even lie with the developer himself! A feature normally goes like this:
- Requirements arise from the customers
- The seniors in the team decide whether or not to adopt the feature in the application or not
- The requirement is conveyed to the developers verbally or in the form of documentation.
- The developers develop the requirement and give it for testing
- We as testers who aren’t aware of anything that happened earlier should be testing.
That’s why we need to ask the right questions.
I strongly feel that it is the responsibility of QA engineers to ask the developers or product managers why a feature or a particular approach was adopted for fixing a bug. We can even go the extra mile further by questioning approaches when we are familiar with the product.
Finding the real reason behind the code change and knowing the business aspects throws light on the client’s requirements as well which is what we are supposed to make sure it is met.
I happened to test a printing application that was optimized to print at half the time it used to take. The solution was a very interesting one! The solution included C++ and Java combined. Yes, I did not know different languages could work hand in hand to arrive at a solution that was mind-blowingly fast!
Knowing some history of the product and why some changes are being made will give you a sense of credibility while testing it.
Also, it is nice to know and appreciate a clever solution to a problem.
Who knows you might find a flaw in the solution🤷.
Question 2: How to test? Or how did you verify that it is working as expected?
When we get the answer to the first question, we become clear on what to test but not necessarily how to test.
Aren’t we aware of how we used to test?
Why do I have to ask that to the developer?
If you do not know how it was tested by the developer, we might spend a significant amount of time figuring out how to test rather than testing it.
This doesn’t mean blindly following what the developer did to test, It is highly recommended to put on your thinking caps and figure out ways this could go wrong.
Question 3: What are the edge cases?
Developers are trained to consider edge cases during their interviews they are asked about questions and find edge cases for those questions as well.
They pose a valuable input for your testing.
Even though what we are testing is straightforward, the moment we ask the question you and your developer friend think of ways the product could be broken. 2 minds are thinking of ways to refine the product we are building.
Recently I was testing an API that will calculate tax for shipping charges. Though it might sound very straightforward forward it had very peculiar test cases where:
- There could be items whose selling price could be 0 but they would have shipping charges
- How do you charge for gifts?
- Sometimes there are 0 taxes calculated on items. I didn’t know there was no tax on some items in India.
- Will it go with 0 downtime (not stopping the production server/ application)
- Will the application work as expected even when a migration script (a program that changes the database compatible with the current version of the software) is running?
Keeping in mind these scenarios, we strive to make this software foolproof and reliable, ensuring a robust solution for diverse situations. There might be different scenarios in different work environments but working collaboratively with fellow developers to find situations that might arise and making sure nothing goes wrong gives our users an efficient software experience.
Right Questions Lead to Better Products
Questioning opens up different perspectives on existing solutions, finds loopholes, and also brings QAs and developers closer to providing a robust solution that makes customers’ lives easier and error-free.
Not all the questions are relevant in all the scenarios it depends on the size of the company and the nature of the testing task we are provided with.
To ask better questions learning more about the product’s functionality by reading the documentation properly or setting up meetings with product experts and clarifying the flows and doubts arising during the discussion can help in extending the questions in the framework discussed to test better.
Happy Testing :)
Author: M M Kishore
Stay connected and stay informed with ProductPanda! If you’re a recent graduate who’s hungry for tech-knowledge, make sure to follow us 🎉 on our journey 🚀 .
