What is a Test Charter? | Why Use It & How to Write One?

Most QA pipelines must necessarily include, among other test types, exploratory testing. However, adequately comprehensive exploratory testing requires a certain measure of planning and organization – testing objectives, the features to “explore” in the test, expected results, how to record the actual results, and more. 

All this information needs to be streamlined into a singular, self-explanatory document, accessible and understandable to the right people. In the QA ecosystem, this document is called a test charter. 

In this article, we’ll dive into the definition, nature, benefits, format, and usage of test charters. Think of this as your first step into understanding and creating project-optimal test charters. 

What is a Test Charter?

Test charter refers to a document providing an overview of the parameters, goals, and plans governing a test session. It includes information defining the feature under test, the premise/query, the required tool, possible risks, data dependencies, and expected results as well as deadlines. 

At a high-level, it is a manual for exploratory testing sessions. It answers questions such as:

• What is the primary goal of this test session?
• How long is the test session?
• Which feature(s) will be tested in this session?
• What tools are required for this test session?
• What are the expected results of the test?
• What are the user expectations and requirements for this feature?
• How do I record the actual results?
• Who do I report the results to, once the test is completed?

It is best to assign one test charter to a single session. This helps isolate features when testing and recording results. It also ensures that testers can focus on a single feature, and really get into its systematic operations to verify functionality. 

Why do we need a test charter?

Simply put, we need a test charter because exploratory testing does not follow predefined steps. It also does not come with “expected results” set in stone. This is because the point of the test is to “explore”; testers literally explore the software with the intent to come across any bugs within each feature. 

Note: Exploratory testing is usually not part of test automation suites. It requires human judgment, and must necessarily be manually tested. 

Learn more about test automation

Now, this does not mean that testers “explore” the system randomly. They are chosen for their experience, so they know what to look for, and how users would navigate an app or page. They are also given detailed information about requirements, user expectations, and the software’s main functions – all included in the test charter. 

The charter helps testers stay focused during exploratory sessions. By designating a single feature and laying out our user expectations, the test charter ensures that QAs do not get bogged down in unnecessary details. They don’t end up testing irrelevant components or verifying aspects that end-users don’t care about (at this stage of testing).

Despite providing a guiding principle, good test charters also encourage diverse and creative thinking. They don’t tell QAs what to test, but give them the core values for the session. QAs keep the primary variable (user expectations, software design) as the base of their action, and then use their industry experience to replicate common and uncommon user scenarios. 

Since test charters don’t restrict testers’ actions, they lead to more interesting and experimental test scenarios. That is always a good thing because it generates innovative thinking. 

Benefits of Test Charters

• Facilitates continuous learning: Test charters provide an organized framework for test design, and execution, as well as for interpreting results and extracting accurate learnings. While exploratory testing is always left to the tester’s volition (they decide how to use a certain feature, without predetermined test steps).
  
  However, the test charter provides them with relevant information to better guide the testers’ efforts. An important part of that is evaluating the right variables and identifying opportunities for improvement, be it for the software or the testing process.
  
  Test charters streamline exploratory testing without limiting the testers’ autonomy.
  
• Assists with innovation and sharing knowledge: Test charters provide structure, direction, and a central repository for every tester to add their conclusions. As is well known, agile development and testing flourish best when individual members and teams collaborate.
  
  Test charters provide sufficient context for such collaboration. They record the intent and duration of each session, enabling quicker feedback cycles and analysis.  These charters provide the framework for testers to apply their domain knowledge, intuition, analysis, and user-first thinking.
  
• Helps find bugs not predicted in other tests: Since exploratory testing is unplanned in execution, it reveals bugs that other planned tests do not. With no test scripts, exploratory testers are free to literally do anything they want on a certain software application. Unpredictable user actions will automatically increase the likelihood of finding bugs no one expected when creating test cases and scripts.
  
  By directing and structuring exploratory testing, test charters expand test coverage, extending it to the blind spots of other tests. It provides a significant failsafe mechanism for all software testing projects. 

How to Develop a Test Charter

The key to developing an effective test charter is to be methodical. Break down the process into steps using an outline focused on software requirements and projected user preferences. Additionally, be aware that all elements of the test charter will change as the project and software under development evolve. 

• Start by isolating the feature to be tested. 
• Note down all relevant project specifications, user stories, risk assessment, and technical as well as business requirements. 
• Create the “test idea” i.e., the idea around which the test will proceed. This is up to the QA, who will create it using their experience and intuition. 
• Detail the resources, data, tools, and environment requirements for the test. 
• Mention the goals of the test session. 
• Highlight the expected results. 
• Describe the process for noting results (whether to take screenshots, record video, etc.)
• Finally, state possible obstacles that may be encountered during the test. These hazards can be estimated reasonably accurately by experienced testers who understand the product end-to-end. 

Test Charter Format (Free Template)

At a high level, every test charter should include the following variables:

• Name: The charter name should describe the test in question. For example, “Profile creation for new users on <application name> or “Testing review mechanisms (leaving comments, star or number reviews)”.
  
  The idea is to describe the purpose of the test charter upfront so that anyone else viewing this document immediately knows its purpose and content.
  
  “Quick attacks around profile creation” or “Test multi-user comments, permissions, and race conditions within and out of group membership.”
  
• Test area: Mention and describe the feature to be tested. Additionally, describe the test harness used in the session.
  
• Date and time: Mention the date and time of the test’s starting.
  
• Tester’s Name: Self-explanatory.
  
• Task Breakdown: The tester describes, as an overview, the direction of the test and steps to be taken within the session.
  
• Duration: How long will the test take or is expected to take?
  
• Test Design & Execution: This section should comprise information about how the actual test is conducted, and what steps the tester actually took. This can be filled in detail after the test is completed (since exploratory tests are unplanned).
  
  Simply describe the actions taken during the test. Don’t forget to include the observations gathered during said test.
  
• Bug reports: Describe the bugs found, the nature of each, at what point in the test they showed up, and what anomalies are showing up with each bug and steps to reproduce them. This would largely be information about bugs captured through screen recording, screenshots, text logs, etc.
  
  For convenience’s sake, number or name each bug.
  
• Session setup: Detail the tools, test data, and test environment to be prepped before the test begins.
  
• Charter vs. Opportunity: This is the & of time the tester spends on the expected system features as opposed to unexpected parts of the system under test. 
  
• Expected Results: What is the test expected to achieve? What are the ideal results?
  
• Actual Results: Self-explanatory. 

Here is the link to  a downloadable charter: https://www.tmap.net/sites/tmap/files/2019-08/Template%20Exploratory%20testing%20charter%20Simple%20v1.docx 

Conclusion

Test charters turn exploratory tests into a science and art. They provide direction without hampering creativity, so testers and projects get the best of both worlds. They are essential to rein in the unplanned nature of exploratory testing, and thus keep them on track (there is a real danger of the tester getting lost in exploring features beyond immediate requirements). 

Use this article to create your first test charter. As you keep building more tests and corresponding charters, it will become simpler to predict and understand the needs of the team, customers, and other stakeholders. Consequently, creating mature, targeted test charters will be a simple task. 

Frequently Asked Questions

What is an exploratory test charter?

An exploratory test charter is a document that details all the parameters, goals, and plans governing an exploratory test session. It mentions and discusses the feature under test, the premise/query, the required tool, possible risks, data dependencies, and expected results as well as deadlines.