Where a Tester Gets Answers in Case of Uncertainty?
I think everyone can relate to this. Imagine, you come to a new project/company and you know almost nothing about it. The first weeks are quite stressful, as you need quickly figure out how the product works.
A pretty common situation, when a QA Engineer needs to identify what particularly has to be tested in some task. Where to run and whom to ask questions? When the task itself is unclear and requires some additional info. What to do if you are not sure is it a bug or not?
Let’s break it down into different scenarios and establish our action plan for every scenario.
Scenario #1: the task is dedicated to a feature (or a part of the feature) that needs to be verified has pure description with low details
This scenario describes WHAT this feature should do.
This is a very common scenario for a newcomer or if a person replaces someone in the team and is not aware of details of this particular task. If we have some question that was not revealed earlier and it’s appealing to a business part, we have to ask the Project Manager or someone who has that knowledge of a product’s business logic.
Here you can read more about the importance of good requirements and QA role in it.
Of course, you might ask a Developer for this matter, but let me ask you something. How would you know the Developer understood the requirements correctly and passed you actualized info? QA Engineer is the one who checks the expected result. If a tester got wrong info in the first place the whole testing activity would be jeopardized. So, my advice would be to double-check requirements and choose the source of truth wisely. Especially, when it comes to a product’s business logic.
Scenario #2: the task is releated to a technical side of the product (for instance, frontend/backend tasks)
This scenario describes HOW this feature will be implemented.
If some aspects of this task are unclear to QA Engineer, s(he) has to cooperate with a particular Developer who is a bearer of this technical task. As a result of this conversation, clarity should be given in what this task has to do and bring testing ideas to a tester.
Often, the QA Engineer is not the only one who gets benefits of such discussions. The Developer also gets some insights about what to take into account when developing a feature with more understanding of how the tester will be performing the test verification.
Scenario #3: doubts if it’s a bug or not. Whom to ask before creating a ticket?
This scenario describes WHY you think it’s a bug.
- is the discovered bug based on a good sense?
- have you found some evidence in the documentation or did you speak with the Product Manager?
- maybe the Developer never implemented that simply because it wasn’t specified in the requirements?
- or Developer implemented that behavior based on his own vision and experience?
- is the current behavior differs from other platforms (Web, Android, iOS) and why?
Before creating a ticket in case of doubts, ask a tester with more knowledge about the product, ask a PM in case of business stuff, ask a Developer in case of technical specifics.
Either way, we have to cut off our own or Developer’s assumptions and ask Designers and management how the feature should actually behave.
Scenario #4: bug was returned from Developer with the “it’s not a bug, it’s a feature” comment
Were designs and requirements have been changed but never actually updated and a tester has outdated information? If so, then it’s a collective mistake.
In other cases, in my personal opinion, such a scenario is not good for QA’s reputation (especially if you work long enough on the project to know literally everything about the product). It means, a tester never passes through scenario #3. As a result, a Developer starts working on this so-called defect, and after some investigation realizes it’s not a bug. I think the only thing that Developers feel at that moment is frustration, annoyance, or even anger. Time spent inefficiently. The solution would be to find out with QA, PM, Designer if it’s a bug. Once it’s done, we can decide rather the bug should be closed or should it be fixed.
These scenarios I find the most common. But it doesn’t mean this is a full list. Let me know if you have other scenarios that might be helpful for QA Engineers to feel more prepared and confident. Remember, additional information received from the outside can dissolve the uncertainty and spread the light on how things should work.
