4-1. 테스트 설계 및 구현 프로세스

테스트 설계 및 구현 프로세스(Test design & implementation process)

- 테스트 설계 진행 방식은 테스트 조직 구성, 테스팅과 개발 프로세스의 성숙도, 시간적 제약, 참여 인원등 테스팅 정황에 따라 달라짐

1. 테스트 조건(Test Condition)

- 테스트 분석 과정에서 무엇을 테스트할지 결정하기 위해(테스트 조건을 식별하기 위해) 테스트 베이시스를 분석함

- 테스트 조건은 하나 이상의 테스트 케이스로 확인 가능한 항목 또는 이벤트

- 예: 기능, 트랜잭션, 품질 특성, 구조적 요소 등

2. 테스트 설계 과정

- 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 함

1) 테스트 케이스 설계

- 테스트 케이스 목적: 목표하는 보장성을 만족하는 최소한의(최적의) 테스트 케이스로 가능한 많은 결함을 발견하는 것

- 테스트 대상을 가능함 빠짐없이 테스트하여 원하는 수준의 테스트 보장성(Coverage)을 확보할 수 있도록 테스트 케이스를 설계

- 테스트 케이스 구성요소: 입력값의 묶음, 실행 사전 조건, 수행 절차, 기대 결과, 실행 사후 조건으로 구성

(이외에도 테스트 케이스 ID, 테스트 케이스 명, 추적성, 중요도, 결과(합격/불합격) 등 다양한 내용이 포함될 수 있음)

ID(식별번호)

• 테스트 케이스를 식별하기 위한 번호나 식별자

테스트 케이스명

• 테스트 내용을 간단 명료하게 표현

사전 조건(Pre-conditions)

• 테스트 수행에 필요한 사전 조건에 대한 정보(선행 조건)
• 구동환경, 테스트 데이터에 대한 정의 등

테스트 수행 절차(Test Step)

• 구체적인 테스트 수행 단계
• 7단계 이내 권고
• 테스트 케이스를 실행할 테스터의 스킬, 능력, 해당 시스템에 대한 이해 등을 고려하여 테스트 케이스의 상세함 정도를 조정

기대 결과(필수 항목)

• 테스트 실행 후 의도한 대로 동작했는지를 판단하는 근거(결과값, 데이터나 상태의 변화, 그밖의 결과 등을 기술)
• 기대 결과가 정의되지 않으면 테스트 결과가 정상인지 판단하기 어려움
• 실행 사후 조건이 필요하면 기대 결과에 포함하거나 별도로 기술함

결과(합격/불합격)

• 테스트 케이스 수행 결과
• Pass: 의도대로 동작함
• Fail: 의도대로 동작하지 않았음
• Not Tested: 아직 테스트를 수행하지 않음
• Blocked: 사전 조건이 충족되지 않아 테스트가 수행되지 않음, 테스트 결과 확인 불가

추적성

• 테스트 케이스와 관련된 요구사항 및 적용된 기법 등 기록

중요도

• 시간적 제약이 있을 경우 테스트 대상을 선택하기 위한 기준
• 시간이 부족할 경우 테스트하지 않을 것만 표시할 수도 있음

비고

• 테스트 케이스 작성 의도 등 관련 내용 기술

- 소프트웨어 테스트 문서 표준(IEEE 829)은 테스트 설계 명세(테스트 조건 포함)와 테스트 케이스 표준 양식 제시

3. 테스트 구현 단계

1) 우선순위 선정, 배치

- 테스트 프로시저 명세서(Test procedure specification)를 만듦

- 테스트 프로시저(또는 수동 테스트 스크립트): 효율적인 테스트를 위한 테스트 케이스 실행 순서

- 테스트 실행 도구를 사용하여 테스트를 수행한다면 테스트 프로시저는 테스트 스크립트(또는 자동화된 테스트 프로시저)로 기술

2) 테스트 실행 스케줄 구성

- 작성된 테스트 프로시저와 자동화된 테스트 스크립트를 언제 누가 수행할 것인지에 대해 구성

- 리그레션 테스트 여부, 우선순위, 기술적/논리적 종속 관계 등을 고려하여 결정

3) 테스트 케이스 작성

- 테스트 수행 절차를 얼마나 상세하게 작성할지를 결정해야 함

- 테스트 케이스를 실행할 테스터의 스킬, 능력, 해당 시스템에 대한 이해 등을 고려하여 테스트 케이스의 상세함 정도를 조정함

- 공식적인 기법으로 먼저 작성 후 경험 기반의 비공식적인 기법으로 보완함(두 기법이 발견할 수 있는 결함의 종류가 다르기 때문)

테스트 전략

- 소프트웨어가 요구사항을 기반으로 구현되었는지 여부에 따라 테스트 전략이 달라짐

1. 요구사항에 명시되어 있으나 구현되지 않은 경우

- 요구사항을 기반으로 테스트 케이스를 작성해 실행해야 함

2. 요구사항대로 구현되었으나 때에 따라 정상동작하지 않는 경우

- 요구사항을 기반으로 테스트 케이스를 작성해 실행하고 추가적인 테스트 케이스를 수행(네거티브 테스트 포함)

3. 요구사항에 명시되어 있지 않지만 구현된 경우

- 요구사항 기반의 테스트로 해당 결함을 발견하기 어려우므로 비공식적인 테스트(탐색적 테스팅을 사용할 수 있음)를 추가적으로 실행

- 결함을 발견하기 위해 실제 구현된 부분을 반영하여 요구사항을 변경해야 함

4. 요구사항에 명시되어 있지 않지만 구현되었으며, 정상동작하지 않는 경우

- 요구사항 기반의 테스트로 결함을 발견하기 어려우므로 비공식적인 테스트(탐색적 테스팅을 사용할 수 있음)를 추가적으로 실행

- 기대결과를 알기 어려우므로 요구사항을 기반으로 보다 체계적이고 강도 높게 비공식적인 테스트를 설계, 실행함