IT System Acceptance Testing: Handover Scenarios and Protocols

Why acceptance testing is needed and what it covers

Acceptance testing of IT systems is the final check before commissioning, when the customer confirms: “yes, we receive exactly what we ordered and this can be used in production.” This is not the same as the developer's internal testing, where they look for bugs and improve the product. At acceptance you evaluate readiness against pre-agreed conditions and record the result in a protocol.

Acceptance is often confused with commissioning. Commissioning answers “does it boot and is it configured correctly?”. Acceptance answers “does the system perform the required functions, withstand loads, are documents in place, and can it be safely transferred to operations?”.

Most handover disputes come down to one thing: what exactly counts as “done”. The contractor says “VPN is up,” while the customer sees unstable connections in branches and voice calls dropping. Or: “servers are installed,” but there is no backup, monitoring, or clear recovery procedure. Acceptance testing prevents such disputes by turning expectations into measurable checks: scenario, steps, metric, pass/fail criterion.

For the customer, “system commissioned” usually means four things: it works for key scenarios, performance is acceptable, security and access are configured, and ongoing support is practically possible (instructions, diagrams, procedures, support contacts).

To avoid turning results into opinion fights, fix roles before starting:

• Acceptance initiator (usually the system owner on the customer side) approves scenarios and criteria.
• Executor (contractor/integrator) prepares the testbed, access and addresses comments.
• Recorder (secretary of the commission or an operations engineer) keeps the protocol and collects evidence (logs, screenshots, measurements).
• Signatories (the commission) make the decision: accepted, accepted with remarks, or not accepted.

When these rules are agreed in advance, acceptance becomes a quick measurement rather than a negotiation at project end.

What to prepare before testing

Before acceptance, assemble a "project folder" so tests are based on facts, not participants' memories. This saves days on clarifications and avoids disputes like “we never agreed that.”

First, collect documents that record the expected result and the system structure: requirements/specification, brief architecture description, network and integration diagrams, admin and user instructions, list of settings (access policies, backups, monitoring parameters). If some agreements remain in emails or chats, include them as annexes.

A key tool is the requirements matrix. It links “what was promised” with “what we check” and becomes the foundation of the acceptance test program. For each requirement the matrix should include: the check (scenario/test), criterion (number or condition), actual result with date and executor, and status (passed/failed/with remarks).

Next, define acceptance boundaries. Record what is included (for example: office network, servers, backup, key user scenarios) and what is excluded (pilot features, future training, workplace upgrades outside the project). This should match how the acceptance protocol is filled.

Prepare the testbed and access in advance: accounts for the commission, admin rights, access to logs and monitoring, test data and test users, service desk request templates (if present). Simple example: if you test backup recovery, agree beforehand on "control files" or a database that will clearly show successful recovery.

Also agree on the work window and communications: responsible people, daily call times, channel for defect logging, escalation rules and response times for blocking issues. Then acceptance follows the plan and does not become a series of postponements.

Acceptance criteria: how to make them measurable

A good acceptance criterion answers three questions: what we check, how we check it, and what value counts as success. The wording must be measurable, with tolerances and a clear verification method. Bad: “network works stably.” Good: “packet loss between nodes A and B not more than 0.5% under load X, measured by ping/iperf for 30 minutes, 3 runs.”

Set threshold values in advance and tie them to real scenarios. For networks, record latency and loss; for servers, recovery time and availability; for applications, response time and error rate. For infrastructure, agree on RTO/RPO upfront: for example, RTO 60 minutes and RPO 15 minutes.

Specify two modes: normal and failure. In normal mode criteria cover performance and stability. In failure mode state what counts as successful failover and acceptable degradation. Example: “if one switch fails, connectivity between critical segments is restored within 30 seconds; loss of a single TCP session is allowed for no more than 1% of active users.”

Record deviations with rules: who logs them, where they are stored, reaction and fix time. It’s useful to define criticality levels (critical/medium/low) and attach deadlines. Then the dispute moves from "is this important" to which category the issue belongs.

Conditional acceptance is acceptable when the system is safe and fit for work and shortcomings do not block key processes. The protocol must include a list of fixes with specifics: description, readiness criterion, owner, deadline, and proof of correction (retest, log, screenshot, report).

