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. The 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 we’re 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 the 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 the user guide and installation guide. We just tested functionality and product flow as we were struggling with the completion deadline. It took me half an hour to explain to management 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 the 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 suggestions to improve the quality.
Today I am going to talk about some points or testing tasks we forgot or have intentionally avoided for years while testing.
5 Most Important Testing Tasks We Tend to Forget
#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, the same will be the reaction from our customers 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 a 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
#2) Pair Testing
While playing a jigsaw puzzle, if you have a 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 for tire puncture and advises us to take care of the things to not face the situation again.
Yes, the 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 the 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 the narrow down the 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 of GUI and performance too. Because customer always wants a complete working product and for that, in situations, he may even consider extending the deadline!
Conclusion
This was my small attempt to educate all the testers on these common testing tasks. I 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 appreciates good ideas and innovations but hates monotonic work, people and the environment.
As usual, I am excited about your questions and discussion. Please tune in…
Agree. Most of the time we forget to test documents and user manuals.
I like the way you explain. Thanks you for these great posts.
Thanks
Nice post. As a tester we are all forgetting above issues and mostly focus on Functionality. I like this post. Great appreciation to bhumika.
Very nice article, Bhumika. You narrate the situation in simple and clear way. We also had few instances, where customer reported that something not working as mentioned in the document. We should also be very careful with the support configuration documents, which provides the information such as – Browsers, OS we support to run our application.
We follow SCRUM methodology and most of the tasks such as – verifying functionality, documentation, performance, Database migration/upgrade, testing on cross-browsers, UI – will be covered within our sprints itself. However, we still perform few non-functional testing activities as a part of release testing (Service pack release every month and suite release). Such tasks include – Upgrading / Migrating few big customer databases, Setting up the application on customer like environment (setting up application server, web server and Db on different machines), Single Sign-On, File uploads (including Demilitarized Zone), Web services.
A nice read. Thanks for sharing Bhumika.
Just a small correction in the ‘About the Author’ section. This seems to be a ‘guest’ post and not gust.
Good Post !!!!!
Nice article mam..
I want to ask you one question
I am working in small organization
while doing testing they always telling me that do only functional testing is that ok?
or i should give attention to other type of testing also we are use agile development model
my manager some times not follow the requirement
I am expecting answer soon
@Sheetal, @Mayank, @Hariprasad, @Sid, @Latha
Thanks for your readership and glad to know that you like the post.
@Rahul Sehgal,
Thanks for those kind words and thank you for showing the mistake. We appreciate it.
great post !
attention to details and planning is key to success of testing .
@Bibhishan,
To grow as a good software tester, its important to consider all the sides of testing. Only functional testing never helps. You can convince your manager by finding some critical non-functional defects that how much important it is and how seriously software testing should be take care.
This is a nice compilation of some obvious things which sometimes get skipped due to tight deadlines or due to limited time available for testing in the first place!
Nice article .. Thanks for posting..
Great Article Bhumika…
Thanks 🙂
HATS OFF…your information is clear,informative,simple and easy to understand..great article for a amateur tester..Thanks Bhumika
Really very nice post….Thanks for sharing this info.. Keep further posting.
I do agree 100% with the third point, to know how it was fixed helps the tester to define his/her retest and test regression especially for the weird bugs. Personaly, I have this habit to ask the developer, what was the problem and how you reslove it.
Thank you so much for this article, very helpful 🙂
Very useful indeed. Thanks so much for sharing.
Thanks so much for your post!
@Bineet, @Anil, @Minh Nguyen
Thank you so much for you readership and for the kind words.
awesome article…
Great Article. Good Job.
A very nice article , very informative and easy to understand. Thanks for sharing! 🙂
Totally Agree..Good points are mentioned..Thanks for sharing this article.
Nice article. Thanks for make us realizing the truth.
This is very good article and can be used by every tester in his day to day working.Thanks for all the efforts you made Bhumika.
This is very nice article,Thanks for sharing.
nice post…and bestr learnings from article.
@Bawinder, @Nafisa, @Deepak, @Sangram Kumar, @Chandrasekar, @Rishav, @Pravin, @Deepa
Thanks a lot for your readership and encouraging words.
Thank You Bhumika Mehta 🙂
very nice article.
Got an idea about how a tester thinks.
Really all your articles inspired me to become the best tester who ensures and improves the quality of the system.
It is really useful stuff. Good work “Bhumika Mehta”
@Mila, @Aslam,
Glad to know that the article was useful. Thanks for your readership.
This was helpful
Very Helpful and awesome article.
Brilliant Post….thanks for making us better testers.
@Sapna, @Rohit, @Inder
Thanks a lot for your readership and happy to know that the post was helpful.
nice post bhumika
Hi Bhumika, thanks a lot for such a nice information. i would like to request you to share some more information on this and like wise any other such things.
regards,
Ranjit
Thanks Bhumika . . . . !
Article is so interesting…
Will be more useful & I will always keep these points in my mind while testing.
Regards,
Ajay
@Arup Ashish, @Ranjit, @Ajay,
Thanks a lot for your readership and kind words.
Awesome blog to know the importance of QA in each and every step of project as well as real life.
I obviously follow all these stuff and make sure that the product / project works as per customer expectations and not as per team’s expectation.
Might be clashes fall in, if we try to raise bugs or issues (with dev team or internally in QA team), but the ultimate aim/goal is to make sure that the work is done smoothly and confidently.
Hi,
Thanks , nice article.
most of the time in agile process requirement is not clear from PM and Developer site. So hesitate to release the task.
Let me know what can I do for the above scenario ? As poor documentation future release not able to convenience PM ,developer that scenario already tested.
Is project completion testers responsibility?
I mean if a tester wont get a build from developer for testing at specified time. What exactly is testers responsibility?
Hi Bhumika, Thanks a lot for writing this post. I am facing same issues and this post gives good insights on how to prioritize testing during time crunch. I will try to implement it at work and hopefully release a stable build live. 🙂
Here is a similar story – about installation documentation correct, but still not being used correctly. A manufacturer created a comm router that did everything the IBM comm router did. The dip switch settings were even the same, so you could even use the IBM documentation, or swap out the IBM for this cheaper model.
The trouble was, the dip switch was mounted upside down, so you counted right to left when setting them on/off. It was in the manual – at the bottom of page 4.
A yellow WARNING sheet in the shipping box to highlight this minor difference would have prevented a lot of heartache, customer dissatisfaction , returned units , and lost credibility.
Even I feel that functionality is important but performance should be given due importance too.In a specific instance my device had severe performance issues under load scenarios which was even impacting basic functionality
This article was very useful. Though we are doing enough testing, we got to know on which area we have to concentrate to avoid the defect from end user. Thank you Bhumika.. 🙂
Thank You Bhumika. Excellent stuff that you are placed here
Hellow Bhumika,
It is wonderful .I have a small doubt about reporting to the superior about bugsat and results .will you please send a mail are doc how to mention what are the things
to mention ….pls
Hey I wonder if there’s a way to actually test the documention, using something like Cucumber or Behave?
If the original problem was that the documentation wasn’t tested to see if it was accurate, then maybe running it through some kind of automated test would uncover issues.
Anybody know if that kind of thing has been done before?
Well Written
thank u….its very helpful