QA

좋은 TC(테스트 케이스)는 무엇일까?

stdout 2024. 8. 8. 09:12

많은 회사를 거쳐다니지는 않았지만, QA 정보를 리서치하다보면 여러 사람들이 작성한 TC를 볼 기회가 많습니다.

 

회사마다 양식이 다르고, QA마다 스타일이 다르고, 플랫폼, 장르, 테스트의 종류 등을 감안하면 정석이라고 할 수 있는 TC가 없다는게 맞는 것 처럼 느껴집니다.

 

재직 중이던 회사 중 한 곳은 QA 인력을 전문적으로 육성하기 시작하는 단계였던 회사였는데, QA에 특화된 회사에 맞게 TC에 대한 커리큘럼이 비교적 확고했습니다.

 

QA마다 TC를 작성하는 스타일은 다르지만 몇 가지 필수적인 룰은 만들어서 지키자는 기조였고, 제 개인적으로는 이후 다른 회사에 이직했을때도 그 때 익혀뒀던 방식이 TC의 퀄리티, 테스트 수행 시의 편리함 등 여러모로 많은 도움이 됐다고 생각하여 공유해볼까합니다.

 

처음에 말씀드렸듯, TC 작성에 정답은 없으니 참고 차 정도로만 봐주시면 좋겠습니다.


 

 

 

1) '정상' 이라는 표현의 지양


TC에 기대결과 항목을 작성할때,  확실한 명세가 없는 내용에 대해서는 '정상적으로 노출된다', '정상적으로 작동한다.' 등의 두루뭉실한 내용으로 작성하고 싶어지는 유혹에 필연적으로 빠지게 됩니다.

 

하지만, '어떤 상태를 기준으로 정상을 판단해야하는가?' 라는 생각을 해보면 '정상'이라는 단어는 TC에 사용하기에 좋지 않은 단어라는 것을 떠올릴 수 있습니다.

 

이미지에 대해 '정상적으로 노출된다.' 라는 케이스를 작성한다고 하면,

'틀린 이미지라도 일단 노출은 되면 정상인지?'

'맞는 이미지지만 사이즈가 과하게 크거나 작지않은지?'

이런 케이스에 대한 내용이 빠지게 되는 것입니다.

 

그러므로 실제 요구사항이 뭔지 정확하게 파악 후, 기대결과를 세분화하여 작성하는 것을 권고드립니다.

날긴 하니까 정상인가?

 

 

 

2) 케이스의 순서


케이스의 순서는 TC의 퀄리티보다는 테스트를 수행하는 사람의 편리함 및 수행 속도에 연관된 고려사항입니다.

체계화된 케이스와 그렇지 않은 케이스의 테스트 수행 속도는 상상 그 이상으로 많은 차이가 납니다.

 

설명하기 편하게 게임에서 몬스터에 대한 케이스를 작성할 때로 예시를 들어보겠습니다.

 

 1) 몬스터의 체력을 확인한다

 2) 몬스터 처치 시 경험치가 획득된다.

 3) 몬스터의 패턴을 확인한다.

 

위와 같은 순서일 경우, 2번에서 몬스터를 이미 처치한 상태라 3번의 케이스를 수행하려면 다시 몬스터를 젠 시켜야하는 번거로움이 존재합니다.

그러므로 케이스의 순서는 1 > 3 > 2로 변경하여 최적화하는 것이 좋습니다.

간단한 예시이므로 '당연한 것 아닌가?' 라고 생각 할 수 있지만, 이것을 고려하지않고 작성했던 TC를 보면 단편적인 부분이 아닌 전체적인 내용으로 넓게 보면 고칠만한 부분이 많이 보일 것입니다.

다시 1번 케이스부터 시작해야 할 수도 있습니다.

 

 

 

3) 예외사항의 중요성


물론 QA를 진행하며 가장 중요한 것은 실제 요구사항과 동일한 작동을 하는지가 제일 첫 순위입니다.

 

그리고 두번째로 예외사항인데, 두번째라지만 QA 업무를 진행했다면 예외사항의 중요성은 누구나 다 알 것이라고 생각합니다.

 

하지만 막상 케이스를 설계하다보면 예외사항이 떠오르지 않는 경우가 상당히 많고, 기본적인 기능에 대한 검증만이 들어간 사실 상 체크리스트와 다를 것이 없는 TC가 만들어지게 되는 일이 비일비재합니다.

 

예외사항이라함은 기획 명세 및 요구사항에 포함되지는 않지만 확인이 필요한 내용들이라고 볼 수 있는데, 플랫폼이나 프로덕트에 대한 이해가 깊지않으면 쉽게 놓치게 됩니다.

 

이를 방지하기위해 QA로서 본인이 맡은 프로젝트의 상세한 구조, 이 프로젝트의 플랫폼에 대한 지식 습득, 그리고 다방면으로 시나리오를 구성할 수 있는 상상력(?)이 필요합니다.

 

웹페이지를 QA한다면 브라우저 기능이나 쿠키, 세션 등으로 여러 케이스를 만들어 낼 수 있을 것이고,

게임 등의 앱을 QA한다면 작업중인 기획과 연관된 다른 컨텐츠와 시스템에 대한 연결고리로 여러 케이스를 만들어 낼 수 있을 것입니다.

 

TC 작성단계가 아닌 킥오프 단계에서부터 QA로서 명세되지않은 예외사항에 대한 처리방안을 기획자, 개발자와 상의할 수 있도록 합시다.


 

 

'QA' 카테고리의 다른 글

성능 테스트용 툴 Locust 소개  (0) 2024.08.14
software QA 채용공고에서 보이는 테스팅 툴  (0) 2024.08.06
QA 기술 스택 정리  (1) 2024.08.06