Acceptance test protocol template (structure)

A protocol ensures results are verifiable: what was tested, how it was measured, what happened, what is considered accepted and what is not. One document should be understandable to the customer, contractor and operations team.

Practical structure:

• Document passport: object (system/segment), version, site, dates, participants, basis (contract, spec, change request).
• Scenario registry: list of tests with step-by-step actions, input data, expected result and actual result.
• Metrics and measurement methods: which indicators are checked and what tools record the values.
• Nonconformance log: what failed, how critical, who fixes it and by when.
• Conclusion: findings, assumptions and limitations, list of annexes, signatures.

Scenario registry: how to format it to avoid disputes

A common cause of conflicts is “we checked and it seems to work.” Therefore write observable results, not vague phrases. For example, not “VPN is up” but “tunnel is established, ping to address X succeeds, no loss, average latency not above Y ms for 10 minutes.”

Scenarios are convenient to present as a table in the protocol. Minimum columns:

Metrics and tools in plain language

List what you measure (response time, throughput, error rate, recovery time) and how you record results. The important part is reproducibility: any participant should repeat the measurement using the same steps and get comparable results.

For nonconformities create a short card to close them one by one:

• Where it appears (scenario, step, environment) and what exactly happens.
• Impact on operations (what the user or service cannot do).
• Priority and closure criterion.
• Owner and fix deadline.
• Recheck (date, result, attached evidence).

At the end add the overall status (accepted/accepted with limitations/not accepted), a list of restrictions (for example, “branch N channel will be expanded by date ...”) and signatures. This is especially useful when equipment, integration and support are done by different teams.

Step-by-step acceptance plan: how to run tests without chaos

To keep acceptance calm you need a single work order and a simple rule: do not test anything until the initial state is recorded. That way any discrepancies can be explained and reproduced.

Start with a “system snapshot”: software and firmware versions, configurations, network diagrams, list of nodes, test accounts and boundaries of responsibility (who changes settings, who confirms results). Record the date, location, testbed composition and what is the reference in the protocol.

Then go from simple to complex. First run a quick smoke check of basic operability (availability, authentication, main services) so you don’t spend days on deep checks if the foundation is not ready. Then move to subsystem scenarios: network, servers and storage, and applications.

A convenient route:

• Record initial state (versions, configs, diagrams, components).
• Run a short smoke test of basic functions.
• Execute agreed scenarios by subsystem with metrics.
• Check fault tolerance and recovery (if included in the project).
• Document results, agree on remarks and repeat tests after fixes.

Agree failure tests in advance: what exactly is “broken”, how long service may stay degraded, who authorizes switches. Examples: disconnecting one switch in a pair, simulating a disk failure, restarting an application service. Record facts (recovery time, packet loss, error counts, response time), not impressions.

Finish with protocol discipline. For each test record steps, actual result, evidence (log, screenshot, measurement), status and the person responsible for fixes. Repeat runs must follow the same steps and system snapshot. If the supplier is also the integrator (as GSE.kz often is in turnkey projects), set a single window for fixes and reruns so versions and settings don't diverge.

Network test templates: scenarios and metrics

Accept the network by diagrams and numbers. Then acceptance testing becomes fact-checking: segments reachable, services responding, latency within norms, redundancy actually works.

Minimal scenario set (what to test)

Start with routes and reachability: traverse key segments in the network diagram (user, server, Wi‑Fi, DMZ, management) and verify traffic flows as designed.

Keep a short but representative set:

• Segment availability: ping and traceroute between control points (PC, server, gateway, Wi‑Fi controller) with recorded results.
• Basic services: DHCP (address and options issuance), DNS (internal name resolution), NTP (time sync) and verification of secondary servers or sources.
• Performance: latency, loss, throughput on typical paths (user↔server, branch↔DC, Wi‑Fi↔LAN).
• Redundancy: link or route failure, failover to backup and measurement of recovery time.
• Basic security: segmentation and ACLs (what is allowed and denied), guest access (if provided) without access to internal resources.

To make metrics comparable agree on measurement method and time window. For example, for latency and loss use 100–300 ICMP packets during work hours; for throughput test between two agreed points, single and multiple parallel streams.

