Part III Development: keeping the project on track
Chapter 20: Testing, acceptance, and launch
With acceptance, you take over the work. Invoicing, the start of the warranty, and the shift in liability for defects are all tied to it. It is the last moment when you have leverage, so do not accept anything under time pressure, without verification on real data, or without the code or documentation. Launch based on readiness, not on a date, and expect several weeks of increased support after launch.
There are many kinds of tests, and you personally do only one
Each kind of test checks something different. Most are carried out by the vendor or a specialist. Ask for their results. But you do the user acceptance testing yourself: with key users, on real scenarios and anonymized real data. Made-up data will not reveal all the problems of real operation.
| Test | What it asks | Who does it | What to ask to see |
|---|---|---|---|
| Unit and integration | Do the individual parts and their connections work? | vendor, automated | report from the automated build |
| End-to-end | Does the whole process run across systems? | vendor | results on real scenarios |
| Performance and load | Can the system handle as many users as it promises? | vendor or specialist | results against the non-functional requirements |
| Security scans | Does the code or a library contain a known vulnerability? | vendor, automated | scan results and fixes |
| Penetration test | Can an attacker get in? | independent third party | report and proof of fixes |
| Accessibility | Can a person with a screen reader or only a keyboard use the system? | auditor | automated and manual audit |
| User acceptance (UAT) | Can people actually work in it? | your key users | report and list of A/B/C defects |
| Migration and recovery | Is the data transferred correctly, and can the original state be restored? | vendor and your IT | reconciled counts and totals |
Based on common practice; specific testing requirements belong in the contract and the acceptance criteria.
Commission the penetration test from a third party, not the software vendor. Nobody should test locks they installed themselves. Fixed findings from the test belong among the conditions of acceptance.
Acceptance has three possible outcomes
The vendor hands over a stage with a report on its own tests. You test within the agreed time limit. As a rough guide, plan for 10–15 business days for a stage and 3–5 days for a sprint. You record every defect you find and assign it to a category. The outcome is one of three:
- accepted,
- accepted with reservations: only minor defects remain, or a limited number of serious ones with a fix date,
- not accepted: the vendor fixes the defects and acceptance is repeated.
Signing the acceptance has major consequences. The vendor can invoice, the warranty starts to run (as a rule of thumb, 12–24 months), and from that moment defects are handled as warranty claims, not as unfinished work. So keep part of the price, roughly 5–10%, as retention (retainage) until the end of the warranty or hypercare.
Put the defect categories and their limits in the contract in advance. Otherwise, you will be arguing about whether a defect is “critical” at the moment when the vendor is pushing for a signature and you are pushing for the deadline.
| Category | What it is | Effect on acceptance | Typical fix |
|---|---|---|---|
| A (critical) | the system or a key process does not work, data loss, a security hole | prevents acceptance | hours to 1–2 days |
| B (serious) | a feature is limited, but a workaround exists | up to the agreed number, with reservations | days |
| C (minor) | cosmetic issues, inconvenience | does not prevent it | in the next version |
The overview is based on common practice; fix times are indicative. Agree on the limit of B defects for acceptance with reservations in the contract.
Do not accept the work without the code and documentation
By signing the acceptance, you lose your leverage. Before that, ask for the handover package: the code in your repository with its history and build procedure, a license for modifications, including by another company, a list of third-party components (SBOM), documentation, access in your name, and the test results. The test is simple: “Show us that we can build and deploy the system without you.”
Whatever you do not receive at acceptance will cost you for years. ADIS, the Czech tax administration’s information system, shows where this leads: dependence on the vendor stemming from a 1992 contract ended in fines from the Office for the Protection of Competition (ÚOHS); see chapter 24.
Launch based on readiness, not on a date
Go/no-go is a decision shortly before launch: is the system ready? Approve the launch only when all of the following conditions are met:
- no open A defects, and B defects below the agreed limit,
- a successful trial data migration,
- a passed performance test,
- a penetration test with no critical findings,
- trained users,
- a prepared and tested rollback,
- approved security and, for a public authority, statutory obligations met.
Record the decision, including who made it. Launch gradually: first a pilot with one department or branch, then expansion. The UK Government Digital Service (GDS) first releases new services to a limited group of users, then to everyone in beta, and makes them live only after an assessment GDS, beta phase. A gradual launch limits risks that would otherwise affect all users at once.
Migrating data from the old system is a separate part of the delivery with its own acceptance: a trial migration on a copy of the production data, reconciled counts and checksums, and a tested rollback (see the checklist).
Digitalization of building permits: the launch (MMR, 2024)
The system went into production nationwide on July 1, 2024, because the law set that date. Acceptance took place on June 20, 2024, before user testing ended on June 28. The building permit information system was tested by 4 users, representatives of key users were not involved in acceptance, and all deliverables were accepted without reservations. Penetration tests covered only some of the systems DSŘ audit, technical part, 2025.
According to the legal part of the audit, the systems did not meet all the requirements of the Cybersecurity Act, and operation began without the operations documentation being submitted to DIA DSŘ audit, legal part, 2025. Yet the steering committees met in March and April 2024, and the independent technical oversight warned them of critical risks. Nobody responded effectively DSŘ audit, technical part, 2025. In October 2024, the government decided not to develop the systems any further and to prepare a new tender Government, October 16, 2024.
The lesson: a statutory date does not replace a go/no-go decision. If a deadline is at risk, negotiate a transition period or a fallback solution in time. Chapter 19 discusses the options for stopping a project. Chapter 12 describes the dispute over the tender before ÚOHS.
Source: DSŘ audit, technical part (August 19, 2025), DSŘ audit, legal part (April 4, 2025), Government briefing paper, October 16, 2024
After launch: people and a period of increased support
A system is finished only when people know how to work in it. Run role-based training shortly before launch, not three months in advance, when people will forget much of it by launch day. Super users, a training environment, and short how-to guides help in the workplace. Expect a temporary drop in productivity, and make sure the old procedure really ends. In 2026, the Supreme Audit Office (NKÚ) pointed out that digitalizing forms has not yet sped up the work of public authority staff, because the internal processes remained manual NKÚ, 2026.
For the first 4–12 weeks after launch (rule of thumb), you need hypercare: a reinforced vendor team, shorter response times, and a short daily meeting on problems. The end of hypercare is determined by criteria set in advance, such as 2 weeks without an A defect, not by a date. Hypercare belongs in the development contract; regular operations then belong in the support contract (chapter 21).
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrongAcceptance “on paper” under time pressure. | How to do it rightAcceptance based on criteria and time limits agreed in advance. |
| How it goes wrongUAT on made-up data. | How to do it rightUAT with key users on real scenarios and anonymized real data. |
| How it goes wrongA pentest only after launch, or done by the vendor itself. | How to do it rightAn independent pentest before launch, findings fixed before acceptance. |
| How it goes wrongCode handed over as a ZIP file without a build procedure. | How to do it rightA repository with its history and build; a third party builds and runs the system. |
| How it goes wrongLaunch set by a date, for everyone at once. | How to do it rightGo/no-go based on criteria, a pilot, then expansion. |
| How it goes wrongAfter launch, “call us if anything comes up.” | How to do it rightHypercare for 4–12 weeks with exit criteria in the contract. |
- Put the acceptance conditions, defect classification, penalties, and handover package in the tender documentation and the contract. Softening them or extending the time limits later is a contract modification (chapter 18).
- The administrator of a designated information system submits the operations documentation to DIA before operation starts, and may launch the service only after DIA has issued its opinion Act No. 365/2000 Coll.. Allow for this in the schedule.
- Meet the security obligations under Act No. 264/2025 Coll. (Cybersecurity Act) before launch. The hypercare team must be able to recognize an incident and report it within the statutory time limits Act No. 264/2025 Coll. (chapter 15).
- Before launch, arrange an accessibility audit and an accessibility statement Act No. 99/2019 Coll..