"Some birds aren't meant to be caged, their feathers are just too bright"- Morgan Freeman, Shawshank Redemption. This blog is from one such bird who couldn't be caged by organizations who mandate scripted software testing. Pradeep Soundararajan welcomes you to this blog and wishes you a good time here and even otherwise.

Wednesday, August 09, 2006

Million questions a tester should ask

Hi Reader,

I was wondering, "is there a way I could have learn't testing more effectively?", than what I did, had I asked *good questions* to myself. This post is a result of it, through which, I want to guide (misguide) upcoming testers through a set of questions, good ones, to be more precise.

"Pradeep, how can you be sure that *good questions*, lead to better understanding of a subject?"

Hey, that itself, is a good question, you may ask at the beginning of this post.

Before, I tell some gyaan, let me take a situation, which makes you more confident to read this post.

Let me touch a sensitive part of all of us, money. You must have asked yourself, "Am I earning enough?", which would have lead to -

a) Comparison, of your salary with your peers ( a common mistake, though).
b) Change of a job/company/profile.
c) Plan for a side business.
d) Change the way you work.
e) Change your attitude, all together.

Isn't at least one of them true? Have you never witnessed your friends doing the above?
If not, time to hit the close button which is appearing on your right top corner of the window.

_ Million questions a tester should ask _

Now, I am not going to list a million questions but just giving you an excerpt from the article, I was planning to write and stopped it mid way. ( I am ashamed to say, I do not have time, right now)

Assume you have been asked to frame a testing process for the company, which is establishing a new testing team, answering the following questions, may help you -
  1. Should I be getting more clarity from the management, as to what kind of testing team, they are planning to establish?
  2. Should I spend some time in documenting my understanding after a meeting with them and get the document reviewed?
  3. Should I read, process documents, case studies, understand what process is followed by other companies?
  4. Should I need to attend some training on the process and process management, in order to gain more understanding on the documents, I read, or will be reading? If "yes", who are the best trainers, I can talk to?
  5. Should I write a document of my whole understanding after the reading/training and get it verified by someone who is deemed to do that, which will help my company to be confident of my proposal?
  6. Before, I write a proposal of process, should I need to consult the developers/management to ensure, it meets their requirements and is easy for them to implement or adapt to the implementation?
  7. Should I be directly taking the process from somewhere, which may suit, or, I need to tailor it to the needs?
  8. Should I make the process tester friendly/developer friendly, or both?

..... lots such, without which, your process is a screwed up one. I quit a company, for its process being screwed up by a person who asked only one question to himself "How much hike will I get after I frame the process for testing?"

Now, let me take another example -

Assume, you are about to raise a bug you have found, asking the following questions, and beyond, may help you in writing a fantastic bug report -

  1. First, of all, is it really a bug?
  2. Am I sure about the way I reproduced it?
  3. Is the same or similar bug already raised by someone else, existing in the bug tracking system?
  4. Is there any other possible way, I can reproduce the same bug?
  5. Am I clear about whom should I assign the bug?
  6. Have I written the description of the bug, in a simple, one line sentence?
  7. Have I written the "steps to reproduce", in a way, that any tester/developer, can reproduce the issue, with the help of that?
  8. Have I given them the test input/files, I used to reproduce the issue?
  9. Am I sure that whatever I wrote in the "Observed Result", is same as what I observed?
  10. Am I sure, the "expected result", is the same as what the document/spec/design expects it to be?
  11. Have I given any extra information, which may help the developer to fix the bug faster?
  12. Have I taken the logs and attached the same with the report?
  13. Do I know, where the problem is, to suggest a fix?
  14. Am I sure about the "Severity" and "Priority" to be set for the bug I have found?
  15. Did I miss out anything that may make the job of reproducing the bug, a difficult one, for the tester/developer, who is going to reproduce it?
  16. Did I include screen shots/snaps/video, supporting the bug?
  17. Do I have enough information to clarify someone, if they defer it?
  18. Do I need to ask some other tester to reproduce it before I log the bug?
  19. Is it a fantastic idea to first ask someone to read the information I have jotted down, and ask them to follow exactly what has been written and observe, what difficulty they are facing in reproducing?

Lots... lots ... but never ask yourself "Why should I spend so much time for a simple thing?" , that is the last question, you will ask yourself, if you would want to improve yourself.

_ End of _ Million questions a tester should ask _

A man died without asking any questions, God asked him “Did you ever use brains?


Pradeep Soundararajan



anurag said...

hi pradeep...
anurag here.
before reading ur blogs, i thought testing very boring.Now i am developing inclination towards it.People think that testing is a brainless job,but now i am using my mind more than ever.thanks

RamanujamManchikalapudi. said...


If anybody reading this all thru thorougly and again ask the same brainless question what is there in testing that person is brainless.


tarik Sheth said...

Great Post Pradeep, Truely Questioning is the way to know one's self..
Keep up the good work!!

Anonymous said...

Thanks Pradheep,

The way you present the each topic excellent. this helps lot of peoples like me who are entered in to the Testing has a carrier.

MOhan Reddy

chinnaiyan said...

Thaks for your wonderful job
Keep it up!!!!!

Anonymous said...

i read all your blogs,the way u have expressed it is very nice ,we can learn many things being a tester and choosing testing as a profession and testing many real time problems is really happy and enjoyable work

rahul aggarwal said...

hi pradeep,

i am new to this world of testing .. a novice .. recently started reading your blog ..

firstly i want to congratulate you for the initiative you took and the overwhelming response you are getting .. great work!!!

as i was going through this post and previous 1s before this...today i just felt like asking you this question .. i may sound silly but please excuse my ignorance ..

what is the difference between a bug , a defect and an error ?

thanks for all the posts.

keep well

rahul aggarwal