Operational acceptance testing: Difference between revisions

Revision as of 00:20, 13 March 2015

Latest revision as of 11:38, 16 August 2025

(20 intermediate revisions by 14 users not shown)

Line 1:

[[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 non-functional [[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''' (ORT). [[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 OATto verify the ''non-functional'' aspects of the system.

According to the International Software Testing Qualifications Board (ISTQB), OAT may include checking the [[backup]]/restore facilities, IT [[disaster recovery]] procedures, maintenance tasks and periodic check of security vulnerabilities.,<ref>ITSQB http://istqbexamcertification.com/what-is-acceptance-testing/</ref> and a White Paper on Operational Acceptance Testing, an evaluation of ISO 25000 SQuaRE vs ISO 29119 Software Testing by Anthony Woods, OAT generally subsumes:<ref>Whitepaper: Operational Acceptance Testing. January 2015 Anthony Woods, Capgemini</ref>

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>

* Accessibility Testing

* Backup / Recovery Testing

* Code Analysis

* Compatibility Testing

* Conversion Testing

* Disaster Recovery (across data centres)

* Failover Testing (within the same data centre)

* Installability Testing

* Interoperability Testing

* Localization Testing

* Maintainability Testing

* Performance Testing

* Portability Testing

* Procedure Testing

:* including IT Service Management

* Reliability Testing

* Security Testing

* Stability Testing

* Usability Testing

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>ITSQBISTQB http://istqbexamcertification.com/what-is-acceptance-testing/</ref> and awhitepapers Whiteon PaperISO on29119 and Operational Acceptance Testingby Anthony Woods,<ref name="ISO 29119 OAT">{{cite document|author=Anthony Woods|title=Operational Acceptance - an evaluationapplication of the ISO 2500029119 SQuaRESoftware vsTesting standard|date=2015|publisher=Capgemini and Sogeti|pages=1–12}}</ref> and ISO 2911925000 Softwareand Operational Acceptance Testing by AnthonyDirk WoodsDach et al., OAT generally subsumesincludes:<ref>WhitepaperWhite Paper: Operational Acceptance Testing, Business Continuity Assurance. JanuaryDecember 20152012 AnthonyDirk WoodsDach, CapgeminiDr Kai-Uwe Gawlik, Mark Mevert</ref>

During OAT changes may 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 occurs after [[user acceptance testing]] (UAT), it is a final verification before a system is released.

* InstallabilityComponent Testing

An approach used in OAT includes these steps:

* Failover Testing (withinWithin the same data centre)

:* Component fail-over

:* Network fail-over

* Functional Stability

:* Accessibility Testing

:* Conversion Testing

:* Stability Testing

:* Usability Testing

:* including IT Service Management (Supportability)

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

* Portability Testing

:* Compatibility Testing

:* Interoperability Testing

:* Installation and Backout

:* Localization Testing

* Disaster Recovery (across data centres)

:* Application/system recovery

:* Data recovery

* Reliability Testing

:* Backup /and RecoveryRestoration Testing(Recovery)

:* Disaster Recovery

:* Maintainability Testing

:* Performance, TestingStress and Volume,

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

:* Security Testingand Penetration

During OAT changes may 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.

An approach used in OAT includesmay follow these steps:

* Design the system,

* Assess the design,

* Build the system,

* Confirm if built to design,

* Deploy the application,

* Evaluate the system addresses business functional requirements,

* Maintainability and Supportability of the system.

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

* Validate the backup and recovery procedures for the system

* Deploy the applicationsystem,

* MaintainabilityAssess operability and Supportabilitysupportability 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}}