The conference room was silent and every face was staring at me. Just ended client call left all of us clueless about how we can rectify the mistake. Client was very unsatisfied and he was thinking that the product was not tested at all. When my manager tried to argue that all the functionality were working well, he cut shot him saying “What is the use of functionality, if users are not able to install the product?” We were stunned.
We borrowed two hours of time frame to look into it and finished the call. But no one moved out. Everyone was asking a question – How can it happen? Why we did not catch it?
I knew the answer.
We did not test the documents, especially user guide and installation guide. We just tested functionality and product flow as we were struggling with completion deadline. It took me half an hour to explain to management about what went wrong and why we had to face the situation.
That incident taught me big lessons in my testing career.
As a tester or senior software tester or QA Manager, most of the time, most of us think that we know how to test, what to test, how to decide coverage, and how to define testing scope. We assume that whatever we learned from years of experience while doing software testing, has made us an expert. But we forget the definition of QA – we are not supposed to test the quality, we need to provide suggestion to improve the quality.
Today I am going to talk about some points or testing tasks we forgot or have intentionally avoided since years while testing.
#1 Documentation Testing
While you are excitedly following that user manual of a refrigerator to make it work and if you are not able to switch it on, what would you do? Yes, you will call to customer support. They will ask you every detail and then will tell you that you need to connect it to UPS first and then the other end of the cable should go to the main plug.
What will be your reaction? I will shout – then why you did not mention it in the user manual?
Yes, same will be the reaction from our customer if we miss or do not test user and installation guides. How many of us really consider it as a part of testing and religiously test it, whether or not it’s been asked to test? I know, only few hands will be raised.
Most of the time, we blame our client for shouting at us, for change requests and for not understanding the workflow. Have you ever tried to put yourself in their shoes? When the customers will come to know that the company has distributed a faulty user manual with a great product, surely it will affect future sales.
Recommended read => How to Achieve Your Software Testing Documentation Goal and How to perform test documentation reviews.
#2. Pair Testing
While playing jigsaw puzzle, if you have partner, the puzzle turns more interesting. You will be able to resolve the puzzle faster, you will come to know about better ideas, you will know how to work as a team.
Again, the same thing applies to testing. No matter, how expert you are and how many years of experience you have, pair testing is always more effective. If you pair up with a fresh mind, you will come to know about better ideas to test and if you pair up with an experienced fellow, you will be able to understand different scenarios and many other tricks about testing.
#3. Studying Bug Fix
Don’t disregard this title by saying – we do re-testing and regression testing.
When a Tyre repairer repairs a puncture, he just does not repair it but he observes other things like what kind of tube has been used, what was the reason of tire puncture and advices us to take care of the things to not face the situation again.
Yes, developer fixes bugs and we, as a tester, verify them and mark them closed and we feel satisfied that we did our job. Do we even try to understand what kind of code fix has been applied by the developer? What kind of changes he has made?
Don’t you think this little knowledge can really take our testing abilities to the next level?
Understand how the developer fixed the bug (not all bugs) and try to correlate it with other areas of the product. What if the developer would have applied other logic to fix the bug? Ask and discuss.
#4. Connecting product testing to real-time
You are participating in a competition. You are given a bag of grains. It’s a mixture of wheat and rice. To win a competition, you need to take out the wheat from that mixture. Time is limited. If you try to pick the wheat from the mixture manually, you have already lost the competition. Use your mind. Use a sieve and separate the wheat from rice. Isn’t it simple?
Now, co-relate it to your testing activity. Understand concept, use relevant tools, keep yourself updated, do research in free time and increase your valuable treasure of knowledge. Whenever and whatever you test, try to correlate it with real time scenarios and apply the same logic. Your testing task will become simple.
#5. Learning Priorities
Most of the time while testing software we face deadlines, pressure situations and continuous hammering from the dev team. These all lead to narrow down scope of testing and we try to show the test result report as green as possible. And needless to say, this hurry to show the result report green makes our career with red question marks. :)
Yes, deadlines are always there. And with time we need to understand, learn, and practice priorities. Defining priorities while testing is an important part of making our task qualitative. No matter, if a developer has asked you to check only functionality, you should take care about GUI and performance too. Because customer always wants a complete working product and for that, in situations, he may even consider extending the deadline!
This was my small attempt to educate all the testers on these common testing tasks. Hope you won’t forget these tasks now onwards.
About the author: This is a guest post by Bhumika Mehta. She is a project lead, carrying more than 7 years of experience in software testing. She appreciate good ideas and innovations but hate monotonic work, people and environment.
As usual, I am excited for your questions and discussion. Please tune in…