“I really appreciate your concern for the product and making us helpful in understanding end user perspective. It’s going to be very helpful. Thanks for the good work and keep it up!!!”
This was the last e-mail of 21 e-mails long chain, from our client. It was midnight and our product release was delayed due to a critical bug reported by us. You might think, what is new in that? It may happen for many times. But this was really different as the critical bug we reported was not a result of any documented test case.
After completing regression testing for the last time on that evening, I was just playing with product. And what does that mean? You are free to do what you are not supposed to do. Based on my experience and project knowledge I had some ideas to test the product apart from our test repository. But that’s what called Exploratory Testing. And that exploratory testing found a critical bug which was related to server hang issue while doing something unexpected.
Being a fan of exploratory testing, I love to explore the product in different ways. For me, the definition of software is:
“It should do what it is supposed to do and it should not do what it is not supposed to do.”
Limiting testing boundaries to check whether supposed to work things are working or not makes you incomplete tester. In fact, tester’s life starts when documented regression testing ends and results are updated. Looking product from different perspectives and understanding end user requirements in different scenarios make the whole lot of difference, so today; let’s understand together, how that difference can be made:
How to look product from different perspectives?
#1. Understand customer / end user
Software testing is all about checking quality of product in terms of customer satisfaction. How do you know customer’s view point? Answer is simple – you have to be customer. OK, let me correct. Being customer will not be enough. You need to understand how the customer wants to handle the product. No two customers who bought same raw materials will prepare same recipe. Yes, the product we develop / deliver is a raw material for customer’s business and they have different mindset about using it.
Being a software tester, we need to check purpose of product and not the object or aspect of it.
Let me give you some real life practical examples about it:
- Scissor was never limited to cut paper only. Cutting is the purpose and not the paper (object).
- Cell phone was never limited to calling only but “able to call” is always the basic purpose.
- Storage boxes are used to store but safety of material stored is as important as storage.
Understanding stake holders and wide range of their expectations should be the baseline of exploratory testing.
#2. A mindset
While looking for (let’s say) job requirement ad, do you see that jackpot ad in between the page with bold font? Most of us do not (believe me, it’s true). Because we have instructed our mind to look for what is useful or to be checked. Anything else is of no use and so mind denies recognizing.
Open your mind and do not set any expectation when you start exploring product. Always remember, it’s not OK if the product is doing what it is supposed to do. It is also important that it should not do what it is not supposed to do.
I remember one classic example about it:
In Linux, ‘cat’ command is used to check content of file and ‘ls’ command is to check content of directory. Working with Linux and that too in software testing for five years, I never thought to do cat <dir name> because my mind was set that for dir content I need to use ‘ls’. True I was. But the reverse side of expectation where product was not supposed to behave the way it was not supposed to be was wrong. One of our customers, who did not know Linux well, did cat <dir name> by mistake and the system crashed. We paid for the mindset.
Be always ready to make mistakes with the software because that is what end user is going to do. To test the software, you have been trained but the end user will not be as trained as you or he/she will not be technically as expert as you. Also, he/she will do anything with the software when they are in trouble. Think about those scenarios and provide testing feedback. Life of the software and yours (as a tester) will rock.
#3. Know the competitors
While testing any software application for your client, did you ever care to know and understand other software with same purpose? Did you ever care to suggest some useful functionality you observed in competitor’s product? It does not fall in our job profile, is the answer most of the time. But do you know the benefit of doing it?
Here are few real life examples to make you understand the point:
- Don’t you like that designer most that just not stitches your dress but provides you input about matching accessories?
- Don’t you like that pizza brand most who just not make great pizzas but home delivers on time?
- Don’t you like the photographer who just not takes good photographs but suggests about different kind of frames for the photo print?
Everyone wants to have something extra for what they pay for. Our analysis of competitive software can work the same way for us. The customer always likes to hear valuable suggestions – mainly comparative suggestions to make the product more useful or marketable.
Also this kind of comparison and analysis of same range of products make our analysis more powerful and eventually we create a treasure to which we can go back at any moment and find something useful always.
Over to you
Ending this post here, knowing it is incomplete. Do you want to add something or want to wait for continued part in next post? I welcome your suggestion and inputs to make software testing community make more effective and productive.
Thank you for reading and sharing appreciation and views. We are overwhelmed with the positive response from the readers.
About the Author: This is a guest post by Bhumika Mehta. She is a project lead, carrying 7 years of experience in software testing. She appreciates good ideas and innovations and risks too. And of course hates monotonic work, people and environment.