Skip to content

Master Test Plan
Document Master Test Plan
Author: LinearB
Version: 1.0
Date: 23.04.2025

General information

A master test plan (MTP) is a high-level document that describes the overall testing strategy, objectives, and scope for a software project or product. It provides a comprehensive overview of the key decisions, resources, risks, and deliverables involved in the testing process. It also defines the relationship and coordination among different test levels, such as unit testing, integration testing, system testing, and acceptance testing. An MTP helps to ensure that the testing activities are aligned with the project goals and requirements, and that the quality of the software is verified and validated. You can find more information about MTPs from these sources:

Master Test Plan

1. Introduction

This document outlines LinearB test plan and strategy for the development of our ecommerce service using PrestaShop. The system to be subject of our testing includes all necessary tools utilized to run our product, ranging from our host services, our database, and our web environment.

In order to systematically identify and fix issues, and to satisfy user requirements efficiently and effectively, we plan to mainly focus in:

  1. Non-Functional Testing: tests that focus in requirements like performance, scalability, portability, stress, etc.
  2. Integration Testing: tests that focus in two or more modules of the system. For example, the usability of our database and its components.
  3. System Testing: through exploratory testing, checking the general user experience and go through each step of the customer journey to detect issues, but most importantly to make sure the system works efficiently. In other words, to validate our software in accordance to our customer requirements.

2. Test Objectives

The main goal of our testing process is to ensure that our product developed using PrestaShop meets all specified requirements and performs reliably in a production environment. The specific objectives of the testing process can be categorized as follows:

  1. Verify Security Measures:
  • Ensure that the integration with the vulnerability scanning tool (FEA010) effectively identifies and reports known vulnerabilities.
  • Validate that all security fixes are correctly implemented and do not introduce new vulnerabilities.
  1. Validate PrestaShop as a Service:
  • Confirm that the Dockerized service production (FEA003) is correctly implemented, allowing for efficient deployment and management of the PrestaShop service.
  • Ensure that secure service access (FEA002) is properly configured to protect user data and transactions.
  1. Ensure Effective Bug Fixes:
  • Verify that the bug reporting and triage processes (FEA081) are efficient and effective in identifying and prioritizing issues.
  • Confirm that the integration with version control systems (FEA023) supports effective tracking and management of code changes and bug fixes.
  1. Test Payment Integration:
  • Validate the integration with popular payment gateways (FEA192) to ensure seamless and secure transaction processing.
  • Ensure that the payment integration supports a wide range of payment methods and provides a smooth user experience.
  1. Functional and Non-Functional Requirements:
  • Verify that all functional requirements are met, ensuring that the ecommerce service operates as intended.
  • Validate non-functional requirements, including performance, usability, and reliability, to ensure a high-quality user experience.
  1. Risk Mitigation:
  • Identify potential risks and ensure that appropriate mitigation strategies are in place to address them.
  • Verify that the system is resilient to common issues and can recover gracefully from failures.

3. Test Items

The following components of the ecommerce system will be tested:

  • PrestaShop instance deployed via Docker containers
  • Custom modules and services developed for secure access
  • Vulnerability scanning integration
  • Version control integration and bug tracking mechanisms
  • Payment integration components (Stripe, PayPal, etc.)
  • The user interface (UI) and overall user experience (UX)
  • Database layer and service configurations

4. Features to be Tested

Epic Feature ID Description
EPIC 03: Presta shop as a servce FEA002 Secure service access
EPIC 03: Presta shop as a service FEA003 Dockerized Service Production
EPIC 01: Security fixes FEA010 Integrate with a vulnerability scanning tool to automatically detect and report known vulnerabilities
EPIC 08: Bug fixes FEA023 Integrate with version control systems (e.g., Git)
EPIC 08: Bug fixes FEA081 Ensure efficient bug reporting and triage processes
EPIC 19: Payment integration FEA192 Integration with Popular Gateways: Integrate with a wider range of popular payment gateways (e.g., Stripe, PayPal, Square, Amazon Pay, Apple pay, Google pay)

5. Approach

The approach used for testing in our project will mainly be exploratory testing.

Exploratory testing involves several informal testing sessions aimed at discovering issues or bugs that have not yet been identified. This approach enhances the overall quality of the software, identifies isolated cases, expands test coverage, and can lead to the addition of new features when combined with automated testing and other techniques. It lacks of structural rigidity, encouraging experimentation, creativity, and discovery together within the team.

The rapid feedback provided by exploratory testing helps bridge the gap between testers and developers. Most importantly, it offers a user-oriented perspective and valuable feedback to the development teams. The primary goal is to complement traditional testing methods to uncover significant defects that are typically hidden within the defined workflow.

Preliminarily, we expect to use tools for aiding and explore other approaches to testing: K6, Robot Framework, Selenium.

6. Item Pass/Fail Criteria

Each test item will be evaluated based on the following criteria:

  • Pass: The test case executes as expected, meeting all predefined acceptance criteria without critical or major bugs.
  • Fail: The test case does not meet acceptance criteria or leads to incorrect results, system errors, security vulnerabilities, or regressions.
  • A failed test must be logged in the defect tracking system and resolved before the corresponding feature can be marked as complete.

7. Suspension Criteria and Resumption Requirements

Suspension Criteria: - A critical defect is discovered that blocks further testing. - Major test environment failure (e.g., Docker service fails to initialize). - Failure to deploy core services (e.g., payment gateway fails integration).

Resumption Requirements: - All critical/blocker issues must be resolved and retested. - The test environment must be restored to operational state. - Test data and configurations must be validated before resuming.

8. Test Deliverables

  • Master Test Plan (this document)
  • Test cases and test scripts
  • Test data sets
  • Bug reports and defect logs
  • Test summary reports
  • Automated test results (e.g., Selenium/K6)

9. Testing Tasks

  • Define and write test cases for key features.
  • Set up test environments using Docker containers.
  • Configure and connect scanning tools for vulnerability detection.
  • Develop and execute exploratory test sessions.
  • Perform regression and integration testing.
  • Document all results and track defects.
  • Conduct performance and load testing using K6.
  • Review and approve testing artifacts.

10. Environmental Needs

  • Hardware: Modern workstations for testers
  • Software: Docker & Docker Compose, PrestaShop instance, Selenium & Robot Framework, K6 load testing tool, Git for version control.
  • Network: Reliable internet connection, access to staging servers and APIs.

11. Responsibilities

  • Test Lead: Create MTP, assign test tasks, oversee quality assurance.
  • Test Engineers: Develop and execute test cases, report bugs.
  • Developers: Assist in resolving bugs, unit testing, build deployments.
  • DevOps: Maintain testing environments and Docker services.
  • Security Analyst: Run vulnerability scans and evaluate results.
  • Project Manager: Monitor test progress and ensure alignment with project goals.

12. Approvals

The following individuals must approve the Master Test Plan before testing begins:

  • Team Lead – Lassi Iiskola

  • Lead Developer Team

  • Product Owner