Thou shalt not take the name of the Tester in vain

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

« | »


You must be logged in to post a comment.