Define Your Scenarios

You’ve got your requirements review in hand. Now it’s time to write the Test Strategy.

Good question! Let’s start with a definition.

Some elements mentioned here won’t be familiar yet. That’s completely normal we haven’t covered them in this Course. I’ll explain each one throughout the different sections of this chapter.

Define the characteristics of test scenarios

A functional test strategy is an action plan that outlines the approach and methods used to verify that the system behaves according to the functional requirements.

• It starts with a requirements analysis to identify the features to be tested, the timeframes involved, and the resources available. This step determines the test objectives and success criteria for the project (requirements analysis you saw in Part 1 of this course).

• Next, you determine the types of tests to be performed. For each type, you describe how the tests are executed, as well as the tools and techniques to use.

• Tests are planned and executed iteratively, using short development cycles. They are continually updated and adapted as project requirements evolve.

It also includes methods for managing test results and reports. A test strategy defines how defects are tracked and resolved and how results are communicated to stakeholders.

• Although validated before testing begins, the strategy is reviewed and updated regularly throughout the project to ensure it stays aligned with evolving requirements.

In short, the Test Strategy is a plan describing how tests will be planned, executed, and managed throughout the project.

Get hands-on with test scenarios

Before diving deeper, let’s briefly revisit what a test scenario is.

That explanation says everything and nothing at the same time! If you’ve already taken the Test Execution Course, this will sound familiar. If not, don’t worry—these fundamentals are essential for understanding what comes next.

Let’s look at an example feature on an e-commerce site: implementing the shopping cart.

Our scenarios will require:

• A Name: It must reflect the Test Objective and make the scenario easy to identify.

  Example: Add a product to the shopping cart.

  Depending on the company, naming standards may exist, but they generally include these best practices:

  • use clear and concise terminology so the Goal is obvious;

  • avoid overly long names—they must be short enough to read and remember;

  • use a consistent naming convention for easier organization and searching;

  • be specific enough to avoid confusion with other tests.

• A Goal: What am I testing, and why?

  Example: The scenario aims to add a product to the cart to verify that the customer can purchase it.

• One or more Requirements: Linking the scenario to its requirements ensures it is justified and tied to a real need.

• Test cases:

  • a defined sequence of steps,

  • performed in a specific order,

  • including all required actions,

  • with a precise expected result,

  • e.g.:

Here’s how the structure of a scenario might look:

Absolutely! In our example, we could add scenarios to test behavior:

• by adding two products to the cart;

• by adding multiple products from different departments.

There are many possible combinations.

Here are two best practices to adopt:

• Relevance: The scenario must cover a feature or use case of the software.

  For example, it wouldn’t be relevant to create a scenario about payment methods if the objective is to test the shopping cart implementation.

• Comprehensibility: The scenario must be easy to understand for testers and other team members.

  This starts with the name—“Add product to cart” is clearer than simply “Add product”.

Estimate the number of scenarios

You might be wondering: “How can we test the least while covering the most requirements?”

Indeed, multiple scenarios can validate multiple requirements—let’s see how.

To get an overall picture of your test Scope, define your scenarios at a high level. The idea is to estimate how many scenarios you’ll need to meet the project’s Goals. Is it closer to 10 scenarios? Or 50?

Here’s a method to help estimate the number:

• Identify all the application’s features: adding a product to the cart, removing a product, updating a quantity, validating the cart, etc.

• For each feature, identify the possible test cases. For example, for adding a product to the cart: verifying the product is added, verifying the quantity is correct, verifying the price is correct, etc.

• Estimate the number of test cases for each feature. The estimate depends on feature complexity and the variety of scenarios you plan to test.

• Calculate the total number of test cases for the entire application by adding them up.

Identify impacts on your test assets

This is a crucial step in your Strategy. It helps identify how new features affect existing assets—and ensures you secure those impacts.

To identify impacts, review all new or updated requirements and analyze their potential effect on what already exists.

To do so, ask yourself questions like these:

• Which test cases or scenarios need to be updated?

  This means modifying an existing test case to align it with new requirements.

  • Suppose you have a scenario: “Check the site home page.” The new project adds the shopping cart, accessible from the home page.

  • You will need to update associated test cases to check access to the cart from this page.

• What can be reused?

  A test case can be reused as long as it remains relevant and requires no modification.

  • A scenario like “Access the site” will likely remain unchanged because it only checks whether the site is accessible.

• What becomes obsolete?

  If a function is removed, its test scenarios no longer serve a purpose.

• What must be written from scratch?

  Which new test case or scenario is required that doesn’t yet exist in your test assets?

  • For example, verifying the cart interface introduced in this version.

Over to You!

Context

You’ve completed your requirements analysis. Following your last email, Édouard is still determining how to integrate order information and tracking.

It’s not final, but the current idea is to update the new orders table (t_order) to store these elements. This recording area will not impact your test assets, allowing you to move forward for now.

Instructions

Your current task is to build scenarios per Feature:

• Write a high-level list of scenarios;

• Identify the impact on your test assets.

Summary

• A Test Strategy is an action plan for verifying that an application meets its requirements.

• A scenario is a sequence of steps used to verify expected application behavior.

• To estimate the number of scenarios, identify all features, possible use cases, and then estimate the number of scenarios needed.

• Your test assets are the library where your scenarios and test cases are stored.

• Requirements may impact test assets—you may need to reuse them as-is or update them.

You’ve sketched out how many scenarios you’ll need. Now it’s time to see which pencil to use to create them.