Be a tester first

I was talking to a group of individuals from testing community. They were boasting of the things that they do as part of their testing assignments. I am posting the conversation that I had with them.

Me: What do you do to test a system?

Group: Validate all the requirements that are provided in the form of specifications, UI mockup, rules etc and certify the product for quality.

(I was a bit overwhelmed, smiled and congratulated them on their achievement because as a tester they are doing so much and also certifying the product for quality.)

Group: Why are you congratulating us. This is part of our job that is given to us as a testing team.

Me: If you are doing so much, your client might be delighted about the quality of work that you are doing.

Group (a bit nervous): NO

Me: Why?

Group: Our client does not value us and often says that the testing team is not able to identify bugs that are being reported by the actual customers. We are testing and certifying whatever is provided to us as requirements, still the bugs come.

Me: So you are not doing ‘testing’

Group (confused): We are doing testing. We are verifying everything. We mostly achieve 100% requirement coverage in our testing.

Me: Wow. Then why are bugs coming in?

Group: Because the user can do anything. He sometimes go through the scenarios and does not know what are the right values to put in the fields. Hence it sometimes crashes the system.

Me: Didn’t you tried out those scenarios?

Group: We tried some of them, but on discussing with the development team we were told that these are invalid scenarios and the user will never use that.

Me: Wow. So the developer was creating it for some particular users and they already collaborated with them and told them not to run those scenarios on the system?

Group: No. The system was being developed for the users who will use it on internet. The developers never had idea about who the actual user would be.

Me: Then why didn’t you question that? Who are developers to decide that the user will not use the system in that form?

Group (Whispering): It is how it works.

Me: This is where the problem is. It is often seen that you, the testing team, is being driven by the development team. How can they know that user won’t be using the system in the form that they could not think about or are not able to fix? This is where you as a tester can add value to your clients. Before proudly certifying the product for quality, which is not your job anyhow (Read post), be a tester first!

You should never

  • Remove your thinking caps
  • Be driven by documented requirements
  • Be driven by developers
  • Stop testing once you execute the already created test cases. Read Michael Bolton’s Testing vs Checking series

Group: hmmm. But how should we convince the project manager on this. This might require extra time as well.

Me: Good point. It is not always easy to convince the stakeholders on time. There are two ways. Either you become rigid on implementing what I told above, which is definitely NOT the right approach or you can prove your point first. With proving I mean, show the benefits to the stakeholders that they can reap with the new approach. Showcase how the bugs are getting reduced post delivery. Practice the testing craft and keep on making the complete process more efficient with time. This will add value to what you do and will also be helpful in convincing others.

Group(thinking): Well we understand what you are saying but still not sure if the client will agree. We will try to practice what is suggested above.

Me: Thanks guys. This was a great transpection session that we had. At the end I will say

Think beyond boundaries. Take Control. Don’t allow anyone to define boundaries that you should confine yourself in while testing. – @VipsGupta

P.S. Thanks to Michael Bolton and James Bach whose transpection on twitter inspired me to write this down.