소프트웨어 테스트팀의 산출물

테스트 산출물은 소프트웨어 개발 중 이해관계자와 공유하는 문서입니다. 이 절에서는 다음 내용을 다룹니다.

전체 크기 도표 열기 ↗

소프트웨어 테스트팀의 산출물

• 소프트웨어 테스트 전략
• 소프트웨어 테스트 계획
• 소프트웨어 테스트 시나리오와 테스트 케이스
• 소프트웨어 테스트 지표
• 제품 지표
• 프로세스 지표
• 소프트웨어 테스트 문서
• 소프트웨어 테스트 보고서
• 일일 테스트 현황 보고서
• 인시던트 보고서
• 최종 테스트 현황 보고서(프로젝트 종료)

소프트웨어 테스트 전략

테스트 전략은 프로젝트의 테스트 활동이 나아갈 방향을 제시합니다. 작업을 작고 명확한 프로세스로 나누세요. 전략은 팀이 필요한 시간, 노력, 자원을 추정하도록 돕고, 계획 수립, 관리, 진행 상황 추적에도 도움이 됩니다.

소프트웨어 테스트 계획

테스트 계획은 전체 테스트 전략, 환경, 테스트 수준을 정합니다. 결과를 어떻게 분석하고 어떤 지표를 사용할지 설명합니다. 각 단계의 종료 기준과 테스트에 필요한 노력과 비용의 추정치도 기록합니다.

전체 크기 도표 열기 ↗

소프트웨어 테스트 계획

소프트웨어 테스트 시나리오와 테스트 케이스

테스트 시나리오는 소프트웨어를 체계적으로 평가하기 위한 가상의 상황을 설명합니다. 이야기처럼 복잡할 수 있습니다. 테스트 케이스는 수행할 작업, 제공할 입력, 예상되는 출력을 직접 안내합니다. 케이스는 대개 한 줄로 설명하지만, 시나리오는 테스트 담당자가 탐색할 더 넓은 상황을 제시합니다.

전체 크기 도표 열기 ↗

소프트웨어 테스트 시나리오와 테스트 케이스

Cem Kaner는 2003년에 시나리오 기반 테스트를 현실적인 상황을 탐색하는 방법으로 설명했습니다. 상세한 테스트 케이스에는 여전히 단계, 입력 데이터, 기대 결과를 기록합니다. 이 정도의 세부 정보를 유지하려면 더 많은 노력이 필요할 수 있습니다.

테스트 케이스는 담당자에게 어떤 작업을 하고 어떻게 소프트웨어를 테스트할지 직접 알려 줍니다.

전체 크기 도표 열기 ↗

소프트웨어 테스트 시나리오와 테스트 케이스

소프트웨어 테스트 지표

소프트웨어 지표는 소프트웨어의 속성을 평가하는 데 쓰는 측정 단위입니다. 테스트 지표는 품질을 평가하고 개발 중인 시스템이 얼마나 준비되었는지 보여 줍니다. 왜 측정할까요? 측정할 수 있는 것은 통제할 수 있으므로 개선할 수 있습니다. 개발의 각 단계에서 이전 단계의 지표를 검토하고 결정을 내립니다. 테스트 지표는 두 그룹으로 나뉩니다.

1. 직접 측정값인 기본 지표는 테스트 분석가가 프로젝트 상태를 보여 주기 위해 모은 원시 데이터입니다. 작성했거나 실행한 테스트 케이스 수가 그 예입니다.
2. 간접 측정값인 계산 지표는 기본 데이터를 더 유용한 프로젝트 정보로 바꾼 결과입니다. 완료율과 테스트 커버리지가 그 예입니다.

제품 지표

제품 지표는 품질을 개선하는 방향을 제시합니다. 정기적으로 평가하면 팀이 바로잡아야 할 제품 특성을 제때 파악할 수 있습니다. 측정하는 항목은 다음과 같습니다.

• 규모
• 복잡성
• 설계 특성
• 성능
• 품질

프로세스 지표

프로세스 지표는 일하는 방식을 개선해 시간과 노력을 줄일 기회를 보여 줍니다. 진행 상황을 평가하려면 결과를 프로세스 목표와 비교하세요. 테스트 활동을 추적하면 프로젝트의 효율성과 효과를 높일 수 있습니다. 소프트웨어 개발에서 프로세스 지표는 다음 영역을 다룹니다.

• 소프트웨어 개발
• 소프트웨어 유지보수
• 소프트웨어 테스트

소프트웨어 테스트 문서

테스트 문서는 테스트 이전 또는 진행 중의 활동을 기록합니다. 주요 문서는 다음과 같습니다.

• 테스트 계획
• 테스트 시나리오
• 테스트 케이스
• 추적성 매트릭스

소프트웨어 테스트 보고서

다음 보고서는 테스트 업무에 도움이 됩니다.

• 일일 테스트 현황 보고서
• 인시던트 보고서
• 최종 테스트 현황 보고서(프로젝트 종료)

일일 테스트 현황 보고서

일일 현황 보고서는 테스트팀과 프로젝트 및 프로그램의 이해관계자에게 정보를 제공합니다. 프로젝트 관리자는 하루 동안 보고된 결함 수, 실행한 케이스, 담당자별 작업을 볼 수 있습니다. 다음 질문에 답하는 내용을 담습니다.

1. 그날 계획한 테스트 케이스는 몇 건인가요?
2. 그중 몇 건을 실행했나요?
3. 팀이 보고한 결함은 몇 건인가요?
4. 치명적인 결함은 몇 건인가요?
5. 결함 및 테스트 실행 기록표 등 상세 보고서는 어디에서 찾을 수 있나요?

인시던트 보고서

인시던트 보고서는 테스트와 개발 사이의 협업을 돕습니다. 인시던트 관리에서는 다음을 기록합니다.

• 실제 결과와 기대 결과의 비교
• 테스트 실패 시 차이가 발생한 이유. 자동화 문제, 잘못된 테스트 케이스, 실제 소프트웨어 장애 등이 해당합니다.

실제 장애가 발생하면 인시던트 보고서를 작성하세요. 다음 세부 정보를 포함합니다.

• 식별 정보
• 각 보고서의 ID는 무엇인가요?
• 테스트 대상은 무엇인가요?
• 테스트 대상 소프트웨어 애플리케이션 버전
• 하드웨어와 소프트웨어를 포함한 테스트 환경 세부 정보
• 인시던트를 평가하고 해결할 개발자 이름
• 장애를 언제 발견했나요?
• 분류
• 상태
• 심각도
• 우선순위
• 요구 사항
• 원인
• 문제 설명
• 문제에 대한 구체적인 설명
• 테스트 케이스 세부 정보
• 테스트 담당자의 의견
• 변경 후 개발자의 의견
• 참고 자료가 있으면 기재

최종 테스트 현황 보고서(프로젝트 종료)

종료 기준을 충족하거나 테스트가 끝나면 테스트 책임자가 프로젝트 종료 보고서를 작성합니다. 이후 이해관계자와 고객이 검토합니다. 성공적으로 실행한 테스트 케이스와 배포 후 해결하기로 한 미해결 결함을 포함하세요.