운영 준비 테스팅 기본 정리

운영 준비 테스팅(Operational Readiness Testing)

• 모든 다른 테스팅 활동이 수행되었고 빌드의 라이브 전개가 준비되었을 때 시스템의 “운영 준비도(operational readiness)”를 확인하기 위해 마지막으로 수행하는 테스팅. 시스템이 생산 환경(또는 시장)으로 릴리즈되기 직전에 수행됨 
• 제품/서비스/시스템의 운영 준비가 되었는지를 보기 위해 수행되는 품질 관리 시스템의 일환이며, 시스템의 운영 준비 상태가 적절한지, 시스템이 생산 환경의 일부가 될 준비가 되었는지 등에 테스팅의 초점을 맞춘다.
• ‘운영 테스팅(Operational Testing)’, ‘운영 승인 테스팅(Operational Acceptance Testing)’, 또는 ‘운영 준비 및 보증 테스팅(Operations Readiness and Assurance Testing)’이라고도 알려짐
• 사용자 승인 테스팅(User Acceptance Testing) 이후에 일어나며, 생산 환경과 유사한 테스팅 환경에서 수행된다.

운영 준비 테스팅 점검 항목

운영 준비 테스팅에서 기본적으로 아래의 측면들을 점검한다. 주로 시스템의 비기능적 속성을 확인하는데 집중하며, 기능적 테스팅은 이러한 비기능적 측면들을 검증하는 일환으로 제한적으로 이루어진다.

• 데이터베이스 백업(Database backup): 데이터베이스가 데이터 손실 없이 성공적으로 백업이 되는지를 테스트하고 확인해야 함
• 데이터베이스 복구(Database Recovery): 데이터베이스에 어떤 이슈(예, 네트워크 실패, 웹사이트 다운, 자연 재해 등으로 인한 데이터 손실)가 발생할 경우 손실된 데이터를 복원할 수 있는지 확인해야 함
• 소프트웨어 설치 및 구성(Software Installation and Configuration): 개발된 소프트웨어가 시스템으로 성공적으로 설치되는지 체크하는 소프트웨어 설치 및 구성 테스트가 수행되어야함. 설치 절차의 각 단계가 기술되었는지, 소프트웨어를 설치하는데 있어 어려움이나 이슈가 없는지, 그리고 전개 패키지, 스크립트, 구성 작업이 설치 지침(installation instructions)대로 동작하는지를 확인함
• 롤백(Rollback): 새로운 전개 수행 시 전개된 애플리케이션이 예상대로 동작하지 않을 경우 롤백(마지막 알려진 작동 구성으로 애플리케이션을 되돌림)이 가능한지 확인해야 함
• 장애 극복(Failover): 중복 컴포넌트에 실패가 발생했을 때(예, 네트워크 실패, 서버 실패 등) 백업 시스템으로 리소스를 할당하고 주 시스템이 회복될 때까지 애플리케이션이 운영을 계속할 수 있는지 확인(즉, 중복 메카니즘이 잘 동작하는지 체크). 예를 들어, 온라인 주문 기능을 가진 경우 백엔드 컴포넌트에 실패가 생겼어도 주문이 성공적으로 이루어질 수 있는지 확인함
• 모니터링 및 알람: 시스템 오작동 시 생성되는 이벤트의 처리에 대해 체크함. 어떻게 가용성(availability), 성능, 수용력(capacity) 등이 측정되고 보고되는지, 어떤 이슈나 결함에 대한 적절한 경보가 디스플레이 되는지를 확인
• 성능(Performance): 일반적으로 성능 테스팅이 별도로 수행되지만 운영 준비 테스트에서도 부하가 가해진 상태에서의 애플리케이션 동작 검증이 이루어져야 함. 예를 들면, 일정 수의 사용자로 부하 테스트를 시작하고 애플리케이션 동작을 수동으로 체크함
• IT 서비스 관리: 소프트웨어 제품의 지원 능력(Supportability)을 검증하는데 중점을 둠
• 운영 문서 검토(Operational Documentation Review) 

운영 준비 테스팅 사례

아래 영상은 한 화학제 폐기 플랜트의 운영 준비 리뷰(Operational Readiness Review:ORR)에 대해 간략히 설명하고 있다.

[Pueblo 플랜트의 운영 준비 리뷰]

운영 준비 검토 체크리스트

릴리즈 준비 검토 및 제품 인도 전 감사를 위한 샘플 체크리스트가 아래와 같다(프로젝트 관리자와 품질 담당자에게 유용). 

