Types of software testing: The exploratory test
The exploratory test is an effective and interesting approach to the Black-Box technique, and in some situations it can be more productive than a common planned test. Every tester, perhaps even unknowingly, occasionally uses the exploratory test in his activity. Despite this, the exploration test does not enjoy great credit in the sector. According to James Bach, the exploratory test can be defined as confronting problems without a default setting, and solving them by analyzing the reactions and possible defects of the program being tested. A canonical definition of exploratory test is that which considers it as: “A test design activity and test execution at the same time.”
This is opposed to the planned tests, which put the design of the tests before the test case in its material execution (manual or automatic). The most obvious thing is that one cannot plan an exploratory test on the front in terms of duration and expected results. However, an expert exploratory tester already has an experience that leads him to quickly identify the ideas and the strategy to be adopted to test a particular application, therefore also its duration in a certain sense. The term “exploratory test” was coined by Cem Kaner in his text “Testing Computer Software”, and in the last ten years studies have been carried out by Kaner himself, James Whittaker and James Bach to identify the skills and techniques necessary for a good exploratory test activity.
In fact, in our activity as testers, we run into exploratory tests more often than we believe, even without realizing this. So when are we facing an exploratory test? If in testing, we are influenced by the result of the previous test in setting up the next test, we are doing an exploratory test. Even when we are following a planned test, and a particular output gives us an idea on how to make a test more effective later, we are carrying out an exploratory test. The planned approach remains unaffected by the exploratory test only when relatively weak or already stable functions are tested and when the document is strictly adhered to without further investigation. The exploratory test and planned test approaches often lead to compatible results, and are perfectly mixable activities, as companies such as Nortel and Microsoft have shown that have been using this system for years.
The planned approach tries to put on paper the ideas that the tester develops on the strategy to adopt to test an application, and as is evident this operation has a considerable added value for the accuracy of the relative documentation available. The exploratory tester instead considers that the writing of this long documentation distracts and slows down the intellectual testing process, preventing problems from being solved quickly and concentrated. The richness of the exploratory test consists in the freedom of expression of the tester’s ideas, which can act without constraints based on the intuitions obtained from the reactions of the application, and in the greater rapidity and efficiency in the execution of the same.
Obviously a planned test remains useful and indispensable with regards to automation. The ability to document a repeatable test unambiguously is useful both for internal company purposes, and for the possibility of making a regression test (ie testing the same features in later versions of the product). The exploratory test is mostly used in complex situations, when the product has many features and the documentation is not exhaustive, or alongside the planned test to improve coverage. The basic rule is to use the exploratory test when the next step to be performed in the test is not obvious, or when the next step is not to be expected. James Bach states that this happens in most cases.