회사에서 이것저것 문서를 많이 만지고 만들다 보니
체크리스트도 만들고 있습니다.
NDC 가기 전부터 느꼈지만 TC양식이 꼭 게임 QA 테스트의 맞는가?
에 대한 의문이 항상 들었습니다.
현재는 이전부터 작성하던 방식이 있어서 TC에 들어가는 사전조건이라거나
예상 결과 등을 합쳐서 분류와 기대 결과로만 케이스를 정리해서 작성하는 중이데요
이렇게 만들어도 문제가 없을지, 틀린 방법이라면 어떻게 하는게 좋을지 고민스럽네요.
다른 분들은 어떻게 TC 또는 체크리스트를 작성 관리하시는지 궁금해져서 글 남기고 갑니다.
다음검색
댓글
댓글 리스트-
작성자GameQA 작성시간 12.04.27 SWQA에서는 TC 작성시 ID, 입력값, 사전조건, 사후조건, 기대결과, Pass/Fail 을 넣으라고 되어 있지만,
제가 경함한 바로는, 개발팀 문화에 맞게 고쳐쓰는것이 훨씬 좋습니다.
게임에 따라 테스트 내용과 P/F 만 적어도 충분한 경우가 있고,
반복테스트(리그레이션)를 고려해 수행날짜를 계속 옆으로 덧붙여 나가야 하는 경우도 있습니다.
여러회사에서 사용하는 TC를 많이 봤지만, 회사마다 형태가 다 제각각 이었습니다.
GameQA.org 에 올려둔 자료를 보시면,
반복 수행을 위한 기본테스트시트와 개별 기능을 검수하는 기능테스트시트를 구분해 놓았는데
용도에 따라 TC형태가 전혀 달라지기 때문입니다. -
작성자나선 작성자 본인 여부 작성자 작성시간 12.04.29 좋은 조언들 감사합니다.
좀 더 체크리스트에 대해서 고민해봐야겠네요. 어려운 것 같아요 ㅠ_ㅠ -
작성자빨강소 작성시간 12.05.09 참고로...
tc - 소프트웨어및 시스템의 결합발견 목적으로 준비한 입력데이터와 예상결과의 집합
체크리스트 - 소프트웨어및 시스템의 동작을 점검할때 기준에 따라 질문을 나열한 목록....
이라고 알고 있습니다.;;; -
작성자제이슨본 작성시간 12.06.18 게임 쪽에서 사용하는 테스트 시트는 TC(소프트웨어 테스팅에서 이야기 하는 일반적인 TC: 포함 정보 사전조건/재현정보/실행결과/기대결과/"Pass/Fail"결과)라고 하기에는 무리가 있다고 생각됩니다.
이전 QA팀에서는 초창기에는 게임 소프트웨어의 특성을 고려하지 않고 1000개가 넘는 TC를 작성하였지만, 게임 소프트웨어의 특성 상 "상시 기획 변경"과 "구현 사항 상시 변경" 등의 이슈로 작성된 TC가 쓸모없게 되는 경우가 많이 발생했습니다. 이로 인해, TC 방식이 아닌 체크리스트 방식으로 테스트 시트를 작성하기 시작했었습니다.
이후에 사용되는 테스트 시트는 "체크리스트"로 명칭을 통일하여 사용했구요 ^^ -
작성자제이슨본 작성시간 12.06.18 체크리스트는 아무래도 테스트 엔지니어의 역량에 기대어 테스트 결과가 천차만별인 경우가 많아, 테스트 엔지니어의 역량을 지속적으로 발전 시킬 수 있도록 교육(외부 교육 청강, 내부 교육 프로세스 정립 등)에 많은 시간을 투자 했었습니다.
또한 체크리스트 작성 시(주도적으로 작성은 보통 TL이나 선임 TE) 명세기반 기법/구조기반 기법/경험기반 기법을 병행해서 적용하며 최대한 커버리지를 높일 수 있도록 했었습니다.