Tester, Verify Thyself

It's not that I'd ever compare Hiccupps to the Bible, you understand, but, now that I've mentioned it, the notion of carving these blogs in stone and tossing them at you from a great height appeals to my inflated notion of my own importance.

Chip, chip, chip, chip ... chip. Here you go.

Keep "Tester, verify thyself" in mind when you're working. This doesn' t mean you need to get into some recursive eat-your-own-tail cycle of self-doubt. No, you'll get that elsewhere in your life as a tester, usually just before a major release ships. What it means is that you should make sure you review what you're doing, how you're doing it and what the  justification for it is.

Let's say you're writing some test automation scripts. You have some valid test data and you write the scripts so that the suite passes. Great. But did you think to modify the test data so that there are some failures? Did you do it for all the test cases? Are you sure that the conditions for success you put into your suite will only be true on success? No? Oh.

We rightly expect high standards from Dev, and we should expect the same from ourselves.

Put Traffic Lights on Your Roadmaps

Process, huh, what is it good for? Well,  some might find pleasure in its potential as a catalyst for inter-department wars but for me it's the road that gets you from the start to the end of a task as fast and efficiently as possible.

In my team we use a wiki to document our processes and we try to match the process overhead to the task that it runs.

For example, some processes are just a list of bullets for a QA engineer to review - perhaps when smoke testing an internal script. Others have to coordinate actions from several parts of the company, with control passing back and forth as different deliverables are generated, reviewed, tested, built for production, tested and deployed.

All the participants in one recent project use Bugzilla for defect tracking so, to avoid reinventing the wheel, we controlled a process using bug tickets. Each stage in the process corresponded to a stage in the life cycle of a ticket and we provided pro-forma comments that just needed editing with the details that changed on that iteration.

Say you'd produced the first-round deliverable, then you'd mark the bug fixed with a comment that told QA where the deliverable was and what the expected performance envelope was this time around.

The process is the road you follow to complete the task. Along the way different people need to start and stop and you want them to drive on the right side so they don't crash into everybody else. Put traffic lights and white lines on the road to guide them. And from time to time the road will need repairs. Fill the pot holes in quickly or people will start to use their own routes.

Sign Language

I saw this sign for a sex shop and it made me laugh - well, on a professional level it made me grimace but  on that inner schoolboy level I liked it so much I wrote it on the back of my Maths book. In my best felt pens. With arrows pointing at it.

Whoever commissioned it probably wasn't joking, which just reinforces the fact that, as QA Hates You likes to say, the least testing you should do is to get someone else to read your copy before you ship it. But, hey, it probably doesn't matter to the target audience, does it?

But this sign was outside another shop, the one the sex shop is at the back of. And what does the other shop sell? Signs. And the target audience of a sign shop is not interested in having amusing faux pas committed on their signs. The target audience of a sign shop would like to be reassured that the sign shop would inject some quality control on their behalf. That audience might get their sign made somewhere else.

Your audience is not just the target audience, it's anyone who sees what it is you've done and forms an opinion of you because of it.