X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

     
   
탐색적 테스팅 적용 해보면서 느낀점에 대해서 공유 드립니다.^^
글쓴이 : 됴아 날짜 : 12-07-29 14:23 조회 : 221019
안녕하세요. 네오위즈INS의 이주희입니다.
이번에 저희 조직에서 탐색적 테스팅 교육을 받은 후 실제 업무에 도입한 사례가 있어 그 부분에 대해서 공유 드리려고 합니다. 최근 권대표님과 미팅을 했는데 저희 시뮬레이션 결과를 보시고 좋은 피드백을 많이 주셨고, 생각보다 탐색적 테스팅이 어렵구나 라는 것을 많이 느껴 이 내용을 공유 하고 같이 고민해 보면 어떨 까 하는 생각이 들었습니다. ^^

1. 진행 내역
- 탐색적 테스팅 집체교육(STA컨설팅)
- 2회 정도 내부 추가 교육 진행
- 5개의 프로젝트 파일럿 진행(약 3개월 소요)

2. 파일럿 프로젝트 전제 조건
- 탐색적 테스팅 진행 후 테스트 케이스 기반으로 진행
- 테스트 케이스 기반 진행 후 탐색적 테스팅 병행
- 테스트 케이스 기반으로 프로젝트 테스팅 완료 된 후 탐색적 테스팅 추가 진행

확인사항
- 테스트에 참여한 엔지니어의 경력과 기법 사용의 상관관계 및 활용 후 느낌을 확인한다.
- 초보 테스터가 탐색적 테스팅을 잘 실행 할 수 있는 방안을 고민한다.
- 탐색적 테스팅의 기본 룰 과 개념을 잘 준수 하는지 확인한다.
- 테스트 케이스 기반 테스팅을 발견하지 못한 결함을 탐색적 테스팅으로 발견한 경우가 있는지 확인하고 분석한다.

3. 진행시 고려 했던 점
- 탐색적 테스팅과 조직문화
  탐색적 테스팅은 기법이 아니라 접근법이기 때문에 기법을 활용해야 하는 사람이 얼마나 체계적으로 사고를 하고 테스트를 설계 해 나가느냐에 중점을 두고 진행해야 한다. 테스트 케이스 기반으로 진행할 때 처럼 엔지니어가 기획서에 요구 된 사항을 하나하나 확인하지 못하는 불안감에서 벗어나지 못하면(완벽해지고자 하는 욕심) 창의적으로 테스트 하기가 어렵다. 특히 매니저나 관리자가 탐색적 테스팅을 적용 할 때 추가적으로 어떤 결함을 찾아냈는지, 얼마나 꼼꼼하게 확인 했는지를 검사하기 시작하면 창의 적인 사고를 하기 어려운 것 같다. 검사 하는 대신 테스트 엔지니어 본인이 얼마나 체계적으로 설계 하였는지 더 관심을 가지고 디브리핑을 통해서 이런 경험들이 팀 내에 전파되어 테스팅 조직이 계속 진화 해 나가도록 꾸준히 장려해야 한다.
이런 분위기에 대해서는 상위 관리자 들이 지속적으로 조직의 문화를 바꾸어 나갈 필요성이 있어 보인다. 테스터 개인에게 창의적일 것을 강요하지말고, 창의적으로 재미있게 일 할 수 있는 환경을 만들어 주는 것이 가장 어렵고 힘든 점인 것 같다.

 - 반드시 지켜야 할 것은?
탐색적 테스팅의 기본 룰인 타임박싱, 차터설계, 테스트 노트 작성, 디브리핑은 꼭 지켜야 한다. 한가지라도 지키지 않는 다면 이것은 탐색적 테스팅이 아니라 랜덤 테스팅이나 경험 기반 테스팅과 다를 것이 없으며, 이런 제한적인 룰을 따르는 것이 테스팅을 함에 있어서 순간적인 집중력을 높혀주어 엔지니어들이 쉽게 몰입할 수 있도록 도와준다. 
하루 종일 테스트 하고 싶은데로 하라고 하는 것과, 하루 일과를 세션 단위로 나눠서(시간) 테스트를 해야 하는 목적과 미션을 차터로 제시하고, 그것에 따라서 테스트 엔지니어가 테스트를 설계 하고 시간을 효율적으로 활용 하는 것을 학습하는 것이 경험 기반 테스팅과 탐색적 테스팅의 큰 차이점이다. 
전자는 아마 처음에는 몰입도가 높겠지만 계속 진행하다 보면 테스트 아이디어의 고갈이 빠르게 올 것 이다. 후자의 경우는 테스트 리더가 계획한 시간에 따라서 테스트의 목적을 달성해 나가는 구조로 되어 있기 때문에 테스트 아이디어가 고갈이 날 수 있는 상황을 미션 제시(차터)를 통해서 환기 시켜 줄 수 있다고 생각한다. 그래서 이런 최소한의 장치가 있기 때문에 탐색적 테스팅이 체계적인 테스팅 접근법이라고 할 수 있을 것이다.

