"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.

Tuesday, August 15, 2006

The first customer is always a tester

Hi Reader,

How many developers do realize, it is a Tester, who acts as a customer, when an internal release is taken for testing?

How many testers realize that they need to help the developers after rejecting a build for testing?

Are the above questions essential for you?

While you try to answer the above questions, I would want to help you with some gyaan**, I got, either through someone or through mistakes.


_ The first customer is always a tester _

I have had an experience of rejecting a few releases that were made to me for testing, before releasing it directly to the customer. Yes, I did my job well, so did I reject the release.

Sometimes, it so happens, you have to wait for your managers approval to reject a release and there is nothing wrong in it, since, we are not in those loops, which has the discussions of business needs and customer dissatisfaction.

I need to tell you, when can we(testers) reject a build?

  1. Reject a build/release, if it fails in BVT (Build Verification Test)
  2. Reject a build/release, if it even fails to install on the target.
  3. Reject a build/release, if it fails to come up after the installation.
  4. Reject a build/release, if it fails in core functionality.
  5. Reject a build/release, if the bug, which was supposed to be killed, is alive and active.
  6. Reject a build/release, if the previous working features, works more with bugs.
  7. Reject a build/release, if there is no time to test, even basic functionality.
  8. Lots more... (context based)

I also need to tell you, what is the way to reject a build?

  1. Before you reject, ensure, you have solid proof to support rejection.
  2. Before you reject, go through pointers from the test plan, which has the criteria to reject.
  3. Before you reject, state it clearly in the mail you draft, as to , why you think it can't be tested?
  4. Before you reject, discuss it, informally, with the developers/testers/lead/manager. Don't give them surprises.
  5. Before you reject, plan on the help, you are going to provide the developers/management, in an effort to make the next build, a better quality one.
  6. The mail you draft should be soft and not in a way that, you are pointing finger on a particular developer.
  7. Be a good customer, to a developer.

I should not forget to tell you, What should you do after rejecting a build?

  1. Sit with the developer, work a way out to fix the blocking issue, provided, he/she needs help and is comfortable, working, while having you next seat.
  2. Engage yourself, in an activity, preparing for the next release.
  3. Request the developer, to review his unit test cases. As of now, I would put it in a way like this "Hey XXXX, there have been wonders when a fool looks at something, similarly, I would like to do a wonder with your unit test cases, would you want to witness it?
  4. Utilize the time, you may have, after rejecting a build/release, in improving yourself.

_ End of _The first customer is always a tester _

"Dont feel bad when she rejects your love, just because you rejected her build"

Thanks and Regards,

Pradeep Soundararajan

pradeep.srajan@gmail.com

5 comments:

Anonymous said...

I really love to read your posts.
I only wish everyone would read them and also apply them.
Of course every developer should think of testers as customers. Sadly, only the good ones do that :).
But our job, besides making sure all is good enough to be launched, includes trying to make everyone and everything good enough (including people and ourselves).
And by good enough, I really mean good enough and not perfect. Because if you try to make it perfect, then you will never release it.

Thank you Pradeep for shedding light into these issues, I hope many read this and understand :).
Good luck,
Victor

Anonymous said...

This is a very good post came out from your experience.Thank you for sharing the experince Pradeep keep up the good work!!!!!

Mysorean said...

Haven't yet come across a tester as committed as you are! This is a great job! Keep it up!

Anonymous said...

I just want to point out (or) clarify one thing. you have mentioned that if the release fails in build verification test, tester can reject that.
I feel sanity test is more appopriate term than BVT.According to me BVT will be usually done by developers before releasing to test team and tester starts with sanity.
correct me if I'm wrong...

Pradeep Soundararajan said...

@ Suha

You are right, but I did not want to use the term "Sanity" testing, since till date, I have not found a proper meaning for it.

It shows, in your organization or experience, BVT was done by developers, but usually, in most product companies, I have been, testers do BVT.

I have never written a post about Sanity testing, since, people would come out asking "What is smoke testing then?", I may have to answer off topic and the stuff which is usually grinded in all testing forums. A 100 years to come , people will still keep asking "The difference betweeen Sanity and Smoke" and yet, no one would get convinced.

Thanks for the thought provoking comment