Posts Tagged ‘software testing’

“All I Really Need to Know I Learned in Kindergarten.” Use your rules of childhood into guidelines for living life as a tester.

Share everything:

If you are a experienced tester on any project then help the new developers on your project. Some testers have habit to keep the known bugs hidden till they get implement in code and then they write a big defect report on that. Don’t try to only pump your bug count, share everything with developers.

Play fair:

Let the developers know any bug you found in design phase. Do not log the bug repeatedly with small variations just to pump the bug count. Build trust in developer and tester relation.

Don’t hit people:

As a tester you should not always blame developers for the bugs. Concentrate on bug, not always on pointing that bug in front of all people. Hit the bug and its cause not the developer!

Put things back where you found them:

You probably use a test lab. It’s probably a common resource used by other testers. When you are finished, put things back–reconfigure the hardware, restore the software, reload the test data, set up the accounts, and reset the parameters.

Clean up your own mess:

When you finish doing any test scenario then reconfigure that machine to its original configuration. The same case applies for bug report. Write a clean effective bug report. Let the developer find it easy to repro and fix it.

Don’t take things that aren’t yours:

Do not take others credit. If you have referred any others work, immediately give credit to that person. Do not get frustrated if you not found any bug that later has been reported by client. Do work hard, use your skill.

Say you’re sorry when you hurt someone:

As testers, we’re in the error-discovery business. Our job is to find other people’s mistakes. When we find them, we report them publicly. We know to always focus our reports on the errors, not the person who made the errors. But still, sometimes egos are bruised; sometimes feelings are hurt.

Say “I’m sorry.” It is one of the most powerful, healing phrases in the human language.

Wash your hands before you eat:

In other words–start clean. Once the system fails, it may not be in a stable state to look for more defects. Reboot or reload often.

Remember to flush: :)

Like the toilets flush all the software’s at some point. While doing performance testing remember to flush the system cache.

Live a balanced life:
There are things in life in addition to testing–friends, family, travel, love, food, rest, health, fitness, art, recreation, good deeds, spirituality, learning, play, and, of course, introspection.

It is difficult, especially in the early years of our careers, to put work aside and focus our attention on other things.

But, as the great philosopher Ferris Bueller once said, “Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.”

From a testing viewpoint, create diversified test teams and develop diversified test strategies.

Learn some, think some, draw some, paint, sing, dance, play, and work every day:

This one is more difficult to apply. How about “Learn some, think some, model some, explore some, document some, communicate, and test every day”?

Take a nap everyday:

We need time to think, get refresh or to regenerate our energy.
Some times its important to take one step back in order to get fresh insight and to find different working approach.

When you go out in the world, watch for traffic, hold hands, and stick together:

Always work in teams, team score are always better and powerful than individuals.

Be aware of wonder:

Be aware of wonder as a tester: the wonder that they made so many stupid mistakes; the wonder that so much actually does work; the wonder that your organization is still in business; the wonder of your own talent as you discovered an amazingly convoluted bug in the code; and the wonder that you have so much fun and get paid for it.

Now its time to take nap ;-) Happy Testing!


This is a phrase that you come across dozens of times a day, ‘Creative Thinking’ or ‘Out of the Box Thinking’.

Do we know what it actually 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 the above definition could be extended when we relate it to our field, Software Testing.

When we step into the field of software testing the first thing we are taught or we learn are the Two Boxes, a white box and a black box. Since then all we 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 these could help us in gaining a higher pace towards a solid career in software testing?

Thinking Out of the Box

Below we will be discussing a few techniques which I follow and many of my Mentors follow as well,

Rapid Fire Test Case Creation:

This technique, as the name suggests is about rapidly creating test cases. The first thing that comes to our mind when we talk about test case creation is a Requirement Document, an Excel Sheet and some guidelines provided by the organization. For once keep aside all the things, get an idea about what you think you are about to test , Pick up a Pen and 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 definitely be surprised by the number of ideas you already have without looking into the requirement document.

Cross Testing Ideas(Analogy):

While testing an application, treat it like an entirely different application which you have used before and then start testing. Doing this you might come across issues which are not part of the requirements but is just a common/generic feature which should be present and often overlooked.

For Example: If you are testing a portal, use it like you use your E mail 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 was able to bypass the login mechanism using Secure ID and this was neither a test case nor any other team member thought that this could be one of the scenarios.

Reverse or Backward Testing Ideas:

What is the normal work flow 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 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 more positive testing. The End User might not do the same 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 you can upload a file which does not exceed file size of 10 MB. The most testers will follow uploading a 1MB, 2MB, 3 MB and so on till 10 MB is reached or error message is displayed. Why not start with 10MB and then try 11MB and then 9 MB. This example is nothing but a BVA but how many of us have tried using BVA in scenarios other then 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 performing the testing.


Researching proves to be very beneficial before starting the testing, just be aware of the issues which other people faced while doing similar assignment. Say you have to start a 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 ice breaker

Testing sometimes could be a monotonous process and the ideas may begin to saturate, you might start feeling that none of the solutions are 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.

Apart from being Creative, timing, speed of implementation of ideas and their execution are 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.