Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Exploratory testing techniques: Finding software defects using creativity and diligence

Amy Reichert QA Engineer, RxMxUSA

The ability to do effective exploratory testing is an essential skill for any QA test team. Typically, exceptional and experienced testers have an instinctive manner in which they find defects. Exploratory testing continues to build and retain an active group of followers because it works—within a QA team, the large majority of software defects are found using these testing techniques. The downside of exploratory testing is that its value depends on the tester's skill and understanding of the application's design, function, and purpose.

Even if you're not at the "instinctive" stage or are in the process of learning, don't despair—testers at any level can use exploratory testing to find defects. The key is being both creative and diligent while exploring the application as the customer sees it, being able to manipulate the application, and potentially make it fail.

Creativity and diligence

If anyone during your QA testing career calls you creative, thank them profusely. As a skill, creativity has been overlooked for years, but it's truly critical for QA tester's career. Being creative helps you discover user workflows that are off the beaten path, in several directions. In order to find defects, testers have to leave the happy path, because that's typically covered by automated or manual regression testing. An exploratory tester finds the alternative answer, goes the wrong way, performs functions incorrectly, goes backwards, clicks repeatedly like a lunatic, closes windows directly using the x in the upper right—especially with warning or error dialog boxes. (Often, warning or error messages can be circumvented simply by closing them.) An exploratory tester enters values with punctuation, uses both numeric and alpha, and tests the boundaries with both types of values. Even if a developer has covered the possibility of a user entering an invalid numeric value, they may not anticipate someone entering an alpha value or a combination of alpha and numeric values.

Be brave—change areas

Diligence helps the passionate exploratory tester find bugs, especially well hidden, deeply rooted ones. Diligence means keeping up testing until defects are found. We all know any application has defects, but sometimes it's difficult to see them, especially if we're used to testing in the same functional area. A diligent tester is not afraid to venture into unknown territory or break new ground.

One option is to test outside your comfort zone. Test in an unknown functional space. It happens that testers become so familiar with an application during the course of its development that they sometimes can no longer see the defects. After working around existing defects the tester may not recognize them or stop long enough to investigate fully. It can be effective to have test teams switch testing areas in order to see if new defects can be found.

Another option is to find locations in the code that aren't well tested. Perhaps this portion of the code was done by a development group that seems to fly below the radar or by a group of savvy, intimidating developers. Bingo! This is the perfect spot to test. Jump in, see what you find. Chances are high you'll find significant defects where other testers fear to tread.

Yet another option is to find areas in the application that are ignored because they're complex, unpopular, or may be older and less interesting to test. And it goes without saying, if the area isn't tested well, there are likely defects waiting to be found there.

Data transfers

When data is transferred or messaged between tables, the code that manages this holds a potential failure point. Often, development teams may not communicate clearly when changes are made to one end of the message, which may break things at the unsuspecting other end. Passing data is error prone, and database development is not as evolved as other application development. Data transfers or messaging systems remain prime places to find high-priority defects.

As you perform exploratory testing, focus on how customers could possibly interrupt, corrupt, or crash the messaging system. Sometimes this can involve turning on error logs for troubleshooting or overloading the system with a larger than normal number of messages. Frequently the configuration settings available to customers may contain defects or fail to be updated along with the latest code, so if a user changes a specific configuration setting, the messaging system fails.

Moving away from default mode

Here's a situation I've encountered from time to time. A business decides they want the application to perform differently, and there's a configuration setting that controls the function in question. Many test teams don't, or frequently can't, test all configuration setting options. In fact, not all the defaults themselves may be fully tested, let alone the numerous configuration setting possibilities that exist within the majority of software applications.

When you explore the depths of configuration, you'll definitely find defects. It may take some digging, but eventually you'll land on a lethal combination. I always start with settings for anything that's regulated or high risk—for example, in medical applications this could be medication ordering, dosing calculations, or diagnosis coding. High-risk areas are important to hit first because they potentially cause the most damage. It may be tedious to flip switch after switch in random combinations, but you'll eventually find a defect—or even several.

Pay attention and look for settings that contradict each other. Turn them both on and see what happens. One has to trump the other, or the conflict will cause a failure.

Exploratory testing is not only useful for finding defects. It also allows the QA team to creatively search and test areas they may not normally venture into. Additionally, it opens up to scrutiny areas that are often skipped or lightly tested. All you need is a software application and the willingness to creatively and diligently disassemble it.

Image source: Flickr

Keep learning

Read more articles about: App Dev & TestingTesting