<8> 좋은 TC란 무엇일까?
QA for Beginners
좋은 TC란 무엇일까?
앞서 TC를 작성하는 데 정해진 형식은 없지만, 처음 테스트를 수행하는 사람도 이해하기 쉽게 작성해야 하며, 작성을 완료한 뒤에는 가급적 리뷰를 하는 것이 좋다고 언급했었다. 그렇다면 잘 쓴 TC의 기준이 있을까? 좋은 Test Case란 무엇일까?
우선 TC의 정의와 목적을 한번 더 정리해 보자.
TC는 명세 기반 테스트의 설계 산출물로, 설계된 입력값, 실행 조건, 기대 결과로 구성되어 있는 테스트 항목의 명세서를 의미한다.
이 산출물에는 정해진 양식이 없어서 Excel에서부터 Jira나 Testrail과 같은 전용 툴에 이르기까지 다양한 플랫폼을 활용하여 만들어지게 된다.
TC를 쓰는 근본적인 목적은 기능 누락 방지를 위해서이다. 기존 기능 3개와 신규 기능 7개가 검증 영역이라면, TC와 같은 형태로 명세하지 않는 이상 그 많은 범위를 한 부분도 빠뜨리지 않고 외워서 검증하기에는 사람의 기억력에 한계가 있기 때문이다.
좋은 TC를 작성하는 방법
그렇다면 어떻게 TC를 작성할까? 처음 TC를 써보면 감이 잡히지 않을 것이다. 왜냐하면
첫째, 구체적으로 써야 한다는 기준이 모호하기 때문이다. 나는 ’버튼을 클릭한다‘ 정도만 명세해도 어떤 버튼을 클릭해야 가격 순으로 정렬되는 것인지 이해했는데, 동료는 버튼이 왼쪽의 버튼을 말하는 것인지, 오른쪽의 버튼을 말하는 것인지, 또는 버튼을 클릭해서 노출되는 팝업에 있는 버튼을 말하는 것인지를 이해하지 못할 수 있기 때문이다.
둘째, 저마다의 작성 스타일이 다르기 때문에 동료와 같은 부분에 대한 케이스를 작성했어도 서로 다른 케이스를 명세한 것으로 오해할 수 있다. 보통 지칭하는 용어를 다르게 기술하거나, TC의 구조를 다르게 작성할 때 발생한다. 예를 들어 나는 모바일에서의 클릭 동작은 선택, PC에서의 클릭 동작은 클릭으로 정의했는데, 동료는 Select Box에서 여러 항목들을 고를 수 있는 경우에만 선택이라고 정의하고 그 외의 클릭 동작은 모두 클릭으로 정의했을 경우이다.
보통은 새로운 팀에 합류하면 해당 팀의 동료들이 팀 내에서 정의한 TC 작성 규칙에 대해 설명해 줄 것이다. 그러나 서로 간의 인식이 맞지 않는 상황이라면 다음의 내용들을 빠르게 통일시켜야 한다. 유관 부서들을 포함한 프로젝트 규모에서 사용하는 용어 (특히 Navigation Bar (GNB, LNB 등), 버튼, 마우스 오버/호버와 같은 UI 관련)들을 통일한 뒤, QA 팀 내에서 사용하는 용어(특히 노출, 클릭과 같은 동작 관련)들을 통일하는 순서로 용어들을 통일하는 것이 하나의 효율적인 방법이 될 수 있다.
더 좋은 테스트 케이스를 작성하는 방법(How to Write Better Test Cases)의 저자 Dianne L. Runnels는 좋은 TC란 다음의 품질 표준을 충족해야 한다고 말한다.
정확성(Accurate): 테스트 케이스의 서술 부분에 테스트하겠다고 쓴 것을 테스트한다.
경제성(Economical): 테스트 케이스 목적을 위해 꼭 필요한 단계/필드 만을 가진다.
반복성, 자립형(Repeatable, self-standing): 테스트 케이스가 잘 제어된 실험이다. 그걸 누가 테스트 하든지 간에 매번 동일한 결과가 나온다.
적합성(Appropriate): 테스트 케이스가 테스터와 테스트 환경에 알맞아야 한다. 어떤 테스트 케이스가 이론적으로는 견고하다 해도 테스터 중 누구도 갖고 있지 않은 기술을 요구한다면 사용될 수 없다.
추적성(Traceable): 해당 테스트 케이스가 어떤 요구사항을 테스팅하고 있는지 알아야 한다.
자기 세정(Self-cleaning): 스스로 회복. 테스트 환경을 테스트 이전 상태로 스스로 되돌려 놓는다.
이들은 TC를 많이 작성하다 보면 자연스럽게 지켜지게 될 것이다. 몇가지를 더 첨언하자면
하나의 케이스를 확인하는 데 있어 케이스를 너무 길게 쓰지 않도록 주의하라. 확인 과정이 6개를 초과한다면 케이스를 나눠서 3 ~ 4개의 확인 과정이 하나의 케이스를 확인하게끔 작성하는 것이 좋으며, 이상적으로는 동작 하나당 한 개의 케이스로 1:1 매칭되게끔 작성하는 것이 좋다. 만약 로그인을 확인하는 과정에서 ID 입력과 PW 입력을 하나의 케이스로 작성했을 경우, 둘 중 한쪽만 결함이 발견되어도 케이스를 Failed 처리해야 하기 때문에 자칫하면 이것이 ID와 PW 입력 과정 모두 결함이 있는 것인지 혼동을 야기할 수 있기 때문이다.
케이스를 확인하는 단계, 즉 확인 과정을 일부 생략하지 마라. 번거롭더라도 모두 작성해야 한다. 예를 들어 회원 가입을 할 때 회원 가입이 완료되었다는 팝업을 확인해야 최종 가입이 완료된다고 하자. 그런데 만약 이 팝업이 노출되는 경우 또는 팝업을 닫는 경우를 생략한 채 회원 가입이 완료된다는 기대 결과만을 명시했는데, 실제로 테스트해 보니 팝업의 문구가 이상하거나, 확인 버튼은 잘 동작하는데 닫기 버튼을 누르면 아무 반응이 없어 가입이 완료되지 않는다거나 등의 결함이 발견되었다면 해당 케이스에 대한 이슈 추적(Jira를 예로 들면, 발견한 결함(이슈)을 이슈 리포트로 작성하게 되면 ABCD-123과 같이 고유 번호가 부여된 티켓으로 등록된다)을 할 때 애로 사항이 발생할 수 있다.
기대 결과를 명확히 명시하라. 버튼이 노출된다는 케이스에 이어서 버튼을 클릭하는 과정을 작성할 때 이 버튼이 활성화 상태 또는 비활성화 상태로 노출되는지, 클릭이 가능한 상태로 노출되는지가 명시되지 않으면 테스트 수행 관점에서도, 이슈 관리 관점에서도 애로 사항이 발생할 수 있다.
동작을 수행하는 주체가 누구인지 명확히 명시하라. 특히 사전 조건을 작성해야 하는 경우, 내가 직접 초기화를 시켜놓아야 하는지 또는 이전 케이스를 수행한 결과로 시스템 자체적인 초기화가 일어나는지 명시하지 않으면 테스터의 오해를 야기하여 불필요한 동작을 수행하느라 리소스를 낭비하게 될 수 있다.
TC 유지보수성을 높은 우선순위에 두어라. 여러 확인 과정을 거쳐서 확인 가능한 케이스가 있다고 하자. 각각의 개별 확인 과정들이 기획 변경으로 인해 추가 기능이 생기거나, 동작의 변동 가능성이 발생할 수 있음을 예상하지 못하고 아주 딱 맞는 케이스를 작성할 경우 추후에 발생하는 기획 변경으로 인해 번거로운 보수 과정을 거쳐야 할 수 있다. 또는 버전 별로 TC를 작성하다가 갑자기 전체 기능을 점검하는 Full TC Regression을 수행해야 할 경우, 개별 버전들의 내용을 모두 취합한 다음 가장 최신의 기획 내용으로 수정해야 하는 큰 리소스 소요가 발생할 수 있다. 또는 새로 투입된 동료의 이해도를 고려하지 못한 채 불친절한 TC를 작성한 바람에 TC 설명과 수정을 해야만 하는 상황에 직면할 수 있다.
좋은 TC를 쓴다는 것은 어쩌면 좋은 코드를 짜는 것과 비슷하다. 정확한 용어로 명확한 동작과 기대 결과를 명세하되, 유지보수성이 용이하게 작성한다면 좋은 TC라고 할 수 있다.
이것이 아직 어렵다면, 적어도 당신의 동료들이 당신의 TC만으로도 혼자서 90% 이상 테스트를 수행할 수 있도록 작성해 보자.
시간 투자만큼 중요한 것은 없다.
많이 쓰고, 많이 리뷰하고, 많이 참고하며 좋은 TC에 대해 고민한다면 어느 순간 어떤 프로젝트에 참여해도 좋은 TC를 쓰고 있는 자신을 발견할 수 있을 것이다.
