Prepare Your Test Plan

Identify the Structure of the Test Book

Since the beginning of this Course, you’ve been reading, thinking, refining, and making decisions—from reviewing the specifications to writing the Test Strategy.

Now it’s time to apply the rules you defined by building the test book.

Before getting into the format, let’s talk about the content—or rather, its skeleton.

The structure of a test book is always similar, regardless of the tool your organization uses. The names may differ, but the logic remains the same. You will generally find sections dedicated to:

• Requirements:

  • All functional and non-functional requirements to be tested are imported into this section of the tool.

  • The goal is not to duplicate the specifications, but to ensure traceability and coverage in reports.

• Test cases:

  • This is what we call the test assets (remember the library analogy from this chapter?).

  • Test cases and scenarios will be written and stored here.

• Test campaign:

  • You will assemble your scenarios into test suites in order to cover the project’s Scope.

• Report:

  • You will automatically generate execution reports and campaign summaries.

• Anomaly:

  • This section helps you write defect reports by retrieving the steps and expected results from the test cases.

  • Most tools include this section, but not all. I’m mentioning it because it’s an essential feature in day-to-day testing.

Depending on your organization, you may work with different tools.

Import Your Requirements

Importing requirements can feel intimidating, yet it’s essential for the practices used on your project.

Once your requirements have been imported into your test management tool, verify that best practices are followed. You should see:

• The requirement’s unique identifier — the same one used in the specifications.

  • Occasionally, identifiers may differ, but the unique mapping between the two must be clear.

• Its version: Is this requirement at version 1 or version 2?

• Criticality: Is the requirement critical, major, or minor?

• Status: What is the requirement’s state?

  • Approved: The requirement is considered applicable and ready to be used.

  • Obsolete: The requirement is outdated. It may need updating, archiving, or deletion.

• Category: What type of requirement is it?

  • Functional

  • Non-functional

  • Performance

  • Technical

• Description: This may include a complete description or a summary. Practices differ from one company to another, but at the very least you should find a URL link to the specification.

Reread Your Requirements

At the end of this step, rereading the imported requirements is essential. You can do this yourself or ask a peer to review them.

Your goal is to ensure that all requirements are present and that all necessary descriptive information is included.

Every requirement you identified during your requirements analysis should appear here.

Over to You!

Context

Your Test Strategy has been validated by Édouard. You now begin preparing your test book.

You estimated that this task would take two days, and you’ll perform it on your own, without Andy’s help.

You start by importing the requirements into your test tool.

Instructions

Fill in the various columns of the table. In the “Name” column, do not use action verbs.

In the “Description” column, write a brief description of the requirement’s Goal.

Summary

• The test book lists all tests that must be performed during the campaign.

• It consists of five main sections: requirements, test scenarios, the test campaign, reporting, and anomalies.

• You’ll work with various tools to manage your test books; they differ in design but share a common structure.

• After importing requirements, check that all necessary requirement elements are present.

Your requirements are now imported. Next, let’s look at what test cases are made of.