what are iq oq pq 3 q s software validation process
IQ-OQ-PQ 소개 :
IQ, OQ 및 PQ는 소프트웨어 검증 프로세스의 3Q를 구성합니다.
테스터로서 우리 모두는 소프트웨어 개발 팀이 소프트웨어 요구 사항 사양 (SRS), 기능 사양에 따라 사내에서 소프트웨어를 개발한다는 것을 알고 있으며, 나중에 테스트 팀은 가장 간단한 것부터 다양한 테스트 환경에서 다양한 테스트 수준에서 구현을 검증합니다. 따라서 프로덕션 환경을 복제합니다.
SDLC의 이러한 접근 방식을 통해 소프트웨어 개발 팀은 일반적으로 완성 된 소프트웨어 (개발 및 검증)를 운영 팀에 넘김으로써 손을 씻습니다. 또한 프로덕션 환경에 배포하고 최종 사용자가 사용할 수 있도록 준비하는 운영 팀 (일반적으로 Ops 팀이라고 함)입니다.
이제 여기에 운영 팀이 프로덕션 환경에서 소프트웨어가 작동하도록 만드는 진정한 도전이 있습니다. 소프트웨어 개발 단계에서 개발 및 검증이 시뮬레이션 된 환경에서 수행되었으며 실제 환경에 거의 근접하지 않았기 때문입니다. 데이터 가용성 및 프로덕션 환경 구성의 경우.
여기에서 소프트웨어의 유효성 검사가 필요합니다. 검증이 완료되고 프로그램 / 제품 팀이 소프트웨어를 사인 오프하면 운영 팀은 소프트웨어가 예상대로 작동하는지 증명하기 위해 프로덕션에 배포 할 소프트웨어를 수락하기 전에 일련의 활동을 수행합니다. 유효성 검사 활동 일뿐입니다.
학습 내용 :
검증 vs 검증
여기서는 '검증'과 '검증'활동의 차이점을 명확하게 이해하겠습니다. ' 확인 ’는 개발자와 테스터가 소프트웨어 개발 사이트에서 사내에서 수행하는 주어진 요구 사항 및 사양과 관련하여 소프트웨어를 평가하는 것입니다.
반면 ' 확인 ’는 제품을 수령하거나 구매하기 전에 적합성을 확인하기 위해 외부 고객, 소유자, 공급 업체가 제품에 대해 수행하는 일련의 품질 보증 검사입니다. 검증 활동은 대부분 생산 현장에서 수행됩니다.
따라서 애플리케이션 개발의 경우 소프트웨어에 대한 유효성 검사 활동을 수행하는 것은 운영 팀입니다.
또한 읽으십시오 :
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
검증 프로세스 단계
일반적으로 모든 제품의 유효성 검사 프로세스는 개발에서 사용 및 유지 관리에 이르는 제품의 전체 수명주기를 의미합니다. 따라서 유효성 검사 프로세스는 5 단계로 나뉩니다.
검증 프로세스의 5 단계는 다음과 같습니다.
이 검증 프로세스의 5 단계 접근 방식은 제조, 의료, 제약 등과 같은 많은 산업에서 따르고 있습니다. 여기서 검증은 기계, 장비 또는 제품을 구매하기 전에 최종 고객이 수행합니다.
소프트웨어에 대한 유효성 검사 활동의 구성 요소는 '소프트웨어가 사용자가 사용할 준비가되어 있음'을 증명하고 주로 소프트웨어의 성공적인 설치에 이어 기능 및 운용성을 확인하는 것입니다.
3Q의 접근 방식 : IQ-OQ-PQ
그러나 소프트웨어 컨텍스트에서 3Q의 접근 방식, IQ-OQ-PQ 유효성 검사의 일환으로 추적되고 있으며 운영 팀에서 수행하며 궁극적으로 소프트웨어를 프로덕션에 배포 할 책임이 있습니다.
다음은 유효성 검사 프로세스 흐름도입니다.
3Q를 수행하기 위해 입력 된 템플릿, 계획 및 기타 문서는 소프트웨어 팀에서 소프트웨어에 대해 배치하며 여기에는 이러한 자격의 일부로 수행 할 세부 접근 방식, 작업 / 활동 / 테스트가 포함됩니다. 테스트 결과와 함께.
요약 보고서는 바이너리 및 기타 결과물과 함께 소프트웨어 핸드 오버 중에 운영 팀에 전달됩니다.
높은 수준에서
전반적으로 IQ, OQ 및 PQ를 수행하는 목적은 소프트웨어를 성공적으로 배포하고 모든 기능을 병목 현상없이 사용할 수 있도록하는 것입니다.
이상적으로 IQ, OQ 및 PQ는 순서대로 실행해야하는 순차적 활동입니다. 설치가 완료되지 않으면 소프트웨어의 기능을 확인할 수 없으며 기능이 입증되지 않으면 성능을 측정 할 필요가 없습니다. 때때로 시간 제약으로 인해 PQ는 OQ의 핵심 측면이 설정되면 OQ와 병렬로 시작할 수 있습니다.
이제이 세 단계 각각에 대해 자세히 이해하겠습니다.
설치 자격 (IQ)
또한 설치 자격 ‘IQ’ 은 제공된 소프트웨어 (바이너리, 스크립트 등)를 지정된 구성으로 지정된 환경에 성공적으로 설치할 수 있는지 확인하고 이러한 설치 단계가 '설치 가이드'라는 문서에 어떻게 기록되어 있는지 확인하는 프로세스입니다.
다음 항목은 제공된 소프트웨어 패키지와 함께 개발 팀에서 제공하며 운영 팀에서 IQ를 수행하는 데 사용됩니다.
1) 선택한 환경의 설치 단계를 설명하는‘설치 가이드’문서.
두) 소프트웨어의 구성 가능한 설정을위한 '구성 가이드'문서. 때때로이 문서는 설치 가이드 문서 자체의 일부가됩니다.
삼) 소프트웨어 패키지 및 설치 스크립트 (가급적 자동화 스크립트).
소프트웨어 설치 검증 단계는 가장 중요한 단계이며 일반적으로 많은 문제로 간주됩니다. 열다 이 단계에서.
때문에:
에) 개발 환경은 설치 문제를 확인하는 데 사용할 수있는 100 % 실시간 환경이 없기 때문에 환경의 차이가 여러 문제에 기여합니다.
비) 여러 가지 이유로 인해 소프트웨어 개발 초기 단계에서 개발 팀과 운영 팀 간의 협력 및 조정이 충분하지 않아 문제를 잘 처리하지 못할 수 있습니다.
씨) 문서에 실제 설치 단계를 기록하는 동안 일부 문서화 문제가있을 수 있으며, 이는 프로덕션 환경에서 정확히 일치하지 않을 수 있습니다.
요즘에는 전체 소프트웨어 설치 절차가 일련의 스크립트를 통해 최대한 자동화됩니다. 설치에 문제가있는 경우 구성의 불일치로 인해 자동 설치가 실패하고 이러한 문제를 해결하기위한 수동 개입이 필요합니다.
Ops 팀은 설치 가이드의 소프트웨어 팀이 제공 한 지침을 엄격히 준수하여 IQ를 수행하므로 '설치 가이드'가 다음과 같은 방식으로 작성되었는지 확인하는 것이 매우 중요하며 소프트웨어 팀의 책임이기도합니다. 설치 단계는 실시간 환경과 일치합니다.
그리고 '설치'프로세스가 완전성에 대한 문서 검증과 함께 사내에서 검증되었는지 확인하고 시스템에서 문서화 된 단계에 대해 시스템에서 실행될 실제 단계와 일치하지 않는 부분을 식별하는 것은 테스터의 책임입니다. 설치 안내서.
생산시 소프트웨어 설치 중 문제를 최소화하기 위해 설치 가이드를 작성하고 사내에서 확인할 때 다음 사항을 염두에 두어야합니다.
| SNO | 설치 가이드 포인트 |
|---|---|
| 7 | 소프트웨어를 설치하는 데 걸리는 일반적인 시간은 설치 가이드에 언급되어 있어야 운영팀이 대략적인 설치시기를 파악하여 그에 따라 활동을 계획 할 수 있습니다. |
| 1 | 무엇보다도 '설치 가이드'는 간단하고 따라하기 쉬운 언어로 작성되어야합니다. |
| 두 | 5 페이지를 초과하는 긴 페이지로 실행되지 않도록해야합니다. 짧고 깔끔해야합니다. |
| 삼 | 상태를 추적하려면 각 실행 단계에 대한 일련 번호를 제공해야합니다. |
| 4 | 가능한 한 단계를 자동화하고 모든 단계를 단일 스크립트로 묶습니다. |
| 5 | 설치 절차를 작성하려면 표준 템플릿을 사용해야합니다. |
| 6 | 미스 매치를 방지하기 위해 전제 조건을 명확하게 언급하고이를 확인하는 단계를 제공해야합니다. 일치하지 않는 경우 예상 수준으로 가져 오거나 해당 패키지를 설치하라는 지침이 제공되어야합니다. |
| 8 | 설치 중 중단해야하는 서비스, 중단 방법, 중단의 영향은 가이드에 명확하게 언급되어야합니다. |
| 9 | 다른 문서에 대한 링크를 제공하지 말고 한 문서에서 다른 문서로 전환해야합니다. 필요한 모든 정보는 동일한 문서에서 사용할 수 있어야합니다. 추가 문서를 참조해야하는 경우 소프트웨어 패키지와 함께 제공하고 차례로 기본 문서에서 참조해야합니다. |
| 10 | 문서에 언급 된 스크립트의 이름이 바이너리와 함께 패키지 된 것과 동일한 지 확인해야합니다. |
| 열한 | 설치 가이드 문서에 언급 된 모든 스크립트가 바이너리와 함께 제공되는지 확인해야합니다. |
| 12 | 모든 구성 매개 변수가 기본값 및 기타 지원되는 값과 함께 설치 안내서 / 구성 안내서에 명시되어 있는지 확인하십시오. |
| 13 | 소프트웨어 설치가 완료된 후 빌드 검증 테스트를 수행하기위한 자동화 테스트를 제공해야합니다. 빌드가 성공적으로 설치되었는지 확인하려면 최소한의 숫자와 중요한 숫자 여야합니다. |
| 14 | 시스템의 종단 간 연결이 완벽하고 시스템의 모든 구성 요소가 예상대로 서로 통신하는지 확인하려면 '연기 테스트'를 제공해야합니다. |
| 열 다섯 | 소프트웨어 설치에 실패한 경우 패키지와 함께 롤백 스크립트가 제공되며 롤백 절차는 설치 가이드에 명확하게 기록되어 롤백을 수행하고 시스템을 성공적으로 복원합니다. |
위의 모든 사항에주의를 기울여야하는 경우 인적 오류를 방지하기 위해 최소한의 인적 개입으로 소프트웨어 설치 프로세스를 자동화하는 것이 가장 좋습니다.
IQ 유효성 검사 단계에서 문제가 발견되면 소프트웨어 팀에보고되며 수정시 연기 테스트 및 빌드 검증 테스트 소프트웨어 설치의 성공 여부를 확인하기 위해 수행됩니다.
따라서 IQ 단계에는 소프트웨어 패키지 설치와 빌드 확인 및 연기 테스트 수행이 포함됩니다.
따라서 IQ 단계를 성공적으로 완료하는 것은 소프트웨어의 성공적이고 올바른 설치가 기능 장애와 관련된 대부분의 문제가 무효화되도록 보장하기 때문에 매우 중요합니다.
운영 자격 (OQ)
라고도하는 운영 자격 뭐 IQ가 성공적으로 완료된 후 소프트웨어 검증 프로세스의 다음 활동입니다.
운영 자격 활동에는 다음이 포함됩니다. 그는 소프트웨어가 운영상 소비자에게 배포하기에 적합한 지 확인하기 위해 실행할 테스트를합니다. 이상적으로는 소프트웨어의 주요 기능이이 검증 프로세스의 일부로 검증됩니다.
OQ 검증을 수행하기위한 OQ 계획은 소프트웨어 팀 (테스터)에 의해 준비되어야하며, 이는 아니오와 같은 세부 사항을 포함하여 수행해야하는 OQ 테스트의 모든 측면을 포함해야합니다. 테스트, 테스트 일정, 방법론, 도구, 서비스에 대한 영향, 테스트 실행 순서, 문제보고 방법 및 문제 해결을위한 SLA, 결함 분류 접근 방식 등
OQ의 일부로 실행되는 운영 적격성 테스트는 소프트웨어 결과물과 함께 소프트웨어 팀에서 다시 제공합니다. 이러한 운영 적격성 테스트는 전체 소프트웨어 시스템이 예상대로 작동하는지 확인하기 위해 '기능 요구 사항 사양'문서를 기반으로 설계된 중요한 테스트 모음입니다.
이 OQ 테스트 사양 문서는 기능 요구 사항 사양 문서에 대해 테스트 엔지니어가 준비합니다. 종종이 문서는 SDLC의 시스템 테스트 단계에서 준비되고 확인되는 시스템 테스트 사양 문서의 하위 집합입니다.
테스트는 운영 팀 요구 사항 및 실행될 사이트의 조건에 맞게 변경 또는 업데이트 될 수 있습니다.
따라서 OQ의 일부인 테스트를 선택하는 동안 추가주의를 기울여 모든 주요 기능과 주요 비즈니스 워크 플로가이 검증의 일부로 포함되도록해야합니다.
다음은 OQ 테스트 사양 문서를 준비하는 동안 테스터를위한 팁입니다.
| Sno | OQ 테스트 사양 문서를 준비하는 동안 테스터를위한 팁 |
|---|---|
| 7 | 경계 값과 관련된 테스트 케이스를 포함 할 필요는 없습니다.이 경우 극한 값을 확인하지만 필요한 경우 가장 일반적인 일상 사용 값을 입력으로 사용합니다. |
| 1 | 예상대로 소프트웨어 기능이 선택되고 포함되어 있음을 증명하기위한 주요 기능 테스트가 OQ 테스트 사양 문서에서 각 작성된 테스트 케이스에 필요한 추적 성을 제공하는지 확인합니다. |
| 두 | 테스트가 단계별 조치로 깔끔하게 작성되고, 자명하며 일반 사람이 이해할 수 있는지 확인하십시오. |
| 삼 | 이 문서의 사용자는 사용 된 테스트 데이터가 시스템에 이미 존재하지 않기 때문에이 문서의 사용자가 해당 용어에 대해 알지 못할 수 있으므로 테스트 케이스에서 기술 용어를 가능한 많이 참조하거나 사용하지 마십시오. 사용자가 테스트 케이스를 두 번 이상 실행하려는 경우 여러 데이터 세트를 제공하십시오. |
| 4 | 각 테스트의 필수 및 선택적 전제 조건을 명확하게 언급하십시오. |
| 5 | 기능을 확인하기 위해 대부분의 긍정적 인 테스트 사례를 포함합니다. |
| 6 | 부적절한 입력의 경우 소프트웨어 동작이 예상과 같고 시스템이 음성 사례를 성공적으로 처리 할 수 있도록 부정적인 테스트 사례를 거의 포함하지 않습니다. |
| 8 | 기본값에서 변경해야하는 경우 설정할 구성 값을 언급합니다. |
| 9 | 가능한 경우 실행할 자동화 된 테스트 케이스를 제공하십시오. 이러한 자동화 스크립트가 OQ가 계획중인 시스템에서 실행될 수 있는지 미리 확인하십시오. |
| 10 | 각 테스트 사례에 명확한 '예상'및 '실제'결과가 참조로 포함되어 있는지 확인하십시오. 그리고 필요한 경우 실제 결과를 설명하기 위해 주석을 추가하십시오. |
| 열한 | 또한 각 테스트 케이스에 대한 '승인 기준'을 포함해야합니다. 허용 기준은 테스트 케이스 실행 후 시스템의 상태가 될 수 있습니다. |
| 12 | 각 테스트에 사용할 '테스트 데이터'를 정확하게 입력하십시오. 라이브에서 가장 일반적인 데이터를 제공하십시오. 또한 예외적 인 데이터가 거의 없으므로 시스템이 예외적 인 경우도 처리 할 수 있습니다. 사용 된 테스트 데이터가 시스템에 존재하지 않는지 확인하십시오. 사용자가 테스트 케이스를 두 번 이상 실행하려는 경우 여러 데이터 세트를 제공하십시오. |
| 13 | 여러 운영 사용자가 서로 다른 위치에서 병렬로 테스트를 실행하는 경우 서로 다른 데이터 세트를 사용하여 그에 따라 테스트를 수행하도록 지침을 제공하십시오. |
| 14 | 테스트를 실행하기 전에 모든 구성, 필수 구성 요소가 예상대로 설정되었는지 확인하기 위해 필요한 경우 체크리스트를 제공합니다. |
| 열 다섯 | 시스템에 액세스 할 수있는 경우 테스트가 실행 중일 때 로그를 계속 모니터링하십시오. |
| 16 | 가능하고 필요한 경우 이러한 테스트 사례를 실행하는 동안 운영 사용자에게 실행 지원을 제공합니다. |
| 17 | 실행 중에 발견 된 문제를보고하는 방법을 설명합니다. 버그 추적 도구를 사용하여 문제를 추적하는 것이 좋습니다. 각 문제를주의 깊게 모니터링하고 합의 된 SLA에 따라 종료합니다. |
| 18 | 중요하고 심각한 문제를 이해하고 이러한 문제에 대한 업데이트를 자주 제공하기 위해 권리 이해 관계자가 참여하는 '결함 분류'를 실행합니다. |
| 19 | 실행 완료 후 최종 결과를 게시하려면 최종 'OQ 테스트 실행 요약 보고서'템플릿을 제공합니다. |
따라서 준비된 OQ 계획 및 테스트 사양은 관련 이해 관계자가 철저히 검토하고 서명하여 주로 적용 범위가 너무 적거나 너무 많지 않고 모든 주요 기능이 포함되는지 확인해야합니다.
OQ를 성공적으로 완료하면 소프트웨어가 선택한 환경에서 작동 사양에 따라 작동하고 소프트웨어를 프로덕션으로 이동시키는 단계 게이트이며 검증 프로세스의 다음 활동을 진행하라는 신호입니다. PQ .
성능 검증 (PQ)
성공적인 IQ, OQ 완료를 확인한 후 유효성 검사 프로세스의 다음 활동은 제품 / 소프트웨어가 프로덕션 환경에 병목 현상을 일으키지 않고 예상 부하에서 지정된 성능 측면을 일관되게 충족하는지 확인하는 것입니다.
PQ의 핵심은 소프트웨어가 예상 시스템에 설치되었을 때 실시간 부하를 처리하고 예상 응답 시간을 충족 할 수 있으며 동시 사용자를 처리하는 동안 최대 부하 및 스트레스에서 충돌하지 않습니다.
따라서 PQ는 주로 소프트웨어에 대해 지정된 성능 기준이 라이브 패턴과 마찬가지로 다양한 부하 조건에서 신뢰할 수있는 기반으로 일정 기간 (아마도 일주일)에 걸쳐 달성되는지 확인하는 것입니다. 따라서 이러한 테스트는 소프트웨어 시스템 동작을 모니터링하기 위해 매일 실행해야하므로 PQ는 시스템의 성능이 입증 될 때까지 완료하는 데 시간이 걸립니다.
이상적으로는 소프트웨어의 기능이 보장되고 제품 또는 소프트웨어의 성능 측면을 검증 할 수있는 OQ 완료 후 PQ 유효성 검사가 수행됩니다. 때때로 시간 제약으로 인해 PQ는 OQ 완료율에 대한 신뢰도를 기반으로 OQ와 병렬로 시작할 수 있습니다.
완전히로드 된 시스템이있는 라이브 시스템 또는 라이브와 유사한 조건에서 이러한 성능 테스트를 수행하고 성능 측면에 병목 현상이 없는지 확인하는 것이 이상적입니다.
다음 테스트는 일반적으로 Performance Qualification의 일부로 실행됩니다. 그리고 테스트 선택은 소프트웨어마다 다릅니다.
# 1) 가용성 테스트 : 충돌이나 다운없이 소프트웨어를 지속적으로 사용할 수 있도록합니다.
# 2) 접근성 테스트 : 문제없이 예상되는 성능 속도로 모든 위치에서 소프트웨어에 쉽게 액세스 할 수 있도록합니다.
# 3) 부하 테스트 : 예상되는 일일 부하 및 최대 부하 조건에서 시스템의 동작을 측정합니다.
# 4) 스트레스 테스트 : 극한 부하 조건에서 시스템의 중단 점을 측정합니다.
# 5) 처리량 성능 테스트 : 시스템의 응답 시간 측정 및 TPS (초당 트랜잭션) 측정
# 6) 확장 성 테스트 : 시스템은 예상되는 동시 사용자를 처리하도록 확장 할 수 있습니다.
성능 테스트 시나리오 및 해당 자동화 스크립트는 '사용자 요구 사항 사양'문서에 지정된 성능 관련 요구 사항을 기반으로 준비됩니다.
OQ 계획과 유사하게 테스트 접근 방식, 전략, 계획 및 일정을 도구와 함께 명확하게 설명하는 세부 PQ 계획을 준비하고 PQ 실행자와 함께 실행해야합니다.
성능 메트릭을 측정하고보고하려면 PQ가 수행되는 환경에 성능 테스트 및 모니터링 도구를 설치해야합니다.
다음은 운영 팀이 PQ를 성공적으로 수행 할 수 있도록 테스터를위한 팁입니다.
| Sno | 테스터가 운영 팀을 활성화하기위한 팁 |
|---|---|
| 7 | 시스템에서 성능 테스트를 수행하도록 운영 팀을 안내, 지원 및 교육합니다. |
| 1 | URS를 기반으로 성능 테스트를 수행하기위한 주요 비즈니스 특정 시나리오를 준비합니다. |
| 두 | 시스템이 다양한 부하 조건에서 응답 시간, 속도, 확장 성 및 안정성에 대한 기대치를 충족하는지 입증하는 테스트가 포함되었는지 확인합니다. |
| 삼 | 지정된 부하를 사용할 수 있는지 또는 필요한 부하를 생성하는 방법과 도구가 각 테스트 사례에 명확하게 언급되어 있는지 확인합니다. |
| 4 | 시스템에 존재해야하는 사전로드 조건, 동시 사용자 수 등과 같이 각 시나리오의 전제 조건을 명확하게 언급합니다. |
| 5 | 각 테스트 범주 및 각 테스트에 대한 성능 테스트를 수행하는 데 사용하도록 권장되는 언급 도구입니다. |
| 6 | 성능 메트릭을 모니터링하는 프로세스가 명확하게 언급되었는지 확인합니다. |
PQ가 성공적으로 완료되면 성능 관련 편차가 사용자에게 불편 함을 초래하여 막대한 비즈니스 손실을 초래할 수 있으며 사용할 소프트웨어에 대한 신뢰가 상실되어 소프트웨어가 실패 할 수 있으므로 성능 요구 사항을 충족하는 것이 매우 중요합니다.
간단히 말해서, t 아래 표는 IQ-OQ-PQ 활동을 요약 한 것입니다.
| IQ | 뭐 | PQ | |
|---|---|---|---|
| 뭐 | 소프트웨어 설치 프로세스 및 프로세스 문서화 방법을 확인하려면 | 시스템이 제대로 작동하는지 확인하려면 | 고객, 소유자, 공급 업체, 운영 팀 |
| WHO | 고객, 소유자, 공급 업체, 운영 팀 | 고객, 소유자, 공급 업체, 운영 팀 | 고객, 소유자, 공급 업체, 운영 팀 |
| 어디 | 소유자 사이트, 운영 팀 위치, 라이브 사이트, 제품과 같은 환경 | 소유자 사이트, 운영 팀 위치, 라이브 사이트, 제품과 같은 환경 | 소유자 사이트, 운영 팀 위치, 라이브 사이트, 제품과 같은 환경 |
| 언제 | 소프트웨어 팀으로부터 소프트웨어를받은 경우, OQ 및 PQ 전에. | 사용을 위해 시스템을 출시하기 전과 성공적인 IQ 완료 후 | 시스템을 Live로 전환하기 전과 성공적인 IQ, OQ 완료 후 |
아래 표는 각 검증 단계에 대한 다양한 입력을 설명합니다.
| 유형 | 입력 |
|---|---|
| IQ | 1. 설계 사양 문서 2. 소프트웨어 바이너리 및 기타 설치 스크립트 3. 설치 가이드 문서 4. 구성 가이드 문서 5. 검증 및 연기 테스트 문서 작성 |
| 뭐 | 1. 기능 사양 문서 2. OQ 계획 문서 3. 운영 자격 테스트 문서 4. OQ 테스트 요약 보고서 템플릿 5. IQ가 성공적으로 완료되었습니다. |
| PQ | 1. URS (User Requirement Specification) 문서 2. PQ 계획 문서 3. 성능 검증 테스트 문서 4. PQ 테스트 요약 보고서 템플릿 5. IQ 및 OQ가 성공적으로 완료되었습니다. |
결론
제품 / 소프트웨어가 모든 검증 단계를 통과하고 IQ-OQ-PQ 중 하나를 증명하지 못하더라도 결과는 재앙이 될 수 있으며 막대한 비용이 발생합니다. 따라서 IQ-OQ-PQ를 성공적으로 완료하는 것은 개발 사이트에서 프로덕션 사이트로 제품을 성공적으로 전송하는 것입니다.
전반적으로 IQ-OQ-PQ 검증 프로세스를 성공적으로 완료하면 소프트웨어에 대한 확신을 가질뿐만 아니라 클라이언트, 소유자, 소프트웨어 개발자 및 테스터에게도 안심할 수 있습니다.
deque C ++이란?
IQ-OQ-PQ를 실행하면 테스트를 수행하지 않고 실시간으로 배포 할 위험이 줄어들고 실패 비용이 줄어들고 제품 리콜 위험이 완화됩니다.
따라서 Guys, Software Developers 및 Testers는 사내에서 개발 및 테스트를 완료하고 소프트웨어를 Ops Team에 출시 한 후 축하 할 일이 없습니다. 축하 행사는 IQ-OQ-PQ를 성공적으로 완료하고 소프트웨어가 대상 시스템에 활성화 된 경우에만 열립니다.
따라서 소프트웨어의 성공 여부는 IQ-OQ-PQ의 성공적인 완료와 소프트웨어가 라이브 상태이고 최종 사용자가 사용할 준비가되었는지 여부에 달려 있습니다.
저자 정보 : 이 기사는 STH 팀원 Gayathri Subrahmanyam이 작성했습니다. 그녀는 소프트웨어 테스팅 분야에서 20 년 이상의 경험을 가지고 있습니다. 테스트 경력 동안 그녀는 많은 TMMI 평가, 테스트 산업화 작업, TCOE 설정을 수행하고 테스트 제공을 처리하고 대규모 참여를 위해 DevOps 연습을 구현했습니다. 하지만 그녀에 따르면 학습은 결코 멈추지 않습니다.
검증 프로세스 수행에 대한 경험을 공유하고이 기사에 대한 질문이 있으면 알려주십시오.
추천 도서
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 경력으로 소프트웨어 테스트 선택
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
- 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
- 소프트웨어 테스팅 과정 피드백 및 리뷰
- 소프트웨어 테스팅 도움말 제휴 프로그램!