Page History
Table of Contents |
---|
What is a charter and why it is relevant
In ET (Exploratory Testing) approach, we don't follow predefined steps and check for well-known expectactions. We also don't test in a random way.
While performing ET, we use our experience and knowledge to uncover new information. Exploring can be done at any moment, at any time, even without a specific explicit reason whatsoever.
Usually, however, exploratory testing starts due to a reason and around some feature or area.
To focus our exploration activities, we use a charter. By having a charter, we can focus our attention around a certain question or concern we want to address. This way, we will be able to explore in more depth and find information that othewise would be hard to depict.
Before coming up with a charter, reflect a bit about:
- What is/are my main goal/s for the testing session?
- Do I want to deepen knowledge about a very specific "thing" (e.g., feature, flow, behaviour) or do I have to want a more high-level overview?
- Will I be using specific resources, tools, or heuristics?
- Will I be focused on certain quality criteria attributes? (e.g., correctness, performance, accessibility)
- Do I want to focus my attention more around positive test scenarios or negative test scenarios?
In sum, Why am I going to do this session? What "exactly" will be looking at? Using what? .
The structure of a charter
There is a common format that works for most teams.
Info | ||
---|---|---|
| ||
Explore <area, feature, risk> with/using <resources, restrictions, heuristics, dependencies, tools> to discover <information> |
Adapted from Maaret Pyhäjärvi, Elisabeth Hendrickson
However, the charter doesn't have a strict structure; we can actually taylor it to our own needs.
Examples
Next, there are some examples of possible charters.
In this case, we have a high-level charter, to have an overview of the system.
Info | ||
---|---|---|
| ||
Explore the system With typical usage scenarios To discover how it works. |
We can also focus on a specific feature, or page, and around a specific concern/quality criteria (e.g., usability).
Info | ||
---|---|---|
| ||
Explore the login page Using Chrome and different screen sizes To discover problems with usability |
We can still be focused on a specific feature, or page, but aiming to test how it works for different contexts/environments (e.g., browsers).
Info | ||
---|---|---|
| ||
Explore the login page Using Chrome, Firefox, Edge, and Opera To discover problems with CSS styling and JavaScript |
Eventually, we may even having a more focused charter, for example, to depict problems around some specific processing.
Info | ||
---|---|---|
| ||
Explore the REST API endpoint for importing test results in JUnit format With different test reports To discover problems in their processing and mapping to internal entities. |
Our exploration can be focused on a certain feature/area (e.g., REST API endpoint) and we can explicitly enumerate a subset of items we wish to validate (e.g., operations).
Info | ||
---|---|---|
| ||
Explore the REST API endpoint for managing bookings and the CRUD operations
Using the "curl" command line tool and the REST API specification To discover problems with the syntax |
Our exploration can be made around specific personas relevant for the context of our product.
Info | ||
---|---|---|
| ||
Explore the book store site With a mid-age, non-technical teacher persona perspective To discover problems around the easiness of the whole process of buying books |
Sometimes we're concerned about product consistency (e.g., in terms of layout, terminology, options, operations); we can have a charter for that.
Info | ||
---|---|---|
| ||
Explore the Traffic Report Using Chrome and different data sizes To discover consistency problems with other reports |
Charters can be used for targeting specific testing types such as security testing, for example. We may want to focus our attention and concerns around specific features and ways of "attacking" them.
Info | ||
---|---|---|
| ||
Explore the shopping cart Using Chrome and RestMan extension to perform API calls To discover if the shopping cart and its related properties can be tampered someway |
Info | ||
---|---|---|
| ||
Explore the product web site Using Chrome to craft and make API calls To discover problems related to authorization |
Tips
Start with broad and then go to specifics
Start with broad (i.e. more generic) charters and common usage scenarios to have a more general idea about the system under test.
Use and stay focused to the charter
While testing, we should stick with the charter; if we depict something a bit unrelated, we can take notes and then decide afterwards if we want to create a charter around that.
Enumerate items you know in advance that you want to cover
You may add a list of bullet points to your charter if you want to enumerate certain aspects you aim to test or subsets for your charter (e.g., operations, user profiles).
Don't detail too much
Avoid having long charters as eventually they will tend to become closer to test scripts and limit your exploration.
Include quality attributes you aim to test
Usually, it is a good idea to know in advance the quality attributes/aspects you will be focused on, so you can target your exploration around those.
Discuss the charters with the team
Provide visibility of what you aim to test. The team can give you feedback about areas or aspects they may consider relevant, among others.
Reuse the charter
Charters can be reused; the findings of sessions with the same charter can and will be mostly different each time a person uses them during a testing session. A charter can be reused by another colleague, a tester, or even a developer.