처음 작성했던 TC 포트폴리오 회고

ISTQB를 공부하며, QA 포트폴리오에는 어떤 형태의 테스트 케이스를 담아야 하는지 알아보기 위해 다양한 자료를 참고하며 TC를 작성했다. 테스트 대상으로는 평소 플레이하던 게임들 중에 트릭컬 리바이브를 선정했다.

 

처음 테스트 케이스를 작성할 당시에는 게임의 주요 기능을 빠르게 파악하고, 사용자가 실제 플레이 과정에서 접근하는 흐름을 기준으로 검증하는 것을 목표로 했다. 이에 따라 로비에서는 프로필, 재화, 메뉴, 콘텐츠 진입 버튼 등 화면 구성 요소를 확인했고, 교주정보에서는 UI 진입 후 각 기능 버튼과 상호작용 요소를 검증했다. 또한 모험에서는 콘텐츠 이동과 주요 시스템 요소가 정상적으로 동작하는지 확인하는 방식으로 테스트 범위를 구성했다.

 

이 과정은 게임 내 기능 누락을 방지하고 전체적인 구조를 파악하는 데에는 의미가 있었지만, 이후 작성한 TC를 다시 검토하면서 테스트 설계 관점에서 부족한 부분을 발견했다.

 

기존 TC는 "UI가 정상적으로 출력되는가", "버튼을 눌렀을 때 원하는 화면으로 이동하는가", "기능이 실행되는가"와 같은 기본 동작 검증에 집중되어 있었다. 일부 왕사탕, 별사탕, 애장품과 같은 시스템에서는 조건과 데이터를 고려한 테스트를 작성했지만, 전체적으로는 기능 목록을 기준으로 정상 동작 여부를 확인하는 형태에 가까웠다.

처음 작성한 로비 TC의 내용의 일부

QA에 대한 학습을 이어가면서 기존에 작성했던 로비, 교주정보, 모험 TC의 부족한 점을 확인할 수 있었다.

해당 TC들은 주요 UI와 기능의 존재 여부, 버튼 동작, 화면 이동 등 기본적인 동작 검증에는 적합했지만, 기능 목록을 기반으로 정상 동작 여부를 확인하는 UI 체크리스트 및 Smoke Test 성격이 강한 형태였다고 생각한다.

교주 정보에 관한 내용 (윈드차임과 꽁냥콜의 경우 친밀도가 40, 50 이상인 사도가 존재해야 하지만, 단순히 해당 콘텐츠의 화면 출력여부만를 체크했기에 친밀도 조건은 제외했었다. 윈드차임의 조건을 나누어서 친밀도 40이상의 사도를 보유하고 있는 사전조건,친밀도 40이상의 사도들을 보유하고 있는 사전조건, 보유하지 않고 있는 사전조건을 분리해 작성했어야 했는데 처음 작성하다보니 여러 조건을 고려하지 못했었다.)

 

실제 테스트에서는 단순히 버튼이 출력되고 화면이 이동하는지를 확인하는 것에서 끝나는 것이 아니라, 해당 기능이 어떤 조건에서 활성화되는지, 데이터 변화에 따라 결과가 어떻게 달라지는지, 사용자의 행동 흐름에서 발생할 수 있는 예외 상황은 무엇인지까지 고려해야 한다. 하지만 기존 TC에서는 이러한 시스템 규칙과 예외 상황을 기반으로 테스트 범위를 설계하는 관점이 부족했다.

경계값 분석을 적용하려고 시도한 케이스(모험)

경계값 분석을 적용하려는 시도가 있었지만, 특정 조건을 확인하는 수준에 머물렀으며 기능 전체의 규칙을 분석하고 테스트 범위를 도출하는 방식으로 발전시키지는 못했다.

---