What is the first word that comes to your mind when you hear about “Exploratory Testing”. You can comment below and let me know.
Over the years I have been performing exploratory testing in all the different domains. When I had started my career as a fresher in software testing, hardly had I known the real meaning of it and I was doing exploratory testing in all the assigned projects. Later, I realized the significance of “Exploratory Testing” and I cannot deny how important exploratory testing in a software project. Therefore, I thought there will be many more people like me who might be doing exploratory testing in their projects without actually realizing the importance of it.
I am an ISTQB certificated professional so let’s start from the definition provided by “The International Software Testing Qualifications Board” (ISTQB) which says:
“Exploratory testing is an informal test design technique where the test activity controls the design of the test as those tests are performed and used information gained while testing to design new and better tests.”
All about Exploratory Testing
Exploratory testing means exploring the application in order to discover the unknowns. Usually, in a Software development lifecycle, the test requirements, test plan, and test strategy are pre-defined.
Special Thanks to Elisabeth Hendrickson for the source image.
Once, a test requirement is given to you, you analyze it, and depending upon your analysis, you start writing high-level scenarios. Based upon those scenarios, you start writing test cases. In this case, test cases are determined in advance. These are called “Scripted testing.” Scripted testing requires a lot of preparation, planning, and documentation, etc.
Whereas when we talk about exploratory testing, these are few points which I can think of:
1. No test cases are written beforehand. There are no test cases to follow.
2. Little preparation needed before doing exploratory testing.
3. Test design and Test execution happen in parallel.
4. A tester uses his creative thinking and intuition for exploratory testing.
5. You can find bugs that might have got missed in scripted testing.
6. Exploratory testing can be performed at any stage/phase in the software development lifecycle.
7. Sometimes, requirements are very complex to understand. In that case, you investigate the application from every nook and corner to find the bugs that you were not intended to discover.
8. Exploratory testing helps in discovering hidden defects.
9. Exploratory testing is ad-hoc testing to expose critical defects. It does not restrict a user to depend upon test cases only.
10. You are free to explore the application in any way possible.
11. You learn many new things about the application (AUT) while doing exploratory testing that helps in the overall productivity and quality of a release.
Exploratory Testing Techniques
In real-time projects, I have always worked on exploratory testing. There are some techniques also which are used for performing exploratory testing. For your reference, I have mentioned the techniques below.
1. Test Charters
2. Session-based testing
3. Test Design Heuristics
4. Timeboxing
You can read James Bach's blogs to know in-depth details for these techniques. I hope, now you consider exploratory testing as a critical step in your project and you will provide equal importance to exploratory testing as you give it to all other different types of testing which you have been doing in the project assigned to you.
To Summarize:
Needless to say, exploratory testing is testing where manual efforts are needed. It can help in finding bugs in those areas of the application where automation may not be effective. This type of testing is used to identify the flaws or to make required changes in a software product for improving the overall quality of a software product without undergoing a planned testing approach.
Happy Exploratory Testing!
Let’s explore to learn more! Thank you for reading!
Watch the Exploratory Testing talks below:
This is interesting post, Mukta, because among other things it highlights the dichotomy between the ISTQB and Rapid Software Testing views about Exploratory Testing. In the latter James Bach and Michael Bolton reach the conclusion that all testing is exploratory (https://www.satisfice.com/blog/archives/1509)
In my day-to-day work I use heuristics as one of many inputs to my session based testing, which I document in a test charter. One of the other inputs may be a mind-map, which I use as a loose guide and which changes during the session.
It's an approach that has been informed by lots of reading, a workshop at the 2019 Romanian Testing Conference, which I wrote about here http://bit.ly/3vIOOfp, and also the Rapid Software Testing Explored course,…
I've never heard the ISTQB definition of Exploratory Testing but I believe it conflicts with the definition given in Elisabeth Hendrickson's book which defines Exploratory Testing as an approach, not a test design technique. Maybe you dive into this a bit?
I also think it's interesting that you said "Usually, in a Software development lifecycle, the test requirements, test plan, and test strategy are pre-defined." Is this true? I mean is this true today? I think it might have been true in the 70s and 80s (at least in the United States), but wasn't true in the 90s and 2000s as organizations moved to Agile.