TC(Test Case)는 어떤 기준으로 작성하나요?

TC를 작성할 때 당연하게 생각했던 것을 말로 해보려니까 풀어내지 못하는 것 같아서 정리 겸 TC의 작성 방식을 한번 서술해 보려고 합니다. 현업에서 느꼈던 부분을 개인 정리 겸 하나의 포스팅으로 작성해 보겠습니다 :)

 

안녕하세요. 수비입니다 :) 

이번엔 자동화가 아닌 매뉴얼 QA로 업무 중 고민했던 사항인 TC의 작성 기준에 대한 개인적인 생각을 정리해보려고 합니다.

 

테스트 케이스를 작성하는 방식은 개개인마다, 경험 기반으로, 고정된 양식 기준으로 등등 다양한 기준이 있을텐데요.

제가 TC 작성 중 고민했던 부분과 너는 어떻게 TC를 짜고 있어?라는 질문을 받았을 때 무의식처럼 그냥 손 가는 대로..? 당연하다고 생각하며 작성했던 부분들을 정리하기 위해 글을 써보려고 합니다.

 

이번 포스팅의 주제는 2가지로 선정하였고, 아래와 같습니다.

 

1. TC의 양은 많은 것이 좋을까? 적은 것이 좋을까?

 

2. 어떤 기준으로 어떤 것을 테스트하려는 TC를 작성하는지?

 

더 많은 이야기가 있을 수 있으나, 이번 포스팅에는 2가지 주제로 제 생각을 정리해 보겠습니다 😀

 

---

1. TC의 양은 많은 것이 좋을까? 적은 것이 좋을까?

QA 관련 커뮤니티에서 다양한 이야기들을 봤을 때 가장 많이 봤던 질의응답이 있었습니다.

• 담당하는 제품에 TC를 몇 개나 만드셨어요??
• 테스트 기간에는 하루 TC 몇 개 정도 진행하세요?

첫 질문인 "담당하는 제품에 TC를 몇 개나 만드셨어요??" 어떤 분은 "TC는 제품 하나에 1만 개 정도 작성했었어요!"라고 하시는 분들도 있고, "1천 개 정도로 관리하는 것 같아요!"라고 하시는 분도 있었습니다.

 

이는 제품 규모에 따라 TC규모가 달라지는 것은 분명하기 때문에 TC가 많다? 적다?를 판단하기엔 어려운 답변일 수 있습니다.

 

그럼 2번째 질문인 "테스트 기간에는 하루 TC 몇 개 정도 진행하세요?"를 질문하는 경우 답변은 "하루에 100개 정도 하는 것 같아요!" 혹은 "하루에 6~700개는 처리하는 것 같은데요?"라는 답변을 종종 본 적이 있습니다.

 

이 두 가지 질문을 종합했을 때 얼마나 TC를 분리해서 작성했는지, 축약해서 작성했는지 대략 파악이 가능할 것입니다.

하나의 예시로 TC 1만 개를 가지고 있는 분의 TC를 구경해 본 적이 있는데 정말 상세한 부분까지 쪼갠 것을 확인할 수 있었습니다. 바로 기억나는 TC가 있었는데 아래와 같습니다.

• 키보드 방향키 "→" 키를 눌렀을 때 반응
• 키보드 방향키  "←" 키를 눌렀을 때 반응
• 키보드 방향키  "↑" 키를 눌렀을 때 반응
• 키보드 방향키  "↓" 키를 눌렀을 때 반응

이렇게 키보드 방향키 동작에 따른 결과 값을 TC마다 작성해 놓은 것을 본 적이 있습니다. 이렇게 분리했을 때 장점은 각 동작에 따른 기댓값이 명확하게 TC로 표현된다는 점입니다. 이 장점은 어디서 효과를 발휘할까요?

 

작성한 TC를 제품을 잘 알지 못하는 사람에게 줬을 때 TC를 작성한 QA의 의도대로 테스트를 진행한다는 큰 장점이 있습니다. 보통 QA, QC분들이 테스트를 진행하고 수행한 TC 목록을 고객사 혹은 PM에게 전달하는 경우가 있습니다.

 

그럼 이분들은 TC의 내용을 확인하면 어떤 동작을 테스트 했는지, 어떻게 동작하면 어떤 결괏값이 나오는지 명확하게 알 수 있습니다. 그래서 일손이 부족한 경우 TC를 그대로 전달하여 수행 비용 부담을 나눌 수 있죠.

 

그리고 작성된 TC의 양을 확인하는 경우 "이렇게나 많이 테스트를 진행했어? 훌륭한데?!"라는 의견을 듣는 경우가 있고, 양으로 압도하여 품질에 더욱 힘써 보이는 평가를 얻을 수 있습니다. 

 

 

정리해 보면 장점은 이런 것 같습니다.