4. 파일럿 결과로 얻은 점과 피드백
- 세션과 차터의 개념
세션은 시간의 배분을 의미하고 차터는 테스트를 해야하는 목적이나 미션을 제시해 주는 것에 가까운데 팀 내에서 도입 했을 때는 차터를 설계 해야 하는 테스트 리더들이 이 부분을 가장 많이 혼동하고 계셨으며 이 부분에 대해서는 권대표님께서 지적해주셔서 팀내에 추가 교육을 진행하였다.

- 테스트 케이스 기반 테스팅을 먼저 하는 것보다는 탐색적 테스팅을 먼저 하는 것이 효율이 좋다.
프로젝트의 이해도를 초반에 높힐 수 있으며, 초기에는 결함이 보통 많이 나오기 때문에 수백개의 테스트 케이스를 체크하면서 꼼꼼하게 확인하기보다는 어떤 유형의 결함이 나오는지를 쉽고 빨리 확인 할 수 있어 효율 면에서는 처음 탐색적 테스팅을 진행하고 신뢰성을 높히기 위해서 테스트 케이스 기반 테스팅을 진행하는 것이 좋을 것이다.(내부적으로는 탐색적 테스팅만 진행하는 경우는 지양하고 있습니다. 그룹사의 아웃소싱을 담당하는 조직이기 때문에 신뢰도 측면에서 아직 탐.테의 테스트 데이터만 가지고는 설득이 어렵고 실제로도 교차 확인하는 것이 더 효율적이라는 내부 판단이 있었습니다.)

-리스크 기반 테스팅 전략과의 연계가 필요하다.
리스크 분석을 통하여 중요한 기능들을 분류하고 그 기능들을 테스트 해야 하는 목적과 중요도에 따라서 차트 분배를 효율적으로 조정할 필요가 있다. 탐색적 테스팅의 경우에도 타임박싱 기반이고 한정된 시간에서 최대한의 결과를 뽑아내야 하기 때문에 무분별한 차터의 생성보다는 리스크라는 기준에 맞춰서 작업하는 것이 더욱 체계적이다.

정리를 하다보니 조금 길게 쓰게 되었는데요. 마지막으로는 탐색적 테스팅은 처음 도입했을 때보다는 점점 활용할 수록 진화하는 테스팅 방법이라는 생각이 들었습니다. 그리고 무엇보다도 단어가 매력적이어서 테스트 엔지니어들의 긍정적인 반응을 끌어낼 수 있고게임 같이 재미도 있고^^ (탐색적 테스팅이라고 하면 꼭 MMORPG같은 생각이 들기도 하고, 차터가 퀘스트 같은 느낌도 들었습니다.) 테스팅을 하시다가 지루함을 느끼고 슬럼프가 왔을 때에 무엇보다도 테스트를 재미있게 할 수 있도록 해 줄 수 있는 획기적인 방법이라고 생각이 듭니다. 이런 좋은 방법이 무늬만 탐색적 테스팅이 아니라 제대로 활용 할 수 있도록 전파가 되면 좋겠다는 생각에서 글을 쓰게 되었습니다.

그밖에 실제로 각 파일럿 결과 및 세션과 차터, 테스트 노트 작성, 디브리핑이 어떻게 진행되었고 발생한 문제점은 어떤 것이었는지 또한 보완하기 위해서 어떤 것들을 개선중인지에 대해서는 8월에 발표할 기회가 생겨서 아마 그때 발표 할 수 있을 것 같습니다.

8월 21일 코엑스에서 NOC2012가 진행됩니다. 네오위즈에서 처음으로 외부 공개하는 네오위즈 오픈 컨퍼런스 입니다. 그때 제가 위에 정리한 내용을 조금더 구체적으로 발표 해 볼 예정입니다. 도움이 될지 모르겠지만 관심이 있으신 분들께서는 오셔서 들어보시고 피드백도 주시고 궁금하신 사항이 있으시면 질문도 해주시면 좋을 것 같습니다.

