Skip to main content

Jul 25, 2008 - 3 minute read - Entertainment Evil Tester

Noob lessons for Software Testing

Raising Defects can challenge even the best of testers, as the tester at ClicheQuest Offices found out to his peril.

Lessons this cartoon has to teach us about raising, or not raising, defects - ed: ‘so we should say “lowering” then?’ (sorry, I couldn’t resist):

  • “All we want are the facts ma’am” as Joe Friday would prompt.
  • Don’t tell people what to do.
  • Work sensible hours
  • Get your own back

“All we want are the facts ma’am”

I describe what I see. I describe what I observe. I make every effort to specify what I observe. e.g. The system didn’t hang, instead the GUI would not respond to mouse clicks or key presses. And process explorer showed that the CPU usage dropped to 0%, even when I monitored it for 60 seconds, even when I left my computer untended for 30 minutes and returned, the GUI did not respond to inputs or showed any CPU usage in Process Explorer.

I even go so far as to write in e-prime where possible, and wrote a tool to help me check that I write e-prime compliant text. The full reasons for that shall lie awaiting the writing of another post, but I recommend experimenting.

Experiment: take a defect report you wrote, and re-write it in e-prime. How much more ‘observational’ and ‘your experience based’ did the rewrite make it?

Don’t tell people what to do.

Don’t tell them how to fix it - no matter how tempting that seems.

Don’t presume you know the solution. Provide them enough information to enable them to work out the solution.

Don’t…unless you did the investigation, and changed the code, and retested it, and found that your change actually made it work.

So… don’t.

(Cue comments outlining contexts and situations where the ‘correct’ response involved telling people what to do.)

Work sensible hours

Why would you work at 20:30 on a Friday?

Unless of course you work in the US, in which case the time difference makes it 15:30, so that seems reasonable.

Get your own back

When I had fewer years to my age and less hair, I would often have happy teams of developers rush out a build on Friday night expecting the execution of tests to happen in parallel with their journey home and later carousing, and preferably to continue over the weekend. (The testing, obviously, not their carousing for I work with gentle folk.)

So the best thing to do? Find and raise a defect - Ha! That’ll teach them.

And if you’re lucky - since they delivered in a rush before going home on a Friday night there will exist some ‘silly’ ones in there, so simply clicking on a button may cause the app to crash - ya gotta love Friday night rush defects - unless of course, you work for ClicheQuest.

Other true to life tales of testing from The Noob:

  • episode 249 “Bugged” - lesson… some bugs fall into the class of exploit - so see how far you can push them.
  • episode 254 “Quality Assurance”  - lesson… don’t let yourself get labelled with a “Quality Assurance” tag or this might happen to you. After all - you don’t assure quality.
  • episode 314 “Hotfix” - lesson… test it anyway.

You will need a Github account to comment. Or you can contact me with your comment.

I reserve the right to delete spam comments e.g. if your comment adds no value and its purpose is simply to create a backlink to another site offering training, or courses, or etc.