Elisabeth Hendrickson, Quality Engineer – Pivotal Labs, offers a description of Exploratory Testing: “Exploratory Testing is simultaneously learning about the system while designing and executing tests, using feedback from the last test to inform the next.”
To further explain Exploratory testing, it is more than strictly speaking a ‘practice’, a style or approach to testing software which is often contrasted to ‘scripted testing’, and characterized by the following aspects among others:
- It emphasizes the tester’s autonomy, skill and creativity, much as other Agile practices emphasize these qualities in developers;
- It recommends performing various test-related activities (such as test design, test execution, and interpretation of results) in an interleaved manner, throughout the project, rather than in a fixed sequence and at a particular phase;
- It emphasizes the mutually supportive nature of these techniques, and the need for a plurality of testing approaches rather than a formal test plan;
Exploratory testing has become a cornerstone in Agile testing strategies. Although automated and manual tests are great for creating a safety net for every change made directly to your application, they don’t catch errors outside of the scope of what they are testing. Manual and automated tests aren’t good at what your users excel at: unexpected or erratic behavior; canceling when one shouldn’t, combining actions in a way that wasn’t in your user-story, or configuring your application in an unintended, but technically possible, way.
Where Does Exploratory Testing Fit During an Agile Project?
In the past, when traditional development models were more prevalent, the product development process was more rigid, with clear specifications laid down in detail. In the current day scenario where Agile projects have become more dominant, we all know that time is of essence and that team collaboration is encouraged more, than writing down all product and feature specifications. This is part in true because of time constraints but is also largely driven by dynamic product requirements, which make specifications obsolete very soon. All disciplines are de-emphasizing documentation and focusing more on hands on work.
Product specifications have been a guiding pillar for the test team all along in helping them understand the product, design test cases and know what to expect from the implemented piece of software. Given that this scenario is changing, where specifications are only written at a high level and not necessarily maintained throughout the life cycle, Exploratory Testing comes in very handy to help the tester understand the product’s behavior and implementation. This helps them play around with the product in a free-flowing manner even before tests are designed, helping resolve any product queries upfront; it also helps the developers get a feel for product quality as quickly as possible.
In some Agile projects, releases are extremely short, with time to market as short as 1 week or even less. It is not a practical use of the tester’s time in such cases to go through the regular process of test planning, test case design, test execution, defect management etc. While test case design is invaluable, in situations such as these the focus on test execution (which is exploratory) is what will yield maximum return on investment. In all these situations the testers should not under-play the importance of test design and should spend time writing test cases for valid bugs from such exploratory efforts, to ensure they form part of a robust regression testing suite, for subsequent re-use.
Roles for Agile Testers
- Testers can help the whole team work in a test-driven way by:
- Assisting with defining requirements in the form of user stories and generating system-level tests from those requirements. Think of this as a questioning, test-driven approach to development.
- Assisting with modeling the requirements (user stories)—by asking questions—and generating system-level tests from these stories.
- Testers provide information about each chunk, as the developer delivers it. Sometimes that information is confirmation that the code does what the user story says, does not have side effects, and is release-able at the end of each iteration. Sometimes that information is extra information about the product and other paths the testing could take.
- Finally, testers can perform system-level regression testing during iteration. (Generally on well-established Agile teams, the developers typically run the low-level regression tests, allowing the testers to do what they do best: explore, question, and learn) If the organization is new to Agile, the testers might run regression system-level testing at the end of the project.
Referred From Silicon India
