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
- Anonymous
August 10, 2005
"Source Server" - The best "Hidden" feature in Whidbey
Debugging [Via: Matt Pietrek ]
101 Code Samples... - Anonymous
August 10, 2005
"Source Server" - The best "Hidden" feature in Whidbey Debugging [Via: Matt Pietrek ]
101 Code Samples... - Anonymous
August 10, 2005
The comment has been removed - Anonymous
August 10, 2005
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. - Anonymous
August 11, 2005
The comment has been removed - Anonymous
August 15, 2005
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. - Anonymous
August 15, 2005
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. - Anonymous
August 17, 2005
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. - Anonymous
November 28, 2005
Remember to test the error messages. It's such an easy thing to forget to do... - Anonymous
February 26, 2006
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 >_<" - Anonymous
April 25, 2006
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? - Anonymous
July 13, 2006
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. - Anonymous
May 26, 2009
PingBack from http://castironbakeware.info/story.php?title=sara-ford-s-weblog-5-tips-for-surviving-as-a-tester