Exploratory Testing Styles
There are different Exploratory Testing Styles and variations that often yield similar results. What follows are some styles I’ve observed.
This is the most common style. Testers who haven’t learned specific exploratory testing techniques tend to do this naturally. When you ask them what they are doing when they are testing in the absence of pre-scripted test cases, they may say, “I don’t know why I did that,” or that they are using their intuition. Intuition is just a fancy way of saying, “I am doing this because of the insight I have based on my experience and knowledge.” It can appear to be random or chaotic, but when the tester is pressed for an explanation of what he did, a structure and purpose emerge.
This is also very common. Even shops that insist that all their test cases be designed and recorded prior to formal testing use this exploratory testing style during test design. While writing test cases, the test designers will try out new software or a new feature that they need to learn about. As they learn, they invariably find bugs. This is also true of automated testing. As the automators learn about the system, they often will use an exploratory approach as they try to get the automation tool to interact correctly with the application.
More advanced exploratory testing involves using a particular system, model, or strategy to guide your testing. This is done to be more thorough in looking at and testing the system, and to be more consistent in our exploratory testing work.
Exploratory testers often use automation tools to help them. For example, if regression testing is becoming a burden, some aspects of testing may be automated. Task automation focuses on speeding up activities like data loads or installing new builds and can extend to test setup for exploratory testing sessions. These tests are run under the supervision and direct control of the tester who can step in and intervene manually at any time.
Exploratory Testing – Good And Bad Sides
Checks application usabilityThis, of course, depends on how the tester is sensitive to usability. Usually, however, something that is understandable for the developer and the robot, it is not obvious to the tester. Because exploratory tests are treated as a whole, it is easier to see the wrong assumptions in cross-section of multiple modules or functions.
Helpful with a lack of documentation, requirements, test cases, etcThere are situations when we get application to test without any documentation, test cases or automation scripts. Natural way is, of course, writing the test scenarios first. Soon testers will have the information about the quality level of the product – our benchmark. Testers will have a good basis to start writing the missing parts. So this kind of testing allows you to get temporary salvation and able to maintain the expected quality in short term.
Find holes in requirementsExploratory tester usually report many errors caused by wrong requirements or documentation. What is interesting – that such errors are usually reported as critical. As mentioned earlier, deduction across whole applications have no small importance here. Exploratory testing can upset upside down some of the assumptions.
We do not need test scenarios, unit tests, test automation, etc. ! We have skilled testers !The situation is often encountered in smaller firms where there are no dedicated quality assurance teams. Tester is a programmer, a tester is a business owner, a secretary, all strive to perform exploratory tests. At the end of their testing, it becomes a set of performed routine activities. For larger companies, we also deal with the syndrome, “Our application is free of errors!”
Poor detection of minor issuesExploratory tester is focused on finding gaps in mainstream business process covered by tested application. But of course there are also deviations on the other side, for example : focusing on the type of error – whether it is possible to enter a negative value in the field, which should has only positive values. Fields validation is a role of automated or unit testing.
Exploratory testers can get into a routineDescribed methodology is based on the deduction, which degrades when is constantly exposed to the same experience. Tester which is extensively used in this way, often becomes an automation robot that uses a memorized test script. As team leaders we have seen this phenomenon in advance. The easiest way to counteract this situation is to apply the testers and test applications rotation.