Content deleted Content added
Added modern approach list for creating Exploratory Testing business case, or for use in interviews when asking about the topic. |
Jnestorius (talk | contribs) |
||
| (One intermediate revision by one other user not shown) | |||
Line 17:
== Description ==
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 [[Test case (software)|test case]]s and finding [[software bug|defects]]. The more the tester knows about the product and different [[test method]]s, the better the testing will be.
To further explain, comparison can be made of freestyle exploratory testing to its antithesis [[test script|scripted testing]]. 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).
Line 43:
== Scientific studies ==
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.<ref>{{Cite journal|last1=Itkonen|first1=Juha|last2=Mäntylä|first2=Mika V.|date=2013-07-11|title=Are test cases needed? Replicated comparison between exploratory and test-case-based software testing|journal=Empirical Software Engineering|language=en|volume=19|issue=2|pages=303–342|doi=10.1007/s10664-013-9266-8|issn=1382-3256|citeseerx=10.1.1.363.6524|s2cid=254472881 }}</ref> 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.<ref>{{Cite journal|last1=Itkonen|first1=J.|last2=Mäntylä|first2=M. V.|last3=Lassenius|first3=C.|date=2013-05-01|title=The Role of the Tester's Knowledge in Exploratory Software Testing|journal=IEEE Transactions on Software Engineering|volume=39|issue=5|pages=707–724|doi=10.1109/TSE.2012.55|s2cid=1763558 |issn=0098-5589}}</ref> 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.<ref>{{Cite book|last1=Itkonen|first1=J.|last2=Rautiainen|first2=K.|title=2005 International Symposium on Empirical Software Engineering, 2005 |chapter=Exploratory testing: A multiple case study |date=2005-11-01|pages=10 pp.–|doi=10.1109/ISESE.2005.1541817|isbn=978-0-7803-9507-7|s2cid=7974121 }}</ref> 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.<ref>{{Cite book|last1=Pfahl|first1=Dietmar|last2=Yin|first2=Huishi|last3=Mäntylä|first3=Mika V.|last4=Münch|first4=Jürgen|title=Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement |chapter=How is exploratory testing used? A state-of-the-practice survey |date=2014-01-01|series=ESEM '14|___location=New York, NY, USA|publisher=ACM|pages=5:1–5:10|doi=10.1145/2652524.2652531|isbn=9781450327749|hdl=10138/153363|s2cid=17924562 }}</ref>
== See also ==
| |||