This is number two in my list of

It probably goes without saying that actually performing testing will be your main job function. Talking about testing, thinking about testing, planning your test process - these are all very important and very useful things to do, but the primary reason for your continuing pay packet is your raising of bugs and highlighting of issues. In other words, go forth and break software.

Thou shalt seek the better bug

So, you’ve found a problem. It’s a minor thing - perhaps a screen widget doesn’t disallow an invalid entry. But how deep does the rabbit hole go? Does it blindly store the invalid entered value? Is that same dodgy value then retrieved by another process or business function and utilised somewhere it really shouldn’t be? Is there an external symptom of this case, like a somewhat alarming error in the system log? Go the whole hog - can you make the application crash?

You are not Peter Sinclair; never take an application’s first answer. Find out how much more value you can get out of the bug before you raise it. If nothing else, it provides you with a lot of supporting information and scenarios that can be provided to the development team.

Thou shalt make thy bug a prime target

Assuming that the organisation you work for is a rational one, a small bug ain’t gonna get fixed unless someone cares about it. It is your job to find out why someone should care, and demonstrate the knock-on impacts possible; it’s almost always better to be able to raise a serious bug than a minor one, and a serious bug warrants more attention by far.

Of course, you have a similar responsibility to reality. If your discovered issue doesn’t actually affect anything, this should be writ large in your report. Again, assuming that your organisation is rational, you aren’t paid on the severity of the issues you raise, so be sensible.

Thou shalt apply diverse half-measures

There is another important heuristic to be followed when you’re testing software: the rule of diverse half-measures. Essentially, this says that: it’s better to do more, different kinds of testing to a pretty good level than it is to do one or two kinds of testing perfectly.

"This strategic principle derives from the structured complexity of software products. When you test, you are sampling a complex space. No single test technique will sample this space in a way that finds all important problems quickly. Any given test technique may find a lot of bugs at first, but the find-rate curve will flatten out. If you switch to a technique that is sensitive to a different kind of problem, your find rate may well climb again. In terms of overall bug-finding productivity, perform each technique to the point of sufficiently-diminished returns and switch to a new technique.

Diversification has another purpose that is rooted in a puzzle: How is it possible to test a product for months and ship it, only for your users to discover, on the very next day, big problems that you didn’t know about? A few things could cause this situation. A major cause is tunnel vision. It wasn’t that you didn’t test enough; it was that you didn’t perform the right kind of test. We’ve seen cases where a company ran hundreds of thousands of test cases and still missed simple obvious problems, because they ran an insufficient variety of tests." – the Bible

Even though this heuristic is obviously a deep and considered approach to scalable and effective test management, you may find it useful to glibly sum it up in a way that is more familiar to programmers: we didn’t expect the user to do that.

This is number one in my list of commandments for testers.

Most individuals in the field of software testing have their fingers in many pies – some have come from development, some want to move to management, and some just want to break software until the day they dump core.

However, during a project you must be a Tester first and foremost. It is not your job to worry about customer management, development management, requirements management, watering the plants, etc., etc. Obviously, if you can ease the way of the project by assisting in those areas, then do so, but be aware of your prime driver.

There is a fairly obvious caveat here that the two upcoming sub-commandments refer only to the role of a Tester within a project - wanting to become a Project Manager or Technical Lead, career-wise, is both acceptable and admirable. Acting like either of those roles within a project is a generally bad idea.

Secondly, all Testers should be proud of the role that they inhabit and the value they provide. We are a combination of expert user, implementer, designer, witch doctor, and faux-psychic. Never, ever, let someone refer to you - or refer to yourself - as ‘just a tester.’ Perhaps invest in a Stick of Whack to be kept behind your desk for these lessons.

Thou shalt not covet the role of Project Manager

Project Managers are there to, unsurprisingly, manage the project. They worry about resources, timeframes, work allocations, and other bits and bobs. Testers, on the other hand, do not need to worry about this at all, except to communicate clearly with said Manager about their needs for a successful test effort and ensure that enough information flows upwards to keep sundry other managers happy.

Managers tell you what to do. You tell the test team how to do it.

Thou shalt not covet the role of Technical Lead

As Testers, we have to ensure that we keep a firm delineation between our function and the Technical Lead or Developer functions. In short, although we can be considered to be usability, functionality, or requirements experts, we must be careful not to cross the line into design, as tempting as it may be sometimes.

We can advise. We can provide references of good practices, concepts, or examples. We can recommend or support one course of action, or point out flaws in another; that’s all required behaviour. We can’t do wholesale design, though; that’s outside the scope of our role.

Thou shalt not take the name of the Tester in vain

These concepts represent what we as testers should be capable of and comfortable doing. The role of a test professional, predominantly, is to ensure that the quality and suitability of a product going out the door is known. Not assumed, not estimated, but known. Contrary to popular belief, testers are not responsible for the quality or suitability of a release - we are primarily responsible for communicating and quantifying that information of the release to all concerned parties.

We must be happy with our station, clear on our mission, effective in our practices, and do just as much process-type stuff as we have to - and no more.

Keep these commandments in mind - and if you’re wondering why there ain’t ten of ‘em - well, let’s let James explain it:

We might assume that just because they are ‘commandments,’ there have to be ten of them. Since we know the assumption to be true (because that’s the nature of an assumption) then we convince ourselves that there is no need to ever bother checking whether the assumption may become false.

Assumptions are a very bad thing for software testers. Assumptions can reduce productivity and undermine an otherwise good project. Assumptions can even undermine a career. Good testers can never assume anything. In fact, the reason we are called testers is that we test assumptions for a living. No assumption is true until we test and verify that it is true. No assumption is false until we test that it is false.

Any tester who assumes anything about anything should consider taking up development for a career. After all, what tester hasn’t heard a developer say ‘Well, we assumed the user would never do that!’ Assumptions must always be tested. I once heard a test consultant give the advice: “Expect the unexpected.” With this I disagree; instead, expect nothing, only then will you find what you seek. - James Whittaker

We should borrow and amend a credo that developers have long known: ASSUMPTIONS CONSIDERED HARMFUL. If it makes you feel better, you can just imagine that I cracked the donkey joke, but it’s not actually going to happen in my lifetime.

The next few entries will go into each of these commandments in more detail.

(Oh, and if you’re wondering why there’s no obvious take on false witness? Well, really – if I have to specify that you shouldn’t lie while doing your job, perhaps it’s time to just give up on humanity in general. Next you’ll be saying “hey, what about murder? Murder’s HOT.”)

You won’t find any ivory tower best practices here. Going by the wise words of the masters, over-used catchphrases are right out the door too.

In line with the real-world, practical approach taken, there may even be occasional naughty words. Management apologises in advance.