• 테스트 동작에 대한 결과가 명확하여 테스트 신뢰도를 높일 수 있다.
• 누구든 수행할 수 있는 TC이기 때문에 업무 지원이나 제품을 잘 모르는 사람도 TC를 수행할 수 있다.
• TC를 분리한 만큼 양이 많아지기 때문에 테스트 수행 TC 양으로 품질을 증명할 수 있다.

 

 

하지만 단점은..? 제가 생각한 단점은 아래와 같습니다.

• 작성된 TC만큼 유지보수 비용이 많이 증가하여 관리가 어렵다
• 테스트 실행 시간이 증가한다.
• 비효율적인 테스트가 수행될 수 있다.

 

말 그대로, 제품 버전이 변경되어 기능 변경사항이 발생하는 경우 단순한 기능 변경이라도 수많은 TC를 수정해야 할 수 있습니다. 이는 곧 유지보수 비용 증가로 나타날 수 있습니다.

 

그리고 테스트양이 많은 만큼 매번 처리해야 할 테스트가 많아지고, 하나하나 다 확인을 해줘야 하는 부분이 생기다 보니 테스트 케이스 설계가 잘못된 경우 중복 케이스를 생성하거나 비효율적인 테스트 진행이 이뤄질 수 있습니다. 

 

그럼 반대로 테스트 케이스 양이 작은 경우는 어떨까요?

 

위에 작성한 키보드 테스트를 예시로 들면 아래처럼 표시할 수 있을 것 같습니다.

• 키보드 방향키 조작에 따른 정상 동작 확인

 

이렇게 표현했을 때 테스트 케이스의 장점은 효율적인 테스트가 가능해지고 테스터의 역량에 따라 새로운 결함을 확인할 수 있습니다. 테스트를 수행하는 것은 사람이기 때문에 코딩처럼 명확하게 설명하지 않아도 이런 기능이 동작할 것이다를 알 수 있겠죠?

 

그리고 이전에 설명했던 4개의 TC가 1개의 TC로 표현되었기 때문에 테스트 실행 속도도 빠르게 진행될 것입니다. 당연히 유지보수도 쉬워지겠죠.

 

정리해 보면 테스트 케이스 양이 적을 경우 장점은 아래와 같습니다.

 

• 효율적인 테스트 수행이 가능하고 창의적인 테스트가 가능하다.
• 기능 변경에 따른 TC 유지보수가 상대적으로 쉽다.
• 테스트 전체 수행 속도가 빨라진다.

 

반대로 단점은 어떤 점이 있을까요??

• 테스터 역량에 맡기기 때문에 신뢰도가 낮아질 수 있다.
• 제품을 잘 알지 못하는 사람에게 TC를 전달하면 수행하기 어렵다.
• 되는 부분만 확인하고 넘긴다면 부족한 테스트를 진행할 수 있고, 릴리스 후 결함이 발견될 가능성이 있다.

 

테스트 케이스 양이 많아서 좋다! 양이 적어서 테스트가 부족하다!라고 판단하기보다는, 제품에 맞게 적절한 테스트 케이스 양을 수립하는 게 가장 좋을 것 같습니다. 물론 이런 양을 조절하기엔 어렵지만, 테스트 경험이 쌓이다 보면 어떤 부분까지 TC를 작성해야 할지 생각이 들 것입니다. 

 

저는 개인적으로 TC는 축약해서 작성하고 있습니다. 테스트를 제가 직접 하다보니 모든 기능에 대한 상세 설명을 쓰는것도 비용이 많이 들어가고, 기능 변경 시 유지보수 비용도 만만치 않았기 때문입니다.

 

그리고 너무 상세한 범위로 작성하지 않아서 오히려 결함을 발견한 경우도 종종 있었기에 축약해서 TC를 작성하고 있습니다. TC 1개에 10분 이상 걸리는 경우도 있지만요.. ㅠ

 

물론, 회사 내부 규칙이 있다면 위에 설명보다 가장 먼저 반영되어야 하겠죠?! 테스터를 누가 할 것인지 확인하고, 테스터의 역량에 따라 TC의 세분화를 진행하는 것이 가장 좋을 것 같습니다.

 

---

 

2. 어떤 기준으로 어떤 것을 테스트하려는 TC를 작성하는지?

 

TC를 작성할 때 어떤 기준으로 작성을 할까요?

 

너무나 당연하게도 제품 기획 문서를 확인하고 관련 기능에 대한 TC를 작성할 것입니다.

 

그럼 어떻게 작성하나요?

 

저는 이 질문을 받아본 적이 있었는데, 어떻게..? 하던 대로! 유효성 검사를 진행하고... 음... 기능 정상 동작을 확인한다?라고 말한 적이 있었습니다.

 

뭔가 나만의 기준은 명확하게 있긴 한데 이것을 설명하기가 어려웠죠.. 그래서 한번 정리해보려고 합니다.

 

1. 입출력 기능은 정상 동작, 네거티브 테스트, 경계값 테스트

