Test Case 작성법

1. 테스트 프로세스

테스트 프로세스는 테스트와 관련된 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 모든 구성요소를 엮어주는 역할을 함.

테스트 프로세스 5 단계

  계획/제어 -> 분석/설계 -> 구현/실행 -> 완료/리포팅 -> 마감

테스트 프로세스는 계획/제어, 분석/설계, 구현/실행, 완료/리포팅, 마감 5단계로 구성.

1. 계획과 제어 :
   테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 확인하고 필요한 활동을 정의.
   테스트 제어는 계획 대비 실제 신행 상황을 비교하는 지속적인 활동.
2. 분석과 설계 :
   테스트 분석과 설계는 일반적이고 추상적인 테스트 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환.
3. 구현과 실행 :
   테스트 구현과 실행은 가장 효율적이고 효과적으로 테스트스를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시져를 명세화.
4. 완료 조건과 리포팅 :
   초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가.
5. 테스트 마감 :
   완료된 테스트에서 발견된 사실 및 수집된 데이터, 경험을 취합하고 축적.

---

2. TC 작성 절차

  문서 수집 -> TC 작성 -> 내부 검토 -> 커버리지 분석 -> 승인

1. 참조 문서 수집 :
   테스트 계획서에 명시된 테스트 케이스 작성 지침과 수준을 고려,
   테스트 설계에 필요한 분석 및 설계 문서 수집.
2. TC 작성 :
   테스트 설계 기법을 이용하여 TC를 작성.
3. 내부 검토 :
   PM, 아키텍트, 디자이너, 기획자, 개발자, QA 담당자가 작성된 TC의 적정성 검토.
4. 요구사항 대비 커버리지 분석 :
   TC가 어느 정도 요구사항을 반영하는가에 대한 분석.
   기본적으로 테스트 가능한 요구사항은 모두 TC에 반영되어있는지 확인.
5. 승인 :
   작성된 TC를 클라이언트(현업), 기획자 및 PM에게 승인을 받음.

---

3. TC 구성요소

• 식별 번호 :
  TC의 고유 식별자.
• 이슈 번호, 제목 :
  제목과 이슈 번호를 기입. (Redmine NO., Jira NO.)
• 요약 (Description) :
  TC의 목표 등 요약된 정보
• 사전 조건 (Precondition) :
  테스트 수행에 필요한 조건 및 실행환경. (선행 조건, 전제조건)
• 종속성 (Dependencies) :
  테스트 요구사항 또는 기타 TC에 대한 의존성 판단.
• 수행 절차 (Test Step) :
  TC를 수행하기 위한 정확한 단계.
• 기대 결과 (Expect Result) :
  절차대로 진행 시 테스트 통과 여부를 결정하는 기대 결과.
• 실제 결과 (Actual Result, PASS / FAIL) :
  테스트 수행 후 실제 결과.
• 비고 (Remark, Note, Comment) :
  기타 비고 사항을 기입.
• 그 외 :
  우선순위, 모듈 이름, 테스트 설계자, 설계일, 테스트 수행자, 수행일 등

구성 요소는 조직이나 프로젝트에 따라 변경/추가/삭제 될 수 있다.

---

4. TC 작성 시 주의 점 및 장/단점

주의점

• 절차의 누락 :
  테스트 절차를 정확하게 입력하지 않을 경우 테스트 수행의 어려움이 생기는 테이스 발생 가능.
• 장황한 설명 :
  TC 작성 시 상세하고 충분한 정보를 제공해야 하지만, 너무 많은 단어와 불필요한 설명으로 소통의 오류 유발 가능.
• 전문 용어의 과다 사용 :
  TC 작성 시, 직군간 소통이 불가능한 전문용어를 과다사용시 테스트 수행에 어려움이 있을 수 있음.
• 분명하지 않은 PASS/FAIL 기준 :
  테스트 수행 후 테스트 결과가 통과인지 실패인지 예상 결과에 정확히 기입하지 않아 결과 판단에 어려움 유발 가능.

단점

• TC 작성 시간이 수행 시간보다 오래 걸릴 수 있음.
• 기능 변화에 따른 TC 변경 :
  기능을 자주 변경한다면 추후 테스트 케이스의 통제에 어려움이 생기게 될 수 있음.
• 배경 지식 판단의 어려움 :
  TC를 작성하는 사람은 테스트 하는 기능을 잘 알고 있으나, 테스트 수행자는 배경 지식이 없을 경우 테스트 수행 시간이 길어지거나 수행에 어려움이 있을 수 있음.

장점

• 이력 참조 :
  TC는 어플리케이션 런칭 후에도 사용, 유지보수 팀과 추후 어플리케이션의 버전을 담당자의 테스트 이력 참고가 가능.
• 테스트 진행 상황 추적 :
  TC를 문서화 하면 수행한 TC의 수, 통과/실패 수, 과업 범위 별 케이스 수, 테스트 커버리지 등의 정보를 추적/확인 가능.
• 반복성 :
  잘 작성된 TC는 누구나 반복적으로 수행 가능.

---

5. TC 정렬

TC의 정렬은 업부의 효율과 연결될 수 있다. 테스트의 흐름, 테스트 환경 등을 고려해서 정렬 하도록 하자.

흐름이 이어지는 TC 정렬

정렬 전 스펙 문서에 따라 쓴 TC	정렬 후 흐름에 맞춘 TC
1. A 기능 1 실행	1. A 기능 1 실행
2. A 기능 2 실행	2. A 기능 1의 추가기능 실행
3. A 기능 3 실행	3. 기능 2 실행
4. A 기능 1의 추가기능 실행	4. A 기능 2의 추가기능 실행
5. A 기능 2의 추가기능 실행	5. 기능 3 실행
6. A 기능 3의 추가기능 실행	6. A 기능 3의 추가기능 실행

환경이 비슷한 TC 정렬

정렬 전 스펙 문서에 따라 쓴 TC	정렬 후 흐름에 맞춘 TC
1. 기능 A를 관리자(Root) 계정으로 테스트	1. 기능 A를 관리자(Root) 계정으로 테스트
2. 기능 A를 사용자(User) 계정으로 테스트	2. 기능 B를 관리자(Root) 계정으로 테스트
3. 기능 B를 관리자(Root) 계정으로 테스트	3. 기능 C를 관리자(Root) 계정으로 테스트
4. 기능 B를 사용자(User) 계정으로 테스트	4. 기능 A를 사용자(User) 계정으로 테스트
5. 기능 C를 관리자(Root) 계정으로 테스트	5. 기능 B를 사용자(User) 계정으로 테스트
6. 기능 C를 사용자(User) 계정으로 테스트	6. 기능 C를 사용자(User) 계정으로 테스트

---

---

TC-template-20240510.xlsx

0.02MB