Recently I finished a book on creativity called – Sticky Wisdom. It’s a lovely book and gives practical advice 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 a mundane and repetitive activity with same problems and similar solutions (call it best practice) – even on different projects, teams or products.
This article 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, the author suggests the rule of 4Rs to force our mind to think. These 4Rs are – Re-expression, Related words, 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 usually raise in almost every project – Not enough time for testing, the 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 the main features of our system.
- We spend a lot of time in maintaining / creating test data / environment, and that leaves us very little time to test.
- It is 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
- The testing column looks like a bottleneck on the agile story-board.
- Confusion is the common 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 on the train every day.
- And maybe few more…
If we push ourselves, perhaps it is possible to come up with such a long list for any issue we are facing. Sometimes, this might lead us to the a-ha moments because they prompt us to the exact reason for the problems and those reasons can be eliminated quickly. It’s entirely 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 a 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 are making automation problematic and see if you can express it in different ways.
Related words – Was there any similar issue addressed in the different world (or field)?
In this technique, we force our mind to find a similar or related problem in a different area 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 using our mind and training it to think differently.
Sometimes, it might work and lead us to a solution and sometimes it will not. Whether we get a solution with this 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 to be successful) in other related worlds? Some examples could be
- Council / official responsible for managing roads
- Transport officials responsible for railway tracks
- Officers responsible for safety in roller coaster rides
- 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
The third R for this rule is very interesting. It’s about deliberately opposing accepted rules and assumption and see where it leads us. There are many obvious places to use this rule – for the manually 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 to the 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 into 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 the Gulf of Mexico might give us a 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. The idea is to exercise and force our mind to think and get that link – even if it is absurd. For the 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 the environment and animal protection groups, Bad weather, etc.) affected the whole recovery process. Now in the context of application – should there be any notification for the 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 your 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.