Exploratory testing

<h2 id="history">History</h2>
Exploratory testing has always been performed by skilled testers. In the early 1990s, <a href="/facts/Ad_hoc/IYxx5Ha8">ad hoc</a> was too often synonymous with sloppy and careless work. As a result, a group of test methodologists (now calling themselves the <a href="/facts/Software_testing_controversies/B24Baw8y">Context-Driven School</a>) began using the term "exploratory" seeking to emphasize the dominant thought process involved in unscripted testing, and to begin to develop the practice into a teachable discipline. This new terminology was first published by <a href="/facts/Cem_Kaner/Pwl8JbhT">Cem Kaner</a> in his book Testing Computer Software <a class="footnote-ref" id="fnref:4" href="#fn:4">4</a> and expanded upon in Lessons Learned in Software Testing.<a class="footnote-ref" id="fnref:5" href="#fn:5">5</a> Exploratory testing can be as disciplined as any other intellectual activity.

<h2 id="description">Description</h2>
Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The quality of the testing is dependent on the tester's skill of inventing <a href="/facts/Test_case/TVWkj0AQ">test cases</a> and finding <a href="/facts/Software_bug/I1uSXySv">defects</a>. The more the tester knows about the product and different <a href="/facts/Test_method/sGtHudUV">test methods</a>, the better the testing will be.
To further explain, comparison can be made of freestyle exploratory testing to its antithesis <a href="/facts/Test_script/Yz2uKhaP">scripted testing</a>. In the latter activity test cases are designed in advance. This includes both the individual steps and the expected results. These tests are later performed by a tester who compares the actual result with the expected. When performing exploratory testing, expectations are open. Some results may be predicted and expected; others may not. The tester configures, operates, observes, and evaluates the product and its behaviour, critically investigating the result, and reporting information that seems likely to be a bug (which threatens the value of the product to some person) or an issue (which threatens the quality of the testing effort).
In reality, testing almost always is a combination of exploratory and scripted testing, but with a tendency towards either one, depending on context.
According to Kaner and <a href="/facts/James_Marcus_Bach/GvjPrtDj">James Marcus Bach</a>, exploratory testing is more a <a href="/facts/Mindset/WNWNaQz0">mindset</a> or "...a way of thinking about testing" than a methodology.<a class="footnote-ref" id="fnref:6" href="#fn:6">6</a> They also say that it crosses a continuum from slightly exploratory (slightly ambiguous or vaguely scripted testing) to highly exploratory (freestyle exploratory testing).<a class="footnote-ref" id="fnref:7" href="#fn:7">7</a>
The documentation of exploratory testing ranges from documenting all tests performed to just documenting the <a href="/facts/Software_bug/I1uSXySv">bugs</a>. During <a href="/facts/Pair_testing/NjzQNTDx">pair testing</a>, two persons create test cases together; one performs them, and the other documents.
<a href="/facts/Session-based_testing/yymAtvKn">Session-based testing</a> is a method specifically designed to make exploratory testing auditable and measurable on a wider scale.
Exploratory testers often use tools, including screen capture or video tools as a record of the exploratory session, or tools to quickly help generate situations of interest, e.g. James Bach's Perlclip.

<h2 id="benefits-and-drawbacks">Benefits and drawbacks</h2>
The main advantage of exploratory testing is that less preparation is needed, important bugs are found quickly, and at execution time, the approach tends to be more intellectually stimulating than execution of scripted tests.
Another major benefit is that testers can use <a href="/facts/Deductive_reasoning/HadA1zWS">deductive reasoning</a> based on the results of previous results to guide their future testing on the fly. They do not have to complete a current series of scripted tests before focusing in on or moving on to exploring a more target rich environment. This also accelerates bug detection when used intelligently.
Another benefit is that, after initial testing, most bugs are discovered by some sort of exploratory testing. This can be demonstrated logically by stating, "Programs that pass certain tests tend to continue to pass the same tests and are more likely to fail other tests or scenarios that are yet to be explored."
Disadvantages are that tests invented and performed on the fly can't be reviewed in advance (and by that prevent errors in code and test cases), and that it can be difficult to show exactly which tests have been run.
Freestyle exploratory test ideas, when revisited, are unlikely to be performed in exactly the same manner, which can be an advantage if it is important to find new errors; or a disadvantage if it is more important to repeat specific details of the earlier tests. This can be controlled with specific instruction to the tester, or by preparing automated tests where feasible, appropriate, and necessary, and ideally as close to the unit level as possible.

<h2 id="scientific-studies">Scientific studies</h2>
Replicated experiment has shown that while scripted and exploratory testing result in similar defect detection effectiveness (the total number of defects found) exploratory results in higher efficiency (the number of defects per time unit) as no effort is spent on pre-designing the test cases.<a class="footnote-ref" id="fnref:8" href="#fn:8">8</a> Observational study on exploratory testers proposed that the use of knowledge about the domain, the system under test, and customers is an important factor explaining the effectiveness of exploratory testing.<a class="footnote-ref" id="fnref:9" href="#fn:9">9</a> A case-study of three companies found that ability to provide rapid feedback was a benefit of Exploratory Testing while managing test coverage was pointed as a short-coming.<a class="footnote-ref" id="fnref:10" href="#fn:10">10</a> A survey found that Exploratory Testing is also used in critical domains and that Exploratory Testing approach places high demands on the person performing the testing.<a class="footnote-ref" id="fnref:11" href="#fn:11">11</a>

