πŸ—ΊοΈ Exploratory Testing

Exploratory Testing is a method of testing which relies heavily on experience.

  • Therefore, if the tester has never used the application before, nor any other similar application, they will not likely be very productive.
    • Effective exploratory testing involves exploring the specifications manually and methodically while providing a lot of test coverage (not 100%).
      • The practice itself involves having a very high-level mission without a pre-determined route.
        • There is a lot of experimenting, backtracking, repitition and other processes that most people would likely not have the patience nor understanding to execute faithfully. (Failure or lack of experience in doing so is why this form of testing is often downplayed and discredited).
          • To prove the above would require explaining cognition, learning and memory, but in general it involves subconscious experience, intuition and diligence.
            • Sources: Exploratory Data Analysis (Tukey 1977), Strategies for Qualitative Research (Glaser and Strauss 1999), and Basics of Qualitative Research, 2nd Edition (Strauss, Anselm, and Corbin 1998
    • Luckily exploratory testing can be thought of as a way of thinking while testing very objective acceptance criteria in a less declarative way. When verifying very specific requirements for example, it may occur to the tester to verify something slightly exterior or out-of-scope of the primary objective so as not to take everything for granted. It is this application of exploratory testing that can often yield discoveries of regression, or at the very least, enhance the tester's understanding of the current scope of the acceptance criteria.
  • Exploratory testing often involves verifying explicit and implicit requirements.
    • Technically and explicitly a requirement could give you a very specific input and instruct you to expect a specific output, however, implicitly the "expected" output may be technically correct but obviously not expected. Although this is also something difficult to explain an example would be when a result does not make human-readable sense: The code appends the word "Truck" to every Make and Model string output of a list of vehicles - but the name of one of the Vehicles is the "Ford Super-Truck" - therefore the output is "The Ford Super-Truck Truck". Technically this is correct but implicitly it is not. Another common example where explicit requirements are invalidated by implicit requirements occur with product versioning where the year or other qualities of the product are not expected but the main product is technically the same.