Checklist: accepting software without nasty surprises
For: Clients of software projects
Updated: 2026-11
Software acceptance succeeds when acceptance criteria are fixed before testing: test cases derived from requirements, realistic test data, testing by future users, a clear classification of defects by severity, a signed protocol and an orderly handover to operations with documentation and access.
Acceptance is the moment a software project ends contractually and responsibility changes hands. Doing it without preparation means either accepting too early or arguing about defects that were never defined.
This checklist applies equally to agile and traditional projects. In HERMES projects it corresponds to the end of realisation and deployment.
The checklist
- 01
Define acceptance criteria
Before testing, derive from the requirements what must be met for acceptance.
Done when: Every acceptance-relevant requirement has at least one verifiable criterion, and both sides have confirmed the list.
- 02
Write test cases
Write a test case with steps and expected result for each criterion.
Done when: Test cases cover all acceptance-relevant requirements, visible in a traceability table.
- 03
Provide test data and environment
Set up a production-like test environment with realistic, privacy-compliant test data.
Done when: The test environment matches the target in version and configuration; test data contains no real personal data without a legal basis.
- 04
Have users run the tests
Future users execute the test cases, not only the development team.
Done when: Every test case has a documented result with date and tester.
- 05
Classify defects
Classify defects by agreed classes, such as blocking, major and minor.
Done when: Every defect has a class, a reproduction description and an owner.
- 06
Record acceptance
Record the result, open defects with deadlines and any reservations in writing.
Done when: A protocol is signed by both sides and lists open points with deadlines.
- 07
Arrange handover to operations
Hand over documentation, source code, access, operations manual and support arrangements.
Done when: Operations can restart, back up and restore without asking the project team.
Common mistakes
- —Discussing acceptance criteria only during testing.
- —Letting only the development team test, which knows the software too well.
- —Accepting under time pressure with many major defects and no deadline for fixing them.
- —Not treating source code, documentation and access as part of acceptance.
What this checklist does not cover
- —The checklist does not replace contractual rules on acceptance and its legal consequences, which follow from the contract and applicable law.
- —Load, security and penetration tests are separate examinations not covered here.
- —Public clients may have additional formal requirements.
Parent service: Custom Software Engineering
Matching offers
Requirements analysis (IREB)
We elicit, document and validate requirements following the IREB Certified Professional for Requirements Engineering method: identify stakeholders, elicit requirements in workshops, model processes in BPMN 2.0, write acceptance criteria and deliver a requirements catalogue the client can formally sign off. A basis for tenders, development or standard software.
External IT project management (HERMES)
External IT project management takes over steering a project from initialisation to closure — following HERMES where the public sector or regulated environments require it. You get leadership, clean documentation and reliable communication without having to fill a position internally.
FAQ
What is the difference between testing and acceptance?
Testing checks whether the software works. Acceptance is the formal declaration that it meets the agreed requirements.
Can you accept with open defects?
Yes, with minor defects recorded in the protocol with a deadline. Blocking defects must be fixed first.
Who writes the test cases?
Ideally the business side with support from business analysis, derived from the acceptance criteria.
More checklists
Checklist: ready to report a cyberattack within 24 hours
A company is ready to report when it has clarified its applicability under the ISA, regulated roles and 24/7 reachability, has a decision aid on the reporting duty, prepared the initial report, knows parallel reporting duties, obliged providers to cooperate and exercised the process.
Checklist: preparing for SRO membership
SRO membership is prepared in seven steps: clarify coverage and professional activity, choose a suitable SRO from the current FINMA list, define organisation and AML responsibility, align directives with the regulation, prepare a risk assessment, submit a complete application and set up operations with documentation from the first client.
Checklist: introducing Microsoft 365 governance
Microsoft 365 governance is introduced in seven steps: take inventory, set rules for creating teams and sites, require at least two owners per team, review guest access regularly, classify sensitivity and retention, define a lifecycle with archiving and steer flows and apps through an approval process.