어떤 테스트 기법을 활용하여 테스트 케이스를 작성하는 것이 좋을까?(쇼핑몰 테스트 케이스 예시 파일 포함)

쇼핑몰 TestCase.xlsx

0.02MB

개요

웹 쇼핑몰 개발을 마친 후 모든 기능이 수행되는 것을 직접 동작해보며 확인해 보았지만, 본인은 소프트웨어 웹 개발이 처음이므로 놓친 부분이 분명 있을 것이라 판단 되었다. 이에 소프트웨어 테스팅 국제 표준에 따라 테스트를 진행하여 잘 개발된 소프트웨어인지 확인해 볼 필요성이 있다.

소프트웨어 테스팅 국제표준(ISO/IEC/IEEE 29119) 현황

TTA SW시험인증연구소에 따르면 소프트웨어 테스팅이 소프트웨어 개발 단계에서 매우 중요한 역할을 수행함에도 불구하고, 'ISO/IEC/IEEE 29119'가 제정되기 전까지 소프트웨어 테스팅에 대한 명시적 표준이 없었다. 그렇기에 표준 간의 모순적 내용, 중복 또는 누락된 내용들을 모두 정리한 통합된 국제 표준에 대한 필요성이 강하게 제기되었다. 그렇기에 2007년 5월 국제표준이 출판되었다.ISO/IEC/IEEE 29119의 최초 제안은 총 4개의 파트로 시작했으나, 여러 과정을 거쳐 2016년 7월에 최종국제표준안(Final Draft International Standard)이 완료되었다.

 

'검증 및 확인(V&V)' 활동 중 '동적 테스팅'에 대한 절차와 기법을 다루며, 정적 테스팅에 대해서는 간접적인 설명이나 참조만 제공한다. V&V 활동의 범주 내에서 동적 테스팅과 관련된 절차와 기법을 제공하지만, 특정 생명주기모델에만 한정된 내용을 제공하지 않는다. 오히려 고전적인 폭포수 모델 기반의 프로젝트에서부터 에자일 접근방법을 사용하는 프로젝트까지 두루 적용할 수 있는 표준을 제공하는 것이 이 표준의 목표이다.

 

파트 - 1(개념과 정의): 전체 시리즈에 대한 가이드를 제공
파트 - 2(테스트 프로세스): 테스트 프로세스에 관한 부분으로, 조직, 테스트 관리, 동적 테스트의 세 가지 수준의 다계층 프로세스 모델을 설명
파트 - 3(테스트 문서화): 테스트 문서의 견본과 예시를 제공해주는 부분
파트 - 4(테스트 기법): 소프트웨어 테스팅 기법에 관한 부분으로, 테스트 설계 및 구현 단계에서 활용할 수 있는 명세 기반 테스트 설계, 구조 기반 테스트 설계, 경험 기반 테스트 설계 기법을 제공
파트 - 4.5(키워드 주도 테스팅)

 

국제표준을 직접 살펴보는 것도 좋은 방법이지만, 오늘은 어떤 테스트 기법을 활용할지가 주요 주제이므로 유튜브 '와이즈와이어즈' 채널을 참고하여 고려사항들을 적으려고 한다.

2. 고려사항

• 업무에 형향을 미치는 수준
• 고객의 요구사항이 무엇인지
• 테스트를 통해 원하는 목표가 무엇인지
• 참고할 만한 문서가 있는지 -> 있다면 명세기반 기법, 부족하다면 경험 기반 기법
• 테스트의 지식 수준이 얼마나 되는지 -> 적다면 명세 기반 기법, 높다면 경험 기반 기법
• 시간과 예산 제약은 어떻게 되는지 -> 없다면 명시기반 기법, 많다면 경험 기반 기법

 

만약 테스트 지식 수준 및 소프트웨어의 내부 접근성이 높다면 구조 기반 테스트 기법

3. 테스트 케이스(TC) 기본항목

1) NO: 수행한 TC 수량 산출, TC 수, 수행율 산출(삭제될 경우 NO는 삭제)

 

2) TCID: TC의 유일한 ID로 무결성 보장, TC삭제 시 ID도 삭제,
테스트 대상 힌트(ex: order__01)

 

3) 분류체계: 대분류, 중분류, 소분류
메뉴트리 이용한 기준, 때에 따라 항목명 수정 가능

 

4) Priority: TC별 우선 순위, (high, medium, low or A, B, C etc.)
TC 작성 전 명확한 기준 제시 후 결정, 하나의 기준으로 결정

 

5) Test Description: TC에 대한 간단한 설명
잘못된 활용은 테스트 신뢰도에 영향, 간단하게 설명

 

6) Pre-Condition: 테스트 절차 수행 위해 필요한 환경

 

7) Test Step: TC 수행하기 위한 절차

 

8) Test data: TC 수행 시 필요한 데이터

 

9) Expected result: 테스트 명세에 표기되어 있는 해당 TC의 출력 값
구체적인 예상결과 작성, 결함의 추적성과 TC 유지보수

 

10) Actual Result: 예상 결과와 비교해 결정
Pass, Fail, N/A(Not available), N/T(Not Tested), 속성 값의 기준은 프로젝트 내에서 동일하게 유지

 

11) Taster: 테스트 수행한 인원의 정보

 

12) Test Date: 테스트 수행한 날짜

 

13) Defect ID: 결함관리 툴에서 생성된 결함 ID,

결함관리 툴 사용하지 않은 경우, 별도 결함 ID 입력, 결함, TC, 요구사항 간의 추적성 확보

 

14) Description: 결함의 상세한 내욕 혹은 특이사항 기입

 

추가적으로
테스트 버전, 수정버전, 수정날짜가 쓰일 수 있습니다.

Reference

https://www.tta.or.kr/data/androReport/ttaJnal/167-5-3.pdf

https://www.youtube.com/watch?v=gKn1huOrdrs&list=PL6uFGC24Yo2eMDpX2zYl5HrxqRR1WdWud&index=1

https://www.youtube.com/watch?v=E_hVdjEe-yk&list=PL6uFGC24Yo2eMDpX2zYl5HrxqRR1WdWud&index=7