Informatization achievement acceptance testing is an independent verification and validation process that confirms whether the deliverables of an IT or informatization project—software systems, infrastructure, data resources, and documentation—conform to contractual requirements, design specifications, and applicable standards before formal project acceptance. Conducted by accredited third-party laboratories in accordance with frameworks such as GB/T 25000.51 and ISO/IEC 25010, this testing provides objective evidence for project owners, supports budget settlement, and reduces delivery risk. This guide covers the technical scope, testing items, methods, standards, and practical applications of informatization acceptance testing.
Technical Overview
Informatization achievement acceptance testing refers to the systematic, independent evaluation of all deliverables produced by an informatization project prior to formal acceptance by the project owner or funding authority. Informatization projects typically encompass custom-developed application software, procured hardware, network infrastructure, integrated platforms, data resources, and a complete set of project documentation. The purpose of acceptance testing is to establish objective, reproducible evidence that these deliverables meet the functional, performance, security, and quality requirements defined in the contract, the approved design specifications, and relevant national and international standards.
Unlike developer-led internal testing, acceptance testing is performed by accredited third-party laboratories that maintain organizational independence from both the contractor and the project owner. This independence is critical in government-funded projects, state-owned enterprise investments, and public-private partnership initiatives, where the acceptance report often serves as a precondition for final payment, asset registration, and long-term operation and maintenance handover.
The evaluation framework is typically anchored in the software product quality model defined in ISO/IEC 25010 and its Chinese national standard counterpart GB/T 25000.51, which specifies quality requirements and evaluation instructions for software products intended for acquisition and supply. Complementary standards include the ISO/IEC/IEEE 29119 series for software testing processes, GB/T 9386 for software test documentation, GB/T 22239 and GB/T 28448 for cybersecurity classified protection requirements and evaluation, and ISO/IEC 27001 for information security management systems where applicable.
Testing Samples
Application Software Systems
The primary test objects are custom-developed or configured business applications, including management information systems, business processing platforms, portals, workflow systems, and mobile applications. Test laboratories verify the deployed system version against the requirement specification, typically in a staging environment that mirrors the production configuration in architecture, data volume, and integration scope.
Infrastructure and Hardware Deliverables
Server clusters, storage arrays, network equipment, security appliances, and data center facilities supplied under the project are inspected for quantity, model conformity, installation quality, configuration correctness, and operational status. Verification includes cross-checking serial numbers and specifications against the bill of quantities and equipment contracts.
Integrated Systems and Interfaces
Middleware, message queues, API gateways, data exchange platforms, and integration interfaces with external or legacy systems are tested for interoperability, data format compliance, transaction integrity, and error handling across system boundaries.
Data Resources and Migration Outcomes
Databases, migrated historical data, master data sets, and shared data resources are evaluated for completeness, accuracy, consistency, and conformity with documented data standards. Sample-based verification is applied where full population checking is impractical.
Project Documentation
The complete documentation set—requirement specifications, design documents, test plans and reports, deployment and configuration records, operation manuals, and training materials—is reviewed for completeness, internal consistency, traceability to requirements, and alignment with the as-built system.
Testing Items
Acceptance testing evaluates deliverables across the following quality characteristics, with the exact item list tailored to the project scope and contract clauses:
- Functional suitability: functional completeness, functional correctness, and functional appropriateness against the requirement specification and user stories
- Performance efficiency: response time under defined loads, transaction throughput, concurrent user capacity, resource utilization of CPU, memory, storage, and network, and behavior under stress and spike conditions
- Security: identity authentication, access control, audit logging, data encryption in transit and at rest, session management, vulnerability density, and conformity with cybersecurity classified protection baselines under GB/T 22239
- Compatibility: coexistence across browsers, operating systems, and terminal devices; interoperability with adjacent systems and standard data formats
- Reliability: maturity, availability, fault tolerance, and recoverability, including backup and restoration verification and failover behavior
- Usability: navigation clarity, error prevention and messaging, UI consistency, and accessibility conformance
- Maintainability: modularity, code quality indicators, traceability of changes, and adequacy of maintenance documentation
- Portability: installability, adaptability to supported environments, and replaceability of components
- Data quality: accuracy, completeness, timeliness, and consistency of migrated and newly generated data
- Documentation quality: completeness, correctness, and consistency of all contractual documents
Testing Methods
Testing is executed through a combination of dynamic testing, static review, and on-site inspection techniques selected according to the risk profile and acceptance criteria of each project.
- Black-box functional testing: requirement-based test design using equivalence partitioning, boundary value analysis, decision tables, and scenario-based testing to exercise each function under normal, abnormal, and extreme input conditions
- Performance and load testing: simulated user load generation using industry-standard tools to measure response times, throughput, and resource consumption at target, peak, and stress levels, including soak testing for sustained stability
- Security testing: automated vulnerability scanning, configuration baseline review, weak password and permission audits, and penetration testing where authorized by the project owner
- Interface testing: protocol-level verification of APIs and data exchange services covering normal transactions, malformed requests, timeout handling, and replay protection
- Static documentation review: checklist-based inspection of the document set against contractual deliverable lists and standard templates
- On-site inspection and demonstration: physical verification of hardware installation, environmental conditions, and witnessed walkthrough of key business scenarios with end users
- Regression testing: re-execution of affected test cases after defect fixes to confirm resolution without introducing new defects
All activities follow a documented test process covering test planning, test case design, execution, defect logging, and reporting consistent with the ISO/IEC/IEEE 29119 series and GB/T 9386 documentation requirements. The final acceptance report records tested items, pass and fail results, defect classification, residual risks, and an overall conformity conclusion.
Applications
Informatization achievement acceptance testing is applied across a wide range of public sector and industry scenarios:
- Government e-government platforms, one-stop service portals, and inter-agency data sharing projects requiring independent verification before launch and budget closeout
- Smart city programs covering urban operations centers, intelligent transportation, public safety video networks, and IoT sensing infrastructures
- Enterprise digital transformation projects, including ERP, MES, SCM, and CRM deployments where acceptance gates contract milestones
- Healthcare informatization, such as hospital information systems, electronic medical record platforms, and regional health data centers
- Education informatization, including digital campus platforms, online learning systems, and examination management systems
- Financial and critical information infrastructure systems where regulatory compliance and cybersecurity grading requirements apply
- Project completion audits, dispute resolution, and system handover between contractors, integrators, and long-term operation providers
FAQ
When should acceptance testing be scheduled in the project lifecycle?
Acceptance testing is scheduled after the contractor has completed development, internal testing, integration, and trial operation, and once the system has reached a stable state. Conducting it too early produces excessive defects, while scheduling it too late compresses the remediation window before the contractual acceptance deadline.
Who should perform the testing?
Testing should be performed by accredited third-party laboratories with demonstrated independence from both the contractor and the owner. Accreditation to recognized laboratory competence standards and qualified testing personnel ensure the report carries evidentiary weight in audits and disputes.
What materials must the contractor submit before testing begins?
Typical submissions include the requirement specification, design documents, the deployed software version, deployment and configuration records, internal test reports, user and operation manuals, and access credentials for the test environment, along with the acceptance criteria extracted from the contract.
How does acceptance testing differ from developer testing?
Developer testing verifies the system against the developer's own understanding and focuses on defect removal, while acceptance testing is an independent conformity assessment against contractual and standard-based criteria, producing a formal conclusion suitable for decision-making by the project owner.
What happens if defects are discovered?
Defects are classified by severity. Critical and major defects must generally be resolved and retested before a passing conclusion can be issued; minor defects may be documented for correction during warranty, subject to the agreement of the parties.
Is acceptance testing connected to cybersecurity classified protection evaluation?
They are related but distinct. Systems subject to classified protection requirements must separately undergo grading, filing, and evaluation under the GB/T 22239 and GB/T 28448 framework; acceptance testing verifies overall deliverable conformity and commonly incorporates baseline security checks, but it does not substitute for a formal classified protection evaluation where one is mandated.
How long does acceptance testing take?
Duration depends on system scale, test item coverage, and defect remediation cycles. Small single-application projects may complete in two to four weeks, while multi-system integration programs with performance and security testing can require several months including regression rounds.