테스트 구현이란, 보통 테스트케이스를 작성하는 것을 의미합니다.

---

4. Test Implement - 테스트 구현

테스트 구현단계에서는, 설계한 테스트 케이스들을 바탕으로 좀 더 깊고 꼼꼼하게 테스트 케이스를 정리하며, 실행순서나 순서의 정의, 테스트 데이터의 준비 등을 진행합니다.

이 단계에서 많이 쓰이는 용어는 다음과 같습니다.

용어	의미
테스트 케이스(Test Case)	어떤 테스트 목적, 조건을 테스트하기 위한 입력값, 실행 전의 상태, 기대 결과, 실행 후의 상태 등을 기재한 것. 하나의 테스트 항목.
테스트 스크립트(Test Script)	테스트 케이스의 실행을 위한 어떠한 지시서, 혹은 자동 테스트에서 사용되는 테스트 코드들
테스트 스위트(Test Suite)	테스트케이스의 집합체. 일반적으로는 시나리오 별로 구분되거나 특정 feature, version별로 나누기도 합니다.

테스트 구현단계에서 고려해야할 사항들은 아래와 같습니다.

테스트 케이스를 작성하고, 우선순위를 결정한다.

테스트 설계단계에서 여러가지 카테고리 별 테스트항목이나 조건들이 어느정도 도출될 것 입니다. 이 테스트 목적, 조건에 맞추어 구체적인 테스트 케이스를 작성해나갑니다.
테스트케이스 작성시에는 확인해야할 기능, 메뉴들에 따라 대분류/중분류/소분류 등으로 잘개 쪼개가며 대상 테스트 아이템을 기재하기 편하게 분류합니다.
또한 테스트를 위해 테스트 데이터를 준비합니다. 이 때 테스트 데이터란, 최대한 실제 환경과 가깝게 데이터를 구성하는 것이 좋으며, 비정상패턴을 확인하기 위한 이상(abnormal)데이터를 준비하기도 합니다. 준비하는 방법은 여러가지가 있겠으나, 직접 테스트 대상을 미리 조작하여 만들거나, 개발팀에 의뢰하여 준비하도록 합니다.

또한, 케이스를 작성하는 중에, 적어도 아래 3가지정도는 정의, 기재되어야할 것입니다.

• 테스트를 하기 위한 전제조건, 전제 상태
• 입력값
• 예상되는 기대치, 기대되는 출력값, 테스트 후의 상태

물론 경우에 따라서는 이 세가지 전부 정의할 필요는 없을 것입니다. 대체적으로 위 3가지 정도가 공통적으로 정의되더라~ 라는 의미입니다.

테스트 케이스 작성 시에도 몇가지 고려되어야할 사항이 있습니다.

1. 전제조건 및 입력값의 정리, 그룹핑

특정 케이스들은 경우에 따라서 같은 전제조건, 입력값이 필요한 케이스들이 있습니다. 이 것은 즉, 어떤 특정 케이스의 조건을 만족한다면, 다른 케이스들도 자연스럽게 확인이 된다거나, 확인이 쉬워진다는 것입니다. 때문에 테스트케이스를 작성해나가면서 전제조건들을 추려내는 것이 필요합니다.

2. 테스트 순서의 정리

테스트 케이스들을 작성하면서, 특정 테스트케이스를 확인하면 자연스럽게 확인되는 케이스라던지, 반대로 특정 테스트 케이스를 확인하면, 확인할 수 없게되는 테스트 케이스들이 있습니다. 이런 것들을 정리하여 순서를 고려해야할 것입니다.

3. 애매한 표현의 확인

좋은 테스트케이스의 기준은, 실시자가 계속 바뀌어도, 작성자가 의도한 결과가 똑같이 나오는 것입니다. 테스트케이스는 반드시 작성한사람이 실시하는 것은 아닙니다. 오히려 작성자와 실시자가 다른 경우가 더 많습니다. 이때 조작의 내용이 애매한 뜻을 함유하여 실시자의 판단이 들어가게 되는 경우면 좋지 않습니다. 테스트 케이스에 따라 같은 조작을 하면, 테스트 실시자가 바뀌어도 같은 결과가 계속 나와야 합니다.

