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”

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 black box or white box testing. This has limited our mind from thinking beyond the boxes. Did we ever think that going beyond black box or white box testing could help us in gaining a higher pace towards a solid career in software testing?

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

What You Will Learn:

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 which you have used in past. Doing this will let you identify such issues which are not related to requirements but represent a common/generic feature which 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 which 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 which 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 the similar assignment. Say, you are required to start a cross-browser testing as one of your assignments. Before starting the tests, researching for 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.

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 which you think have helped you at any point feel free to share below.