Informatization Project Acceptance Testing: Standards, Scope, and Technical Process

Informatization project acceptance testing is a systematic, standards-based evaluation conducted to verify that a completed information technology project satisfies its contractual requirements, functional specifications, and quality objectives before formal handover and payment. Typically performed by accredited third-party laboratories in accordance with frameworks such as ISO/IEC 25010 and the corresponding GB/T series standards, this testing provides objective, reproducible evidence for project owners, contractors, and supervising authorities. This article explains the technical scope, project categories, testing items, methodologies, and practical applications of acceptance testing for informatization projects.

Technical Overview

Informatization project acceptance testing is the final verification and validation activity performed before an information technology project is formally delivered, commissioned, and paid for. Its purpose is to provide project owners and stakeholders with independent, objective evidence that the delivered system conforms to the contract, the approved requirement specifications, and applicable quality and security standards. Because informatization projects often involve substantial public or corporate investment, acceptance testing serves as a contractual and legal gate: a project cannot pass final acceptance until the test results demonstrate that the system meets the agreed criteria.

The evaluation is typically organized around the software product quality model defined in ISO/IEC 25010 (Systems and software Quality Requirements and Evaluation, SQuaRE), which characterizes quality through eight major attributes: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. In many national procurement environments, the corresponding domestic standard GB/T 25000.51, which specifies requirements and evaluation guidance for ready-to-use software products and their test documentation, is the primary technical basis for acceptance testing. Supporting references include ISO/IEC/IEEE 29119 for software testing processes, GB/T 15532 for computer software testing specifications, GB/T 9386 for test documentation, and GB/T 22239 or ISO/IEC 27001 for information security requirements.

Acceptance testing is generally carried out by accredited third-party laboratories that operate independent of both the developer and the project owner. This independence ensures that the test verdicts, defect statistics, and conformity conclusions are impartial and can withstand audit, review, and, where necessary, contractual dispute resolution.

Testing Samples

Acceptance testing applies to a broad range of informatization deliverables. The tested object is usually the complete, deployed system running in an environment representative of production, together with its delivered documentation and source code. Common project categories include the following.

E-Government and Public Service Platforms

Online government service portals, administrative approval systems, integrated citizen service platforms, and inter-departmental data exchange systems. These projects are frequently subject to mandatory third-party acceptance testing as a precondition for final settlement in government procurement.

Enterprise Information Systems

Custom-built or secondary-developed management platforms such as enterprise resource planning (ERP), customer relationship management (CRM), office automation (OA), human resources, supply chain, and financial management systems deployed within an organization.

System Integration and Infrastructure Projects

Data center construction, network integration, video surveillance and security systems, industrial control integrations, and multimedia command-and-control platforms in which hardware, networks, and application software must be verified as a coherent whole.

Big Data, Cloud, and Intelligent Platforms

Data governance and analytics platforms, cloud service deployments, geographic information systems, smart city subsystems, and AI-assisted decision platforms where data volume, throughput, and algorithmic behavior must be validated.

Industry-Specific Information Systems

Sector-specific deployments in healthcare (hospital information systems), education (digital campus platforms), transportation (tolling and traffic management), energy, finance, and logistics, each of which may carry additional regulatory or standard-specific requirements.

Testing Items

The testing items are derived from the requirement specification and contract, then mapped to the quality characteristics of the applicable standards. A typical acceptance test report covers the following dimensions.

• Functional completeness: verification that all contractual functions have been implemented and are demonstrable in the delivered system.
• Functional correctness: verification that each function produces correct, accurate results against defined inputs, business rules, and expected outputs.
• Functional appropriateness: assessment of whether the implemented functions are suitable for the intended tasks and user scenarios.
• Time behavior: measurement of response times, transaction processing times, and throughput under defined normal and peak load conditions.
• Resource utilization: evaluation of CPU, memory, disk, network, and database consumption under representative workloads.
• Capacity: verification of the maximum concurrent users, data volumes, and transaction rates the system can sustain within agreed thresholds.
• Coexistence and interoperability: testing of interfaces, API integration, cross-browser and cross-platform behavior, and data exchange with external systems.
• Usability: evaluation of user interface consistency, error prevention, help facilities, and learnability against recognized ergonomic expectations.
• Reliability: assessment of maturity, availability, fault tolerance, and recoverability, including behavior under abnormal input, service interruption, and failover scenarios.
• Security: verification of authentication, authorization, access control, audit logging, data protection, and resistance to common vulnerabilities such as those enumerated in the OWASP risk categories, alongside compliance with applicable cybersecurity protection requirements.
• Maintainability: review of modularity, reusability, analyzability, and modification capability, supported by code quality metrics from static analysis.
• Portability: verification of adaptability, installability, and replaceability across the target operating environments.
• Documentation quality: conformity review of user manuals, operation manuals, design documents, test reports, and deployment guides against GB/T 8567 or contractual documentation requirements.

