What is exploratory testing<\/strong>?<\/h2>\n\n\n\nExploratory testing can do much more than just working off test cases in a monotonous way: It promotes creative thinking during a test session, blasts limitations and satisfies curiosity. At the same time, it requires discipline regarding reaching the set goal during a test implementation and with regard to documentation.<\/p>\n\n\n\n
ISTQB<\/a> (independent panel of experts for standardized training for software testers) describes exploratory testing in its glossary<\/a> as a \u201ean approach to testing whereby the testers dynamically design and execute tests based on their knowledge, exploration of the test item and the results of previous tests\u201c (archived version 3.4 of the ISTQB\u00ae GTB Glossary<\/a>). Unlike the \u201cclassic\u201c testing with prepared test cases, it is therefore an intuitive test approach where each previous idea leads to the next one. There are various tools to achieve a new starting point, to develop ideas and create more structure. These include for example the test charter, the heuristics, the test oracle or also the test tours.<\/p>\n\n\n\n![\"Hand](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/02\/AdobeStock_245065919_kl-600x399.jpg\")
Figure: Exploratory testing – an intuitive test approach <\/em><\/figcaption><\/figure>\n\n\n\n<\/div>\n\n\n\nIn summary, the tester creates the tests through experience, intuition, curiosity and structured approach. Nevertheless, this type of testing is not only well-suited for experienced testers but also for project newcomers who are just getting to know the test object and\/or the procedure. To take the person by the hand a goal should be defined or an overview of the object should be created. This can be done either in direct exchange via pair testing<\/a> or in groups via the mob-testing approach<\/a>.<\/p>\n\n\n\n<\/div>\n\n\n\nPrejudices against exploratory testing<\/strong><\/strong><\/h2>\n\n\n\nBut what prejudices are there now against which exploratory testing must stand its ground?<\/p>\n\n\n\n
Exploratory testing is often notorious for having no structure; for not being comprehensible; and being unquantifiable \u2013 plain and simple “I-will-click-around-and-see-what-happens”. The statement of obsolete documentation further complicates it to charge for exploratory testing in client projects. This is an understandable reason, if it is assumed that exploratory testing is documentation-free and thus the test performance is not traceable. The following statement and the killer argument are therefore also made quickly that there is no time available for this test.<\/p>\n\n\n\n
In the following, we will take a closer look at the allegations just presented as well as other negative statements and comment on them.<\/p>\n\n\n\n
Prejudice Number<\/strong><\/strong> 1:<\/strong> \u201cExploratory testing is not comprehensible.\u201d \/ \u201cI cannot test exploratively-tested content again.\u201d \/ \u201cHow am I supposed to do a bug retest?\u201d These statements made us curious. When asked what is meant by exploratory testing, we often received the answer that it is used for spontaneous clicking around in the test object. It should promote getting to know the test object or test further variants that were not considered in the previous test-case creation. And thus, it is carried out in an unplanned as well as unstructured way. No documentation was mentioned. This explains how the prejudice comes about that this test method is not comprehensible, and that tests and bug fixes are difficult to retest. It is absolutely true that exploratory tests support spontaneous test taking. However, care must be taken to always document the tests steps, expected results, or even deviations, and thus make the tests traceable. The depth of documentation must be defined individually for each project according to its framework conditions. As a conclusion we maintain that: Exploratory testing does not mean not to document.<\/strong><\/p>\n\n\n\n
In summary, the tester creates the tests through experience, intuition, curiosity and structured approach. Nevertheless, this type of testing is not only well-suited for experienced testers but also for project newcomers who are just getting to know the test object and\/or the procedure. To take the person by the hand a goal should be defined or an overview of the object should be created. This can be done either in direct exchange via pair testing<\/a> or in groups via the mob-testing approach<\/a>.<\/p>\n\n\n\n But what prejudices are there now against which exploratory testing must stand its ground?<\/p>\n\n\n\n Exploratory testing is often notorious for having no structure; for not being comprehensible; and being unquantifiable \u2013 plain and simple “I-will-click-around-and-see-what-happens”. The statement of obsolete documentation further complicates it to charge for exploratory testing in client projects. This is an understandable reason, if it is assumed that exploratory testing is documentation-free and thus the test performance is not traceable. The following statement and the killer argument are therefore also made quickly that there is no time available for this test.<\/p>\n\n\n\n In the following, we will take a closer look at the allegations just presented as well as other negative statements and comment on them.<\/p>\n\n\n\n Prejudice Number<\/strong><\/strong> 1:<\/strong> \u201cExploratory testing is not comprehensible.\u201d \/ \u201cI cannot test exploratively-tested content again.\u201d \/ \u201cHow am I supposed to do a bug retest?\u201d These statements made us curious. When asked what is meant by exploratory testing, we often received the answer that it is used for spontaneous clicking around in the test object. It should promote getting to know the test object or test further variants that were not considered in the previous test-case creation. And thus, it is carried out in an unplanned as well as unstructured way. No documentation was mentioned. This explains how the prejudice comes about that this test method is not comprehensible, and that tests and bug fixes are difficult to retest. It is absolutely true that exploratory tests support spontaneous test taking. However, care must be taken to always document the tests steps, expected results, or even deviations, and thus make the tests traceable. The depth of documentation must be defined individually for each project according to its framework conditions. As a conclusion we maintain that: Exploratory testing does not mean not to document.<\/strong><\/p>\n\n\n\nPrejudices against exploratory testing<\/strong><\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2020\/07\/warak_katharina.jpg\")
<\/figure>