[ISTQB] 5.6 인시던트 관리

공부/ISTQB

모카젤리 2014. 9. 14. 20:03

ISTQB CTFL Syllabus 2011

인시던트 관리

Incident Management

Terms

Background

테스팅의 목적 중 하나는 결함을 발견하는 것이기 때문에, 실제 결과와 예상 결과의 차이는 인시던트로서 기록될 필요가 있다.
인시던트는 반드시 조사되어야 하고, 결함으로 판명될 수 있다.
인시던트와 결함을 처리하게 위한 적절한 행동이 정의되어야 한다.
인시던트와 결함은 수정과 솔루션 확인을 위해 발견하고 분류하는 것 부터 추적되어야 한다.
모든 인시던트를 완성적으로 관리하기 위해서 조직은 인시던트 관리 프로세스와 분류 규칙을 확립해야 한다.
인시던트는 개발, 리뷰, 테스팅이나 소프트웨어의 사용기간 동안 발생할 수 있다.
인시던트는 코드나 동작하는 시스템의 이슈로 발생하거나, 요구사항, 개발 문서, 테스트 문서, 도움말이나 설치가이드와 같은 사용자 정보를 포함한 문서 유형에서도 발생할 수 있다.

- 개발자와 다른 분야의 사람들에게 문제에 대해 식별 가능하고, 분리하고, 필요한 경우 수정할 수 있도록 피드백을 제공.

- 테스트되는 시스템의 품질과 테스팅의 절차를 추적하는 방법을 테스트 리더에게 제공.

- 테스트 프로세스 개선에 대한 아이디어 제공

- 이슈의 날짜, 조직의 이슈, 작성자

- 기대 결과와 실제 결과

- 테스트 아이템(형상 아이템)과 환경의 식별

- 소프트웨어나 시스템 생명주기 프로세스에서 발견된 인시던트의 시점

- 제품의 재생산과 인시던트의 재해결을 가능하게 하는 로그, 데이터베이스 덤프나 스크린샷을 포함한 설명

- 이해 관계자의 관심사에 미치는 영향의 범위와 정도

- 시스템에 미치는 영향의 심각성

- 수정의 긴급도/우선순위

- 인시던트의 상태 (e.g. open, 연기 deferred, duplicate, waiting to be fixed, fixed awaiting re-test, closed)

- 결론, 권고사항, 승인

- 인시던트의 변경 결과에 다른 영역이 영향을 받는 것 같은 글로벌 (전역) 이슈

- 인시던트 격리, 수정, 수정확인에 대해 프로젝트 팀 멤버가 수행한 행동의 연속 같은 변경 이력

- 문제를 발생시킨 테스트케이스 명세의 식별을 포함한 참조사항