테스트 케이스(Test Case)?
예상 결과를 확인하기 위해 특정 작업 또는 조건 집합에서 응용 프로그램의 기능을 측정하는 데 사용되는 시나리오이다. 즉 테스트 케이스는 소프트웨어 애플리케이션의 기능을 인증하기 위해 실행되는 일련의 작업이다.
-
명세 기반 테스트의 설계 산출물로 설계된 입력값, 실행 조건, 기대 결과로 구성되어 있는 테스트 항목의 명세서를 의미한다.
-
테스트 케이스의 목적은 기능 누락 방지이다.
Test Case는 왜 필요할까?
서비스의 모델, 유형 등에 따라 어떤 서비스는 온라인 이외의 영역, 즉 오프라인에서 가치가 제공되고 운영되기도 한다. 이 경우 사람이 문제를 해결하고, 이슈에 대응 할 수 있다. 그러나 대부분은 온라인에서 시작해서 온라인에서 마무리된다.
물론 기능 구현과 구동이 문제 해결과 가치 제공을 100% 보장하지는 않는다. 기획에 의해 구현된 기능은 실제 사용되기 전까지는 어디가 문제가 있을지 모르고 그 기획과 가설이 성공했는지 틀렸는지를 검증하려면 그 기획이 의도대로 온전하게 구현되어 있어야 한다.
QA와 Test Case 작성은 여러가지 가설이 제대로 구현되어있는지 확인하기 위한 최소한의 과정과 방법이다. 이를 문제 해결의 관점에서 보면 Test Case는 사용자에게 제공하기로 한 가치가 제대로 제공될 수 있는지를 확인하기 위해 작성하는 설계이다
Test Case 작성법
Test Case의 작성법은 각 회사마다 템플릿이 다르고 프레임 워크에 달라서 공통적인 사항만 정리해보는 방법을 공부해보자.
-
기획서를 보고 기획에 따라 발생 가능한 모든 시나리오/플로우를 Depth를 나눠 구조화한다.
-
해당 시나리오에서 기대하는 결과를 누가봐도 명확한 문장으로 기록한다. 이부분은 기획자/PM 외에도 제 3자가 보기에 QA를 함께 진행할 때에, 어디서 무엇을 어떻게 테스트하고, 그 결과가 어때야 하는지를 명확하게 이해시켜줘야한다.
-
QA를 진행한 사람과 진행 환경을 기록하기.
QA를 진행하는 동안 이슈를 확인한 개발자가 누구에게 상황을 공유하면 될지 확인하고 해당 이슈를 각인시키기 위함이다. -
진행 결과 기록하기
진행절차대로 진행해 기대하는 결과가 잘이루어지면 통과 P 기획의도와 다른 이슈가 생긴다면 F 미구현과 아예 테스트 를 못하는 경우에는 B로 통일한다
아래에는 테스트케이스 작성법을 알기 전에 프로젝트를 진행하면서 작성했던 일종의 요구사항을 정의해 둔것이다 .
이렇게 해두면 두루뭉실하게 유효성 검사를 진행한 것을 알수가 있었다. 이렇게 해두면 각 분기마다 정확한 테스트를 할 수 없고 뭉퉁뭉퉁하게 검사를 진행 할 수 있었다. 아래에는 테스트케이스 작성법을 공부하면서 작성해보았던 회원가입하기 테스트 케이스를 작성해 보았다.
위 사진을 보면 각 단계마다 Depth를 나누어 심층적으로 테스트케이스를 작성한 것을 볼 수 있다. 확실히 이런식으로 테스트케이스를 작성하여 진행하면 확실히 품질 개선을 할수 있다는 생각이 들었다.
Test Case를 통한 QA 의 장점
장점
-
눈으로 훑으며 보는것보다 하나하나 기획의도에 맞춰 세밀하게 검수 할 수 있다.
-
일반적인 플로우, 경로에서 발생하지 않는 예외사항에 대해서도 잊지 않고 검수할 수 있다.
-
QA를 진행한 검수자와 개발자 사이에 소통이 더욱 명확해진다.
어떤 경우에 어떤 유형의 유저가 어떤 행동을 했을 때 발생하는 이슈라고 소통하거나 Tc 몇행 혹은 몇번 확인해달라고 확실하게 무엇을 가르키는지 확인할 수 있다.
- 프로젝트 관리 관점에서 통과, 보류, 실패 를 한눈에 확인함으로 서 Qa 진척도를 확인할 수 있다 .
단점
-
기능, 서비스 흐름, 로직/ 정책 단위이기 때문에 디자인 검수와는 별개이고 기획~개발 사이의 검수는 TC를 통해 확인되지만 디자인과 개발 사이의 검수는 다시 진행해야한다.
-
결국 사람이 작성하는 문서이므로 담당자, 기획자가 아는 만큼 작성될 수 가 있다. 즉 결국에 사람이기 때문에 놓치는 결함이 발생할 수 있다.
🤷♂️ 좋은 테스트 케이스는?
- 정확성(Accurate): 테스트 케이스의 서술 부분에 테스트하겠다고 쓴 것을 테스트한다.
- 경제성(Economical): 테스트 케이스 목적을 위해 꼭 필요한 단계/필드 만을 가진다.
- 반복성, 자립형(Repeatable, self-standing): 테스트 케이스가 잘 제어된 실험이다. 그걸 누가 테스트하든지 간에 매번 동일한 결과가 나온다.
- 적합성(Appropriate): 테스트 케이스가 테스터와 테스트 환경에 알맞아야 한다. 어떤 테스트 케이스가 이론적으로는 견고하다 해도 테스터 중 누구도 갖고 있지 않은 기술을 요구한다면 그게 사용될 수 없음
- 추적성(Traceable): 해당 테스트 케이스가 어떤 요구사항을 테스팅하고 있는지 알아야 한다.
- 자기 세정(Self-cleaning):스스로 회복. 테스트 환경을 테스트 이전 상태로 스스로 되돌려 놓는다.
🤦♂️ 좋지 않은 테스트 케이스
- 하나의 케이스에 많은 내용을 담으려 하는 경우
- 기대 결과가 명확하지 않은 경우 (실패 결과인지? 통과 결과인지?)
- 제품의 업데이트에 맞게 기능, 명칭 등을 추가/삭제가 되지 않는 경우
- 누락이 없는 TC를 만들기 위해 불필요한 케이스까지 추가가 되는 경우
테스트 케이스를 공부하면서 더 나은 테스트 케이스를 만드는 방법을 생각하게 되었다.
내가 생각하는 좋은 테스트 케이스는 다른사람이 내가 작성한 TC를 보았을때 한눈에 이해 되는 그런 TC를 만들어야 된다고 생각이 들었다.
다시말해 간단 명료한 문장으로 작성하고 애매한 부분들이 없도록 입력과 예상 결과를 구체적으로 작성해야한다고 생각이 들었다.
