Operational acceptance testing: Difference between revisions

Revision as of 13:39, 3 October 2013

Latest revision as of 11:38, 16 August 2025

(26 intermediate revisions by 17 users not shown)

Line 1:

{{unreferenced|date=March 2011}}

[[File:US Navy 070804-N-1745W-122 A Sailor assigned to Aircraft Intermediate Maintenance Department (AIMD) tests an aircraft jet engine for defects while performing Jet Engine Test Instrumentation, (JETI) Certification-Engine Runs.jpg|right|thumb|250px|Operational testing a jet engine]]

'''Operational acceptance testing (OAT)''' is used to conduct operational readiness (pre-release) of a product, service or system as part of a [[quality management system]]. OAT is a common type of [[software testing]], used mainly in software support and [[software maintenance]] projects. This type of testing focuses on the [[operational readiness]] of the system to be supported, or which is to become the production environment. Hence, it is also known as '''operational readiness testing'''. [[Functional testing]] of applications is not to be included or merged in OAT.

'''Operational acceptance testing''' ('''OAT)''') is used to conduct operational readiness (pre-release) of a product, service, or system as part of a [[quality management system]]. OAT is a common type of non-functional [[software testing]], used mainly in [[software supportdevelopment]] and [[software maintenance]] projects. This type of testing focuses on the [[operational readiness]] of the system to be supported, and/or which is to become part of the production environment. Hence, it is also known as '''operational readiness testing''' ('''ORT''') or '''operations readiness and assurance testing''' ('''OR&A'''). [[Functional testing]] ofwithin applicationsOAT is notlimited to bethose includedtests orwhich mergedare inrequired OAT.to verify the ''non-functional'' aspects of the system.

It may include checking the [[backup]] facilities, maintenance and [[disaster recovery]] procedures. In OAT changes are made to environmental parameters which the application uses to run smoothly. For example, with [[Microsoft Windows]] applications with a mixed or hybrid architecture, this may include: [[Windows service]]s, [[configuration file]]s, [[web services]], [[XML]] files, [[COM+]] components, web services, [[Internet Information Services|IIS]], stored procedures in databases, etc. Typically OAT occurs after [[user acceptance testing]] (UAT), it is a final verification before a system is released.

OAT elaborates upon and compartmentalises operational aspects of acceptance testing.<ref>{{Cite web |title=atos-operational-acceptance-testing-whitepaper.pdf |url=https://atos.net/wp-content/uploads/2017/01/atos-operational-acceptance-testing-whitepaper.pdf }}</ref>

The approach used in OAT includes these steps:

* Build the system,

* Deploy the application,

* Supportability of the system.

* Validate the backup procedure setup for the system

According to the International Software Testing Qualifications Board (ISTQB), OAT may include checking the [[backup]]/restore facilities, IT [[IT disaster recovery|disaster recovery]] procedures, maintenance tasks and periodic check of security vulnerabilities.,<ref>ISTQB http://istqbexamcertification.com/what-is-acceptance-testing/</ref> and whitepapers on ISO 29119 and Operational Acceptance by Anthony Woods,<ref name="ISO 29119 OAT">{{cite document|author=Anthony Woods|title=Operational Acceptance - an application of the ISO 29119 Software Testing standard|date=2015|publisher=Capgemini and Sogeti|pages=1–12}}</ref> and ISO 25000 and Operational Acceptance Testing by Dirk Dach et al., OAT generally includes:<ref>White Paper: Operational Acceptance Testing, Business Continuity Assurance. December 2012 Dirk Dach, Dr Kai-Uwe Gawlik, Mark Mevert</ref>

Then checks are made on how the application is behaving, and moreover how the system is behaving as a whole in these conditions. Backup procedures are also checked to ensure proper operation under emergency conditions.

* Component Testing

For running the OAT [[test case]]s, the tester normally has exclusive access to the system or environment. This means that a single tester would be executing the test cases at a single point of time. For OAT the exact OR quality gates are defined, both entry and exit gate. All activities are listed which would be part and covered in the different phases of testing, with primary emphasis be on the operational part of the system.

* Failover (Within the same data centre)

There are various aspects of OAT –

* Fail over testing (resilliance testing)

:* Component fail-over

:* Network fail-over

* Functional Stability

* Alerting/alarming (to ensure proper alerts are configured in the system if something goes wrong)

:* Accessibility

* Backup and recovery testing – to ensure that backup and recovery is successful

:* Conversion

:* Stability

:* Usability

* IT Service Management (Supportability)

* Alerting/alarmingMonitoring and Alerts (to ensure proper alerts are configured in the system if something goes wrong)

* Portability

:* Compatibility

:* Interoperability

:* Installation and Backout

:* Localization

* Recovery (across data centres)

:* Application/system recovery

:* Data recovery

* Reliability

:* Backup and Restoration (Recovery)

:* Disaster Recovery

:* Maintainability

:* Performance, Stress and Volume,

:* Procedures (Operability) and Supporting Documentation (Supportability)

:* Security and Penetration

It may include checking the [[backup]] facilities, maintenance and [[disaster recovery]] procedures. InDuring OAT changes aremay be made to environmental parameters which the application uses to run smoothly. For example, with [[Microsoft Windows]] applications with a mixed or hybrid architecture, this may include: [[Windows service]]s, [[configuration file]]s, [[web services]], [[XML]] files, [[COM+]] components, web services, [[Internet Information Services|IIS]], stored procedures in databases, etc. Typically OAT occursshould occur after each main phase of the development life cycle: design, build, and [[user acceptancefunctional testing]]. (UAT),In sequential projects it is often viewed as a ''final'' verification before a system is released; where in agile and iterative projects, a more frequent execution of OAT occurs providing stakeholders with assurance of continued stability of the system and its operating environment.

TheAn approach used in OAT includesmay follow these steps:

* Supportability ofDesign the system.,

* Assess the design,

* Build the system,

* Confirm if built to design,

* Evaluate the system addresses business functional requirements,

* Assess the system for compliance with non-functional requirements,

* Deploy the applicationsystem,

* Assess operability and supportability of the system.

For running the OAT [[test case (software)|test case]]s, the tester normally has exclusive access to the system or environment. This means that a single tester would be executing the test cases at a single point of time. For OAT the exact OR'''Operational Readiness''' quality gates are defined,: both entry and exit gategates. AllThe activitiesprimary areemphasis listedof whichOAT wouldshould be part and covered inon the differentoperational phases of testingstability, withportability primary emphasis be on the operationaland partreliability of the system.

==References==

{{reflist}}

[[Category:Software testing]]