입출력 기능은 단순히 말하면 텍스트 필드 값에 들어가는 값에 대한 테스트입니다.

예를 들면 구글 계정을 생성하는 화면을 예시로 들어보겠습니다.

"성", "이름" 텍스트 필드가 있으면 이 항목에 대한 테스트 케이스를 작성해야 합니다.

위 화면에 대한 TC는 대략적으로 아래처럼 작성할 것 같습니다.

• 정상 동작 테스트
  • "성", "이름"에 값이 정상 데이터를 입력하고 다음 버튼 클릭
• 네거티브 테스트
  • 값을 입력하지 않고 다음 버튼 클릭
  • "성"만 입력하고 다음 버튼 클릭
  • 특수문자를 입력하고 다음 버튼 클릭
  • 텍스트 필드에 들어갈 수 있는 값을 초과하여 입력 시도
• 경계값 테스트
  • 일 항목에 31일을 초과한 데이터 입력
  • 연 항목에 현재 연도를 초과한 데이터 입력

대략적으로 입력 값에 대한 테스트 케이스를 작성한다면 이런 식으로 구분해서 작성할 것 같습니다.

물론 제목만 적은 것이라 TC 내용은 조금 더 디테일하게 작성해야겠죠..?

 

 

2. 동작 기능은 결정 테이블, 상태 전이, 유스케이스 테스트

동작 기능의 TC 작성 방식은 구분해서 예시를 들어보겠습니다.

• 결정 테이블
  • 네이버 스토어에서 "쇼핑 베스트", "몽클레어패딩" 항목을 클릭했을 때 관련 데이터 출력 여부 확인
  • 필터를 적용했을 때 데이터에 맞게 정상 표시되는지 여부 확인

 

 

상태 전이와 유스케이스 사례는 ATM 기기 화면을 예시로 작성해 보겠습니다.

 

• 상태 전이
  • ATM 기기 사용 시 각 버튼 클릭 시 안내된 문구에 관련된 기능이 출력되는지 확인
  • 화면 확대 기능을 클릭 시 UI가 확대되어 표시되는지 확인

 

• 유스케이스 테스트
  • 고객이 다른 은행으로 정상 입금하는 시나리오
  • 고객이 공과금 납부를 정상적으로 진행하는 시나리오

 

유스케이스 테스트는 실제 사용자의 동작과 시스템의 반응을 기반으로 작성한 것이기 때문에 상태 전이 케이스를 조립해서 하나의 시나리오로 작성할 수 있습니다. 

 

정말 간단하게 구분해 봤지만, 디테일하게 들어간다면 상세한 TC가 다수 생성되겠죠..?

 

 

3. 탐색적 테스트는 필수! 내 맘대로 써봐도 되겠어? 막아보시던지!

 

테스트 케이스를 잘 작성해서 모든 케이스를 수행했다면 테스트가 잘 수행되었다고 생각할 수 있을까요..? 물론 테스트 설계를 잘해두고 TC를 많이 작성해 뒀다면 가능한 부분입니다.

 

하지만 저는 업무를 진행할 때 항상 마지막 혹은 테스트케이스 수행 도중 탐색적 테스트를 섞어가며 진행합니다. 기획 문서를 확인하고 테스트 케이스를 잘 작성했지만, 막상 화면을 확인해 보니 다르게 동작한다면 어떤 반응을 이뤄질지 궁금하거든요!

 

저는 제품을 사용하는 사용자는 절대 개발자나 기획자의 의도대로 사용하지 않는다는 생각을 늘 가지고 있습니다.

 

QA 관련 가장 유명한 이미지처럼 QA나 제품을 사용하는 사용자는 기획, 개발 내용대로 수행해주지 않습니다. 

단순한 예로 스마트폰을 구매하면 설명서를 보는 사람보다 안보는 사람이 더 많지 않나요..?

 

그만큼 자유롭게 사용하는 사용자의 동작을 예상하여 정상 동작을 할 수 있게 가이드해주는지 확인하는 것도 가장 큰 항목입니다.

 

사용자가 데이터를 입력하지 않은 상태로 동작 버튼을 눌렀을 때 적절한 안내 문구가 출력되어 사용자의 정상 동작을 유도하는지 확인해야 합니다.

어찌 보면 네거티브 테스트의 자유도 높은 테스트라고 할 수도 있을 것 같네요!

 

그래서 테스터 역량에 따라 품질 검사가 다를 수 있지만 꼭 해야 한다고 생각하는 탐색적 테스트입니다 :)

 

---

 

간단하게 내용 정리만 하려고 했는데 생각보다 길어졌네요 😥

 

QA 오프라인 모임을 다녀왔더니 미뤄뒀던 블로그 주제가 생각나서 정리 겸 작성해 봤습니다!

 

내용에 대한 다른 의견이 있으면 댓글로 달아주시면 감사하겠습니다 🤩

 

오늘도 좋은 하루 보내세요!!