[준비] 쉽게 작성하고 빠르게 수행할 수 있는 테스트 케이스(TC) 작성하는 방법 공유!!

오프닝: 내가 하는 일이 세상에서 가장 힘든 이유는?

세상에는 많은 일들이 있습니다. 일이라는 것이 누군가에게는 경제 활동이고, 누군가에게는 자아를 성찰하는 활동이고, 또 누군가에게는 그 무언가의 의미일 것으로 생각합니다. 저는 컴퓨터 정보학(입학할 때는 컴퓨터공학이었는데 졸업할 때 컴퓨터 정보학으로 개명됨)을 전공하고, 한 때, 소프트웨어 개발을 하려고 했던 사람입니다. 물론, 개발의 재미와 탐구. 가장 중요한 것은 성취감이었던 것 같습니다.

 

개발의 시작은 대학교 4학년 때, 교수님 추천으로 인턴으로 입사하여 시작하게 되었습니다. 회사도 그 흔한 가산디지털단지나 구로도 판교도 아닌 천안 아산이었습니다. 회사에 정말 10미터 떨어진 기숙사에서 회사와 기숙사를 오가며 회사 생활을 시작했던 것 같아요. 그전에는 안 해본 아르바이트가 없을 만큼 나름 해볼 것 많이 해봤으나 회사에 소속돼서 일하는 것은 처음이었는데 누군가는 꿈꾸었던 기숙사 생활이었습니다.

 

군대 같았습니다. 자고 일어나면 아침을 회사 사람들과 구내식당에서 밥을 먹고, 점심도 같은 식당이고, 밥 다 먹으면 탁구치고 다시 일하고, 저녁 먹고 또 일하고 그랬습니다. 금요일은 그나마 오후 4시에 퇴근하여 서울에 갈 수 있게 배려를 해주기도 했던 회사였습니다.

 

중요한 것은 조선 관련 회사다 보니 인턴 3개월 동안 1개월은 부산에 출장을 갔습니다. 바지선에서 직접 개발한 임베디드솔루션을 테스트해야 했습니다. 그래서 전기 관련 엔지니어와 함께 정말 난생처음 보는 배에 올라 테스트했던 기억이 있습니다. 배의 크기가 아파트 20층 정도 되는 크기였어요. 😢

'테크로스'에서 테스트했던 유조선

 

그렇게 3개월이 지나고는 회사에서 정규직 전환 의사를 물었지만, 서울에서 일하고자 하는 마음에 퇴사를 결정했었습니다. 그리고 속으로는 '개발자는 다 이렇게 일하는 건가?'라는 생각도 하게 되었고, 앞으로의 삶이 걱정되기도 했던 것 같습니다. 정말 내가 하는 일이라서 나만 힘든 거냐고 생각도 하게 되었고요.

 

그리고 서울에 올라와 우연히 테스트라는 일을 하게 되었습니다. 이력서를 처음 작성하고 잡코리아와 사림인에 등록해서 회사로부터 연락이 와서 면접을 보고 입사하게 되었습니다. 그렇게 저의 일, 경제 활동이자 자아를 성찰하기 위한 일을 시작하게 되었습니다.

 

일을 시작한 것이 2010년 2월이었고, 첫 월급이 세후 130만 원이 좀 안 되었던 것으로 기억합니다. 집은 경기도 동두천인데 회사는 서울의 양재라서 출퇴근만 5시간이 걸렸지만 그래도 일한다는 마음에 4~5시간 잠을 자면서 1년을 좀 넘게 일했습니다. 이건 누가 봐도 힘든 것 같죠? 물론 저보다 더 힘든 상황에서 회사에 다니시는 분들도 계실 겁니다. 그리고 지금은 세상도 바뀌고 일하는 방식도 많이 바뀌었으니까요.

 

그렇지만 아무리 세상이 바뀌었다고 하더라도 결국은 "지금 내가 하는 일이 가장 힘든 일이다."라는 것입니다. 누군가는 내가 하는 일에 대해서 보상? 대가에 대한 개념으로 일의 가치를 측정하기도 하고, 성취감이나 보람으로 일의 가치를 측정하기도 합니다. 그래서 이런 피드백에 대한 것이 부족할 때 힘들다는 생각하게 되는 것 같습니다. 그래서 대기업에 다니면 '돈으로 위로받는 회사'라는 표현을 하기도 하는 것 같습니다.

내 삶의 가장 중요하게 생각하는 것은 무엇일까?

 

그래서 지금 제가 하는 일!! QA 혹은 테스트 엔지니어, 품질 관리자라는 직업이 어떠냐고 물으신다면...저는 현재 매우 만족합니다. 이 일을 하지 않았다면 무슨 일을 했을지 상상하기 어렵습니다. 지금의 저를 있게 해준 일이고, 주변에 일부 소중하고 고마운 사람들을 만날 수 있게 해준 것도 지금의 테스트라는 일이, 직업이 가져다준 선물 같은 것이라 생각합니다.

 

