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) 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.

Template metadata
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

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:

Tests follow business processes end to end, not menus or modules.
Tests are executed with end-user logins and the permission sets those users will have in production. Nobody tests as an administrator.
Every test has a written expected result before it is run.
Every result is logged in the tracker on the day it is produced.
A defect has one owner and one target closure date at all times.
[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:

Review new items. Reject duplicates and items without a script reference and evidence.
Classify each item using section 9.
Assign owner side, named owner and target closure date.
Review blocking items first. Agree a workaround or replan the affected scripts.
Review items past their target date. Set a new date or escalate to the PMs.
Confirm the retest list and the testers.
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
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.

Marketplace