In traditional testing follow a fairly simple model in which there are test cases written beforehand for all the possible use cases and then after the test cases are final, they are executed & raise bugs for fail one until they all pass this is one of the traditional model works very well. In the same way, there should be some most effective model or process for Exploratory Testing so here my question is What is the best process to start & perform Exploratory Testing in the most effective way?
Exploratory testing is an experience based testing technique, so it mostly depends on whoever executes the test.
Having said that, James Bach outlines a few good points that we can potentially benefit from:
- An exploratory test session often begins with a charter, which states the mission and perhaps some of the tactics to be used. From my personal experiences, this test charter should be as vague as possible, this way, it does not limit the testers' imagination in anyway.
- Explore and analyze the subject under test, break it down into elements, produce a test coverage based on the elements.
- Identify and test all claims from the subject under test's manual / specification, test every single one of them.
- Define workflows through the subject under test and try each one, each workflow should represent realistic scenarios of use. In my personal experiences, occasionally we need to test unrealistic scenarios too, as it is possible for an end-user to do so.
- Start testing with a normal scenario, and scale it up in terms of number of options and factors until the subject under test breaks down.
- Test all fields that allow data entries, including both valid and invalid data types.
- When the subject under test breaks down, analyze its error-handing capabilities.
- Check user-interface against windows interface standards or iOS interface standards, depending on the context.
- Is there any way to corrupt a configuration file? A data file? How does the subject under test tell if a file is corrupted? How does it handle this corrupted file?
- Integration-test this subject under test with external applications.
- My personal recommendation: time-box exploratory tests. Say, 2 hours per session.
- Provide detailed test reports when test concludes.
In traditional testing the test cases written beforehand for all the possible use cases
The idea is to implement ONE test/use-case, learn from it and decide what the next one will be.
Continue that cycle until the team has delivered something working. Now they can start exploring it. I think exploratory testing should result in indicating gaps in your test automation and give you an idea of the usability from a user-centric view.
Some other questions that cover Exploratory Testing in more detail:
"written beforehand for all the possible use cases"
"that you can think of before getting your hands on the product" would complement the statement.
And since one cannot know everything beforehand, one would start ~exploring~ the product for possible risks, trying to uncover places where one should investigate for things that should not be.
"what is the best process to start & perform Exploratory Testing"
You will not find this answer anywhere; and if you could find it, it would not be the best process right after, because of ~context~. Given your domain, your resources, your knowledge of the product, the risks that you are investigating, and your general experience with testing and any given time, you would come up with a different strategy.
A better question would be: "How to improve myself as a tester?"
The basic trident for personal improvement, on my view is (no order is implied here):
1 - Try; -> Gain experience
2 - Read; -> Know other's experiences
3 - Write. -> Share your experiences and get feedback
How to do it in practice?
1 - Open source projects on a specific domain/technology (LibreOffice is a great pick);
2 - RSS feeds, books, Slack channels, forums;
3 - Blog and speaking - begin with in your company and local communities and expand from there.
If you are new to the field, it's good to have some vocabulary:
- The ISTQB Guide can help you with that. I recommend reading the Chapter 1.
- If you are not familiar with the agile approach, a fast reading for the is also the ISTQB Agile Guide. But for a deep dive, the Agile Testing book is excellent.
Now, about testing engineering, I recommend the following blog posts and videos:
- What Exploratory Testing Is Not | Part 1 of 5 (Worth read all five)
- A Tester’s Commitments
- Exploratory Testing 3.0
- General Functionality and Stability Test Procedure (Paper from 2000, where James Bach (follow this guy on Twitter) shows his process for testing the Windows OS using exploratory testing)
- Understanding exploratory testing
- Testing oracles - HICCUPPS
- A Test is a Performance
- Testing != test execution
- Open Lecture by James Bach on Software Testing
- James Bach on testing in an agile software development team.