4. Test planning, user stories and test cases

Test planning defines the scope, objectives, methods, and responsibilities for testing. Test cases translate requirements and acceptance criteria into concrete and repeatable tests.

Test planning defines what will be tested, how testing will be carried out, who is responsible for it, and how the results will be evaluated. Clear test cases help ensure that testing is systematic, repeatable, and based on defined requirements and expected results.

The amount of test planning should be appropriate to the size, complexity, and risks of the software. A separate, detailed test plan is not necessary for every project, but the team should always have a shared understanding of the scope and objectives of testing.

Good requirements make testing easier. When user stories and acceptance criteria are clear, specific, and testable, they can be used directly as a basis for designing test cases and automated tests.

AI tools can help create test cases and identify scenarios that may otherwise be overlooked. For example, AI can generate candidate test cases from users stories. 

4.1 Test planning

Testing should be considered early in software development. Planning testing together with requirements and implementation helps identify unclear requirements, missing acceptance criteria, technical risks, and potential problems with testability before development is completed.

Test planning should consider at least:

• Scope: What functionality and system components need to be tested?
• Testing types and levels: Which types of testing are appropriate, such as unit, integration, system, acceptance, performance, security, or accessibility testing?
• Responsibilities: Who is responsible for planning, implementing, executing, and evaluating the tests?
• Test environments: Where will the tests be executed?
• Test data: What data and test users are needed?
• Automation: Which tests should be automated?
• Risks and priorities: Which functions require the most attention?
• Acceptance criteria: How is it determined that the functionality has been tested sufficiently and can be accepted?

Testing effort should be prioritized based on risk. Business-critical functionality, integrations, security-sensitive functionality, frequently used features, and functionality where failures could have significant consequences usually require more thorough testing.

4.2 User stories and acceptance criteria

Requirements should be written so that their implementation can be verified through testing.

When user stories are used, each story should have clear acceptance criteria describing the conditions that must be met for the story to be considered complete.

For example:

User story:
As a user, I want to search for videos by keyword so that I can find content relevant to me. 

Acceptance criteria provide the basis for acceptance testing but can also help identify the unit, integration, and system tests needed to verify the implementation.

4.3 Test cases

A test case describes a specific situation or functionality to be tested and the expected outcome.

Not every test needs to be documented as a detailed manual test case. For example, automated unit tests may themselves provide sufficient documentation of their test conditions. More explicit test cases are useful when tests need to be executed manually, repeated consistently, used for acceptance testing, or shared between different people.

A test case should contain enough information for another person to understand what is being tested, how it is tested, and what the expected result is.

Depending on the situation, a test case can include:

• Test case name or identifier
• Purpose: What requirement or functionality is being verified?
• Preconditions: What must be true before the test can be executed?
• Test data: What data, accounts, or values are required?
• Test steps: What actions should be performed?
• Expected result: What should happen if the software works correctly?
• Actual result: What happened when the test was executed?
• Result: For example, passed or failed

4.4 Example test case

Test case: Search for videos by keyword

Preconditions

• The application is available in the test environment.
• Test videos have been indexed for searching.

Test steps

1. Open the video search.
2. Enter biology in the search field.
3. Start the search.

Expected result

• Search results are displayed.
• The results contain videos matching the search term.
• No unrelated error message is displayed.

This level of detail is often sufficient for a manual test case. More complex functionality may require several test cases covering different scenarios.

4.5 Consider both successful and unsuccessful scenarios

Testing should not cover only the expected user path. Test cases should also consider relevant alternative and error situations.

Depending on the functionality, consider testing:

• valid input
• invalid input
• missing or empty values
• boundary values
• different user roles and permissions
• errors in integrations or external services
• duplicate or conflicting data
• interrupted operations
• unexpected sequences of user actions

For example, testing a form should not only verify that valid information can be submitted. Relevant tests may also verify required fields, invalid values, maximum lengths, access permissions, and how the application behaves when the backend service is unavailable.

The goal is not to create a test case for every theoretically possible situation. Test cases should concentrate on requirements, realistic usage, identified risks, and situations where failures would have meaningful consequences.

4.6 Keep test cases maintainable

Test cases are useful only when they reflect the current behaviour and requirements of the software.

When functionality changes:

• review the related acceptance criteria
• update affected test cases
• update automated tests
• remove obsolete tests
• add tests for defects when appropriate to prevent regressions

Test documentation should be detailed enough to support repeatable testing, but not so detailed that maintaining the documentation becomes disproportionate to the value it provides.