Skip to content

Master Test Plan
Document Master Test Plan
Author: Topias Koskela
Version: Ver 0.03
Date: 15.3.2024

General information

Some resources for the testing team:

Master Test Plan

1. Introduction

This document describes our testing plan for Tukko 2.0. It can be used as guidance by our testing team in their path to properly documented testing. The plan is subject to chance as the skills and needs of our testing team are defined further.

2. Test Objectives

The objectives for testing in Tukko 2.0 is to learn more about manual and automated testing and get a grasp on what proper testing methologies are in an IT project. Also our goals are to test Tukko 2.0 into a working condition where a normal user would not encounter any major issues while using it.

Another objective is to try out automated testing on FEA109 "Search location by name" and get some kind of pipeline to run automated tests whenever new changes are implemented.

3. Test Items & Features to be Tested

Manual testing will be conducted for these features of Tukko 2.0:

  • FEA106 Improve dark mode colors
  • FEA109 Search location by name
  • FEA110 Enhance color contrast for color blindness
  • FEA514 Monitor server loads with a GUI

Automated testing will be tried out for these features:

  • FEA109 Search location by name

4. Features not to be Tested

The following features were selected to not be tested with test cases. They will have their own acceptance tests that need to be met for the features to be considered done.

  • FEA510 Establish automated testing and quality assurance processes
  • FEA516 Manual Testing
  • FEA517 Maintainable documentation

Our project team decided not to run any security related testing during our project since we don't have the expertiece to do those and we are not developing any security related features for Tukko.

5. Approach

  • Any and all new functionalities created should have basic unit tests created by the development team. Whenever possible the tests should be created by a different person compared to the developer creating the functionality.
  • All features selected will have acceptance tests created by the testing team and run by a person on the team that did not create the feature in question.
  • Test cases can be run during development to see if a feature is looking ok and when all test cases related to a feature pass the acceptance test can be tested.

6. Item Pass/Fail Criteria

Feature passes tests if all unit tests pass, the test cases related to it pass and if the acceptance test passes. Typically a test case can be considered passed if it meet the user stories related to the feature, it is convenient and easy to use for the target audience and no major unrelated bugs are found.

7. Suspension Criteria and Resumption Requirements

Testing should be suspended only if the following issues are found:

  • A 3rd party component Tukko relies on breaks the service with an update to the component
  • The platform being tested on is crashing or unresposive to the point that testing is painfully slow.
  • A high priority bug is detected that the fixing of will change majorly the functionality of the platform being tested on.

Suspension of testing should be a temporary measure and it should become a high priority for the other teams in the project to resolve any issues that are causing the suspension.

8. Test Deliverables

Testing in Tukko 2.0 will include the following test documentation: test cases in GitLab, acceptance tests on the opf page and robotframework in GitLab. Test results should be written in their own folder in opf.

Exploratory testing done has its own folder under 50-test-managment and they should be well documented.

9. Testing Tasks

All unit tests, test cases and acceptance tests should pass for testing to be done.

10. Environmental Needs

Testing is done on a modern PC and a modern browser on a display that has adjustable brightness. For color blindness testing a Chromium based browser where the steps listed on the tutorial how to emulate vision deficiencies can be followed. The tutorial gives the tools necessary for color blindness and poor visibility testing.

11. Responsibilities

  • Unit testing is the responsibility of the development team. If possible the unit tests should be designed by a different person on the development team compared to the person developing the feature.
  • Manual Exploratory testing is the responsibility of the testing team.
  • Acceptance tests will be designed by the testing team
  • Acceptance tests should be tested by a person from the project team that did not design the test or develop the feature tested.
  • Test cases can be tested by anyone assigned to do it.
  • Security testing has been ommitted by the decision of the project lead.

12. Staffing and Training Needs

All required staff has already been recruited into the team but they still need training in testing methologies and documentation to become better testers. Testing team requires introduction and further knowledge on the robot framework being used in the automated testing of the project.

13. Schedule

Schedule for each feature and their testing has been covered in the Project release plan. Each Feature should be tested within the time scheduled for the feature.

14. Risks and Contingencies

Risks related to the whole project are included in the project risk managment plan.

15. Approvals

Testing plan is approved by both the testing team lead and the project lead.