Recently I finished a book on creativity called - Sticky Wisdom. It's a nice book and gives practical advices on how creativity can be fostered in our day to day life and especially at work. I found it very relevant to software testing field for many reasons. I have seen many people complaining about or questioning how creative software testing as a field is? There is a notion that software testing is mundane and repetitive activity with same problems and similar solutions (call it best practice) - even on different projects, teams or products.

This is the first in the series of articles in which I will discuss techniques suggested in this book and explore how they are relevant to software testing field. In the first article of this series - I will discuss freshness of ideas and how fresh ideas and different perspectives can be generated and are relevant to software testing. So how do we get fresh ideas in software testing? In this book, author suggests the rule of 4Rs to force our mind to think.

These 4Rs are - Re-expression, Related worlds, Revolution and Related links. Let’s look at these in detail and see their relevance in our field.

Re-expression - Is there any alternate way of describing this issue?

Let's think about the problems we normally raise in almost every project - Not enough time for testing, application is not testable, defects are not being fixed, and devs are not writing unit tests are probably repeated every-time. Let’s pick one of these issues (Not enough time for testing) and force ourselves to think of alternative ways of expressing this.

• We do not have sufficient time to gather information related to key features of our system.
• We spend lot of time in maintaining / creating test data / environment and that leaves us very little time to test.
• Its a complex project and test automation for it is becoming very challenging and needs more time
• There is a huge regression pack that we need to execute every time and that does not leave us time
• There is very little help from build masters, devs or DBAs
• There are far more developers than testers in the team
• Testing column looks like a bottle neck on the agile story-board.
• Confusion is the prevailing state of mind and it’s difficult to decide whether to focus on testing stories, closing defects or work on automation.
• There are only 24 hours and I spend 4 hours in train every day.
• And may be few more...

If we push ourselves, may be its possible to come up with such a long list for any issue we are facing – in project or life. Sometime this might lead us to the a-ha moments, because they lead us to the exact reason for the problems and those reasons can be eliminated easily. It’s quite possible that those reasons have nothing to do with product or schedule. It could be all down to project management, environment management or even your test strategy.

So remember - if there is any issue giving you hard time – practice, brainstorm with team members and try to express it in as many possible ways as you can. Let’s try to re-express - Dynamic elements and data on the page is making automation problematic and see if you can express it in different ways.

Related worlds - Was there any similar issue addressed in different world (or field)?

In this technique, we force our mind to find a similar or related problem in a different field and see how they are solving (trying to solve) it. We might (will) not be able to use the solution people in other fields are applying, but it might give us a spark which may lead us in the right direction. Remember, with these exercises, we are exercising our mind and training it to think differently. Sometime it might work and lead us to a solution and sometime it might not. Whether we get solution with these exercise or not is not important – our mind is exercised and thinks differently for a while is important. Let’s take an example - time we spend on maintaining our automation suite is becoming an issue and we need to address that. So where can we find similar problems (Where people need to maintain on a regular basis in order to be successful) in other related worlds -

• Council / official responsible for managing roads
• Transport officials responsible for railway tracks
• Officers responsible for safety in roller-coaster.
• Many more...

In all of these examples - there are different ways in which these people solve their problems. For managing roads - council might have some procedures for (regular cleaning) and also for controlling / scheduling work which needs to be carried by other departments (telephone / gas / electricity or water lines ). Relating it back to our problem, is it possible to have scheduled time for maintenance rather than spending time on the ad-hoc basis? Or is it possible to get communication channel working between devs, DBAs and testers so that changes with the potential to break automation are always communicated. Similarly is it possible to get funding for additional resources (rail replacement bus service) or highlight the risk (Risk of not maintaining roller coaster) so that this maintenance does not become an issue.

Revolution - Deliberately challenging the rules and assumption

Third R for this rule is very interesting. It’s about deliberately opposing generally accepted rules and assumption and see where it leads us. There are many obvious places to use this rule - for manual scripted testing, use of matrices, our perceived role of quality assurance, how automation is used and loads of other things. But this rule should not be used for only those things which we know are not right - it’s more useful when we use this for things which we know are right. For example - what if we do not have dedicated test environment, what if our test automation does not have any oracle related to application data, what if we cannot access data in the database - remember idea here is to find alternatives. These alternatives might or might not be good - but they will certainly force us to think and that’s the main thing. It will open our mind for new ideas and new ways of looking at the same problems.

Random Links - Choose a random item and deliberately link it to the problem

This last 'R' is very interesting but very difficult to implement and put in practice. In this technique, we randomly select any object, concept and try to relate it to the problem we are solving. It’s like saying mars-rover is the solution for our unstable environment or oil leak in Gulf of Mexico might give us clue to the memory leak in our application and see if it leads us somewhere. It’s difficult to see the link and that's the whole point. Idea is to exercise and force our mind to think and get that link - even if it is absurd. For Gulf of Mexico, we know their failure mechanism failed, BP underestimated it initially, they tried one solution at a time and external issues (Political pressure, pressure from environment, animal protection groups, Bad weather etc) affected the whole recovery process. Now in the context of application - should there be any notification for memory leak, should we just abort application, is there any possibility of this application affecting other applications or being affected by other applications, what's the worst which could happen and so on.

So to summarize, re-express the issue, find connections in related worlds, oppose all assumptions and try to find connections with random stuff to exercise mind and generate fresh ideas. Let’s be a bit more creative in our work and challenge (or educate) folks who says software testing is not a creative field.

By the way - we have recently launched iCheckWebsite to look at how websites are checked and monitored - in a different way. Do look at our short demo to see how it works.