<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Ad_hoc_testing/bjo2Ssf1">Ad hoc testing</a></li>
<li><a href="/facts/Spike_(software_development)/5lUQroAU">Spike testing</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li>James Bach, <a href="http://www.satisfice.com/articles/et-article.pdf">Exploratory Testing Explained</a></li>
<li>Cem Kaner, James Bach, <a href="http://www.testingeducation.org/a/nature.pdf">The Nature of Exploratory Testing</a> <a href="https://web.archive.org/web/20080511190045/http://testingeducation.org/a/nature.pdf">Archived</a> 2008-05-11 at the <a href="/facts/Wayback_Machine/nmQ3a6JC">Wayback Machine</a>, 2004</li>
<li>Cem Kaner, James Bach, <a href="http://www.context-driven-testing.com">The Seven Basic Principles of the Context-Driven School</a></li>
<li>Jonathan Kohl, <a href="http://www.methodsandtools.com/archive/archive.php?id=65">Exploratory Testing: Finding the Music of Software Investigation</a>, Kohl Concepts Inc., 2007</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">Cem Kaner, "A Tutorial in Exploratory Testing Archived 2013-06-12 at the Wayback Machine", p.2 <a href="http://www.kaner.com/pdfs/QAIExploring.pdf" target="_blank">http://www.kaner.com/pdfs/QAIExploring.pdf</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">Cem Kaner, A Tutorial in Exploratory Testing Archived 2013-06-12 at the Wayback Machine, p. 36. <a href="http://www.kaner.com/pdfs/QAIExploring.pdf" target="_blank">http://www.kaner.com/pdfs/QAIExploring.pdf</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">Cem Kaner, A Tutorial in Exploratory Testing Archived 2013-06-12 at the Wayback Machine, p. 37-39, 40- . <a href="http://www.kaner.com/pdfs/QAIExploring.pdf" target="_blank">http://www.kaner.com/pdfs/QAIExploring.pdf</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">Cem Kaner, Testing Computer Software, TAB Books, Blue Ridge Summit, PA, 1988. p. 6, 7-11. <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">Kaner, Cem; Bach, James; Pettichord, Bret (2001). Lessons Learned in Software Testing. John Wiley & Sons. ISBN 978-0-471-08112-8. <a href="978-0-471-08112-8" target="_blank">978-0-471-08112-8</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">Cem Kaner, James Bach, Exploratory & Risk Based Testing, www.testingeducation.org Archived 2008-05-11 at the Wayback Machine, 2004, p. 10 <a href="http://www.testingeducation.org/a/nature.pdf" target="_blank">http://www.testingeducation.org/a/nature.pdf</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">Cem Kaner, James Bach, Exploratory & Risk Based Testing, www.testingeducation.org Archived 2008-05-11 at the Wayback Machine, 2004, p. 14 <a href="http://www.testingeducation.org/a/nature.pdf" target="_blank">http://www.testingeducation.org/a/nature.pdf</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">Itkonen, Juha; Mäntylä, Mika V. (2013-07-11). "Are test cases needed? Replicated comparison between exploratory and test-case-based software testing". Empirical Software Engineering. 19 (2): 303–342. CiteSeerX 10.1.1.363.6524. doi:10.1007/s10664-013-9266-8. ISSN 1382-3256. S2CID 254472881. <a href="/wiki/CiteSeerX_(identifier)" target="_blank">/wiki/CiteSeerX_(identifier)</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
<li id="fn:9">Itkonen, J.; Mäntylä, M. V.; Lassenius, C. (2013-05-01). "The Role of the Tester's Knowledge in Exploratory Software Testing". IEEE Transactions on Software Engineering. 39 (5): 707–724. doi:10.1109/TSE.2012.55. ISSN 0098-5589. S2CID 1763558. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></li>
<li id="fn:10">Itkonen, J.; Rautiainen, K. (2005-11-01). "Exploratory testing: A multiple case study". 2005 International Symposium on Empirical Software Engineering, 2005. pp. 10 pp.–. doi:10.1109/ISESE.2005.1541817. ISBN 978-0-7803-9507-7. S2CID 7974121. <a href="978-0-7803-9507-7" target="_blank">978-0-7803-9507-7</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></li>
<li id="fn:11">Pfahl, Dietmar; Yin, Huishi; Mäntylä, Mika V.; Münch, Jürgen (2014-01-01). "How is exploratory testing used? A state-of-the-practice survey". Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ESEM '14. New York, NY, USA: ACM. pp. 5:1–5:10. doi:10.1145/2652524.2652531. hdl:10138/153363. ISBN 9781450327749. S2CID 17924562. <a href="9781450327749" target="_blank">9781450327749</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></li>
</ol>

Exploratory testing open-in-new

Exploratory testing