So you’re a tester, but what’s your testing goal?

Everyone involved in software development spends some time testing software, maybe you’re a dedicated tester spending all day testing a product, maybe you’re a developer checking that the new thing you’ve built is working, or maybe you’re a product person making sure the feature does what you asked for it to do. Whatever your job title, at some time you’ll be evaluating the product and checking for bugs but what are you actually trying to achieve?

Your goal will drive the way that you approach software testing, a developer tends to look at something to see if it’s done, unsurprisingly they tend to be pretty bad at finding bugs. On the other side testers tend to focus on bugs, they’ll often have broken the software in 10 different ways before they even know if it can do what it’s supposed to do.

But what is the team’s goal? Are you aiming for a high quality product or are you aiming for a fast release time? Everyone developing and testing a product should be in agreement as to what this goal is and be using it to schedule and plan testing and maybe even more importantly to use it to prioritise bug fixing. If you really want to ship this feature today then you had better be prepared for some unexpected bugs to be around.

Testers are often forgotten in the early stages of the project but don’t be put you off, every time you write a test plan or add a test to your automated test suite make sure you know the team goal for this product and then use it. Learn to be honest with yourself, if you’re secretly trying to prove your value as a tester then you’ll probably be tempted to raise bugs about things that no-one cares about. You don’t need to tell anyone but admitting your real goal to yourself might be enough to switch to your team goal hat and assess your bugs before you hit that submit button.

Edward Bono has some great ideas about different modes of thinking in his book ‘Six Thinking Hats‘. I find it useful to ‘wear’ different hats at different stages of the project, it forces me not to get bogged down in nit-picking before the requirements are even agreed and reminds me of the end-to-end focus towards the end. So try switching to your team goal thinking hat next time you test something, you might find the new perspective uncovers some interesting bugs.


One comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s