A brainstorming session with the team is always a learning experience.
This time, we had a different idea. We divided the team into two groups and decided to ask questions to each other for a common product – Phone. The only restriction was the questions should be limited to testing of the phone.
And the session ended with interesting unanswered questions and some better ideas to test the phone.
This session taught us an important thing – asking questions (sometimes silly even) helps in making product / application better and that is what matters at the end.
I want to support my point with this article.
What You Will Learn:
Being a tester, we know how the real world works when it comes to delivery and timeline pressure.
Even when there is no pressure, having clear and crisp requirement document is not something every tester can dream of. And in both above mentioned situations, testers are prone to assume: when there is no data available and decisions are to be made, assumptions are natural.
Recommended read => How to Deal With Bad Requirements as a Tester
Requirement document mentioned that the essay writing application should show author’s name. While testing, tester learned that there can be multiple authors for the same essay and they can maintain different versions of the essay.
Now, how to show author’s name for this situation? There is no clarity in requirement and no time/person is available. Developer assumed that the author’s name, who owns the latest version of the essay, should display and tester agreed on it.
Questions based on assumptions can be as below:
An application experienced a crash while the user tried to refresh the same page for the 7th time. Now, finding out the issue and reporting the same is good but when there is heavy delivery pressure, we need to have the right data to understand the risk of this specific issue.
For the above situation, if no data is available, a tester will have to assume that it would not be a routine case and can be taken care of later on.
For this case, the Questions based on assumptions can be as below:
From the above two examples, it is important to note that the assumptions that testers have to make and questions we should ask are not always just about the application, but sometimes might be about ‘what to do next, how or why’.
A curious tester, when observes unexpected behavior, ends up investigating and this investigation results in making him ask questions.
After observing an issue where the user was being logged out every 5 seconds, the investigation ended up identifying the issue as an automated query in the database that was executing every 5 seconds, and would clear out all the existing sessions.
Questions based on assumptions can be as below:
Thus investigation results into more questions, which actually helps in determining the right answer.
Having faced the same problem in the past, our human mind instantly retrieves relevant data and that data when applied to the current situation, gives way to more questions.
Based on past experience while working with Linux OS, I knew that rebooting the server possibly causes many errors to disappear automatically. Applying the same technique to the current situation, where the code was deployed and maintained on a Linux server, I observed that the performance of the application improved.
And questions were:
The experienced tester always analyzes data and questions about the possibility of patterns.
After the first version of launch, only 3 system crashes reported and product worked well for every other case. For the second version of launch, failures reported increased to 17. And for the third version of launch, failures reported increased to 47. There were no major changes done. So, why did this happen?
Well, while analyzing data, it was realized that for the first time, when the product was launched, there were only 3 centers which were rural and all the failures were from them.
For the second time, rural launch increased and so failure rate too. While looking into details, it was found that it is not the specific product feature; it was because of low network speed that was the issue. Thus, analysis of data available might lead us to a pattern of the problem.
Note: I am sure you can think of many more Questions you might have. This is just a short list for a basic idea.
Thus, a tester does not ask questions because he wants to ask lots of questions. There can be many reasons, such as:
But as they say, asking questions is an art.
So, the next important question is: How to ask a question?
Asking question is always being encouraged in the industry that we are working in. But if you see a negative or cold response to your queries, maybe you need to tweak those queries or need to polish your question asking skill.
Personally, although I encourage everyone to ask questions, I expect them to do some homework about it. It obvious that no one would like a guy who asks ‘where he can download Skype’ when Google is available :).
So, better apply following techniques while asking questions so that you can get maximum answers.
Ask smart question:
As they say, asking a question is the key to unlocking the world full of knowledge. If you observe a kid, he/she is asking more questions than an adult. Why? – Because they do not understand how to assume something. Just replicate child behavior, when it comes to information.
Keep asking, be curious, get clarification and testing will be easier, productive and interesting.
About author: This awsome article is written by STH team member Bhumik M.
Hopefully, this article has given some answers instead of giving way to more questions. If it did raise questions, please feel free to ask them in the comments below. :)