The Mindset of a Tester

Heather looks into effectively approaching tasks as a tester for the Spacecraft team at Jadu.

Having recently joined the fantastic Spacecraft team, I was asked to write a blog post on my work here. As I’ve heard the ‘we don’t think about things the same way that testers do’ comment a few times, I thought I would ponder this and think about the mindset of a tester and how we may sometimes view tasks differently to the others whom we work alongside.

Try to think backwards

Everyone has their own way of approaching a problem. Developers, UXers and customers could all think about ‘how do I do this?’ in a different way. As testers we need to think about various routes towards a goal with multiple combinations, not all of them being the most obvious or popular. One colleague described seeing it as a maze, trying to get to the hidden pathways.

Take a risk

Or to put it less scarily, assess the largest risks to the current area of testing and focus in on what’s really important. You can never get 100% coverage so this is one key way of helping to find the defects that really matter.

Change hats - represent your customer

It works for me but then I may have spent hours reading and planning about this piece of work before testing it. How will a customer who hasn’t seen this before go about testing it in UAT or how would a casual user approach this on a live site? This is when you start to challenge usability, consistency, accessibility, mobile device views etc.

Testing Suite

Question, question, question

One of my colleague’s favourite mantras. Not just because we are always pestering people with questions to find out what we need to know to write up test cases, but the questions we ask ourselves to challenge the functionality. What will happen if I do this? How will the system handle this? What is the craziest data I can think of to enter here? What if I do this again and again and again . . .?

Be a good detective

Look out for clues: wherever, whenever. If an engineer is cursing a certain module during development more than they usually would, note this one for particular attention. Similarly if a project manager or the support team are nervous about a module that is known to be complex or has been painful in earlier releases, it’s probably worth being prepared for some extra time on that one. Learn from previous ‘investigations’ and try to work out most likely behaviour and failings based on what’s been seen before and follow the bug trail, because we know that bugs are friendly and like to hang out together.

Clean your specs

Warning: familiarity blindness from looking at the same area repeatedly (and possibly retesting the same thing again and again and again) can lead to the lowering of standards! Either change the work subject for an hour, get a cup of tea or ask the opinion of another tester who hasn’t looked at it before.

Be Awkward

Easier for some... Having tested a beautiful piece of development that works exactly as expected when you put in the right data. How about trying to be a bit difficult with it? What happens if I only put in some of the data? Not in the right order? Or I want to use my Euros for a change? Or unplug my mouse? Or use as many special characters as possible? Or be lazy and duplicate all my data? Obviously there’s a chance some defects raised will be seen as out of scope but it’s all useful information and can lead to highlighting areas of weakness that need a closer look.

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.

Share this post


The official Jadu Blog (a peek inside). The musings and magic of the Jadu team and log of new web apps, customer super hero stories and mobile web marvels.

Recent posts