Sample criteria to include in the protocol: latency between office and server segment not more than X ms, loss not more than Y%, throughput at least Z Mbps, link failover time not more than T seconds.

Recording results (what to attach to the protocol)

You need not only “passed” but also evidence to avoid later disputes:

• Configuration exports from key devices (router, core switch, firewall) at test time.
• DHCP/DNS/NTP logs and status screenshots (pools, zones, time sync).
• Measurement tool reports (ping/traceroute, throughput tests) with date, time and A/B points.
• Redundancy confirmation: failure event, recovery event, calculated downtime.
• Snapshots of segmentation/ACL rules and results of access attempts (allowed and denied).

This approach works well for multi-branch setups: repeat the same scenario set at each site to get comparable network quality data.

Server and storage test templates

To avoid disputes, record for each test: preconditions (configuration and load), steps, expected result, actual result, artifact (screenshot, log, report), and pass criterion. These templates suit physical rack hardware and virtual environments.

1) Basic readiness and hardware health

Start by checking that delivered equipment matches the specification. Note model, serial numbers, disk composition, RAM amount, firmware and controller versions. For servers supplied to government or large organizations this step is often critical.

A short set of repeatable checks per node:

• Inventory and spec compliance: serial numbers, configuration, licenses, warranty marks.
• RAID and disk status: RAID level, health, failure forecast, correctness of disk replacement.
• Memory, temperature, power: no overheating, fans and PSUs visible, no critical events.
• Event logs: no repeating errors (disk, controller, network, power) in the last N hours.
• Basic network access: management, storage access (if present), correct link speeds.

2) Performance, virtualization, backup and resilience

Assess performance "within reason": meeting project expectations without throttling or overheating is more important than record results. Fix duration, profile (read/write), target IOPS or throughput and allowable temperature peaks in the criteria.

For virtualization add checks that show readiness:

• CPU/RAM/disk: load test for 15–30 minutes recording metrics and absence of controller errors.
• Virtualization: create a test VM, install an OS, take a snapshot and revert; if clustered — perform a migration.
• Backup: take a backup of the test VM and restore (1) a single file, (2) the whole VM into an isolated network.
• Disk failure: simulate disk removal, check RAID degradation, reconstruction start time and no data loss.
• Power or network module failure: disconnect one PSU or one link, record service availability and correct event logging.

With such tests results are unambiguous: pass/fail is evident from metrics, logs and recovery actions.

Application test templates

To avoid “works or not” disputes, for each test define preconditions (data, rights, environment), steps, expected result, metric (seconds, count, status) and acceptance rule.

1) Functional scenarios (user and admin)

Pick 5–10 most common daily operations: login, search, create entity, modify, approval, export. For admin include user and role management, configuration of directories, backup of settings.

Example case: "Create a request → send for approval → get status 'Approved' → entry in the log → notification sent." Acceptance criterion: status changes correctly, data is not lost, operation time does not exceed X seconds.

2) Access rights, integrations and resilience

Test rights on real roles (operator, manager, auditor, admin), not a superuser. Verify roles see and do exactly what they should, and forbidden actions return a clear error rather than silent failure. Ensure auditing records who changed what and when, with old/new values.

Treat integrations as separate tests: "incoming message → processing → record in system → response/acknowledgement." Set measurable criteria: percent of successful messages, allowable delay, behavior on duplicates and when the partner system is unavailable.

For resilience add scenarios of service restart, temporary DB unavailability and queue recovery. Validate reports by a few control numbers and generation time under typical data volumes.

Run load tests on typical operations (search, save, report). Record median, 95th percentile response time and behavior at peak (errors, queuing, degradation).

Example scenario: accepting a system for an organization with branches

Context: network with 3 branches and a head site (e.g. clinic or school). 100–300 users total, some shift-based. Shared printers, staff Wi‑Fi, servers and storage in the server room, plus an application (patient record or electronic journal). Prepare test accounts in advance: registrar, doctor/teacher, accounting, administrator.

Accept together: Wi‑Fi (coverage and access), servers and backup, domain accounts and rights, application operation, printing (including from branches), service availability from main workstations.

