5 Tips for surviving as a Tester

  • Article

These tips apply for all testers, not just Microsofties.  What other tips would you include in this list?

Bend over backwards to help your dev
You’re going to be breaking his/her code for the rest of your careers together, so you want to have a great working relationship between each other.  First off, establish trust with your dev.  If you say you’re going to buddy test something by such-and-such time, get it done.  Actively seek feedback from your dev on what features are lacking testing, how you can do more testing, etc.  And whatever your dev needs from you, like ad-hoc machines in the lab, status of nightly runs, get that info to him/her asap.  It won’t take long for you to see the benefits of going out of your way to help your dev.  And it’s not just about using common sense, it’s about making sure you’re doing your part in helping the team succeed and how you would want your team to help you out when you need it.

Leave appropriate comments in every bug you verify and close
1 year, 6 months, or even just 3 months down the road you won’t remember how you verified that bug fix.  If you can no longer follow the original bug repro instructions (sometimes bugs morph, other times the fix doesn’t allow you to get to the end of the repro), leave comment explaining exactly what you did to verify the fix.  And once again as common sense would dictate, make sure the build number that you verified the fix on is written some where in your bug tracking database.

Never Assume Anything
Never assume that

  • Someone else is covering that scenario – Test everything you think of.  A little overlap never hurts.
  • Triage (or whoever is reading your bug) will “just get” the bug.  Always be explicit with repros, even when it’s completely obvious (to you) in the attached repro picture.
  • A simple scenario could never be broken.  Always, always, always test – even if it is the simplest feature or part of the feature in the world.

Don’t just get it in writing
Email just isn’t enough.  If you’re not going to cover an explicit scenario, get it in writing in your test plan.  If you’ve discovered an issue and the issue isn’t going to be fixed as stated in an email thread, make sure it is in your bug database.  Email is like leaves on a tree.  You get a lot of new email in, you save a lot of email off to the side (like leaves in a large trash bag which makes for excellent tree house furniture), but after a while, saved old email just gets older and unneeded, just like your furniture that is now collecting spiders, so you throw it out.  Make sure any major decisions involving your test strategy or test bed or written in the appropriate document / database / forum, etc.  And yes, that was my worst analogy ever.

Learn from the bugs you missed
Ask yourself why someone filed a bug report in your feature area that was later fixed?  What could you learn from this bug?  Are you missing other similar tests?  This process is actually called “Root Case Analysis”, but you don’t have to do the formal RCA work to learn from bugs that got away from you.  So many times, I find myself staring at my monitor just wondering what I’m missing.  The answer to that question is just doing a query of fixed bugs not opened by me.  Surprise yourself by seeing just how much you can learn by doing this.

Got a tip?  Add it to the list!