TL;DR
Now that we know Simon’s third diagram, Problems, Questions, Ideas, and Praises (PQIP), let’s explore Neil Boyd’s example of session-based testing. The Charter is to find in the fifteen-century, a new route from Europe to India via sea. This is a part of the Exploratory Testing Pathway. Many thanks to Marcel, who sublimed this great resource on his blog, That’s the buffet table.
Fifteen Century Charter
The best way to check do we really understand some topic is to provide the example of how we would use that knowledge on some real problem. In this post from 2016, Neil provides proof of his understanding of exploratory testing on the Vasca Da Gama’s problem from the fifteen century.
The Charter in exploratory testing is the problem that you need to explore. For example, explore our application using only Firefox. This establishes The Goal of your exploratory testing session. When your manager reads your Charter, it will help him to better understand your testing story. Next is the scope of your Charter. Which part of the application will you explore? For example: The reports feature heavily depends on several Javascript libraries, so let’s focus on that feature. You need to timebox your session duration. Otherwise, you could quickly lose focus or concentration.
It is essential to list the risks in defined scope and Charter. For example, the javascript library could not work on Firefox for some library features (Pie chart diagrams work, but the Bar diagram fails to render).
Here is Neil’s Charter example:
Group Session
Based on his experience, Neil suggests that it is better to execute exploratory sessions as a group of testers. Based on my experience, I think that group sessions should be combined with single sessions. Charter is performed separately by several testers, and in debrief session, we compare their notes. The reason is that each tester has its own mind flow, which could be easily broken with other mind flow.
Keeping A Record
Neil here suggests to keep a record of three things:
- tests executed
- defects found
- areas covered
In the executed test, we explain how to do our passed test. This is useful information for other testers and could spark new ideas. Defects found notes are essential so we could write the RIMGEA bug report from them. Covered areas because it is very easy to forget what we tested in our session.
This is less when we compare this to later defined Bach’s Session-Based Test Management, where we have the following note types:
- bug
- issue
- fact
- oracle
- risk
- heuristic
- idea
- opportunity
Session-Based Test Management gives you more granularity in describing your testing story.
