A real good article and worth reading!!
Once while at work I was getting my test cases reviewed about a
project/domain which I was new to and one of my colleague gave a strong comment
"Mr.X, please think of more cases".
I was a bit disappointed because already there were enough test cases
that it will take 3 days to complete a cycle and I thought "should I
further shoot at my own legs?" (The more cases I write, more I have to
test, it's painful, isn't it?) ..
I tried to defend that testing would become complex if more cases are
there than beyond the objective of the release/product requirements.
Ha! Thanks to what I told, he shared with me a great story which
happened in his previous company and it is one of the best lessons I have had
as a tester!
This (could be a) is True Story that happened in some company.
A digital camera was released in the market and after sometime a
customer came back complaining that........
Problem: The camera's software was crashing continuously while he tried
to capture images.
FIR: They first asked some basic information from the customer and made
an attempt to reproduce the issue but it was not reproducible.
Analysis:
1) Software is crashing - so they listed out all possible scenarios where
the software could crash.
2) Tried putting the camera to all listed possibilities.
3) Giving a report to the management that it was unable to be
reproduced.
Further Analysis:
Taking this as a challenge, a great tester had the following concern –
1) He was concerned what festival was it?
2) He was concerned what was the customer was trying to capture?
3) He was concerned what is the frequency of the crash the customer
noticed?
4) He was concerned about all other surrounding factors like temperature,
place where the festival was celebrated ... etc?
Outcome of Analysis:
1) The festival was Diwali or Deepavali!
2) The customer was trying to capture fire crackers, explosion,
fireworks display in an open ground at around 22 00 hours (night).
What a fantastic tester was he! He identified the problem and told the
developers
"The camera software is crashing when the viewfinder is black
(because of dark night) and a sudden gush of light through the firecracker
explosion is putting the DSP (digital signal processor) to a load/stress beyond
its boundaries to display the image. And at this point of time when the user
tries to capture it simply crashes" What he said was right!
Finally they fixed it and now today it's a robust digital camera!
********End of a probable true story*********
Summary of lessons
- Collect real time data for testing a product/application
- When you are unable to reproduce an issue, think out of the box, and think out of the black box
- When you are unable to reproduce an issue call someone who can dig deeper than you
- Don't assign test case draft to the person who is going to test it; he may omit complicated cases to bring down his/her complexity in executing it
- Review the cases with a non team member/customers/domain specialist/tester network
- When you release a product: anticipate and be prepared to face such situation
- Hate the product while testing and love the product after its release Emotional testing (new concept)
- Good Testers not only report bugs, they suggest a solution!
- Keep learning to be a good tester!
- Test all your products in India, its The Testing Bowl of the world!
- Don't terminate an issue just because you are unable to reproduce, it could kill a company!
