The #1 mistake Testers should avoid

In our lives, we listen to the people we trust. If we are suggested ways to improve our lives by a passerby stranger, we never pay attention. We only heed to the advice of our trust worthy resources: our family members, dearly friends, mentors, subject matter experts etc.

Now as testers, we suggest ways to improve the software. These could be as little as reporting bugs that expose potential vulnerabilities or those can be as big as introducing a new process in our Development practices. The ones listening to us will only listen to us if they trust us and respect our opinion.

LoseTrust

That’s why the biggest mistake we should avoid as testers is ‘to lose trust’.

How to gain trust or how not to lose trust has been a subject of interest of many authors, and all those findings are relevant. Other testers have also written in detail upon this subject which are worth reading. And here is my top list of things that break trust in a way that it becomes hard to re-build.

Asking basic questions about the domain

A friend of mine who is business analyst by profession suggested in a recent discussion that if you go to a client for finding their requirements and say things like: “Okay, tell me how you do it and I’ll note it down” never works. You have to start the conversation in an engaging way after doing some research on the subject. For example, if you are visiting a Bank, you might be better asking: “So what happens once an account is dormant?”.

For the tester, the rest of the team is like a client and you need to learn the domain.

Reporting bugs that are not bugs

If the bugs that you report are not reproducible consistently or prove out to be duplicates of existing bugs or prove out to be behaving as desired, you’ll lose your credibility as a tester. Just yesterday a colleague of mine mentioned that a new tester in their team reported a bug and sent out an email claiming it to be “Bug of the Century”. By afternoon, it was evident that the bug already existed in the database and was scheduled for the release.

Acting as a fake tester

When something is in demand, copies of it get flooded in the market. Such is the case in the recent years that the high demand in testing profession has resulted in some fake testers. If you don’t ever want to be one, read this advice from James Bach. And read the fake tester’s diary column in Testing Circus magazines.

Have you experienced a situation where you lost trust as a tester or you had a tester in your team you didn’t trust? What was the reason in your case?

Tags:

5 responses to “The #1 mistake Testers should avoid”

  1. Ather Imran says :

    Good point – trust is certainly the credibility-value add in any relationship!

    Like

  2. asikfromindia says :

    I agree !!! but this should not be untill u r in ofc !! if you are in the same attitude after ofc then ????!!!

    Like

  3. majd says :

    Interesting thought. I think we should be behaving consistently during and after office hours and establish trust in our professional and personal lives. Putting a mask when you are in office never works in the long run 🙂

    Like

  4. Zaid says :

    Agree …
    But IMO “Bugs to achee hotee han” if reported sensibly either in future it marked as “Not a bug”, “Not reproducible”, “Want Fix”, Duplicate
    1. Not A Bug — When a tester report a bug with some strong comments and Dev not agree with tester and mark it as Invalid that doen’t mean its really not a bug. IMO if tester >60% sure then should follow the issue even that its not fixed. There might be very good chance in future client report this issue and want this fix then at this point all the stakeholder look at QA with red eyes and you feel “Kash ya bug me report kar detta”.
    2. Not reproducible — Some times an issue not 100% reproducible and required some specific env which steps still not identified then IMO we should report the issue with possible steps so that its in our development team radar, Don’t be hesitate to report such issues but make sure your are person who stay behind the reported issue and be ready for some negative reaction from dev side.
    3. Want fix – A bug that consider as valid but not a candidate to fix. Report it with mindful comments be in mind similar issue might be raised from customer side with bigger pressure.
    4. Duplicate – IMO we should report these issue might be new and update the existing, depend on the issue and reported issue.
    4.1 If your steps and already reported steps are similar with similar env then no action required
    4.2 if your steps and already reported steps are similar but different env then only add your comments into existing bug.
    4.3 if your steps and already reported steps are little bit different and dev say its similar then not 100% rely on dev and edit the existing one with your steps, so that whenever CCI perform tester should verify both the reported steps.
    4.4 If steps are totally different and your are >60% convinced its a different issue then report a separate bug with clone of already reported issue.

    Like

    • majd says :

      Thanks Zaid for bringing in your point of view and agreed that testers should not stop reporting bugs and keep them coming. As you can see that tester’s credibility is built upon what issues brought up by that person, so that is where caution need to struck.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s