Creativity in Software Testing

Creativity in Software Testing - Freshness
of ideas
By Anand Ramdeo on May 5, 2011 1 Comment
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.

Creativity in Software Testing

Uploaded by

Copyright:

Available Formats

Creativity in Software Testing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Creativity in Software Testing

Uploaded by

Copyright:

Available Formats

Creativity in Software Testing - Freshness

 Council / official responsible for managing roads

Revolution - Deliberately challenging the rules and assumption

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.