4. 이상계열(abnormal) 패턴의 확인

간혹 테스트케이스들중에서는 정상패턴만 많이 작성되어있고, 이상계열 패턴이 적은 경우도 있습니다. 실제 서비스 운용중에는 어떠한 일이 일어날지 아무도 모릅니다. 테스트 설계단계에서 이미 고려되고, 테스트 케이스 구현단계에서 작성되어야 합니다.

5. 불필요한 테스트 패턴

설계 후 테스트케이스 들을 작성함에 있어서, 불필요한 테스트 케이스들이 생길 수 있습니다. 이 때 설계 단계에서 잘못된 것은 없는지 체크해보고, 줄일 수 있는 케이스가 있다면 과감하게 줄여나갑니다.

그 외 고려되어야할 내용들

1. 정상 패턴과 비정상 패턴

정상패턴 : 해당 대상이 상정하고 있는 입력값에 대해 기대한 대로 출력값이 만들어지는 지 확인한다.
비정상패턴 : 해당 대상이 상정하고있지 않은 입력값에 대해 제대로 대응하고 있는지 확인한다.

2. 결함이 있을법한 테스트 방법의 추측

1. 최대값, 최소값

   • 입력가능한 문자의 최대값, 최소값이 있는 경우, 최소값보다 더 작은 경우, 최대값보다 더 큰 경우 등을 확인합니다.

2. 소수점

   • 소수점 아랫자리 표기에 관해, 몇자리 가능한지 확인합니다.

3. 빈 문자열, 스페이스, 0, null

   • 데이터가 존재하지 않은 경우나 null을 참조하는 경우도 고려합니다.

4. 입력을 의도하지 않는 문자열

   • 예를 들어 이름이 입력되어야하는 곳에 특수기호를 넣어본다던지 등의 패턴도 고려합니다.

5. 윤년, 존재하지 않는 날짜, 시간

   • 윤년의 처리에 문제없는지, 존재하지 않는 날짜 혹은 시간을 입력하였을 때 제대로 핸들링되는지 확인합니다.

위와 같은 내용들은 테스트 설계시에도 고려되면 좋으나, 테스트 분석/설계 단계에서는 테스트 대상들을 추려내고 정상적인 테스트 케이스를 고려하는 경우가 많습니다. 때문에 좀 더 세부적인 것들은 테스트 구현단계에서 진행되어도 문제없습니다.

테스트 스위트(Test suite)를 만든다.

이 은 비슷한 기능끼리, 혹은 여러 프로덕트들이 동시 진행되는 프로젝트에서, 프로덕트 별로 테스트 케이스들을 묶는 역할을 합니다. 특별한 이유가 없다면, 굳이 하나의 기능을 테스트하는데 다른 여러 기능과 테스트 순서를 왔다갔다하며 테스트하는 것은 불필요할 것 입니다.

테스트 베이스(Test base)와 테스트 케이스간의 Tracability를 확인한다.

Test base란, 테스트케이스를 도출하게된 요구사항 정의서, 기획서, 화면설계서 등을 말합니다.

테스트 베이스와 테스트 케이스간의 추적가능성을 확인합니다. 이 것은 추후 테스트결과 확인 시에 원하는 Spec을 검증했는지를 위한 것이기도 하며, 추후 테스트단계에서 피치못할 이유로 기획, Spec이 변경되었을 경우, 테스트 케이스 또한 수정하기 쉽도록 하기 위함입니다.
보통은 테스트케이스의 어느 한 쪽에, 참고했던 Epic, 요구사항 정의서, 기획서, 화면설계서 등을 첨부하거나, 링크를 걸어놓습니다.