아주 작은 일이라도 누군가는 힘든 게 맞습니다. 맞아요. 이것은 부정하면 안 됩니다. 다만, 부정하기보다는 응원하고, 그 일로 인해 나는 무엇을 얻었고, 혹은 무엇을 깨달았는지를 생각하는 것이 나를 성장시킬 수 있는 '일'의 진정한 의미가 아닐까 하는 생각을 하게 되었습니다.

 

근데 제목은 테스트 케이스 작성하는 법이라고 하고 이게 무슨 뜬구름 잡는 얘기인가 하시겠죠? 일에 대한 만족도를 높이기 위해 제가 15년 동안 공부하고, 깨닫고 느낀 것을 앞으로 QA나 테스트 엔지니어들의 주 업무인 테스트 케이스를 가지고 자세히 설명해 드리려고 합니다.

15년 품질 관련 일을 하면서 경험한 삶에 대한 깨달음

 

이전 글도 참고해 주세요.

[고민] 테스트를 잘 완료하기 위해 꼭! 준비해야 하는 것들!!

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

 

테스트 케이스를 작성하기 전 준비할 것 정리하기

우선 많이 갈리는 테스트 케이스, 체크리스트, 테스트 시나리오의 활용 목적을 명확히 해야 합니다. 표준에 나와 있는 이야기는 아니지만 업무를 통해 제가 생각하는 테스트 케이스의 목적은 '요구사항대로 개발이 되었는지 검증하는 목적'이라 생각합니다. 

 

확인(Verification)과 검증(Validation)에 대한 차이점도 면접에서 많이 물어보는 질문 중의 하나이기도 한데요. 간단하게 설명하면 확인은 인풋에 1을 넣으면 0인지 1인지를 확인하는 것이고, 검증은 똑같이 1을 넣었을 때 왜 1을 넣었고 0일 나왔을 때는 왜 0이 나왔으며, 1이 나왔다면 왜 1이 나왔는지에 대한 차이가 있습니다. 그래서 단위 테스트라는 가장 작은 단위의 테스트를 할 때는 확인이라는 표현을 많이 사용하고, 통합 테스트 시점 이후에는 검증이라는 표현을 사용하는 것이 보편적입니다. (슬픈 사실이지만 모르는 사람이 더 많을 거에요. 😂)

 

꼬꼬물로 설명하게 되는데 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트가 있습니다. 개발 생명주기에 따른 매칭되는 테스트 방법이라고 해야 할까요? 업계 표준에는 'V 모델'라는 것이 있습니다. 궁금하시면 구글링해 보시거나 챗GPT에게 물어보시는 것을 추천해 드립니다.

 

혹시나 제가 작성하는 용어 중에 궁금하신 것이 있으면 댓글에 남겨 주시면 제가 아는 한도 내에서 최대한 쉽게 설명해 드리도록 하겠습니다. 😁

 

그리고 체크리스트 목적을 이야기하기 전에 테스트 케이스와 체크리스트의 차이가 무엇인지 많이 물어보시는데요. 명확하게 기대 결과의 유무라고 대답하면 됩니다. 체크리스트는 기대 결과가 없고, 테스트 케이스는 앞에서도 이야기했듯이 요구사항에 대해 검증하는 활동이기 때문에 기대 결과가 명확히 작성되어야 합니다.

 

체크리스트와 테스트 케이스의 차이점을 쉽게 설명하면요.

• 로그인 버튼을 클릭한다.
  • 체크리스트: 로그인 버튼이 클릭 된다. (O | X의 개념)
  • 테스트 케이스: 로그인 버튼 클릭 후 홈 화면으로 이동된다. (기대 결과대로 동작하는지의 개념)

그래서 체크리스트의 활용 목적은 개발 단위 테스트에서 활용하거나 간단하고 빠르게 확인이 필요할 때(배포 전 혹은 출시 후) 많이 활용하고 있습니다. 저는 현재 회사에서도 가끔 활용하고 있습니다. 체크리스트를 쉽게 작성하는 방법은 나중에 자세히 다뤄보도록 하겠습니다.

 

그리고 마지막으로 테스트 시나리오라는 것은 조금 어렵습니다. 품질 관련업을 하지 않으시는 분들이 가장 많이 혼용해서 사용하는 용어 중의 하나입니다. 보통은 테스트 케이스를 이야기하면서 테스트 시나리오라고 이야기하는 경우인데요. 이것 또한 품질 관련 일을 하는 사람이라면 명확하게 구분하는 것이 좋습니다. 테스트 시나리오는 간단하게 이야기하면 흐름을 포함하는 테스트 케이스입니다. 

 

테스트 시나리오와 테스트 케이스의 차이점을 쉽게 설명하면요.

