Thou shalt not take the name of the Tester in vain
June 17th, 2008 by Damian
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.
Posted in Test Professionalism, Testing Guidelines | No comments »
The Commandments of Testing
June 10th, 2008 by Damian
Thou shalt not take the name of the Tester in vain- Thou shalt perform Excellent Testing
- Thou shalt plan Efficiently
- Observe the Milestone and keep it holy
- Honour thy Customer and thy Company
- Thou shalt not be Nice
- Thou shalt learn from History but thou shalt not Repeat it
- Thou shalt document Sufficiently
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.”)
Posted in Testing Guidelines | No comments »
Welcome
April 16th, 2008 by Damian
Welcome to xeque. The purpose of this site is to provide practical, honest advice and insight into testing methodology and practice. The business world and the internet in general is filled with enough self-important words and high-falutin’ management-types.
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.
Posted in Uncategorized | No comments »
Newer entries »