1.     합의된 계약/과업기술서/작업명령서에 어긋나는 내용이 납품에 존재하는가? 납품에 대한 고위 경영진의 승인 메일이 있는가?

2.     요구사항 문서가 고객에 의해 확인되고 승인되었는가?

3.     모든 요구사항이 승인된 요구사항서/명세서(또는 고객과의 합의)에 따라 구현되었는가? 그렇지 않은 경우, 해당 사항이 릴리즈 노트/납품서 등에 문서화되었고, 고객이나 납품 책임자의 승인을 받았는가?

4.     모든 비 기술/비 기능 요구사항들이 충족되었고 완성되었는가?

5.     각 테스트의 사전에 빌드 확인(build verification)이 수행되었는가?

6.     완전한 테스트 커버리지를 보장하기 위해 모든 테스트케이스가 업데이트 되었는가?

7.     모든 테스트 주기가 완료되고 결함이 종료(처리 완료)되었는가? 종료 안된 결함이 있다면, 해당 결함이 릴리즈 노트/납품서 등에 문서화되고, 고객/납품 책임자의 승인이 있었는가?

8.     모든 리뷰 결함이 종료(처리 완료)되었는가?

9.     테스트 커버리지 목표가 테스트 계획에 언급된대로 충족되었는가?

10.   요구사항으로부터 소스 코드, 테스트케이스, 테스트 결과에 이르기까지의 추적성이 문서화되었고 검토 가능한가?

11.   시스템 테스팅, 기능 테스팅, 기타 다른 테스팅 타입의 목표가 충족되었는가?

12.   승인 테스팅(acceptance testing)을 위한 모든 테스트케이스가 식별되고 문서화되었는가?

13.   소프트웨어 품질 보증 계획에서 식별된대로 모든 형상 항목에 대한 모든 감사(audits)가 수행되었는가?

14.   기능적 형상 감사(Functional Configuration Audit), 물리적 형상 감사(Physical Configuration Audit), 기타 감사에서 발견된 사항(findings)들이 종료(처리 완료) 되었는가?

15.   테스트케이스가 타겟 환경(또는 타겟과 유사한 환경)에서 실행되었는가?

16.   시스템 유효성 확인(validation)을 위한 승인 기준(acceptance criteria)이 가용한가?

17.   최종 제품/애플리케이션이 시스템 테스팅 동안 승인 기준을 충족시키는가?

18.   코드 수정 내역이 업데이트되고 코드 파일이 구성 도구에서 올바르게 레이블링되었는가?

19.   모든 작업물, 산출물, 코드가 일관성이 있는가?

20.   전체 릴리즈 패키지의 형상 항목이 식별되었는가?

21.   릴리즈 패키지의 각 형상 항목이 테스트되고, 검토되고, 승인되었는가?

22.   형상 항목의 테스팅/검토에서 찾아낸 모든 발견 사항들이 종료(처리 완료)되었는가?

23.   FTP 접근 자격 증명 또는 CD 키 등이 문서화되었고 고객/사용자에게 전달되었는가?

24.   릴리즈 매체 및 그 액세스가 해당 정보를 고객에게 보내기 전에 확인되었는가?

25.   아래와 같은 문서/작업물들과 고객이 요구하는 기타 산출물이 가용한가?
기능 명세서, 아키텍쳐 설계서, 상세 설계서, 테스트 계획서, 테스트케이스, 릴리즈 노트, 설치 제품, 소스 코드, 테스트 프로그램, 드라이버, Read Me 파일, 라이센스 파일, 알려진 문제점 목록, 설치 절차, 설치 스크립트, 사용자 매뉴얼, 프로그래머 매뉴얼, 관리자 매뉴얼, 테스트 보고서, 교육/훈련 자료

26.   납품이 소스 콘트롤 시스템의 정적 폴더를 통해 이루어지는가?

 

위의 사항들 외에 아래 사항들의 상태도 체크될 수 있다.

l  형상 관리 도구의 산출물 베이스라인

l  프로젝트 백업 및 백업 복원

l  유지 보수/지원 계획의 준비도

l  문제 보고 절차가 문서화되어 고객에게 전달되었는가?

l  연락 담당자가 문서화되어 고객에게 전달되었는가?

l  출시 후 결함 보고 템플릿이 준비되었는가?

l  소스 콘트롤 시스템의 프로젝트 저장소를 읽기 전용으로 만드는 요청이 IT에 제출되었는지 여부