Recently, a colleague of mine asked me “How do you test software repeatedly and still see the software differently?”. Being a Quality Assurance Tester for numerous years, I found this question to be simple yet perplexing and thought about it often. I have to admit that in life, I do not always think outside the box. Just the other day I was performing my daily routine to leave the house for work. I loaded my car with the needs of the day including my laptop and lunch. While re-entering the household, I locked the front storm door. I’m not sure why I did this as it is never locked. I went along my merry way and continued my daily routine of making one last cup of coffee to go and give the pets some treats. In my normal rush to get out the door, I grabbed my purse and ran out the door. Of course, the front storm door was locked which resulted in painful and surprising ‘face plant’. It was at this time it hit me…As humans, when we repeat something often enough it becomes habit.

As a software tester, it is important to not get into a “habit” and to think outside the box. So here is the answer to my colleague’s question.

When I am feeling in a rut, here are a few techniques I use to get me thinking outside the box:

• Take a break. Sometimes stopping and doing something else for a while helps reset the mind.
• Try the things that the software is not supposed to do. If the software is asking for an age, try using a negative number. If the software has a field that is required to have data entered, try leaving it blank.
• Stop the routine. Stop using a particular sequence of steps, do it differently. Use the tab key instead of the mouse. Or run it on through a responsive test sequence for mobile.
• Communicate. Talk to your coworkers and compare your thoughts on the functionality of the software. This may trigger your mind to think “Hm… I should test that…”.
• Second set of eyes. Switch projects being tested with your coworker. This will provide a fresh pair of eyes on each project.
• Switch tasks. When I flip from one task to another, I inadvertently do things differently.
• Review documentation. Take a walk through the documentation and search for the end user permissions. If something is accessible to a System Administrator, try testing it as a non-System Administrator.
• Don’t play nice. When testing new functionality, don’t play nice. End users won’t! If you’re testing something that is supposed to work independently, try combining it with other functionality. Make sure nothing else is adversely affected.
• Negative testing. Test what the software is not expecting. If the software says you can upload a file which does not exceed file size of 10 MB, test what happens when an 11MB file is uploaded.
• Alerts. Searched out the software for every alert, warning, and error message that the application can display. Are the appropriate messages displayed? Are they displayed correctly (accurate message, grammar, color of highlighting, etc)?
• Think like an End User. What would happen if someone who knows little about the software used it? Is the software difficult to learn? While this is not a defect, suggest ways that could be improved.

It’s not always an easy task to think outside the box on a project that periodically changes and needs repeated testing. Should you find your testing beginning to take the form of a “habit”, try some of the above techniques. Preferably, before you find yourself having a “professional face plant”.