❶ 탐색적 테스트 기본
💡 전통적인 개발 방법론에서 만든 소프트웨어를 테스팅하는 것과 애자일 개발 방법론에서 만들어진 소프트웨어를 테스팅하는 차이?
사용자 관점은 달라질 게 없다.
그럼에도 불구하고다른게 ? 애자일에서는 참조할만한 테스트 베이시스가 부족할 수 있다.
제품부터 만들어낼 가능성이 많기 때문에 , 혹은 분석, 구현 , 설계가 굉장히 라이트할 수 있기때문에, 테크니컬한 부분만 기술되어 있을 수 있기때문에.
그러한 이유로 애자일에서는 탐색적인 테스트를 해야할 가능성이 높아진다.
❖ 탐색적 테스트 프로세스
계속 반복하면서 테스트하는게 탐색적테스트의 핵심
(-> 타임박스가 존재하는 이유.)
❖ 탐색적 테스트 구성 요소
► 테스트 차터 :
- 테스트 대상, 목적, 범위 등을 기록한 테스트 미션
- 무엇을 테스트해야하는지 어떻게 테스트해야하는지 어떤 문제를 찾아야 하는지 제시
► 테스트 노트:
- 테스트 기록을 남기는 수단(전통적 테스트 : 테스트로그와 비슷 다만 테스트노트는 무엇을 실행했는지도 기록)
- 테스트노트: 내가 무엇을 실행했는지부터 기록, 실제 결과
- 형식이 있는 포맷을 요구하지 않고, 내가 이해할 수 있는 수준으로 작성하면 된다.
- 테스트 수행기록 및 발견 특이사항과 수행시간 등을 기재
(수행시간 기록 이유 : 테스트 투자 대비 효과성을 측정하기 위해 기재.)
► 타임박싱 :
- 테스터의 집중력을 높이기 위해 테스트 수행 시간을 지정(가장 큰 이유이자 효과)
- 탐색적 테스트는 타임박싱을 통해 테스터의 집중력을 고려해 테스팅을 수행한다.
- 차터와 세션에 타임 박싱 적용
- 차터에는 무엇을 테스트해야하는지 적음,시간을 적어놨다면 세션으로 나누어 기재
► 회고 :
- 테스터의 경험과 지식을 공유
- 세션 종료 후 회고 진행(모든 세션이 끝날 때마다 공유)
- 일반적인 회고는 5분에서 10분 정도 진행 (회고를 길게 하는 것은 비효율적)
(회고교육이 있을 정도로 회고를 잘 하는 것은 중요하다) - 테스트가 종료된 이후에도 회고를 함.(테스트가 종료된다는 것: 모든 세션이 끝난 것)
❖ 스크립트 기반/ 탐색적 테스트의 스펙트럼
reference :https://murianwind.blogspot.com/2015/03/blog-post_23.html
- 정해진 길로만 가기 위한 테스트 설계를 위해서 테스터는 테스트 설계를 따라 테스팅을 하는 것: 순수 스크립트 기반 테스팅
-> 자동화 도구를 통한 테스팅
- 보통 사람들이 개입해서 하는 테스팅은 테스터의 의지가 들어감 : 단순 테스트 케이스 테스팅
-
방향에 맞는 테스트를 하는 것이 차터를 갖고 하는 것 : 차터
-
방향이 없고 테스터의 의지대로 자유롭게 테스팅하는 것 : 몽키테스트
차터가 없음. 자유도 맥스.
방향성을 차터로 두고 탐색적 테스팅을 할 수 있다.
이분법적으로 나누어지는 게 아니라 순수스크립트 기반과 자유로운 탐색 중간 어디쯤에 테스트하는게 중요하고, 일반적인 사람이 진행하는 테스트나 탐색적테스트도 중간에서 하는게 보편적이다.
❖ 결함 발견
- 스크립트 기반 테스트 : 자유도가 제한적이라 똑같은 검증만 할 수 있다.
- 탐색적 테스트 : 매번 다른 경로로 테스트를 하게 되어있기 때문에 새로운 유형의 결함을 찾아낼 가능성이 훨씬 높아진다. (테스트를 많이하면 할수록 더 많은 결함을 찾을 수 있다.)
그럼에도 불구하고 왜 많은 조직이 스크립트 기반테스팅을 할까?
- 테스터의 경험 부족
- 무엇을 테스트했는지는 테스터만 알 수 있다.
- 최소한 스크립트 설계가 있으면 무슨 테스팅을 했는 지 알 수 있음. 안 한 테스팅을 알 수 있음
- 차터를 벗어난 디테일한 정보는 탐색적 테스팅이 어렵다.
- 테스트스크립트는 리그레션테스팅에 유리하다.재사용에도 유리하다.
❖ 탐색적 테스트 Task
탐색& 전략 수립 :
제품의 요소 발견, 어떤 제품에 대한 요구되는 품질, 품질적인 특징이 뭐가 있는지 발견하려고 노력하는 것. 적용할 수 있는 기법 발견
❷ 탐색적 테스트 탐색 및 전략 수립
❖ 탐색적 테스트 계획
- 탐색적 테스트 계획 단계에서는 전략 수립, 계획서 작성, 테스트 차터 작성등과 같은 활동을 진행한다.
- 탐색적 테스트 계획 시 고려사항
- 가용 리소스(예: 인원, 시간, 테스트 환경등)
- 세션 진행방식(예: time boxing)
- 차터 작성자(예: 테스터, 매니저 등)
- 차터의 양식 및 기록할 항목
- 회고 형식
- 결함 관리 절차 및 방법
❖ 제품의 목적 식별
- 테스트가 주요 기능에 대한 작업이므로 제품의 목적 탐색은 반드시 필요함
- 제품을 검토하고 제품이 제공해야 할 기본 서비스 정의
- 개발자 관점, 기획자 관점에서 테스트를 설계하는 것은 옳지 않다.
- 페르소나를 알아야 더 좋은 설계가 가능하다.(탐색대상)
- 제품의 목적 정의
❖ 제품의 기능 탐색
- 제품이 어떤 일을 하는 지 탐색한다.(어떤 기능)
- 모든 주요 기능에 대한 개요를 작성한다.
- 주 기능을 정의하기 위하여 제품의 목적을 파악하고 반드시 필요한 기능인지를 판별할 수 있어야 한다.
- 주 기능과 부 기능을 작성한다.
- 분류 방법을 모르거나 테스트 할 수 없는 기능은 테스트 관리자에게 조언을 구한다.
- 기능을 찾는 방법 예시
- 도움말을 참조
- 툴바를 확인
- 제품의 메뉴를 확인
- 오른쪽 마우스를 클릭해본다
- 제품의 모든 창을 확인한다
- 샘플 데이터를 확인한다
❸ 탐색적 테스트 설계
❖ 테스트 차터
- 테스팅 세션을 위한 1~3문장 정도의 미션
- 테스트를 위한 가이드(휴리스틱)
❖ 차터의 구성내용
- 목표
❶ 어느 곳을 테스트해야 할까
❷ 어떤 기능이나 요구사항일수도 있고, 관련된 특정 모듈이 될 수도 있다
- 자원
❶ 어떤 자원을 가지고 갈 것인가?
❷ 테스팅 도구, 데이터, 새로운 기술, 환경 설정 등 - 정보
❶ 어떤 종류의 정보를 찾고 싶은가?
❷ 보안, 성능 ,신뢰성, 가용성, 사용성등 어느 측면에 우선순위를 둘 것인가?
❖ 좋은 차터란?
- 테스트 순서를 구체적으로 명시하지 않으면서도 테스트의 방향을 알려주는 차터
- 아주 명확한 행동 지침이나 결과물에 대한 언급 없이도 테스트 아이디어를 만들어 낼 수 있는 힌트
- 좋은 예시
✔︎ 사용자가 정상적으로 구매를 완료하지 못하는 시나리오를 찾아라.
✔︎ 보안상 취약한 부분을 찾기 위해 입력필드에 SQL 인젝션 문자열 입력하기 - 나쁜 예시
✔︎ 프로파일 수정 기능이 어포스트로피[']를 포함하는 이름을 제대로 처리하는지 o'malley를 입력하여 이름을 수정해보기 → 너무 구체적으로 작성된 차터
✔︎ 보안에 취약한 모든 부분을 찾기 위해 사용 가능한 모든 해킹 프로그램으로 시스템 보안 테스트 실행 → 너무 광범위하게 작성된 차터
쓸때 대충 쓰지 말고! 공부하면서 써!