이 게시물에도 궁금한점 남겨주시면 답변 드리도록 하겠습니다. 감사합니다.^^

[이 게시물은 스텐님에 의해 2012-10-05 16:46:03 자유게시판에서 복사 됨]

cyberjacky 12-07-29 17:31
좋은 글 잘 보았습니다.
공개 컨퍼런스도 가보고 싶은 호기심이 발동하네요! 기회가 되면 꼭 참석 하겠습니다. ^^
대세는황선임 12-08-01 11:00
안녕하세요 궁금 한 사항이 있습니다만,
탐색적 테스팅 중에서
1. 게임 분야에 적용이 된 것인가요?
2. 소프트웨어 개발 방법론에서 어떤 방법론과 테스팅을 연계 하셨나요?
3. 실제 테스트의 경우 명세 기반의 블랙 박스 테스팅만 진행 하시는 것인지 아니면, 구조 기반의 테스팅도 같이 진행을 하시는 지요?(정적 분석, 단위 테스트)
4. 보통 블랙 박스 테스팅을 하는 경우 몇개의 기능 요구 사항과 TC는 얼마나 나왔습니까?
5. 요구 사항 커버리지와 테스트 커버리지는 어떤 측정 도구로 측정 하셔서 얼만큼의 비율이 나왔습니까?
됴아 12-08-01 11:22
안녕하세요^^ 궁금하신점이 많으셔서 제가 잘 답변 해드릴 수 있을지 모르겠네요~
1. 네 저희회사는 게임쪽 분야입니다.

2. 게임을 한 종류만 테스트 하는것이 아니라서 보통 개발조직의 상황에 따라서 다르게 대응하고 있는데요. 폭포수에 유사한 형태가 가장 많다고 보시면 됩니다만 스크럼을 활용하는 조직도 있습니다.

3. 저희는 아웃소싱업체이기 때문에 주로 명세기반의 블랙박스 테스팅을 진행하고 있습니다.
(보안상의 이유로 제공이 안되는 부분이 많아 구조나 코드기반의 테스트는 거의 진행되고 있지 않습니다. 그리고 개발 초기 참여도 프로젝트에 따라서 가능한 곳이 있고 아닌 곳이 있어서 일반적인것만 말씀드렸습니다.)

4.프로젝트마다 특성이 너무 다르기때문에 보통 블랙박스 테스트 할때 몇개 나온다고 말씀드리기는 어려운 부분이 있고요. 이벤트성 프로젝트라면 TC 갯수가 적은편이고 게임 한개 오픈한다고 하면 수천개가 나오기도 하지요^^;;
사례로 한가지 말씀드리면, 시뮬레이션 1차에서는 클라이언트의 요구사항에 따라서 129개의 Testcase가 나왔으며(명세기반) 이것을 탐색적 테스팅으로 설계 하였을때는 총 6개의 차터가 나왔습니다.

5. 탐색적 테스팅의 경우 아직까지 시뮬레이션 단계이므로 커버리지를 측정하는 단계는 아니고 추가 결함을 발견하는데에 사용하는 선입니다. 차후에는 리스크 기반 테스팅 전략과 조금더 연계를 잘 시켜서 데이터를 측정하는 방향으로 잡고 있습니다.
탐/테로 인한 커버리지를 물어보시는게 아니시라면 일반적인 테스팅 커버리지는 전사적으로 품질관련된 지표를 관리 하고 있는데 그 기준에 따라서 측정을 하고 있습니다.
됴아 12-08-01 11:23
답변이 되셨는지 모르겠네요^^ 또 궁금하신게 있으시면 말씀해주세용~:)
갼이 12-08-01 16:31
질문 몇 가지 드립니다.
1. 초보와 경력 테스터를 구분한 기준은 무엇인가요? 그리고 테스트 결과를 봤을 때, 어떤 차이가 있었나요?
2. 사고의 확장을 위해(혹은 획일화를 피하기 위해) 어떤 활동을 하셨나요? (What이 아니라, 했냐 안했냐가 1차적인 질문입니다)
3. Risk 연계 시, 테스트 수행 중 Risk의 재산정 필요성을 느끼신 적은 없으신가요?
4. Re-test, Regression test (ET 수행 중이던 수행 후던)는 어떻게 하셨나요?
5. ET 결과가 향후 명세 기반이나 다른 테스트에 반영이 되거나 어떤 변화를 가져왔나요?
6. 윗쪽 답변을 보니 아웃소싱업체라고 하셨는데, 개발팀과의 접촉(?)은 없으셨나요? 테스트 결과가 코드 수정이나 버그 관리에 어떻게 반영되었는지요? 기존 개발 프로세스와 문제는 없으셨는지요?
PK 12-08-06 12:07
혹시 Microsoft나 Google에서 한다는 "Touring" Tests 방법론을 적용해 보셨나요?
     
