테스트 설계

테스트 설계란?

테스트를 "설계"한다는 것 무엇일까요? 물건을 만들어 내기 위해 설계가 필요한 것은 의심의 여지가 없는 일입니다. 하지만 테스트란 행위에 대해서 설계를 한다는 것은 간단히 이해하기에는 어려운 일일지도 모르겠습니다.

완성된 프로그램을 실행해보고 결과를 확인하는 것만이 테스트가 아닙니다.

이것은 테스트의 일부분으로 테스트란 실행시켜보는 것 뿐만 아니라, 요구사항과 설계를 충족시키는지 "고객 관점에서의 검증"을 하는 것입니다.

그러기 위해서는 "무엇을 어떻게 확인해야만 하는가", "기대 결과는 어떠해야 하는가"를 확인해서 확정해둘 필요가 있습니다. 

이것이 테스트를 "설계"하는 것입니다.

왜 하지?

그럼 테스트 설계는 무엇을 위해서 하는 것일까요?

- 누가 하더라도 동일하게 실행되도록

- 누가 하더라도 동일한 결과를 얻을 수 있도록

- 누가 하더라도 결과가 P/F인지 동일한 기준으로 판단할 수 있도록

즉, 누가 어떤 대상에 대해 테스트를 하더라도 그대로 재현 가능하고 객관적으로 판단할 수 있도록 하는 것입니다.

뭘 하면 되지?

그렇다면 테스트 설계란 도대체 뭘 하면 되는 것일까요?

- SW는 사용자 needs를 실현하기 위한 "기능"의 집합체로, 기능 내용은 설계서에 기술되어 있음

- 블랙박스 테스트 실행을 위해서는 SW의 모든 기능은 "입력조건" → "처리" → "출력결과" 모델로 설명 가능

- "처리"의 Pass는 "입력조건"에 대한 "출력결과"가 Pass인 것으로 확인 가능

- "출력결과"는 각각의 특성에 맞게 평가를 위한 서로 다른 관점이 존재

즉, 테스트를 설계하는 것은 "기능"과 "관점"의 조합입니다.

다음 간단한 예시에서 기능과 관점에 대한 개념을 파악할 수 있습니다.

테스트 설계  순서

테스트 설계 순서

1. 테스트 조건 식별

식별해야 하는 모든 기능과 동작을 설계서(요구사항, 시나리오, 기능명세서 등)에서 추출하고, 그 기능과 동작 확인에 필요한 관점을 설정합니다.

산출물 예시로 "테스트 조건 리스트"를 작성한 예입니다.

2. 조건분기와 패턴 추출

조건을 좌우하는 요인 = "인자"와 인자 별 설정 단계(취할 값) = "레벨"을 식별하고 인자와 레벨을 조합하여 패턴을 만듭니다.

산출물로 "결정 테이블"을 작성합니다.

실제 현장에서는 이것뿐만 아니라 테스트 데이터나 베이시스를 도출하기 위한 테스트 환경 검토나 여러가지 산출물들에 대한 검토도 필요합니다.

테스트 설계 9가지 항목

그럼, 테스트 계획서에 꼭 들어가야 할 9가지 항목에 대해 설명하고 마치도록 하겠습니다.

1. 테스트 종류와 목적

테스트 목적을 명확히 하고, 이해관계자들이 테스트 계획서를 보고 "이번 테스트는 대체적으로 이런 내용의 테스트를 하는구나"라는 인식을 할 수 있도록 작성되면 됩니다.

2. 참고자료

테스트 계획을 세움에 있어 어떤 자료를 참고로 했는지를 기재합니다.

예를 들어, 기능 명세서나 화면 상태 전이도 등이 이에 해당합니다.

참고 자료를 기재함으로써 어떤 자료를 근거로 계획되었는지를 나타낼 수 있습니다.

3. 테스트 범위

가장 중요한 항목입니다.

테스트 범위가 명확하지 않으면 프로젝트 후반에 이해당사자들 간의 문제가 발생할 수 있습니다.

테스트 계획서를 작성한 테스트 담당자는 명확하게 작성했더라 하더라도, 개발팀이나 PM과의 인식 차이로 큰 문제로 발전하는 경우도 있습니다.

4. 테스트 depth

이 항목도 중요합니다.

테스트 범위와 마찬가지로, 서로의 인식 차이가 발생하기 쉬운 항목입니다.

이러한 인식 차이로 테스트 공수에 큰 영향을 미칠 수 있기 때문에 사전에(테스트 계획 시) 이해당사자간에 명확히 해 둘 필요가 있습니다.

5. 테스트 대상환경

테스트 계획 시 확정되는 경우가 드물어, 뒤로 미루다가 그대로 테스트 시작 시까지 잊어버리는 경우가 많은 항목입니다.

테스트 직전이 되어서야 "서버에 접속이 안되요", "기능 구현이 덜 되었어요" 등이 이 항목에 명기해 두지 않아 발생하기 쉬운 문제들입니다.

6. 테스트 입력항목

테스트 케이스를 실행할 때 테스터가 입력할 항목의 정의입니다.

테스트 시작 후에 "그 테스트는 어떤 환경에서 어떤 항목들을 테스트했나요?"라고 물었을 때 대답을 못하는 일이 없도록 기재가 필요한 항목은 사전에 미리미리 합의하여 정해두도록 합니다.

7. 테스트 판정기준

테스트 실행 시 판정에 사용할 기준을 정의합니다.

보통 "Pass" "Fail" 등으로 정의하기 쉬운데, "보류" "지연" "Skip"등 결과를 사용할 때에는, 서로 간 인식 차이가 발생하지 않도록 확실한 정의를 공유하는 것이 필요합니다.

또한 이슈 등급에 대해서도 각 등급에 대한 정의를 확실하게 하여 테스트 팀이 "S"급이라고 했는데 개발팀이 "B"급이라고 반발하는 일이 없도록 등급에 대한 정의도 필요합니다.

8. BTS(버그 트래킹 시스템)에서 사용할 항목

장애 분석 시 사용할 항목을 정의합니다.

BTS에서 입력하는 이러한 항목들은 추후에 분석 항목으로 사용합니다라고 정의(합의) 후 다른 분석하고 싶은 내용은 더 없는지 확인 및 합의하지 않은 항목으로 이해당사자를 곤란하게 하는 일이 없도록 합니다.

9. 진척관리지표

테스트 진척도 관리에 사용할 항목을 정의합니다.

이것도 BTS항목과 동일하게 사전에 합의하여 진행하도록 합니다. 사전에는 일정 기간 내에 등록된 이슈의 수정율로 진적관리를 하기로 합의했다가, 나중에 TC 검증 완료 항목 수로 테스트 진척율을 관리하겠다고 한다면 문제가 발생할 수 있습니다.

대규모 프로젝트/ 비교, 검증 테스트 / 그 외 프로젝트 QA에 대한 QA Service 지원 및 기타 관련 아웃소싱 업무가 필요한 경우 아래 연락처나 이메일로 연락 주시면 성실히 대응 하겠습니다. 

---

Contact US

Address

서울특별시 금천구 가산디지털1로 19 
대륭테크노타운 18차 20층

2018.12.27 | 지도 크게 보기 ©  NAVER Corp.

Phone
02-6190-7296

E-mail
qa_partner@infrawaretech.com

Homepage
http://infrawaretech-qa.tistory.com/