Skip to main content

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/3rd 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.

Comments

Popular posts from this blog

A Lone Tester at a DevOps Conference

I recently had the chance to go to Velocity Conf in Amsterdam, which one might describe as a DevOps conference. I love going to conferences of all types, restricting the self to discipline specific events is counter intuitive to me, as each discipline involved in building and supporting something isn't isolated. Even if some organisations try and keep it that way, reality barges its way in. Gotta speak to each other some day.

So, I was in an awesome city, anticipating an enlightening few days. Velocity is big. I sometimes forget how big business some conferences are, most testing events I attend are usually in the hundreds of attendees. With big conferences comes the trappings of big business. For my part, I swapped product and testability ideas with Datadog, Pager Duty and others for swag. My going rate for consultancy appears to be tshirts, stickers and hats.

So, lets get to it:

3 Takeaways

Inclusiveness - there was a huge focus on effective teams, organisational dynamics and splitt…

Wheel of Testing Part 2 - Content

Thank you Reddit, while attempting to find pictures of the earths core, you surpass yourself.
Turns out Steve Buscemi is the centre of the world.

Anyway. Lets start with something I hold to be true. My testing career is mine to shape, it has many influences but only one driver. No one will do it for me. Organisations that offer a career (or even a vocation) are offering something that is not theirs to give. Too much of their own needs get in the way, plus morphing into a badass question-asker, assumption-challenger, claim-demolisher and illusion-breaker is a bit terrifying for most organisations. Therefore, I hope the wheel is a tool for possibilities not definitive answers, otherwise it would just be another tool trying to provide a path which is yours to define.


In part one, I discussed why I had thought about the wheel of testing in terms of my own motivations for creating it, plus applying the reasoning of a career in testing to it. As in, coming up with a sensible reflection of real…

What if information isn't enough?

One of my aims for this year has been to attend/talk at what I will class for the purposes of this blog as 'non-testing' events, primarily to speak about what on earth testing is and how we can lampoon the myths and legends around it. It gets some really interesting reactions from professionals within other disciplines.

And usually those reactions (much like this particular blog), leave me with more questions than answers!

Huh?

After speaking at a recent event, I was asked an interesting question by an attendee. This guy was great, he reinvented himself every few years into a new part of technology, his current focus, machine learning. His previous life, 'Big Data', more on that later. Anyway, he said (something like):

'I enjoyed your talk but I think testing as an information provider doesn't go far enough. If they aren't actionable insights, then what's the point?'
This is why I like 'non-testing' events, someone challenging a tenet than has be…