Which of the following design will be helpful to pack the pizza, considering all the relevant terms? I pointed towards the three shapes (circle, Pentagon and square) drawn on the paper and asked the candidate.
Carrying 2.5 years of experience in software testing, the candidate was expecting questions about testing (testing definitions, difference between priority and severity and ultimately bug life cycle). He thought for some time and then answered that as per him all the three designs were suitable for the pizza packing. I asked him to consider all the terms of cost, safety and delivery and still his answer was same. The interview was over.
During my nearer to a decade career in software testing, I have taken around 100+ interviews and believe me, I have never changed my strategy. Since the beginning, when I was a novice for the interview process, I had a clear picture of what kind of people I wanted in my team.
As per me, software testing is not about learning a language and implementing it. It is something more than that and that makes it different. The good software tester must be able to create new ideas continuously. Because testing is not about just executing documented test cases and sending a report with green and red marks.
Software testing is the most important part of project life cycle, where quality is being verified and improved. And when you are holding that big responsibility, constant evaluation of yourself is mandatory. And evaluation here means training and improving brain’s capability to generate new ideas.
What You Will Learn:
Someone would ask. Follow me:
Rather than testing, the important part is to understand what is to be tested. Understanding features of product, details about what the product can do and cannot and finally relating the product to anything routine
For example: most of the time, I try to relate the application/product to be tested with real-life objects e.g. knife, car, table, purse or coffee mug. Relating different modules of application to different parts of related things make it easier for me to think about how to test the same.
Let’s take a deeper dive. Suppose I want to test Google.com website. Let’s relate it to a table.
The basic idea over here was to relate the application with real-time objects and then it becomes really easy to generate ideas to test it with all possible perspectives. But to relate the product/application with a real-time product, you need to generate idea. :)
While testing the product, most of the time we prefer to follow the documented test cases and stop our brain to think about other ideas because we presume that we have generated all the ideas about testing while creating test cases. WRONG!!!
Ideas cannot be generated in a single go. The more you think about the product while being in real time events, more ideas you will get.
Let’s take it this way – you have to test Google.com and you related it to table and created test ideas and documented them as test cases or test scenarios. Now, try to relate the product continuously with whatever you are doing.
For example: While drinking a glass of water, when I compared Google.com with glass, I could co-relate that the way disposable glass can be used for many purposes –
Google.com can be used to access many options available from Google like Gmail, Google+, calendar and many more and in different supported languages too.
So here, the point is – idea, idea about how to use the product and how it can be. And so, to understand usage of product/application, you need to think as an end user in different situation trying to use the product as per his/her convenience, comfort and requirement.
What happens when the developer/manager defer the reported bug or even do not consider the bug as a BUG? Generate ideas again. You need to advocate your bug and for that you need to provide a real-time example and to provide a real-time example, you need to generate ideas.
For example: While testing Google.com, you found that for particular language all the features were not working properly. Your bug was deferred saying the language was rarely used and so it was not risky to attend the bug in a future release.
You need to argue and advocate – what happens if the rare usage happens multiple times within near future and the word spread by mouth about some features do not work? Won’t it be like having ladies’ bogie on the train and using it as pantry by assuming that no lady will get on from next few stations?
Enough to understand the importance of the bug, I think. So ideas will help you to explain the bugs and would make it easy to get them resolved.
Ultimately, ideas are the basics of software testing. There are very few fields which really need a continuous and extreme flow of ideas and software testing is one of them. So, rather than doing monotonous testing, get your brain work and generate ideas.
After all, one idea can change the world! :)
About the author: This awesome post is written by our team member Bhumika Mehta. She is a project lead, carrying 7+ years of software testing experience.