---
title: "Test Strategy Template (IDK-17)"
date: 2026-09-21
description: "Ready-to-use template IDK-17: Test Strategy for IFS Cloud implementation projects, aligned with the IFS implementation methodology."
author: "Dariusz Mysliwiec"
categories:
  - name: "Implementation docs kit"
    url: "https://www.ifs-erp.com/implementation-docs-kit.md"
---

# Test Strategy Template (IDK-17)

Template IDK-17, version 1.0. Phase: Initiate Project (drafted), maintained through Implement Solution.

 ## How to use this template

 
- Write this document early, before any script exists. It sets the rules; the scripts (template [IDK-18](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/18-sat-ort-test-script-and-signoff)) follow them.
- Replace every bracketed field. Rows marked `Example:` show the expected level of detail; delete them before approval.
- Keep all values project specific. Where you see `[agree in project]`, the two project managers decide and record the value.
- Review the strategy at the start of every test cycle and update the cycle table if the plan has moved.
- The customer manages all testing except unit testing. If your contract says otherwise, change section 4 first and let the rest follow.

 | Field | Value |
| --- | --- |
| Template ID | IDK-17 |
| Phase | Initiate Project (drafted), maintained through Implement Solution |
| Owner | Customer test lead |
| Approver | Steering group |
| Qualification gate | Project Initiated |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and principles](#1-purpose-and-principles)
- [2. Scope of testing](#2-scope-of-testing)
- [3. Test cycles](#3-test-cycles)
- [4. Responsibilities](#4-responsibilities)
- [5. Entry and exit criteria per cycle](#5-entry-and-exit-criteria-per-cycle)
- [6. Environment per cycle](#6-environment-per-cycle)
- [7. Tools](#7-tools)
- [8. Metrics and reporting](#8-metrics-and-reporting)
- [9. Defect classification scheme](#9-defect-classification-scheme)
- [10. Daily triage procedure](#10-daily-triage-procedure)
- [11. Risks to the test effort](#11-risks-to-the-test-effort)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Document owner | [Name, customer test lead] |
| Status | [Draft / In review / Approved] |
| Version | [x.y] |
| Storage location | [Link to project repository] |
| Related documents | [Project management plan, data migration strategy, training strategy, cutover plan] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Purpose and principles

 This strategy describes how [Customer] will prove that the IFS Cloud solution is fit for go-live. It covers what is tested, in which cycles, by whom, in which environment, and how results and defects are handled.

 Principles for this project:

 
1. Tests follow business processes end to end, not menus or modules.
2. Tests are executed with end-user logins and the permission sets those users will have in production. Nobody tests as an administrator.
3. Every test has a written expected result before it is run.
4. Every result is logged in the tracker on the day it is produced.
5. A defect has one owner and one target closure date at all times.
6. [Add project-specific principle]

 ## 2. Scope of testing

 
### 2.1 In scope

 | Area | What is tested | Source of truth |
| --- | --- | --- |
| Business processes | All processes in the confirmed solution scope | [Link to process model] |
| CRIM objects | Every configuration, report, integration and modification delivered by the project | [Link to CRIM log] |
| Security | Roles, permission sets, segregation of duties rules | [Link to role matrix] |
| Migrated data | Every data set in the data migration plan | [Link to data migration plan] |
| Devices and output | Printers, labels, mobile devices, scanners, document output | [List] |
| Example: Procure to pay | Example: Requisition to supplier payment, including supplier acknowledgement, receipt with inspection, three-way invoice matching | Example: Process model, area Procurement |

 
### 2.2 Out of scope

 | Item | Reason | Who accepted the exclusion |
| --- | --- | --- |
| [Item] | [Reason] | [Name, role] |
| Example: Standard functionality not used in any in-scope process | Example: Not part of the confirmed solution scope | Example: Customer PM |

 ## 3. Test cycles

 | # | Cycle | Purpose | Phase | Executed by | Supported by |
| --- | --- | --- | --- | --- | --- |
| 1 | Verify application solution | Build scenarios and run them in the test environment. Scripts track progress. Step-by-step guides capture the agreed procedure. | Establish Solution | Customer functional teams | Application consultants |
| 2 | Verify with security and migrated data | Rerun the processes with real permission sets and with data loaded through the migration routines. | Establish Solution | Customer functional teams, technical analysts | Application consultants, technical resources |
| 3 | Scenario scripting | Write the formal scripts: regular and exceptional activities, inputs, expected results, success criteria. | Establish Solution | Customer functional teams | Solution architect |
| 4 | Solution Acceptance Test (SAT) | Prove end-to-end flows in a copy of production with defined roles, migrated data, reports, devices and integrations. | Establish Solution | Customer functional teams | Supplier project team |
| 5 | Cutover test | Rehearse the cutover plan and checklist with full data volumes. Log durations. Correct the plan. | Implement Solution | Cutover manager, technical analysts | Supplier technical team |
| 6 | Expert user training | Train expert users first. This also tests the training material and the step-by-step guides. | Implement Solution | Customer trainers | Application consultants |
| 7 | Operational Readiness Test (ORT) | Expert users run the SAT scripts on their own. The core team advises only. Expert users confirm readiness on behalf of the business. | Implement Solution | Expert users | Core team (advice only) |
| 8 | Load test (optional) | Check concurrency, performance, reliability and volume. | Implement Solution | [Owner] | [Supplier technical team] |

 Load test decision: [Required / Not required]. Reason: [text]. Decided by: [name, role, date].

 ## 4. Responsibilities

 | Responsibility | Customer | Supplier |
| --- | --- | --- |
| Unit testing of CRIM objects before delivery | Informed | Responsible |
| Test strategy and test plan | Responsible | Consulted |
| Writing scenario scripts | Responsible | Consulted |
| Test data preparation | Responsible | Supports |
| Test execution in all cycles | Responsible | Supports |
| Tracker maintenance and reporting | Responsible | Informed |
| Defect triage | Responsible (chair) | Participates |
| Fixing application errors and CRIM defects | Informed | Responsible |
| Fixing data, training and procedure issues | Responsible | Supports |
| Cycle sign-off | Responsible | Consulted |

 Named roles:

 | Role | Name | Released time for testing |
| --- | --- | --- |
| Test lead | [name] | [agree in project] |
| Triage chair | [name] | [agree in project] |
| Script authors per process area | [names] | [agree in project] |
| Testers per process area | [names] | [agree in project] |
| Supplier test contact | [name] | [agree in project] |

 ## 5. Entry and exit criteria per cycle

 | Cycle | Entry criteria | Exit criteria | Who confirms exit |
| --- | --- | --- | --- |
| Verify application solution | [Prototype approved; test environment available; core team trained] | [All planned scenarios run; step-by-step guides drafted; CRIM needs specified] | [Customer PM] |
| Verify with security and migrated data | [Permission sets built; migration routines deliver a complete load] | [Processes run with end-user logins and migrated data; open defects classified] | [Customer PM] |
| Scenario scripting | [Process list frozen; script template agreed] | [Scripts reviewed by process owners; regular and exceptional cases covered] | [Test lead] |
| SAT | [Production copied to SAT environment; CRIM delivered; scripts approved; testers named] | [All scripts executed; no open defect that blocks deployment; completion report approved] | [Steering group] |
| Cutover test | [Cutover plan and checklist drafted; full-volume extract available] | [Rehearsal complete; durations logged; plan corrected; repeat rehearsal decided] | [Cutover manager] |
| Expert user training | [Material and guides final; training environment loaded] | [Expert users trained; feedback on material processed] | [Training lead] |
| ORT | [Expert users trained; ORT environment ready; users attached to roles] | [Expert users sign the confirmation statement] | [Steering group] |
| Load test | [Representative volumes loaded; test profile agreed] | [Results within the agreed limits: `[agree in project]`] | [Customer IT lead] |
| Example: SAT | Example: Use Place SAT environment refreshed from production baseline; open purchase orders and supplier master loaded through Data Migration Manager | Example: Every procure-to-pay script passed or has an accepted workaround recorded in the defect log | Example: Steering group |

 ## 6. Environment per cycle

 | Cycle | Environment | Data | Refresh rule | Owner |
| --- | --- | --- | --- | --- |
| [Cycle] | [Environment name] | [Sample / migrated / full volume] | [When and by whom] | [name] |
| Example: Verify application solution | Example: Use Place test environment | Example: Customer sample data | Example: No refresh during the cycle | Example: Customer IT lead |
| Example: SAT | Example: Use Place SAT environment, copied from the production baseline | Example: Latest migration load | Example: Refreshed once before the cycle, frozen until sign-off | Example: Customer IT lead |

 Rules:

 
- Modifications are built and unit tested in Build Place, then delivered to Use Place environments through the agreed delivery route: [describe].
- Configuration verified in test is moved to the production or reference environment as it is approved: [describe procedure and approver].
- Integrations point to [test endpoints] in every environment except production. Check this after each refresh.

 ## 7. Tools

 | Purpose | Tool | Administrator |
| --- | --- | --- |
| Test scripts | [Tool or folder] | [name] |
| Execution tracker | [Tool] | [name] |
| Defect log | [Tool] | [name] |
| Process model reference | [IFS Scope Tool project link] | [name] |
| Evidence storage (screenshots, exports) | [Location] | [name] |

 ## 8. Metrics and reporting

 | Metric | Definition | Reported to | Frequency |
| --- | --- | --- | --- |
| Script progress | Scripts planned, executed, passed, failed, blocked, per process area | [PMs, steering group] | [agree in project] |
| Defect status | Open and closed defects by cause, owner side and blocking flag | [PMs] | [agree in project] |
| Defect ageing | Open defects past their target closure date | [PMs] | [agree in project] |
| Retest backlog | Fixes delivered but not yet retested | [Test lead] | [agree in project] |
| [Metric] | [Definition] | [Audience] | [agree in project] |

 Report format: [link to report template]. Escalation rule: [when a metric triggers escalation to the steering group; agree in project].

 ## 9. Defect classification scheme

 Every logged item gets all of the following before it leaves triage.

 | Attribute | Values | Guidance |
| --- | --- | --- |
| Cause | Data / User error / Application error / Wrong solution | Data: migrated or basic data is wrong or missing. User error: the script, the guide or the training was not followed or is unclear. Application error: the software or a CRIM object does not behave as specified. Wrong solution: it works as designed, but the design does not meet the process need. |
| Blocks deployment | Yes / No | Yes if the business cannot operate the process in production and no acceptable workaround exists. |
| Contractual | Yes / No | Yes if the item concerns something the supplier committed to deliver. A No may become a change request. |
| Owner side | Customer / Supplier | One side only. |
| Owner | [Named person] | Never a team. |
| Target closure date | [YYYY-MM-DD] | Set in triage. Changed only in triage. |
| May close after the phase | Yes / No | Requires agreement of both PMs. Listed in the cycle sign-off. |

 | Example | Cause | Blocks | Contractual | Owner side |
| --- | --- | --- | --- | --- |
| Example: Supplier payment terms missing on migrated suppliers, invoice due dates wrong | Data | Yes | No | Customer |
| Example: Custom field on purchase order line not shown in the purchase order report | Application error | No | Yes | Supplier |

 "Wrong solution" items go through change control. They are not fixed as defects.

 ## 10. Daily triage procedure

 | Item | Agreement |
| --- | --- |
| Time and place | [agree in project] |
| Chair | [Test lead] |
| Attendees | [Process area leads, supplier test contact, technical analyst, data migration lead] |
| Input | All items logged since the last triage; all items past target date |
| Output | Classified items with owner and date; list of retests for the next day |

 Steps:

 
1. Review new items. Reject duplicates and items without a script reference and evidence.
2. Classify each item using section 9.
3. Assign owner side, named owner and target closure date.
4. Review blocking items first. Agree a workaround or replan the affected scripts.
5. Review items past their target date. Set a new date or escalate to the PMs.
6. Confirm the retest list and the testers.
7. Publish the updated log the same day to [distribution list].

 ## 11. Risks to the test effort

 | Risk | Mitigation | Owner |
| --- | --- | --- |
| Testers not released from daily work | [Backfill plan; test calendar agreed with line managers] | [Customer PM] |
| Migrated data arrives late or incomplete | [Align load cycles with test cycles; agree fallback data set] | [Data migration lead] |
| [Risk] | [Mitigation] | [name] |

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer test lead (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Supplier project manager | [name] | [Reviewed] | [YYYY-MM-DD] |   |
| Steering group chair | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.