5 Tips for surviving as a Tester


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!

Comments (13)
  1. "Source Server" – The best "Hidden" feature in Whidbey

    Debugging [Via: Matt Pietrek ]

    101 Code Samples…

  2. "Source Server" – The best "Hidden" feature in Whidbey Debugging [Via: Matt Pietrek ]

    101 Code Samples…

  3. Norman Diamond says:

    Well the experience of Microsoft customers would indicate that testers survive by denying the existence of bugs instead of verifying them. I’m glad to see that things are different on the inside, but why is there such a big difference. Maybe because PSS provides an insulating layer and you never get to hear about real bugs?

    By the way,

    > Bend over backwards to help your dev

    I agree.

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

    I don’t agree. In a situation where it’s more important to fix bugs than to deny them (not always NASA, sometimes more ordinary industrial products), you don’t want testers to have a great relationship covering each other’s asses. For the good of the company sometimes you need to take devs who hate each other and ask them to tear apart each other’s products, because you’ll find more bugs and can fix them. For the good of the company you want them to bend over backwards to communicate with each other and get the bugs fixed, and leave the personal relationship alone, maybe smoldering on the back burner.

  4. brian says:

    I would add, Automate as much as possible, where appropriate. This includes repetitive tasks, regression tests, etc. Not everything can be automated, but when you automate redundant predictable tests, you leave open the ability for more creative testing.

  5. saraford says:

    Norman: That’s why i said "great working relationship", as opposed to "great personal relationship".

    Almost always devs are extremely thankful to their QA counterparts for finding bugs before they go out into customer hands. There are always those odd bugs that come in because there’s some new requirement, and it’s frustrating because it’s more of a "work item" bug than a "code defect" bug.

    And i just want to clarify that the best way to find bugs isn’t through hatred, but collaboration, because unless you’re doing white-box tesitng, you need the dev’s advice in order to really do some bug bashing.

    -sara

  6. My biggest survival tip is that a tester should not neglect his or her personal life.

    This might sound kind of silly, but back when I was a blue badge on the interview loop, I used to ask about hobbies outside of computing for test candidates, and I’d get really worried if a candidate didn’t mention at least one constructive hobby.

    Of course, I was in the games group, and the average lifespan of a video game tester is under eight months in this industry, but I’ve always found that testers seem to be happiest when they have constructive hobbies.

    I don’t care if it’s model painting, DVD collecting, or even programming…if a tester isn’t exercising the "yin" to his professional "yang," he’ll generally burn out faster than his counterparts.

  7. saraford says:

    I agree with you about the survival tip as having a personal life, but i don’t agree that the subject belongs in an interview.

    All of the training i’ve received has always said to keep it professional in an interivew and on a resume. If i had a hobby that involved programming, that would be applicable to my job. But i wouldn’t put down Karate as a hobby or mention it in an interview.

    When i grow up and become a manager, i will want my directs to have a good work-life balance, and i would become concerned if someone didn’t have a constructive hobby / work-life balance. But that’s once the person is on board.

    Just my two cents.

  8. Mike Dunn says:

    I would add two things that newcomers should learn right away.

    1. Don’t be afraid to report bugs. It’s your job. Oftentimes when I talk to QA people with little/no experience about a bug in my code, I can see the tension in their body language like they’re expecting me to yell at them or something. I always try to give them a compliment at the end of the conversation to reinforce that they’re doing the right thing.

    2. Unless it’s something silly like a spelling mistake, always include repro steps. Newbies will sometimes write out in prose what the bug/problem is almost like it’s a mathematical proof (I understand why, I was a math major and did the same thing at first, since that’s the way I was used to writing). While a dev certainly can recreate the steps from that, it’s easier for everyone if there’s an exact list of steps.

  9. Tammy Mickelson says:

    Remember to test the error messages. It’s such an easy thing to forget to do…

  10. JYung says:

    Work Hard is good and Work Smart is better

    even we are working hard with unlimited time period,we still can’t deliver the bug – free application to customer,

    priorizing the testing case, ensuring critical function is well covered,

    our target goals is ensuring project is delivered within the schedule and users are happy to use it .

    Don’t try to find all bugs in application, it will result in overtesting and overwork >_<"

  11. Rob says:

    What to test for and how would you prioritize tests given that there isn’t enough time to test everything you want to? There are different test types including security testing, accessibility testing, localizaiton testing but when there isn’t enough time is there any latest guideline on what tests are must and how they can be prioritized?

  12. Hi i agree some part of Tips which you people have expressed , we should consider one thing that tester should always keep good relationship the developer then only you will be achieving your targets.

    the developer always he should expect postive results from testor infact,the testor has to proceed with him in right way even if it is more negative,

    Definaltely there is ego problem with dev and testor

    even thought we should alway give marks to developer.

Comments are closed.

Skip to main content