Exploratory Testing
What is Exploratory Testing?
Exploratory testing is an unscripted QA testing technique used to discover unknown issues during and after the software development process. In addition to being used to discover specific bugs, exploratory testing is also understood as a way to learn about the application and design functional and regression test cases to be executed in the future. In 1984 Cem Kaner coined the phrase Exploratory Testing and used an interesting analogy in a 2008 talk to compare the differences between it and automated/scripted testing. The four stages below are not independent of one another and when it is applied yield best results.
Learn
The most important functions that a QE engineer needs is an understanding of the app or website that they are testing. By doing so it provides context and includes information such as competitive benchmark data, domain knowledge and company details. An understanding like this ensures that the QE engineer is able to take in all manner of inputs relating to the app or website when he or she is performing the actual test. Contextual knowledge allows QE engineer to provide details surrounding results that they may find and whether or not they are applicable.
They also need to understand deeply the requirements of the specific test that was requested. A deep and comprehensive understanding of the testing requirements arms the tester with the right amount of knowledge to dive deep into the app or website.
It is also important that the QE engineer knows what the desired outcomes of the testing might be. It is not enough to merely look for bugs but to know what the end goal is for the testing cycle. Sometimes the goal is to ensure that previous bugs have been resolved in such a way that new functional bugs have not been introduced (regression) somewhere else. Sometimes the software testing is to ensure that particular functions work as expected and no bugs found are the desired outcome per se.
Test Design
The difference between exploratory and scripted testing is in design. Designing differs from scripting in that while the test has specific parameters or rules, it is not done in a preset path or prescribed manner. Exploratory QE engineers are able to conduct the test in a way which they deem fit and do not have a desired or expected outcome. Often times, the exploratory testing technique leads to developing more rigorous, scripted test scenarios over time.
Designing also affords testers and test managers the option to map out the various techniques a QE might use. This could mean the device, circumstances or conditions if that has not been established yet by the test requester. QE can use notes, mind maps, flowcharts, decision tables or any manner of organizational tools at their disposal.
Test Execution
Given the freedom to complete the test as QE feels free to do so. As soon as the test is written or requested (note: not a test case), the test can be conducted. This freedom means that nobody is waiting for scripted requirements and creative work can begin. A QE then is observing and learning about the application or website. They are probing and exploring how functions work, how they interact with one another and how those pieces work together so that further exploration can take place. Results are then compiled and reported back through the appropriate methods.
Exploratory testing is a form of testing that encourages and rewards both the product designed and QE by allowing an unconstructed approach to finding bugs. This is stark difference between exploratory testing and adhoc testing although frequently the two are construed to mean the same thing. Adhoc approaches are distinguished by their lack of defined process and approaches.
Analysis
Once QE is done with the test execution it is important to do an Analysis which is the process of looking into the existing test artifacts and requirement document and provide the Dynamic feedback — With QE freed from the traditional test-case based approach, they are able to focus their efforts on key areas or problem areas as needed. This can give developers much needed input on product quality or possible issues on an ongoing and more immediate basis.
References:
We encourage our readers to treat each other respectfully and constructively. Thank you for taking the time to read this blog post to the end. We look forward to your contributions. Let’s make something great together! What do you think? Please vote and post your comments.