갼이 12-08-06 16:05
사족입니다만, Touring Test는 방법론이라기보단 전략으로 보는 것이.....
PK 12-08-07 07:35
제가 알고 싶은 것은 탐색적시험을 하시면서 touring을 적용해 보았고 그 효과는 좋았는가 입니다. 감사합니다.
됴아 12-08-07 10:37
안녕하세요^^
아직 탐색적 테스팅을 적용한지 몇달이 채 되지 않아서 기본 룰을 지키는 것에 초점을 많이 맞추고 있습니다. 추가로 다른 테스트 전략과 연계는 시키지 않았습니다.
또한 말씀하신 Touring에 대해서는 제가 잘 알지 못해서 정확하게 답변드리기는 어렵네요^^
XXMMXX 12-08-09 12:09
경험기반을 중시하는 업무라서 좀 더 발전을 위해 탐색적 테스팅 기법을 적용하고 있는데..
어느정도 체계가 잡힌다면 효과를 볼 수 있더군요..^^
브이테크 12-08-14 13:20
저희는 게임쪽은 아니지만, 저희도 명세기반의 블랙박스테스트 위주기때문에 가끔은 지루한(?) 테스트를 진행할때가 많습니다.
분명 잠재적 버그가 있을거라 판단되는데, 검출율이 현저히 낮아지는 시점이 있어요.
늘 생각은 하고 있었는데, 이참에 저도 한번 제안을 해서 시행해보면 좋겠다라는 생각이 드네요.
좋은 글과 질문과 답 잘 봤습니다
그소년 12-12-24 16:53
튜링 테스트는 탐색적테스팅과 전혀 다른 종류의 접근법이 아닐까요?

저도 영어가 후달려서 정확하게 튜링테스트에 대해 정의하기는 어렵지만
인간과 기계(컴퓨터/디바이스)가 서로간에 의사소통이나 상호작용하는 활동을 관찰하거나
기록하여 보다 해당 기계가 더 능숙하게 인간화될 수 있게, 혹은 인간을 보완, 대신할 수 있게

즉 애플의 시리나, 구글의 검색결과와 같은 IT서비스가
보다 세심하고 매력적이며, 인간의 실수나 오류까지도
커버할 수 있는 수준의 품질에 도달하였는지를 평가하고
개발 프로젝트를 위의 관점에서 개선해나가는 테스트 방법론이라고 여겨지네요.

탐색적테스팅의 목적은 보다 강력하게, 혹은 적은 자원을 가지고 보다 효율적으로
제품에 잠재된 버그나 일반적인 테스트케이스로 검증하기 어려운 위험요소를
(예를 들면 게임은 재미가 없거나 스킬/아이템/맵 밸런스가 똥망,
일반 소프트웨어는 UI의 일관성이나 학습용이성이 똥망 등등)
테스터가 가진 지식과 발견적인(휴리스틱) 관점을 적극 활용하는
설계+테스트 수행+결과보고를 동시에 Doing하는 접근법이라고 생각합니다.

여기서 튜링테스트가 왜 언급되는지 제가 이해가 안되긴 합니다.

http://en.wikipedia.org/wiki/Turing_test

누가 영어 되시면 해석 좀 /구걸

됴아님 멀리서나마 탐색적 테스팅에서 좋은 결과와 성과 만드시기를 응원합니다!!
그런데 네오위즈 QA부서는 아웃소싱이 아니라 서로 협력하는 유관부서 아니었나요? ㅠㅠ
윤터키 15-08-10 20:54
12년도 글인데도 읽으면 읽을 수록 공감되는 내용이 많네요
영화보다잠들기 15-12-18 14:12
좋은 글 잘 읽었습니다.