Use case description test management (#19064)
Initial version of a use case description for test management
@@ -6,10 +6,11 @@ description: Step-by-step instruction about various use cases
|
||||
keywords: use-cases
|
||||
---
|
||||
|
||||
# OpenProject Use Cases
|
||||
# OpenProject use cases
|
||||
|
||||
| Use Case | Description |
|
||||
| -------------------------------------------- | ------------------------------------------------------------ |
|
||||
| [Resource Management](resource-management) | OpenProject does not have the automated functionality to provide detailed resource management or employee work capacity calculations. This guide with detailed step-by-step instructions introduces a workaround that can provide an avenue to accomplish this manually and visually beyond the functionality the Team Planner Module provides. |
|
||||
| [Portfolio Management](portfolio-management) | This guide provides detailed step-by-step instruction on how to set up an overview of your project portfolio and create custom reports using the Project Overview, Wiki and the Rich text (WYSIWYG) editor in OpenProject. |
|
||||
| Use Case | Description |
|
||||
| ------------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
| [Resource management](resource-management) | OpenProject does not have the automated functionality to provide detailed resource management or employee work capacity calculations. This guide with detailed step-by-step instructions introduces a workaround that can provide an avenue to accomplish this manually and visually beyond the functionality the Team Planner Module provides. |
|
||||
| [Portfolio management](portfolio-management) | This guide provides detailed step-by-step instruction on how to set up an overview of your project portfolio and create custom reports using the Project Overview, Wiki and the Rich text (WYSIWYG) editor in OpenProject. |
|
||||
| [Implementing Scaled Agile Framework (SAFe) in OpenProject](safe-framework) | Learn how to set up and configure OpenProject to support the Scaled Agile Framework (SAFe) to successfully deliver value to customers using agile practices at scale. |
|
||||
| [Test management](test-management) | OpenProject can be configured to support lightweight test management using custom work package types, workflows and project templates. This guide describes how to manage test cases and test runs in a reusable, scalable way |
|
||||
|
||||
@@ -0,0 +1,150 @@
|
||||
---
|
||||
sidebar_navigation:
|
||||
title: Test Management with OpenProject
|
||||
priority: 950
|
||||
description: OpenProject can be configured to support lightweight test management using custom work package types, work packages and project templates. This guide describes how to manage test cases and test runs in a reusable, scalable way.
|
||||
keywords: test plan, test case, test case, test management
|
||||
|
||||
---
|
||||
|
||||
> [!IMPORTANT]
|
||||
>
|
||||
> This is use case description is a draft. It will be detailed and improved based on feedback from the community. If you have any feedback please contact us.
|
||||
|
||||
# Test management in OpenProject
|
||||
|
||||
## Purpose
|
||||
|
||||
This guide describes how OpenProject can be used for lightweight test management by modeling test plans, test cases, and test runs using built-in features such as work package types and project templates. It enables teams to manage and execute tests within the same environment they already use for project and requirements tracking.
|
||||
|
||||
## Scope and assumptions
|
||||
|
||||
This use case is intended for teams that:
|
||||
|
||||
- Already use OpenProject for project planning and requirements tracking
|
||||
- Want to include manual or semi-automated testing workflows
|
||||
- Need traceability between requirements, test cases, executions, and defects
|
||||
|
||||
This setup is not a replacement for full-scale test automation or advanced lab management tools, but rather a structured and integrated approach to test tracking.
|
||||
|
||||
## Structure and terminology
|
||||
|
||||

|
||||
|
||||
### Core entities
|
||||
|
||||
| Concept | OpenProject entity |
|
||||
| ------------------ | --------------------------------------------------- |
|
||||
| Requirements | Work package (e.g., type `Feature` or `User Story`) |
|
||||
| Test case | Work package type `Test Case` |
|
||||
| Test run | Work package type `Test Run` (child of test case) |
|
||||
| Test plan | Project (created from a template) |
|
||||
| Version under test | OpenProject *Version* field on test runs |
|
||||
| Defect | Work package (e.g., type `Bug`) |
|
||||
|
||||
### Relationships
|
||||
|
||||
- Each `Feature` or `User Story` may relate to one or more test cases.
|
||||
- Each `Test Case` defines a reusable test specification.
|
||||
- Each `Test Case` has one or more Test Runs (child work packages).
|
||||
- A `Test Run` is specific to one software version.
|
||||
- `Test Plans` are realized as individual projects per version, created from a reusable template.
|
||||
- `Bugs` can be linked to failed `Test Runs`.
|
||||
|
||||
This structure supports traceability from requirements to execution and defect reporting.
|
||||
|
||||
## 1. Test preparation and execution
|
||||
|
||||
### 1.1 Creating a test plan (project)
|
||||
|
||||
A new test plan project is created based on a predefined template using the *create project form*.
|
||||
|
||||

|
||||
|
||||
### 1.2 Adjusting the created test plan
|
||||
|
||||
In the next step the [newly created test plan](https://testmanagement.openproject.com/projects/regression-test-openproject-16-dot-1/work_packages?query_id=90) is adjusted by specifying the test object. The easiest way is to select all work package (`CMD + A`) -> right click -> `bulk edit`.
|
||||
|
||||
* Version of the test object (version ideally shared from the development project)
|
||||
* Tester
|
||||
* Environment
|
||||
|
||||
For all test runs which are not planned the status should be adjusted to something like `Not planned`.
|
||||
|
||||

|
||||
|
||||
### 1.3 Test execution
|
||||
|
||||
1. Testers open the project corresponding to the release version.
|
||||
2. Each test run is executed individually:
|
||||
- Preconditions are verified
|
||||
- Steps are performed
|
||||
- Results are recorded
|
||||
- Status is updated (e.g., `Passed`, `Test failed`, `Blocked`)
|
||||
3. If failures occur, related defects (bugs) are created and linked.
|
||||
4. Boards, filters, or hierarchy views are used to monitor test progress and coverage.
|
||||
5. The test result can be document creating a pdf report of the [test status and results](https://testmanagement.openproject.com/projects/regression-test-openproject-16-dot-1/work_packages?query_id=89).
|
||||
|
||||

|
||||
|
||||
## 2. Configuration guidance
|
||||
|
||||
This section provides guidance on how to configure OpenProject for test management. It assumes familiarity with OpenProject administration features.
|
||||
|
||||
### 2.1 Configuration example: Test Cases (work package type)
|
||||
|
||||
The work package type `Test case` can be configured so it shows the relevant information:
|
||||
|
||||
* Test runs (related work packages table `children`)
|
||||
* Tested features (related work packages `requires`)
|
||||
* Priority
|
||||
* Tested module (custom field of type `Hierarchy`)
|
||||
|
||||
Here you find an [example for a test case](https://testmanagement.openproject.com/wp/37).
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
### 2.2 Configuration example: Test Run (work package type)
|
||||
|
||||
The work package type `Test run` can be configured so it shows the relevant information:
|
||||
|
||||
* Test specification inlcuding preconditions, excecution steps and testresults: Description field Tested features (related work packages `requires`)
|
||||
* Priority
|
||||
* Tester (custom field of type user)
|
||||
* Identified bugs (related work packages `related to`)
|
||||
|
||||
Here you find an [example for a test run](https://testmanagement.openproject.com/wp/65).
|
||||
|
||||

|
||||
|
||||
### 2.5 Workflow and statuses
|
||||
|
||||
- Define custom statuses such as:
|
||||
- `New`,
|
||||
- `In progress`
|
||||
- `Test passed`
|
||||
- `Test failed`
|
||||
- ...
|
||||
- Create a simple workflow for test runs with allowed transitions
|
||||
- Optionally restrict who can move a test run to `Test passed`.
|
||||
|
||||

|
||||
|
||||
### 2.3 Roles and permissions
|
||||
|
||||
- Define useful roles such as:
|
||||
- `Tester`
|
||||
- `Test Manager`
|
||||
|
||||
- Add permissions such as:
|
||||
- Edit work packages
|
||||
|
||||
|
||||
### 2.4 Custom fields
|
||||
|
||||
Define custom fields that describe the test object such as:
|
||||
|
||||
- Test environment (type `hierarchy`)
|
||||
- Tester (custom field type `user`)
|
||||
|
After Width: | Height: | Size: 147 KiB |
|
After Width: | Height: | Size: 137 KiB |
|
After Width: | Height: | Size: 151 KiB |
|
After Width: | Height: | Size: 189 KiB |
|
After Width: | Height: | Size: 180 KiB |
|
After Width: | Height: | Size: 249 KiB |
|
After Width: | Height: | Size: 130 KiB |