Testing Methods

Acceptance testing combines dynamic execution of the system with static analytical techniques. All methods are applied under a documented test plan, with test cases designed to achieve traceable coverage of the requirement baseline.

Specification-Based Black-Box Testing

Test cases are derived from functional specifications using techniques such as equivalence partitioning, boundary value analysis, decision tables, cause-effect graphing, and state transition testing. Each case records preconditions, input data, execution steps, and expected results, and results are compared against actual system behavior to identify defects.

Structure-Based White-Box Testing and Static Analysis

When source code is delivered, static analysis tools measure code compliance, complexity, duplication, and potential defects, while statement and branch coverage analysis quantifies the thoroughness of the test suite. This supports the maintainability and code quality conclusions in the acceptance report.

Performance and Load Testing

Load generators simulate target user populations to measure response time distributions, throughput, and resource saturation under normal, peak, and stress conditions. Soak tests verify stability over sustained operation, and results are compared against quantified performance indicators in the contract.

Security Testing

Security verification combines vulnerability scanning, configuration review, and controlled penetration testing of authentication, session management, access control, input handling, and data transmission mechanisms. Findings are graded by severity and mapped to the applicable security baseline.

Documentation and Configuration Review

Reviewers inspect the delivered documentation set, version consistency between code, build artifacts, and deployment packages, and the traceability matrix linking requirements to test cases and results. This confirms that the deliverables constitute a complete and consistent release baseline.

Applications

Acceptance test reports issued by accredited third-party laboratories are used across the full project life cycle and beyond.

• Final acceptance: serving as the primary technical evidence for the owner's acceptance committee to sign off project completion and authorize final payment.
• Milestone and stage acceptance: verifying phase deliverables such as requirement confirmation, prototype completion, or subsystem rollout before subsequent phases begin.
• Government audit and compliance: supporting fiscal audits, procurement compliance reviews, and performance evaluations of publicly funded informatization investments.
• Maintenance and warranty baseline: establishing the documented functional and performance baseline against which defects and change requests are classified during the warranty period.
• Dispute resolution: providing independent technical findings when the owner and contractor disagree on delivery completeness or quality.
• System upgrade justification: benchmarking existing platforms before modernization, migration, or replatforming decisions.

FAQ

When should acceptance testing be scheduled?

Acceptance testing is scheduled after the developer completes internal integration and system testing, the system is deployed in an acceptance environment representative of production, and the full documentation set has been delivered. Sufficient contingency time should be reserved for defect correction and regression testing before the formal acceptance date.

What documents must the project party prepare?

Typical inputs include the project contract, requirement specification or function list, design documents, interface specifications, performance and security indicators, deployment architecture, user and operation manuals, developer test reports, and, where applicable, the source code package.

Is third-party testing mandatory?

For many government-funded and large enterprise informatization projects, independent testing by an accredited third-party laboratory is a contractual or regulatory precondition for final acceptance. Even where not mandated, an independent test report significantly strengthens the credibility and auditability of the acceptance decision.

Who performs and signs off the testing?

The testing is executed by qualified test engineers of an accredited laboratory under a documented test plan, and the resulting report is issued with the laboratory's accreditation credentials. The final acceptance decision, however, remains with the project owner's acceptance committee, which uses the report as its technical basis.

How long does acceptance testing take?

Duration depends on project scale, the number of functional points, the depth of performance and security testing, and the defect volume discovered. A mid-sized management information system commonly requires two to six weeks including planning, execution, regression, and reporting.

What happens if defects are found?

Defects are classified by severity, documented in the test report, and submitted for correction. Critical and major defects must be fixed and regression-tested before a conformity verdict can be issued; minor defects may be resolved under an agreed remediation plan tracked through the warranty period.

What deliverables does the testing produce?

The laboratory delivers a test plan, test case specification, defect records, raw result evidence, and the final acceptance test report stating the conformity conclusion for each tested quality characteristic, suitable for submission to the acceptance committee and archiving with the project.

Which standards govern the evaluation criteria?

Evaluation criteria are primarily drawn from ISO/IEC 25010 and its national adoption GB/T 25000.51 for software product quality, supplemented by ISO/IEC/IEEE 29119 for test processes, GB/T 9386 for test documentation, GB/T 8567 for software documentation, and GB/T 22239 or ISO/IEC 27001 where security compliance is required.