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.

Have you ever given a 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, then what we always do is either 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 a few techniques here which I and many of my Mentors will 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 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 as you can write within 60 seconds. Repeat the process until 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 that 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 allow you to identify 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 for 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 can 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 there 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. This is why Production Defects or UAT Defects exist even after extensive rounds of Unit Tests, Integration Tests, and System Tests.

For example, Requirement says that you can upload a file that does not exceed 10 MB of file size. Most testers will follow by uploading a 1MB, 2MB, 3 MB or more until 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 the 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 that none of the questions (how so ever small or silly) are ignored.

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.”



Research proves to be very beneficial before starting the testing. Just be aware of the issues that 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 can sometimes 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 off.

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 that will help you generate more ideas in turn.

Further Reading

This is a guest post by Mohit Khatri. The author specializes 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 them in the comments section below.

Related Post

Leave a Reply

Your email address will not be published.