Day-of acceptance scenarios

Run realistic work chains rather than isolated tests:

• Morning: employee in a branch turns on PC, connects to Wi‑Fi, logs in, opens the application.
• Work: creates a record, edits, saves, generates a report.
• Printing: sends to a shared printer, checks time to output and template correctness.
• Failure: simulate Internet outage in one branch (if project includes offline mode or backup channel) and record behavior.
• Evening: run backup and then perform a control restore of one object (file or record) to a test environment.

Typical measurable criteria

Record criteria as numbers and measurement rules, not vague terms:

• User login time: no more than 60 seconds from password entry to desktop readiness.
• Opening a record/document in the application: no more than 3 seconds in 95% of attempts.
• Service availability during working hours: 99.5% over the observation window.
• Print time for a standard document: no more than 30 seconds to first page.

If a dispute arises, do not decide by impressions. Agree on a single measurement method (what starts and stops the timer), repeat the test 3–5 times, record conditions (branch, workstation, time, load) and attach screenshots/logs. If a criterion fails, log it as a nonconformance with a deadline and retest rule. This keeps acceptance measurable regardless of who integrated or supplied equipment (in Kazakhstan such projects are often run by GSE.kz).

Common mistakes that delay acceptance

The main cause of prolonged acceptance is vague agreements. When criteria say “works normally” or “opens quickly” each side interprets differently. Fix numbers in advance: response time, allowable downtime, packet loss percentage, RPO/RTO, concurrent users, defect fix time.

Second problem — no frozen baseline. During acceptance someone updates firmware, changes security settings or adds rules. Then tests cannot be repeated and results are disputable. Record versions, configs and diagrams before start and allow changes only via an agreed request.

Acceptance is often mixed with tuning. Tests turn into implementation: something fails — they tweak it immediately and rerun, then tweak again. This stretches timelines and breaks logic: acceptance should confirm readiness, not replace finishing work. Correct flow: log defects, fix them, then rerun the specific scenario.

A critical blocker is no rollback plan or backups before testing. Any load test or failure check can cause issues. If there is no agreed way to return to a stable state and no responsible party, the team will reduce checks and later dispute quality.

Finally, many stop at “everything booted”: pings respond, users log in, one report generated. Acceptance without recovery and failure tests usually returns as an operational problem. At minimum verify:

• recovery from backup and time to restore service
• restarting key services and behavior after component failure
• degradation on loss of a channel/node and correct failover
• data integrity after a failure

If the project includes servers and integration, agree responsibilities in advance: hardware, OS, applications, and who signs the final protocol. This is important for government and large organizations with strict repeatability and documentation requirements.

Short checklist and next steps after signing

Acceptance ends not with the last test but with clear recording of results and a plan for what comes next.

1–2 days before start run a readiness checklist:

• Test program and methodology, acceptance criteria, testbed composition and responsibility boundaries approved.
• Access ready: accounts, roles, monitoring and log access, backup storage access.
• Work windows and communications agreed: who is on call, where to escalate, how to record incidents.
• Responsible persons from customer, contractor, security and operations assigned (with contacts).
• Initial data prepared: test accounts, datasets, reference configurations.

After tests, assemble the result package so signing is verifiable:

• Test protocols with execution records and outcomes (passed/failed) for each scenario.
• Logs and metric exports (times, errors, availability, throughput) with dates and sources.
• Nonconformance registry: description, criticality, fix deadline, owner, verification method.
• Final acceptance act (or partial acceptance) listing limitations and conditions.
• List of delivered materials: diagrams, manuals, sealed passwords, support contacts.

After signing agree on observation mode. Practical option — control measurements after 2–4 weeks: compare key metrics with acceptance values, check backups in a real cycle and confirm support and escalation work.

If changes are made post-acceptance (patches, hardware replacement, new integrations), version the protocols: version number, date, reason for change, what changed and who approved. This makes it easier to prove what configuration was tested.

When follow-up work is required after acceptance (expansion, support, workstation/server updates), assign an owner for the operations plan in advance. In such cases system integration, supply and equipment support (for example, servers and workstations from GSE.kz) naturally become the next phase — with the same measurable criteria as during acceptance.