Testers are creative beings...or should be

One of the most common misconceptions around the world of software development is that testing is a structured, rigorous and linear process with no room for imagination or creativity. Over the last couple of years of my testing journey I've tried to embrace testing problems with free spirit and an open mind. This was mainly inspired by a distinctly uninspiring project where the lack of quality was only matched by the lack of imagination in the testing effort.

As usual it’s the hard projects which teach you the most and certainly taught me that investing a little time in exploring options can certainly pay dividends further on in the project. There is always a massive amount of pressure to get on with things but it is perfectly acceptable (in my view) to expend a bit of effort on looking for imaginative testing angles. With that in mind, I thought I would spend a little time exploring three of the options that I've used to add a little bit more edge to more recent projects....

1. Speak to People You Wouldn't Normally Ask About Testing

How do you normally approach building a test approach? Who are your 'go to guys'? Usually the tester who's been there for 20 years? Check. That dev guy who seems to know the entire configuration and is always involved in the really complicated stuff? Check. The Business Analyst, Product Owner, Project Manager, the list of usual suspects goes on and on. I do advocate speaking to all these people as their opinions are infinitely valuable but do they give you a different angle? 

So my advice is to try someone different. Perhaps not the Security guy (well depends on the type of testing I guess) but here's a few you might want to check with:

• The Little Guy - this is probably my number one piece of advice. Usually your 'business contact' is a supervisor or a manager; it seems to be a fact of life in a lot of organisations. Again, it’s a valuable viewpoint but what about the little guy, the person who needs to use it day in and day out? As both a tester and a Scrum Master I've found this to be a really useful tool for getting feedback and guidance. Just walking up to the operations floor and asking for an opinion is also quite a powerful show of communication, if you have the disposition to attempt it!
• The Middle Men - Your resident Change Control department are useful people to know and these guys see all the randomness which occurs within an organisation, have a great overall view and can really help when creating build validation test pack as they can see the danger before it occurs. Also, it never hurts to have the gatekeepers to your release on your side....
• The Big Cheese - I definitely read somewhere that the bigger 'bears' in an organisation have an entirely different view on life. In my experience this also would seem to be true. If you have a project which has prioritisation issues in terms of test coverage then I would recommend this approach. You will soon learn what is important and what is not.

2. Pick an Aspect of the Functionality and Explore

Not so long ago I discovered (not claiming to be the first, I mean personal discovery) a technique called mind mapping. Generally on my travels I have seen this used a high level tool to build a picture of a project, however when I really want to understand a key requirement or aspect of the functionality I use it as a drill down tool to really understand a key area of the project and how it can be tested.

I generally look for a few things when identifying my target:

• Confusion - where there is confusion over what something is and how it works the tester can add major value. Build into your approach tests to prove what it is and how it behaves and cascade that information to the relevant parties.
• Assumptions - speak to the development, project and business team and try and drive out any assumptions that have been made and drill into them. You may get lucky and hear the phrase 'this part of the project is a black box.' Now, if you don't know what a black box is then now is the time to ask questions. Project teams often assume that bits of software that are already built or pre-tested 3rd party software do not need to be tested as part of the new project. I firmly believe that anything built by humans to be used by humans cannot be deemed a black box and, at the risk of sounding smug, I've generally been right.
• No Subject Matter Expert - So, you're testing something and you ask around and get the feeling that the only guys that know anything about this piece of functionality are long gone. This is your chance to step in and create a lasting piece of analysis which will genuinely fill a major gap in knowledge and become the subject matter expert yourself.

So, when building your mind map for your specific aspect of the functionality a good heuristic generally works well. A personal favourite is FIBLOTS:

• Frequent: Common application usage.
• Intensive: i.e. Resource hogging activities.
• Business Critical: Even if these activities are both rare and not risky
• Legal: Stuff that will get you sued or not paid.
• Obvious: Stuff that is likely to earn you bad press
• Technically Risky: New technologies, old technologies, places where it’s failed before, previously under-tested areas
• Stakeholder Mandated: Don’t argue with the boss (too much).

There really are lots of others but FIBLOTS has always given me a level of coverage I’m comfortable with. Its personal preference, I’m generally happy not knowing every little thing before I start testing but I know others prefer more rigor.

3. The Joy of Mocking

Last but by no means least, is the art of mocking. Again I'm relatively new to this but in our brave new world of API's and SOAP services this is an essential tool in the armoury of the creative tester.

Ask yourself this question. How many projects have you tested that require a call to multiple services, with a plethora of data dependencies in each? If you are me then the answer is lots. The key is to be able to test the actual functionality, not just wrestle with data combinations. If you are in control of the data being provided (and received) then your testing can be incredibly precise.

So when you are presented with a new project to test some of your creative thoughts might be:

• Which bits reach out to external/3^rd party systems?
• Which bits need to be ‘Live’ and which bits can I mock?
• Are there any areas I can effectively stub out? Any values which could affectively be controlled by setting an expected positive (or negative) response?

This spirit of creativity and technical flair is part of what’s really setting apart the good solid testers from the great ones who want to try new things. As the API becomes king, we as testers will be challenged to broaden our technical knowledge, and our creative selves will need to come to the fore.