• 테스트 케이스:
  • 사전 조건: ID/PW 입력
    • 로그인 버튼을 클릭한다. 
  • 기대 결과: 메인 홈 화면으로 이동된다.
• 테스트 시나리오: 
  1. ID와 PW를 입력한다.
  2. 로그인 버튼을 클릭한다.
     • 기대 결과: 메인 홈 화면으로 이동된다.

테스트 케이스는 하나의 스텝에 하나의 기대 결과를 가지는 것이 가장 바람직합니다. 반면, 테스트 시나리오는 N개의 스텝을 통해 하나의 기대 결과를 가지게 됩니다. 이것 또한, 나중에 이슈(해결해야 하는 문제*)가 발생했을 때의 관리 방법이 다르기 때문에 이것도 다음 섹션에 자세히 다루겠습니다.

 

가장 중요한 것은 상황에 맞게 테스트 케이스가 필요한 것인지 체크리스트가 필요한 것인지 테스트 시나리오가 필요한 것인지를 판단해서 문서를 작성해야 하는 것입니다. 이것은 테스트의 효율이나 효과에 대해서 큰 차이가 있기 때문에 요구사항 문서를 보고 습관같이 테스트 케이스를 작성하기보다는 여러 가지 상황을 고려해서 어떤 방식으로 문서를 작성해야 할지를 먼저 고려해야 합니다.

소프트웨어는 생각을 맞추는 일이다.

 

이렇게 용어의 의미를 명확히 해서 활용해야 하는 이유는 동료들과의 커뮤니케이션을 명확히 하기 위함입니다. 소프트웨어의 성공과 실패는 커뮤니케이션을 잘했냐? 못했냐?의 작은 차이에서 시작된다고 생각합니다. 모두가 똑같이 '아버지가 방에 들어가신다'라고 이해했는데 누군가 한 명이 '아버지 가방에 들어가신다'라고 이해하게 되면 나중에 스노우볼 효과가 되어 큰 문제가 될 수 있기 때문입니다. 물론 중간에 잘 못 이해한 부분을 커뮤니케이션해서 바로 잡아야 하는 것도 매우 중요한 활동입니다.

 

테스트 케이스를 작성하는 것은 명세 기반 테스트 설계 기법이라 합니다. 말이 어렵죠? 요구사항 명세서는 요구사항을 포함하는 문서입니다. 명세하다는 의미는 '분명하고 자세하다'라는 의미로 요구사항 명세서는 '요구사항에 대해서 분명하고, 자세하게 작성된 문서이다'라고 이해하시면 됩니다.

 

예를 들면, 기획서가 대표적이고, 화면 설계서나 스토리보드, 최근 트랜드인 피그마 디자인 문서에 기능 정의를 포함해서 작성한 문서가 명세서라고 생각하시면 됩니다. 우리가 명세서에서 봐야 할 것은 기능 정의입니다. 아래 그래프는 품질 관련 일을 하는 사람들이 지켜나가야 하는 소프트웨어의 성질을 이야기해 주고 있는 그래프인데요. 사용자 관점에서 체감 불만이 가장 높은 것이 기능성이기 때문입니다.

ISO 9126, 29119에 명시된 고객 체감 불만 정도 그래프

 

예를 들면 로그인 버튼 클릭했는데 로그인 안 되는 경우라 생각하시면 가장 쉽게 이해되실 것 같습니다. 그렇기 때문에 우리는 명세서에 작성된 기능에 대한 정의를 테스트 케이스화 해서 문서를 작성해야 하는 것입니다. 기능 명세는 대부분 'OOO으로 동작된다.' 혹은 '로그인: 버튼' 등으로 작성이 되어 있을 겁니다. 우리는 이것을 보고 해당 기능의 위치 정보와 스텝과 기대 결과 등으로 테스트 케이스를 작성해야 하는 것입니다.

 

최근에는 글로만 작성된 명세서를 보고 테스트 케이스를 작성하는 것은 극히 드물 거에요. 기획자들이 작성한 화면 설계서, 스토리보드 혹은 피그마 디자인 문서로 테스트 케이스를 작성하게 됩니다. 

 

글이 길어져서 다음 섹션에 테스트 케이스 작성에 대한 이야기를 본격적으로 시작해 보도록 하겠습니다.

긴 글 읽어주셔서 감사합니다. 🤣

---

관련 참고 자료 및 서비스

Android, iOS, Web 테스트해 드립니다. - 크몽

테스트케이스 작성 및 요구 검증 수행해 드립니다. - 크몽

JIRA를 활용하여 업무 프로세스 구축해 드립니다. - 크몽

실무 적용 QA 테스트 프로세스 관리 문서 패키지 - 크몽

요약 : 투잡, n잡, N잡, 크몽부업, 부업, 부수익, kmong부업, 전자책, vod, 유튜브