안녕하세요. 네오위즈INS의 이주희입니다.
이번에 저희 조직에서 탐색적 테스팅 교육을 받은 후 실제 업무에 도입한 사례가 있어 그 부분에 대해서 공유 드리려고 합니다. 최근 권대표님과 미팅을 했는데 저희 시뮬레이션 결과를 보시고 좋은 피드백을 많이 주셨고, 생각보다 탐색적 테스팅이 어렵구나 라는 것을 많이 느껴 이 내용을 공유 하고 같이 고민해 보면 어떨 까 하는 생각이 들었습니다. ^^
1. 진행 내역
- 탐색적 테스팅 집체교육(STA컨설팅)
- 2회 정도 내부 추가 교육 진행
- 5개의 프로젝트 파일럿 진행(약 3개월 소요)
2. 파일럿 프로젝트 전제 조건
- 탐색적 테스팅 진행 후 테스트 케이스 기반으로 진행
- 테스트 케이스 기반 진행 후 탐색적 테스팅 병행
- 테스트 케이스 기반으로 프로젝트 테스팅 완료 된 후 탐색적 테스팅 추가 진행
확인사항
- 테스트에 참여한 엔지니어의 경력과 기법 사용의 상관관계 및 활용 후 느낌을 확인한다.
- 초보 테스터가 탐색적 테스팅을 잘 실행 할 수 있는 방안을 고민한다.
- 탐색적 테스팅의 기본 룰 과 개념을 잘 준수 하는지 확인한다.
- 테스트 케이스 기반 테스팅을 발견하지 못한 결함을 탐색적 테스팅으로 발견한 경우가 있는지 확인하고 분석한다.
3. 진행시 고려 했던 점
- 탐색적 테스팅과 조직문화
탐색적 테스팅은 기법이 아니라 접근법이기 때문에 기법을 활용해야 하는 사람이 얼마나 체계적으로 사고를 하고 테스트를 설계 해 나가느냐에 중점을 두고 진행해야 한다. 테스트 케이스 기반으로 진행할 때 처럼 엔지니어가 기획서에 요구 된 사항을 하나하나 확인하지 못하는 불안감에서 벗어나지 못하면(완벽해지고자 하는 욕심) 창의적으로 테스트 하기가 어렵다. 특히 매니저나 관리자가 탐색적 테스팅을 적용 할 때 추가적으로 어떤 결함을 찾아냈는지, 얼마나 꼼꼼하게 확인 했는지를 검사하기 시작하면 창의 적인 사고를 하기 어려운 것 같다. 검사 하는 대신 테스트 엔지니어 본인이 얼마나 체계적으로 설계 하였는지 더 관심을 가지고 디브리핑을 통해서 이런 경험들이 팀 내에 전파되어 테스팅 조직이 계속 진화 해 나가도록 꾸준히 장려해야 한다.
이런 분위기에 대해서는 상위 관리자 들이 지속적으로 조직의 문화를 바꾸어 나갈 필요성이 있어 보인다. 테스터 개인에게 창의적일 것을 강요하지말고, 창의적으로 재미있게 일 할 수 있는 환경을 만들어 주는 것이 가장 어렵고 힘든 점인 것 같다.
- 반드시 지켜야 할 것은?
탐색적 테스팅의 기본 룰인 타임박싱, 차터설계, 테스트 노트 작성, 디브리핑은 꼭 지켜야 한다. 한가지라도 지키지 않는 다면 이것은 탐색적 테스팅이 아니라 랜덤 테스팅이나 경험 기반 테스팅과 다를 것이 없으며, 이런 제한적인 룰을 따르는 것이 테스팅을 함에 있어서 순간적인 집중력을 높혀주어 엔지니어들이 쉽게 몰입할 수 있도록 도와준다.
하루 종일 테스트 하고 싶은데로 하라고 하는 것과, 하루 일과를 세션 단위로 나눠서(시간) 테스트를 해야 하는 목적과 미션을 차터로 제시하고, 그것에 따라서 테스트 엔지니어가 테스트를 설계 하고 시간을 효율적으로 활용 하는 것을 학습하는 것이 경험 기반 테스팅과 탐색적 테스팅의 큰 차이점이다.
전자는 아마 처음에는 몰입도가 높겠지만 계속 진행하다 보면 테스트 아이디어의 고갈이 빠르게 올 것 이다. 후자의 경우는 테스트 리더가 계획한 시간에 따라서 테스트의 목적을 달성해 나가는 구조로 되어 있기 때문에 테스트 아이디어가 고갈이 날 수 있는 상황을 미션 제시(차터)를 통해서 환기 시켜 줄 수 있다고 생각한다. 그래서 이런 최소한의 장치가 있기 때문에 탐색적 테스팅이 체계적인 테스팅 접근법이라고 할 수 있을 것이다.
4. 파일럿 결과로 얻은 점과 피드백
- 세션과 차터의 개념
세션은 시간의 배분을 의미하고 차터는 테스트를 해야하는 목적이나 미션을 제시해 주는 것에 가까운데 팀 내에서 도입 했을 때는 차터를 설계 해야 하는 테스트 리더들이 이 부분을 가장 많이 혼동하고 계셨으며 이 부분에 대해서는 권대표님께서 지적해주셔서 팀내에 추가 교육을 진행하였다.
- 테스트 케이스 기반 테스팅을 먼저 하는 것보다는 탐색적 테스팅을 먼저 하는 것이 효율이 좋다.
프로젝트의 이해도를 초반에 높힐 수 있으며, 초기에는 결함이 보통 많이 나오기 때문에 수백개의 테스트 케이스를 체크하면서 꼼꼼하게 확인하기보다는 어떤 유형의 결함이 나오는지를 쉽고 빨리 확인 할 수 있어 효율 면에서는 처음 탐색적 테스팅을 진행하고 신뢰성을 높히기 위해서 테스트 케이스 기반 테스팅을 진행하는 것이 좋을 것이다.(내부적으로는 탐색적 테스팅만 진행하는 경우는 지양하고 있습니다. 그룹사의 아웃소싱을 담당하는 조직이기 때문에 신뢰도 측면에서 아직 탐.테의 테스트 데이터만 가지고는 설득이 어렵고 실제로도 교차 확인하는 것이 더 효율적이라는 내부 판단이 있었습니다.)
-리스크 기반 테스팅 전략과의 연계가 필요하다.
리스크 분석을 통하여 중요한 기능들을 분류하고 그 기능들을 테스트 해야 하는 목적과 중요도에 따라서 차트 분배를 효율적으로 조정할 필요가 있다. 탐색적 테스팅의 경우에도 타임박싱 기반이고 한정된 시간에서 최대한의 결과를 뽑아내야 하기 때문에 무분별한 차터의 생성보다는 리스크라는 기준에 맞춰서 작업하는 것이 더욱 체계적이다.
정리를 하다보니 조금 길게 쓰게 되었는데요. 마지막으로는 탐색적 테스팅은 처음 도입했을 때보다는 점점 활용할 수록 진화하는 테스팅 방법이라는 생각이 들었습니다. 그리고 무엇보다도 단어가 매력적이어서 테스트 엔지니어들의 긍정적인 반응을 끌어낼 수 있고게임 같이 재미도 있고^^ (탐색적 테스팅이라고 하면 꼭 MMORPG같은 생각이 들기도 하고, 차터가 퀘스트 같은 느낌도 들었습니다.) 테스팅을 하시다가 지루함을 느끼고 슬럼프가 왔을 때에 무엇보다도 테스트를 재미있게 할 수 있도록 해 줄 수 있는 획기적인 방법이라고 생각이 듭니다. 이런 좋은 방법이 무늬만 탐색적 테스팅이 아니라 제대로 활용 할 수 있도록 전파가 되면 좋겠다는 생각에서 글을 쓰게 되었습니다.
그밖에 실제로 각 파일럿 결과 및 세션과 차터, 테스트 노트 작성, 디브리핑이 어떻게 진행되었고 발생한 문제점은 어떤 것이었는지 또한 보완하기 위해서 어떤 것들을 개선중인지에 대해서는 8월에 발표할 기회가 생겨서 아마 그때 발표 할 수 있을 것 같습니다.
8월 21일 코엑스에서 NOC2012가 진행됩니다. 네오위즈에서 처음으로 외부 공개하는 네오위즈 오픈 컨퍼런스 입니다. 그때 제가 위에 정리한 내용을 조금더 구체적으로 발표 해 볼 예정입니다. 도움이 될지 모르겠지만 관심이 있으신 분들께서는 오셔서 들어보시고 피드백도 주시고 궁금하신 사항이 있으시면 질문도 해주시면 좋을 것 같습니다.
이 게시물에도 궁금한점 남겨주시면 답변 드리도록 하겠습니다. 감사합니다.^^
[이 게시물은 스텐님에 의해 2012-10-05 16:46:03 자유게시판에서 복사 됨]
지식공유
