Thinking Out of the Box While Testing Software!

Creative Thinking’ or ‘Out of the Box Thinking’ is a phrase that we often come across at our workplace or even in our day to day life.

Did you ever try to find out what it means when we say ‘Thinking out of the Box’?

As per Wikipedia:

Thinking outside the box is to think differently, unconventionally or from a new perspective. This phrase often refers to novel or Creative Thinking”

Thinking Out of the Box

But then the above definition can be extended to our field i.e. Software Testing.

When we step into the field of software testing, the first thing we are being taught or we learn is the Two Boxes – a white box and a black box. Once taught, all we always do is either the Black box or White box testing. This has limited our minds from thinking beyond the boxes.

Did we ever think that going beyond the Black box or White box testing could help us in gaining a higher pace towards a solid career in Software Testing?

Thinking outside the box

Techniques To Follow While Doing Software Testing

We will be discussing here a few techniques which I and many of my Mentors follow while doing Software Testing:

Rapid Fire Test Case Creation

This technique, as the name suggests is about rapidly creating test cases. It’s a human approach to testing which links testing directly to a performance by a human being.

The initial things that come to our mind when we talk about test case creation are a Requirement Document, an Excel Sheet and some guidelines provided by the organization. For once, keep aside all these things and get an idea of what you think you are about to test.

Pick up a Pen & a Paper and write as many scenarios you can write within 60 seconds. Repeat the process till you are not able to think of more scenarios or ideas and finally review them.

You will be surprised to see the number of ideas/test cases you already have without considering the requirement document.

Cross Testing Ideas(Analogy)

Before you start testing an application, keep in mind a similar application that you have used in the past. Doing this will let you identify such issues that are not related to requirements but represent a common/generic feature that should be present in the application but has got overlooked.

For Example: If you are testing a portal, use it like you use your Email program or any application which you worked on before and see how the application behaves.

I remember exploring a critical defect using this technique. I was testing a secure login of a finance application and tried altering the URL and navigating to a different page (which was a defect in my last tested application).

By doing this, I could bypass the login mechanism using Secure ID! This was neither a test case nor highlighted by any other team member as a possible test scenario.

Reverse or Backward Testing Ideas

What is the normal workflow you follow while testing?  Isn’t it the exact same steps that were used while developing the application: “Requirements >> Unit Cases >> Integration Testing >> System Testing” or is it any other approach?

The minds of the people working on the development of an application are bound to think in the direction which will cover most of the positive testing. The End User might not think in the same direction every time. That is the reason why Production Defects or UAT Defects exists even after extensive rounds of Unit Tests, Integration test, and System Tests.

For Example, Requirement says that you can upload a file that does not exceed a file size of 10 MB. Most of the testers will follow uploading a 1MB, 2MB, 3 MB and so on till 10 MB is reached or an error message is displayed. Why not start with 10MB and then try 11MB and then 9 MB?

This example is nothing but a BVA (Boundary value analysis). Still, how many of us have tried using BVA in scenarios other than an input box.



Ideally, every QA engineer should know the purpose of a requirement. Putting up questions will help a QA Engineer to refine his purpose of testing. If a QA Engineer is good at questioning, he/she will be good at testing by default. You need to make sure none of the questions (how so ever small or silly) is ignored.

And, in turn, questioning will also enhance the Domain Knowledge of the person who is performing the testing.

Remember: “The only silly question is the one that is unasked.”



Researching proves to be very beneficial before starting the testing. Just be aware of the issues which other people have faced while doing a similar assignment. Say, you are required to start cross-browser testing as one of your assignments. Before starting the tests, researching the issues which other people encountered while using the same browser will help you find defects before starting the actual testing.

Pause: An Icebreaker

Testing sometimes could be a monotonous process and the ideas may begin to saturate. You might start feeling that none of the solutions is working out or you might even run out of ideas. In such cases, an effective Pause can do a lot of wonders and could help you kick start from where you left.

an ice breaker

A Pause could be a Coffee or simply gazing out of the window or anything you like to refresh yourself.

In addition to being Creative, factors like timing, the speed of implementation of ideas and their execution are also of high importance. You might get an excellent idea but what if it is too late to implement it.

Listed above are just a few ideas which will help you generate more ideas in turn.

Further Reading

This is a guest post by Mohit Khatri. The author is specialized in testing Banking Applications, Automation Testing Frameworks, and Security Testing. If you want to guest post on this blog, read the guidelines here.

If you have more creative techniques that you think have helped you at any point feel free to share below.

Recommended Reading

44 thoughts on “Thinking Out of the Box While Testing Software!”

  1. Well said. Just want to add my perspective to think out of the box. this is quite general but can be applied easily in software testing as well.
    – think differently and do things differently
    – always try to find new ideas and work accordingly

    good luck,

  2. This is a good post.. It is true that testers have to think differently always. It will help them to improve alot..

    All the best

  3. The post is very good..It will help for all the people who want to build their career in software tesing

    Thank you

  4. These are the same things which i came across in my more than 2 years working experience.

    If you are doing the same things which Mohit has listed down, trust me you would be on right path for a excellent testing career.


  5. Hi,
    Can anyone please tell me what are the different software that are used in Software Testing.

    Nishant Balgovind

  6. If The project goes Success they wont say tester did a good job,by the way If project got some issues in Production they will blame why tester has not found the issue in Test regions,

    So do testing in different manner,Break the application.

    good luck,


  7. Nice article, good points discussed, but i wonder why only 2 points ? (i.e. rapid-fire and backward testing ideas)
    rest of the article is quite ‘in the box’
    anyway, as a whole, the article is good and at least different from many ‘typical’ articles, which is a good sign
    keep it up dude

  8. This is a good post. I totally agree with this idea of writing down the scenarios. This is what I do when I am not given a requirements document.

    Please email me more such articles.

  9. this type of articles really helps to all the testing engineers in order to test software applications more easily. thanks for this post.

  10. I am new to software testing. I hope if i follow according to your steps, it will be good for building up a nice career in Testing.

  11. Hi,

    It really helps me a lot. This article is helpful for those who are struggling with the idea of how to test. By reading this, i have gained some knowledge about testing. I hope that you can put up some more useful articles.


  12. Very nice….we were doing the same things in our project but we don’t know the exact terms while we testing..after reading this i got confidence…..

  13. Being a prospective tester have been browsing. I rate your concepts THE BEST. Brief, yet complete. Simple in explaining the complexities. Ex: Write up on All About Database Testing. There a class in your presentation format. Going thru makes us feel one level higher. Thanks.

  14. sir i read your its very good but it is need that you should add any excel sheet as an example it is better to understand

  15. An informative blog. Surprisingly i do follow couple of techniques. However i will make a note and will try to follow the remaining.
    Thank you


Leave a Comment