노년코딩

6.1.5 테스트 실행 및 로깅 지원 도구

▶ 테스트 프레임워크

 - 테스트 수행을 위한 전체적인 프로세스

 - 테스트 자동화 설계 유형

   >> 데이터 주도 : 테이블이나 스프레드쉬트에 테스트 입력값과 예상 결과를 저장하여 스크립트를 작성하고 테스트하는 기법.

   >> 키워드 주도 : 테스트 데이터와 예상 결과 뿐만 아니라 테스트 대상 어플과 관련된 키워드를 포함한 데이터 파일을 사용하는 테스트 기법

 - 테스트 도구를 구축하는데 사용할 수 있는 재사용 및 확장 가능한 테스트 라이브러리

▶ 테스트 실행 도구

 - 저장된 입력 값들과 예상 결과를 이용해 테스트를 자동 혹은 반자동으로 실행(스크립트 언어 이용)

 - 캡쳐 & 재실행 도구 - 테스트 스르립트와 실행결과 저장

 - 테이블 기반 테스트 실행 도구

 - 도입 시 고려사항

   >> 대규모 테스트 자동화에 부적합 - 예상하지 못한 이벤트 취약

   >> 스크립트 언어에 대한 전문가 필요

   >> 테스트 결과의 비교를 위해 각각의 테스트에 대한 기대 결과 저장 필요

▶ 테스트 하네스 도구(개발자에게 더 적절한 지원) 

 - 테스트 대상 실행 환경을 시뮬레이션하여 격리된 상태에서 컴포넌트를 테스트하거나 적절한 스텁과 드라이버와 함께 테스트 할 수 있도록 지원하는 도구

 - 테스트 하네스 도구는 미들웨어 상의 테스트 실행 프레임워크를 제공하는 용도로 사용

▶ 단위 테스트 프레임워크 도구(개발자에게 더 적절한 지원)

 - 컴포넌트 테스트 레벨에 포커스를 맞춘 도구

 - 단위 테스트 레벨에 특화된 테스트 하네스로 코드를 개발하는 동안 컴포넌트 테스트를 병렬적으로 수행 하도록 지원

 - TDD(Test Driven Development) - 단위 테스트 유용

 - 단위 레벨의 테스트 케이스는 리그레션 테스트에서도 의미 있게 재사용

▶ 테스트 비교자

 - 파일, 데이터베이스 혹은 테스트 결과 사이의 차이를 비교하고 결정

 - 자동화 시스템에서 테스트 오라클(판단 근거)을 이용

 - 일반적으로 테스트 실행 도구에 포함

▶ 커버리지 측정 도구(개발자에게 더 적절한 지원)

 - 측정된 유형의 구조가 테스트 세트에 의해 얼마나 완벽하게 실행됐는지 확인

 - 코드 커버리지 도구는 측정하고자 하는 특정 유형의 코드 구조( 구문, 분기 또는 결정, 모듈 또는 함수 호출)가 몇 퍼센트 실행됐는지 측정

▶ 보안 테스트 도구

 - 컴퓨터나 바이러스나 서비스 거부 공격 검사

 - 시스템 특정 취약성을 찾기 위해 부하를 주는 도구

 - 운영체제를 시뮬레이션해 보안성을 테스트 하는 도구

6.1.6 성능과 모니터링 도구

▶ 동적 분석 도구(개발자에게 더 적절한 지원)

 - SW 실행 중에만 발생하는 시간 의존성과 메모리 누수와 같은 결함을 발견

 - 컴포넌트 / 통합 테스팅에서 사용되거나 미들웨어를 테스트할 때 사용

▶ 성능 / 부하 / 스트레스 테스팅 도구

 - 시스템이 시뮬레이션된 다양한 사용 조건 하에서 어떻게 동작하는가를 모니터링

 - 어플리케이션, 데이터베이스, 네트워크 서버와 같은 시스템 환경에 대해 부하를 시뮬레이션

 - 자동 반복 실행에 기초하고 있고 파라미터에 의해 조정

 - 성능 테스팅 전문가 필요(테스트 설꼐 및 실행 결과 해석)

▶ 모니터링 도구

 - 특정 시스템 리소스의 사용량을 지속적으로 분석하고 확인해서 보고

 - 예상되는 서비스 상의 문제점에 대해 경고

6.1.7 특정 어플리케이션 영역을 위한 도구

▶ 특정 유형의 어플리케이션만을 위해 전문화

 - 웹 기반 어플리케이션에 특화된 성능 테스팅 도구

 - 특정 개발 틀랫폼을 위한 정적 분석 도구

 - 보안 테스팅에 특화된 동적 분석 도구

 - 임베디드 시스템과 같은 특정 어플리케이션 분야를 위한 상용 도구 스위트

▶ 자동화도구범위와오픈소스참조

☞https://www.oss.kr/info_test/show/b3f50bf5-7d67-486f-bc70-d426d6f01dc4

☞http://www.pseg.or.kr/pseg/casetest

6.1.8 테스팅 도구 이외의 다른 도구

▶ 기타 도구

 - 테스터는 개발자가 사용하는 도구, 사무용으로 사용하는 도구도 활용할 수 있음

6.1.9 상용 도구와 오픈 소스 도구

▶ 오픈소스도구 

 - 무료로 사용할 수 있는 오픈소스 도구는 코드를 공개하는 경우와 사용만 무료로 하는 경우로 나누어 질 수 있음

6.2.1 테스팅 도구 도입의 잠재 이익과 위험

++ RPA(Robotic Process Automation)란? 
디지털 시스템 및 소프트웨어와 사람 사이의 상호 작용을 에뮬레이션하는 소프트웨어 로봇을 쉽게 빌드, 구현, 및 관리할 수 있도록 해주는 소프트웨어 기술

로보틱 프로세스 자동화(RPA)는 소프트웨어 로봇을 사용하여 인간이 수행하는 작업을 자동화하는 비즈니스 프로세스 자동화 기술의 한 형태이다.

▶ 자동화 도구의 장단점

 - 혜택(benefit)

   >> 테스트 노력 절감 및 실수 감소 : 반복되는 부분을 자동화 시켜, 리소스를 보다 리스크가 높은 부분의 테스팅에 집중하도록 함 / 리그레이션 테스팅 실행, 동일 테스트 데이터 재입력, 코딩 표준 준수 여부 점검

   >> 객관적인 평가 기준 및 테스트의 신뢰성 제공 : 정적 측정치, 커버리지

   >> 테스트와 테스팅에 대한 정보에 쉬운 접근성 제공 : 테스트 진척도, 결함율, 그리고 성능에 대한 통계와 그래프

   >> 월등한 일관성과 반복성 제공 : 비용 효율적 유지보수 가능 --> 고객의 요구에 빠르게 대응할 수 있는 장점

   >> 품질 향상 --> 고객 만족도 향상 

++ 패턴이 있거나 굉장히 단순한 반복이 있다면 자동화를 이용, 건 바이 건 또는 랜덤형식이다. 하면 사람이 하는게 나음.

  -리스크(risk)

   >> 고가이면서 유지비용( 가상사용자, 업그레이드, 기술 지원 등) 높음

   >> 초기 환경 및 테스트 설정에 많은 시간과 노력 소요

   >> 도구를 통해 중대하고 지속 가능한 성과를 얻기 위해 많은 시간이나 노력 소요

   >> 도구에 의해 생성된 테스트 자산인 테스트 스크립트 유지 보수가 어려움

   >> 오픈 소스와 같은 비영리 프로젝트의 갑작스러운 중단

   >> 새로운 플랫폼 지원과 같은 변화된 환경에 대한 지원 능력 부족

   >> 도구에 대한 비 현실적인 기대/ 도구에 대한 지나친 의존

6.2.2 도구 유형별 고려사항

▶ 유형별 고려사항

 - 테스트 실행 도구

   >> 테스트를 실행할 수 있도록 작성된 스크립트를 재생

   >> 이런 종류의 도구는 가치를 끌어내기 위해 상당한 노력과 전문성 필요

 - 성능 테스팅 도구

   >> 성능 테스팅을 설계하고 테스트 결과를 해석할 수 있는 전문가 필요

 - 정적 분석 도구

   >> 소스 코드에 코딩 표준을 강제하는데 사용

   >> 실제 적용시 매우 많은 경고 메시지 발생 >> 유지보수를 위한 조치 취함

 - 테스트 관리 도구

   >> 조직의 요구에 맞는 최적화된 형태의 정보를 생성하기 위해 다른 도구와 연계하여 사용할 필요가 있음

6.3.1 도구 선택 및 도입

▶ 도구 선택

 - 주요 고려 사항

   >> 조직의 성숙도, 강점과 약점을 평가한 후, 도구 지원으로 테스팅 프로세스를 개선할 수 있는 기회를 발견.

   >> 도구 도입을 위한 명확한 요구사항과 객관적인 도구 평가 기준을 가지고 도입 하고자 하는 도구를 평가.

   >> 도구가 요구되는 기능성을 만족하는 지, 도구가 본래 목표하는 바를 달성하는지를 등을 파일럿 프로젝트에 적용하여 입증.

   >> 교육 제공과 지원 능력 등을 고려하여 도구 제작 회사나 배포 회사를 평가한다.

   >> 도구 사용과 관련된 조직 내부 교육과 개별 지도에 대한 요구사항을 식별한다. 

6.3.2 파일럿 프로젝트 적용

▶ 파일럿 프로젝트

 - 목표

   >> 도구와 관련된 상세한 사항을 습득

   >> 현 프로세스나 업무에 도구를 어떻게 적용할 수 있는지 평가하고, 도구 적용을 위해 현 프로세스나 업무의 무엇을 변경해야 하는 지 결정.

   >> 도구의 사용, 관리, 저장, 유지보수하는 표준적인 방식을 결정.

   >> 합리적인 비용으로 목표하는 성과에 도달할 수 있는지 평가. (시간이 너무 들거나 도입할 때 비용이 너무 많이 들면 ㄴㄴ )

6.3.3 테스트 자동화

▶ 테스트 자동화

 - 테스트 자동화시 고려사항

   >> 적절한 자동화 대상 프로젝트 선정

   >> 자동화를 테스트 전략과 계획에 포함
   >> 자동화 도구 선정에 신중

   >> 도구에서 요구하는 것에 따라 제품과 테스트 스펙을 공식적으로 변경
   >> 자동화 테스트 지원 시설(도구) 개발 계획 고려

   >> 상세한 자동화 테스트 지침 필요

   >> 도구 전문가 참여

   >> 자동화 도구 관련 프로세스의 정의와 적용

6.3.4 도구의 배포

▶ 도입한 도구를 조직 내부에 배포

 - 성공 요인

   >> 조직의 나머지 부분에도 도구의 사용을 점진적으로 확대

   >> 도구의 사용법에 맞게 프로세스를 수정하고 개선

   >> 새로운 사용자를 위한 교육과 훈련(멘토링) 수행

   >> 사용 가이드라인을 정의

   >> 도구 사용을 통해 교훈을 얻는 방법을 마련

   >> 도구 사용 현황과 성과를 모니터링

6.3.4 도구 도입 절차

1. 도구 도입 계획 및 전략 수립
- 도구 도입 목적 정의 및 내부 요구사항 식별
- 비용 편익 비율 추정 >> 구체적인 비즈니스 사례 기반
- 상용 도구 도입 시 직접 개발하는 부분 존재(상용 도구 한계)
2. 후보 도구 선정 및 평가
- 자료 검토 및 후보 도구 선정
- 목적 달성 여부 검증
- 요구사항과 객관적인 기준으로 평가
- 교육 및 지원 능력 등 고려해 평가
3. 파일럿 프로젝트 
- 도구 적용 평가 및 프로세스 변경 대상 및 범위 결정
- 도구 사용, 관리, 저장, 유지 보수 등 표준 방식 결정(라이브러리 개발, 테스트 스위트 모듈화 등)
- 합리적인 비용으로 목적하는 성과에 도달할 수 있는지 점검
4. 도구 배포 및 확산
- 조직에 점진적으로 확대
- 도구 / 사용법에 맞게 프로세스 적용/ 개선
- 사용자 교육 및 지도 / 멘토링
- 사용 가이드 라인 정의
- 도구 사용과 성과 모니터링
- 도구 적용에 필요한 적절한 지원(인력, 기술 등)

6.4 도구 도입과 성과

▶ 도구 도입

 - 기대 효과 및 성과

   >> 사람의 실수로 인한 에러 최소화

   >> 수동으로 하기 어렵거나 불가능한 작업이 도구 지원을 통해 가능해짐

   >> 신뢰성 있는 정량적 테스팅 리포팅 >> 실시간 현황 파악 가능

   >> 테스트 시간의 단축으로 제품 릴리즈 시간 단축 가능

   >> 더욱 빈번하게 자주 테스트함으로써 신뢰성을 높일 수 있음

   >> 테스트 스킬이 높지 않아도 도구를 활용한 테스트 실행 가능

   >> 테스트 커버리지 높일 수 있음

   >> 실행 자동화 도구의 경우 리그레션 테스팅의 효과 가능

   >> 도구에 내장된 기능을 사용함으로써 객관적이고 효과적인 도구 사용

이제 드디어 6장만 남겨두고 있다. 이런 저런 일들이 있었지만 다 정리해서 공부하고 새롭게 시작할 공부로 넘어가 보자.

6.1.1 테스트 도구의 분류

▶ 테스트 도구 자동화

 - 테스팅 자동화 --> 모든 테스팅 활동에 대해 고려

   >> 반복적인 작업 자동화 또는 테스트 계획, 테스트 설계, 테스트 리포팅과 모니터링과 같은 메뉴얼 테스트 지원 --> 테스트 효율성 향상.

   >> 수작업으로 진행 시 상당한 자원을 필요로 하는 업무 자동화 (e.g. 정적 테스팅)

   >> 사람이 수행할 수 없는 업무 자동화 (e.g. 클라이언트 - 서버 어플리케이션의 대단위 성능 테스팅)

   >> 테스팅 신뢰성 향상(e.g. 대량 데이터 비교 자동화, 시뮬레이션)

 - 테스팅 활동에 따른 도구 분류

6.1.2 테스트 관리 지원 도구

▶ 테스트 관리 도구

 - 실행된 테스트와 테스팅 활동 관리를 지원

 - 추적성 제공 : 소스 문서(요구사항명세 등)와 테스트 케이스, 테스트 결과, 인시던터(결함) 간의 추적성 제공.

 - 리포트 생성 : 테스트 결과 기록, 테스트 진행 상황에 대한 리포트 생성

 - 정량적 분석 지원 : 테스트 관련 지표(실행한 테스트, 합격한 테스트 등)와 발견된 결함 또는 인시던트와 같이 테스트 대상에 관련된 정량적인 분석(측정)을 지원

 - 조직의 요구에 맞는 양식으로 유용한 정보를 생산하기 위해 스프레드시트, 테스트 실행 도구, 결함 추적 도구, 요구사항 관리 도구와 같은 다른 도구들과 연동 필요

▶ 인시던트 관리 도구

 - 보고된 인시던트 리포트 간에 우선순위 결정

 - 결함 수명 주기 관리

   >> 결함이 발견(탄생)되고, 분배되고, (재)수정되고, (재)확인되고, 종료되는 결함 수명 주기 관리

   >> 결함 수정 불필요, 수정 완료 및 테스트 준비, 수정을 다음 릴리즈로 연기 등의 결함 상태 변경

 - 결함을 기록하고 결함 관리 상황에 대한 리포트 생성(누적 s커브 등)

 - 담당자에게 수정 및 확인 테스트 등의 임무 할당

▶  요구 사항 관리 도구 

 - 요구사항 명세서 저장

 - 요구사항에 대한 특성(우선순위 포함) 저장

 - 요구사항에 대한 고유 식별자 부여

 - 요구사항에 대한 개별 테스트의 추적성 제공

 - 누락된 요구사항 또는 일관성이 없는 요구사항을 식별

** 참고: 요구사항 커버리지가 100% 커버했다고 하더라도 요구사항이 최소한 1개의 테스트 케이스로 테스트되었다는 정도만 의미함

▶ 형상 관리 도구

 - 형상관리 지원 도구는 테스트를 위한 도구는 아니지만 테스트 업무에 활용 가능함

 - 테스트웨어의 버전 관리와 저장을 위해 활용

 - 하나이상의 운영체제, 컴파일러, 브라우저 등의 하드웨어/ 소프트웨어 환경 구성에 필요

6.1.3 정적 테스팅 지원 도구

▶  정적 테스팅 지원 도구

 - 개발 프로세스 초기에 많은 결함을 발견 -> 비용 대비 효과성 올라감

 - 리뷰 프로세스 지원 도구

   >> 리뷰 프로세스에 관한 정보를 저장, 리뷰 코멘트를 저장

   >> 의사소통, 결합 및 노력을 기록/ 보고

   >> 리뷰 규칙이나 체크리스트를 참조할 수 있도록 지원

   >> 문서와 소스 코드 사이의 추적성 확보를 가능하게 함

   >> 온라인 리뷰 지원

 - 정적 분석 도구(개발자에게 더 적절한 지원)

   >> 개발자, 테스터, 품질보증 담당자가 동적 테스팅을 하기 전에 결함을 발견할 수 있도록 지원

   >> 코딩 표준을 지킬 것을 강제

   >> 구조와 의존관계를 분석(링크된 웹페이지의 구조와 의존 관계 분석 등)

   >> 코드 이해 지원

   >> 최근에는 의미 분석, 룰 체크 등으로 구분

 - 모델링 도구 (개발자에게 더 적절한 지원)

   >> 소프트웨어 모델 유효성 검증 지원

   >> 소프트웨어 모델을 기반으로 테스트 케이스 생성 지원

 - 정적 분석 툴이나 모델링 툴에서 가장 큰 이점은 개발 프로세스 초기에 더 많은 결함을 발견하게 하는 비용 효과성을 들 수 있음.

6.1.4 테스트 설계 지원 도구

▶ 테스트 설계 도구

 - 코드, 디자인 모델, 사용자 인터페이스, 요구사항으로부터 테스트 입력값과 실제 테스트 케이스를 생성

 - 일부 도구는 테스트 오라클을 사용해 예상 결괏값을 생성

 - 상태나 객체 모델로부터 생성된 테스트 케이스는 모델 구현을 검증하는데 매우 유용

▶ 테스트 데이터 준비 도구

 - 데이터 베이스, 파일, 데이터 전송을 적적히 조작해 테스트 데이터 마련

   >> 실 데이터의 익명성을 보장하여 데이터를 보호하면서 실제와 거의 동일한 데이터로 테스트 수행함.

   >> 다량의 데이터가 필요한 경우나 특정 생성 규칙에 맞는 데이터가 필요한 경우에도 유용하게 활용됨.

5.3.1 테스트 경과 모니터링

▶테스트 모니터링 목적

 - 테스트 활동에 대한 피드백과 가시성을 제공하여 테스트 계획, 또는 조직 차원의 테스트 정책이나 전략을 준수하는지 관찰.

- 테스트 케이스 작성률 : 계획 대비 완료된 테스트 케이스의 비율
- 테스트 환경 구축률 : 완료된 테스트 환경 구축 작업 비율
- 테스트 케이스 실행 관련 메트릭 : 실행된 테스트 케이스의 비율
- 통과되거나 실패된 테스트 케이스 수 : 결함 밀도, 발견된 결함과 수정된 결함, 장애율, 재 테스트 결과
- 요구사항, 리스트, 코드의 테스트 커버리지
- 제품에 대한 테스터의 주관적 자신감
- 테스트 마일스톤
- 테스팅 비용 관련 메트릭 : 비용 들여 추가 진행에 대한 이득 비

5.3.2 테스트 리포팅

▶ 테스트 리포팅

 - 테스팅 동안의 노력 및 활동에 대한 정보 및 제품의 결함 정보를 요약하여, 이해관계자의 의사결정을 지원할 목적으로 보고서를 작성하고 보고하는 활동

 - 진행 보고서 : 주요 시점에 현재 상황을 보고

   >> 주간, 월간 보고서(제품 품질, 테스트 생산성, 리스크, 프로세스 품질 등)

 - 종료 보고서 : 특정 테스트 유형 및 레벨이 종료되는 시점 보고 

   >> 테스팅 기간 동안 처리했던 주요 업무

   >> 향후 업무에 대한 의사결정을 위해 의미 있게 분석된 정보와 메트릭

 - 테스트 계획 단계에서 미리 계획하고 설계 --> 완성도 올라감.

▶ 결함 관련 메트릭 (메트릭 : 수치로 표현할 수 있는 측정)

 - 평균 결함 건수

 - 심각도별 결함 건수

 - 결함유형별 분포 비율

 - 결함 조치율

 - 발견 단계별 분포 비율

▶ 결함 발생 이유

 - 표준 미준수, 테스트 부족, 마무리 부족, 팀 간 의사소통 부족, 코딩 실수 등.

▶ 결함 유형

 - 시스템 오작동

 - 시스템이 멈추거나 다운됨

 - 예상치 못한 시스템의 동작이나 반응

 - 시스템이 가지고 있어야 할 기능, 성능 특성의 누락이나 불완전한 경우

 - 문서화 결함

 - 사용용이성 저하

 - 선능 저하

 - 데이터 훼손 및 데이터 무결성 깨짐

 - 데이터 손실 

- 수집된 메트릭의 활용
>> 해당 테스트 레벨에 대한 테스트 목적의 적절성 평가
>> 사용된 테스트 접근법의 적절성 평가
>> 목적 대비 테스팅의 효과성 평가

▶테스트 진행 보고서

 - 테스트 진행 중 합의사항과 근시일 내에 진행할 테스트 활동에 대한 내용을 포함.

   >> 소프트웨어 품질, 테스트 생산성, 소프트웨어 제품 리스크, 테스트 프로세서 품질, 테스트 문제점 등.

▶ 테스트 종료 보고서

 - 레벨별 종료 보고서와 프로젝트 종료 보고서로 나뉨

 - 테스트 계획 대비 차이

 - 오픈되어 있는 제품 리스크와 예상되는 영향

 - 해결되지 않은 결함과 그로 인해 예상되는 영향

 - 시스템 파트의 현 상태와 커버된 리스크

 - 테스트 프로세서 품질

 - 테스트 프로젝트 수행 경험

 - 다음번 테스트에 대한 조언

▶ 테스트 보고서 활용

 - 어플리케이션 출시 여부

 - 결함의 심각도 및 유형 파악

 - 요구사항에 대한 테스트 커버리지 확인

 - 어플리케이션 품질 결정

 - 다음 단계의 테스트를 위한 테스트 주요 요소 파악

▶좋은 리포팅 요건

5.3.3. 테스트 제어

▶ 테스트 제어

 - 테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행되도록 가이드 하거나 정정하는 활동

 - 테스트 제어 활동의 예

   >> 테스트 모니터링으로부터 얻은 정보를 기반으로 의사 결정

   >> 프로젝트 리스크가 실제 발생 하였을 때 테스트의 우선순위를 조정

   >> 테스트 환경의 가용성 이슈가 있을 경우 테스트 일정 변경

   >> 테스트 시작 조건 조정

   >> 수정사항 빌드에 반영하기 전에, 해당 수정사항을 개발자가 재 테스트하도록 요구

5.3.4 테스트 완료

▶ 테스트 완료

 - 특정 레벨 또는 유형의 테스팅에서 테스트 계획서에서 계획했던 모든 항목들이 완료되면 시작하는 활동

 - 목적 : 테스트 자산 및 환경을 보존, 테스트 활동에서의 교훈을 찾아내어 이해관계자와 공유

 - 테스트 완료 보고서에는 테스트 계획대비 실적, 결함 상태, 리스크 등과 함께 테스트 자산의 보존 상황 및 교훈을 기록하고 이를 이해 관계자에게 보고함.

5.4 형상 관리

▶ 형상 관리의 목적

 - 프로젝트나 제품의 전체 수명 주기에 걸쳐 시스템이나 소프트웨어(컴포넌트, 데이터, 문서)의 상태를 그대로 보존, 보호하고 유지하기 위함

>> 테스트웨어 식별, 버전 관리, 변경 추적, 상호 연관성, 개발 아이템(테스트 대상)과의 연계 관리 등을 통해 테스트 프로세스 전반에 걸친 추적성 확보.
>> 테스트 문서에서 참조하고 있는 모든 관련 문서 또는 소프트웨어 아이템을 모호하지 않게 관리.

 - 테스터는 형상 관리를 통해 테스트된 품목, 테스트 문서, 케이스와 테스트 하네스(테스트환경셋팅) 등을 혼선 없이 관리하고 효율적 재사용.

 - 형상 관리 절차는 테스트 계획 단계에서 결정하고 문서화

5.5 리스크와 테스팅

▶ 리스크

 - 이벤트, 위험 요소, 위협 혹은 상황의 발생 가능성과 발생했을 경우의 바람직하지 못한 결과 즉, 잠재적 문제

5.5.1 프로젝트 리스크

5.5.2 제품 리스크

▶제품 리스크

 - 소프트웨어나 시스템에서 의도하지 않은 향후 이벤트나 위험 요소가 존재하는 잠재적인 장애 영역.

   >> 개발 팀에서 전달받은 장애 가능성이 높은 소프트웨어

   >> SW 및 HW가 개인이나 회사에 손실을 끼칠 가능성

   >> 취약한 소프트웨어 특성(기능성, 신뢰성, 사용성, 성능)

   >> 의도된 기능을 수행하지 못하는 SW

 - 제품 품질에 대한 리스크

 - 리스크 vs. 테스트

   >> 리스크 : 테스트를 시작하는 시점을 결정하고 더 강력하고 깊이 있게 테스트할 부분을 결정하기 위해 사용.

   >> 테스트 : 의도하지 않은 결과를 야기시키는 리스크를 줄이거나, 의도하지 않은 결과로 야기되는 영향과 손실을 줄이기 위해 사용.  

리스크 관리 : 리스크 식별 --> 리스크 분석 --> 리스크 계획 --> 리스크 추적
 - 리스크 식별 : 무엇이 리스크이고 어디에 리스크가 있는지 확인
 - 리스크 분석 : 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석(리스크 우선 순위 결정.)
                         *리스크 = 장애 발생 빈도 x 장애로 인한 영향
 - 리스크 계획 : 리스크 정보를 근거로 대처 방안 수립 (리스크 줄이는 "테스트" 생성)
 - 리스크 추적 : 리스크 및 리스크에 대한 대응을 모니터링

▶  리스크 식별

   >> 기능적/ 기술적 아이템 모두 도출

   >> 요구사항에 따른 상위 레벨 테스트 관련 항목

   >> 아키텍처에 따른 하위 레벨 테스트 관련 항목

   >> 브레인스토밍을 통해 도출 가능

   >> 한 번에 분석해야 할 리스크 아이템 수를 적당히 제어할 필요 있음.

▶ 리스크 분석

▶ 경험적 리스크 요소

- 프로젝트 상황에 맞게 변형시킬 수 있으며, 가중치 적용 가능

▶리스크 계획 활동

 - 리스크 분석 결과를 근거로 대처 방안 수립

 - 리스크를 줄이는 테스트를 생성

 - 리스크 메트릭스 작성

   >> 리스크 분석 단계에서 합의/ 결정된 리스크 아이템별로 리스크 요소의 점수 이용하여 작성

   >> 장애 발생 가능성 리스크 요소 총점과 장애로 인한 영향 리스크 요소 총점을 구분하여 좌표에 표시

 - 테스트 레벨 별로 차별화된 리스크 기반 테스팅 전략 준비 

▶리스크 추적

 - 리스크 상황을 모니터링 해 잔존 리스크를 줄여나가는 활동

 - 리스크를 효과적으로 추적하기 위해 다양한 지표 개발 필요

5.6 인시던트 관리 ( == 결함관리)

▶ 인시던트 관리 목적

 -  테스트에서 발견한 이슈에 대해 추가적으로 수행해야 할 일에 대해 보고하고 이를 추적하기 위함

 -  인시던트 보고서 : 실제 결과와 기대 결과 사이의 불일치를 작성

 - 기 발생된 결함에 대한 재 테스트인 경우 인시던트 보고서 상태 변경

 - 인시던트 혹은 결함은 프로그램 개발, 리뷰, 테스팅 혹은 소프트웨어 제품 사용 중에 발견되거나 발생.

▶ 인시던트 혹은 결함 보고서

 목적 :
   >> 개발자와 다른 프로젝트 이해관계자가 문제점을 식별하고, 격리하고, 필요하면 정정하도록 피드백 제공.
   >> 테스트 대상 시스템의 품질과 테스팅 진척도를 추적하는 수단을 테스트 리더에게 제공.
   >> 테스트 프로세스 개선에 대한 아이디어 제공.

 - 인시던트 및 결함은 발견 및 분류에서 수정 및 확인까지 추적

 - 인시던트와 결함을 처리할 수 있는 적절한 조치에 대한 정의

 - 모든 인시던트 완료까지 관리하기 위해 조직은 인시던트 관리 프로세스 및 분류 규칙을 설정 --> 결함 생명 주기

5.7 테스트 프로세스 평가

▶  테스트 프로세스

 - 조직을 셋업하고 운영하는 관점에서의 조직 테스트 프로세스

   >> 테스트 정책과 테스트 전략을 수립하고 적용하며 개선하는 프로세스

 - 프로젝트 전체 또는 특정 레벨 및 유형의 테스트를 위한 테스트 매니지먼트 프로세스

   >> 총괄적으로 수행할 테스팅을 레벨 또는 유형 별로 수행되도록 관리, 통제.

 - 테스트 수행 관점에서 동적 테스팅과 정적 테스팅을 구분하여 각각의 프로세스 

▶ 테스트 프로세스 개선 활동(점진적, 효과적, 지속적)

 - 기대효과 

   >> 정렬되고 조직화되며 반복적

   >> 전문적이고 공학적인 활동으로 인식

   >> 개발 활동과는 독립적으로 수행

   >> 결함 발견 활동에서 결함 예방 활동으로 변화

   >> 정량적으로 측정되고, 관련 데이터가 축적되며, 테스트 프로세스의 문제점을 파악

   >> 지속적으로 개선되고 향상

   >> 테스트 비용을 절감시키고 조직 구성원의 만족감을 고취시킴

5.1.1 테스트 조직과 독립성

** 테스팅은 테스터 뿐만 아니라 프로젝트 관리자, 품질 관리자, 비즈니스와 해당 분야 전문가, 인프라 또는 IT 운영자 등 다른 조직에 의해서도 수행 가능.

▶ 테스트 조직 생성 및 운영 시 고려할 사항

 - 개발 프로젝트와 조직의 목적에 부합하는 독립성 수준을 결정

 - 개발팀과 테스트 팀과의 의사소통 계획이 적절하게 수립

 - 독립성 수준을 정할 때 개발 산출물의 오픈 가능성을 고려

 - 조직의 규모에 따라 여러 형태의 독립성 수준의 테스트 조직을 운영

 - 개발팀과 테스트팀 간의 갈등을 초례할 수 있는 부분을 고려하여 테스트 정책을 수립하고 배포

5.1.2 테스트 리더와 테스터의 임무

▶ 테스트 리더(테스트 매니저, 팀 리더, 분석가)

 - 테스팅 활동과 업무를 계획하고 모니터링하고 제어하는 역할.

   >> 테스트 전략과 계획을 프로젝트 관리자 및 이해 관계자와 조정

   >> 프로젝트 테스트 전략과 조직의 테스트 정책을 작성하고 검토

   >> 테스팅 관점으로 통합적인 계획 활동 등 프로젝트 활동에 기여

   >> 정황과 테스트 목적, 리스크를 고려해 테스트 계획을 수립

   >> 테스트 명세(설계), 준비, 구현과 실행, 테스트 모니터링 및 완료 조건 평가등의 시작을 주도

   >> 테스트 결과와 진척에 따라 계획을 조정하고 문제점 보안을 위해 제어 활동 수행

   >> 추적성 확보에 필요한 테스트웨어 형상 관리 체계(시스템)를 구성

   >> 테스트 진척 및 품질 평가에 필요한 메트릭(점수를 도입할수 있는 평가표)을 도입
   >> 테스트 자동화 대상, 범위 방법을 결정
   >> 테스트 자동화 도구를 선택하고 관련 교육을 계획
   >> 테스트 환경 관련 사항을 결정
   >> 수집한 정보를 근거로 테스트 요약 보고서 작성

▶ 테스터(테스트 분석가, 수행가, 네비게이터)

 - 수립된 테스트 전략과 방형, 계획 및 테스트 리더의 지침에 따라 테스트 명세(설계)를 구현하고 실행하는 역할 수행

   >> 테스트 계획을 검토하고 테스트 계획을 이행

   >> 사용자 요구사항, 명세, 모델 등을 분석하여 테스트 용이성을 평가

   >> 테스트 명세를 작성

   >> 필요시 시스템 또는 네트워크 관리 조직과 협의하여 테스트 환경 구축

   >> 테스트 데이터를 준비하고 수집

   >> 모든 테스트 레벨에서 테스트를 구현하고, 테스트를 실행하고 기록하며, 실행 결과를 분석하여 기대 결과와의 차이를 문서화.

   >> 필요시 테스트 운영 및 관리 도구, 테스트 모니터링 도구를 사용.

   >> 테스트를 자동화(개발자나 테스트 자동화 전문가로부터 지원받음)

   >> 컴포넌트나 시스템의 성능을 측정(성능 측정 결과가 필요한 경우)

   >> 동료가 작성한 테스트를 리뷰

5.2.1 테스트 계획

▶ 테스트 계획

 - 테스팅 목적, 테스트 범위, 필요한 자원 그리고 일정을 결정하는 등의 업무를 수행하는 활동

 - 조직 차원의 테스트 정책 및 전략, 테스트 범위, 목적, 제품의 리스크, 프로젝트 리스크, 제약사항, 심각성, 테스트 용이성 그리고 자원의 가용성에 영향을 받음

 - 테스트 생명주기 전반에 관여하는 지속적인 작업

- 테스트 목적/ 목표 설정 및 대상 연구
- 테스트 전략 개발 : 리스크 분석, 전략 수립
- 테스트 종료 조건
- 테스트 추정
- 조직 구성
- 테스트 계획
- 테스트 관리 및 제어
- 모니터링(리포팅) : 리포팅 계획 / 설계, 진행 리포팅 

 - 여러 레벨의 테스팅 또는 비기능 테스팅 등을 총괄적으로 지휘하고 조율하며 통제하는 목적을 가짐.

▶ 레벨 테스트 계획

 - 마스터 테스트 계획 (인수 테스트, 시스템 테스트, 통합 테스트, 단위 테스트, 이식성 테스트, 성능 테스트, 사용성 테스트, 보안 테스트)

 - 각 테스트 레벨에서 수행할 테스트 활동을 기술(마스터 테스트 계획의 내용을 상세하게 기술, 테스트 레벨의 계획서를 별도로 작성)

 - 마스터 테스트 계획에서 다루지 않는 세부 스케줄, 업무, 마일스톤 등을 작성.

 - 각 테스트 레벨에서의 테스트 세부사항은 각각의 레벨 테스트 계획에서 다룸.

 - 비공식적인 프로젝트나 운영환경에서는 주로 하나의 테스트 레벨만 운용하며 이러한 경우 하나의 테스트 계획 문서에 레벨 테스트 계획과 마스터 테스트 계획 내용이 모두 다루어짐. 

5.2.2 테스트 계획 활동 내용

▶ 테스트 계획의 주요 활동

 - 테스트를 성공적으로 수행하기 위한 전략을 수립하는 것과 소프트웨어 생명주기 단계별로 적합한 테스팅 관련 작업들을 결정하고, 테스트 대상, 범위 그리고 전략에 기반한 투입자원 및 일정을 계획하는 활동을 포함.

   >> 테스트 범위와 리스크, 테스팅의 목적을 식별 및 결정

   >> 테스트 접근법 정의(테스트 레벨, 테스트 시작/ 종료 조건)

   >> 테스트에 필요한 리소스의 결정(인원, 테스트 환경, PC 등)

   >> 테스트 분석과 설계 작업의 스케줄링

   >> 테스트 구현, 실행 및 평가의 스케쥴링

   >> SW 개발주기(계획)에 테스트 활동 통합(구매, 공급, 개발, 운영, 유지보수)

   >> 테스트 업무와 역할, 테스트 대상, 테스트 업무 종료 방법, 테스트 결과 평가 방법 등 결정

   >> 테스트 문서의 분량, 상세 정도, 문서 구조와 템플릿 정의

   >> 테스트 준비와 실행, 결함 해결과 발생 등의 프로젝트 리스크에 대한 모니터링과 제어에 필요한 메트릭(평가방법 표) 결정

   >> 원활한 테스트 준비와 실행을 위해 테스트 프로시저(절차) 상세 수준을 결정

5.2.3 완료 조건

 - 테스트 시작 기준 : 테스트 수행 시작 시점과 테스트 수행 준비 조건을 정의

 - 테스트 종료 기준: 테스팅 종료 시점과 테스트 수행 목표 달성 조건 정의

 - 리스크 레벨(수준) 별로 테스트 종료 기준 수립

 - 각 테스트 레벨 별로 종료 기준 수립

5.2.4 테스트 추정

▶ 테스트 추정

 - 테스트 노력을 산정

 - 테스트 매니지먼트의 일환으로, 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정.

▶ 기능 정수 TPA

 - 기능 점수 : 개발에 어려움 정도를 반영 ( 라인수, 비용 사정에 사용 )

 - TPA(Test Point Analysis): 테스트의 어려움 분석( 어려움을 분석하여 테스트의 노력을 체계적으로 산정 )

5.2.5 테스트 접근법, 전략

▶ 테스트 접근법 또는 전략

 - 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정.

 - 방법 : 

   >> 예방적 접근법 : 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계

   >> 사후 접근법 : 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계

4.6 소프트웨어 특성에 따른 테스팅

▶ ISO/ IEC 9126 품질 모델의 품질 특성 기준

 - 특성 테스팅(6가지 테스팅 - 기능성 >> 기능적인 테스팅, 나머지 5개 >> 비기능적인 테스팅)

   >> 기능성(35%) /신뢰성 (15%)/ 효율성(25%)/ 사용성(10%)/ 이식성(10%)/ 유지보수성(5%)

 - 기능성 

   >> 요구되는 기능 및 성능을 만족시키는 능력(수치 데이터).

   >> 제품에 대한 기술 문서인 제품 기능 정의서와 사용자 요구 문서 등에 언급된 모든 기능을 테스트 케이스로 작성 --> 기능 하나하나에 대해 작성.

   >> 기능성에 해당하는 품질 부특성.(이런 게 있나 보다 정도로 알고 있으면 돼)

- 신뢰성

   >> 규정된 시스템 환경에서 결함 없이 의도한 기능 및 작업을 수행하는 소프트웨어의 능력.

   >> 여러 상황의 조합 또는 예외 상황의 처리 능력을 확인하는 절차를 테스트 케이스로 작성

   >> 신뢰성에 해당하는 품질 부특성

 - 사용성

   >> 사용자가 이해하고 배우기 쉬운 정도를 의미

   >> UI나 어떤 기능을 실행하기 위한 순서, 내용 및 처리 메시지가 적절한지 등을 확인하기 위한 테스트 케이스 작성.

   >> 사용성에 해당하는 품질 부특성

 - 효율성

   >> 자원의 적절한 사용 및 적정한 반응시간 정도로 정의

   >> 어떤 기능을 수행하거나 정보를 출력할 때 처리 시간과 자원 사용량이 적절한지를 확인하는 내용을 테스트 케이스로 작성.

   >> 효율성에 해당하는 품질 부특성

 - 유지보수성

   >> 소프트웨어의 수정 및 변경의 용이성

   >> 소프트웨어상에서 변경이 발생하거나 기존의 시스템을 다른 시스템으로 교체하는 경우에 작업 절차가 용이한지에 대해 확인하는 과정을 테스트 케이스로 작성

   >> 유지보수성에 해당하는 품질 부특성

-이식성

   >> 지원하는 다양한 운영환경에서 운영될 수 있는 소프트웨어의 능력

   >> 지원하는 모든 시스템 환경에서 제품이 정상적으로 실행되는지 확인하는 과정과 해당 운영 환경에서 실행되고 있는 다른 프로그램과의 호환성에 대한 내용을 테스트 케이스로 작성

   >> 이식성에 해당하는 품질 부특성

** 테스트 종류에 대한 용어 정리

4.4.2 구조 기반 기법
4.4.2.1 분할 방법으로 접근한 조건 / 결정 커버리지

 - 분할 

   >> 논리적 테스트 컬럼의 각각을 선택한 커버리지로 생성한 모든 논리적 조합으로 분할하여 테스트 케이스를 작성하는 방식.

   >> 모든 조합을 분할해서 나열하기 때문에 결함 원인은 매우 빨리 발견할 수 있지만 테스트 케이스 수가 크게 증가함.

 - 포함

   >> 논리적 테스트 컬럼의 각각의 선택한 커버리지

   >> 생성한 조합 중에서 단 하나만 선택하여 하나의 논리적 테스트 케이스로 작성하는 1:1 전환 방식(테스트 케이스 줄임)

 - 결정 테이블을 분할로도 만들수 있고 분할돼있는 걸 포함해서 다시 만들어낼 수 있음.

4.4.3 경험 기반 기법
4.4.3.1 오류 추정

 - 테스터가 테스트 할 시스템에 대하여 완전히 이해한다는 전제로 적용되는 기법.

 - 취약점 식별 작업에 기반한 테스트.

 - 테스트 프로세스의 마지막 단계에서 사용.

 - 일반적인 유용성

   >> 테스트에 참고할 명세가 없거나 불충분할 경우, 시간적인 압박이 심한 경우 유용.

   >> 다른 기법이나 공식적인 테스트를 보완할 때 유용하게 사용.

   >> 가장 심각한 결함을 찾았다는 확신이 필요한 경우 사용함으로써 테스트 프로세스 및 완성도를 확인하는 기준을 제공.

4.4.3.2 체크리스트

▶ 체크리스트

 - 테스팅 절차와 테스트 대상 기능 및 시스템 요소 등을 체크리스트로 작성함.

 - 일반 체크리스트 : 수행해야 할 테스트 목록과 절차를 나열함.

 - 기능(블랙) 체크리스트

   >> 전체 시스템의 최상위 기능 체크

   >> 개별적인 컴포넌트 기능

   >> 서로 다른 레벨의 기능과 그룹핑

 - 시스템 요소 체크리스트

   >> 상위 레벨 서브 - 시스템이나 모듈

   >> 개인 구문이나 데이터 아이템 체크

   >> 서로 다른 레벨의 시스템 요소와 그룹핑 체크

▶ 체크 리스트와 테스트 케이스 비교

 - 체크 리스트

   >> 경험과 노하우의 반영물이어서 테스트를 효율적으로 진행할 수 있음.

   >> 효과성은 없음.

   >> 테스트 베이시스에서 결함을 발견하는 데 주로 사용되어서 정적 테스트기법의 주요 도구 사용.

 - 테스트 케이스

   >> 동적 테스팅의 주요 도구가 됨.

   >> 기법을 적용하여 도출되는 경우가 대부분이고 기법이 보장하는 범위에서 효과성을 보장해줌.

4.5 테스트 기법의 선택

▶ 어떤 테스트 기법을 사용할지 결정할 때 고려할 사항
 - 시스템 유형 및 특징
 - 강제적 표준 또는 법적 기준 적용 여부
 - 고객 또는 계약상의 요구사항
 - 리스크 수준
 - 리스크 유형
 -테스트 목표
 - 문서(베이시스)의 존재 여부
 - 테스터의 지식수준
 - 시간과 예산
 - 테스트 레벨
 - 개발 생명 주기
 - 유즈케이스, 상태 다이어그램 등 개발 설계 모델 존재 여부(있다면 이용, 없다면 새로 만들어)
 - 발견된 결함 유형 등 이전의 경험

▶ 테스트 기법을 잘 사용하게 되면...

 - 테스트 전략을 구체적으로 해석해 적절한 기법을 적용

 - 임의로 테스트 케이스를 작성하는 것보다 결함을 발견할 수 있는 효과적인 테스트 케이스 작성 가능(결함 발견율 높아짐)

 - 테스트(케이스)의 높은 재사용성 보장

 - 테스트 강도(커버리지)와 품질에 대한 통찰을 제공

4장은 솔직히 시험에선 그렇게 안 중요하데. 시험에 잘 안 나오나 봐.

근데 중요한 내용이긴 하니까 알아두자고.

유튜브 김기태의 java를 자바의 sw 테스팅을 보면서 공부를 하고 있는데 아무래도 예전 강의라 그런지 실라버스에 있는 내용과 약간씩 달라지는 내용이 있는 것 같다. 올라와 있는 강의를 다 보고 최신 버전으로 나온 실라버스로 다시 정리를 하면서 공부를 해야겠다. 그래도 이쪽 공부를 새롭게 하다 보니 점점 재밌어지고 있어서 나름 만족감과 즐거움을 느끼고 있다.

4.4.1.2 명세기반 기법 - 페어와이즈 조합 테스팅

▶ 페어와이즈 조합 테스팅

 - 페어와이즈 관찰 결과 대부분의 결함이 2개 요소의 상호 작용에 기인하여 나타남.

 - 페어와이즈는 테스트 하는데 필요한 각 값들이 다른 파라미터의 값과 최소한 한 번씩은 조합을 이루게 된다는 것.

 - 3개의 파라미터가 각 5,4,5가지 값을 가질 때 100가지에서 만약 테스트를 100가지 경로로 하게 되면 10000개의 테스트를 실행해야 함 --> 조합을 최소화 함.

* 동작 모드와 설정 파라미터의 각 값들을 중복되지 않게 배열하고, 이퀄라이저의 값을 동작모드와 설정 값과 순차적으로 중복되지 않게 배정하기.

4.4.1.3 직교 배열 테스팅 (거의 잘 안 써서 이런 게 있다 정도로만 알아두면 돼)

▶ 직교 배열 테스팅

 - 6-시그마 기법에 이용되고 있으며 소프트웨어 테스트에 적용하여 사용되고 있음.

(6-시그마 : 프로세스의 품질을 개선하기 위한 방법. 결함을 최소화하고 효율성을 높이기 위해 사용되는 통계적인 기법)

 - 직교 배열의 원리를 소프트웨어 테스트에 적용하여 조합의 수를 줄임으로써 테스트 케이스의 수를 합리적으로 줄임.

 - 직교 배열에서 열과 행이 페어와이즈 하다는 것은 직교 배열의 각 행과 열의 조합이 서로 다르다는 것을 의미함.

 - L4(2^3) 

궁금해서 찾아본 < L(런 수)(수준 수 ^ 요인 수) 표기 >
 - L(런 수) = 런 수 = 조합수(라인수) == 배열의 행 수. 즉 생성될 테스트 사례 수
 - (수준 수 ^ 요인 수) = 각 요인의 수준 수 ^ 요인 수
런수 : 조합수(라인수).
요인 : 처리할 수 있는 최대 변수 수로 변환되는 배열의 열 수. (파라미터)
수준 : 단일 요인에 사용할 수 있는 최대 값 수. (값)
ex) L8 설계에는 런이 8개 있음. (2^3) 또는 (2 3)은 수준이 2개인 요인이 3개 있음을 나타냄.
L(런 수)(숫자 ^ 지수 개수 ^ 지수) 형태의 표기인 경우 혼합 수준 설계를 나타낸다.
L18(2^1 3^7)은 설계에 런 18개와 수준이 2개인 요인 하나와 수준이 3개씩인 요인 7개가 있음을 나타낸다.

*참고 자료 - 직교 배열 테스트란 무엇인가.
https://www.guru99.com/ko/orthogonal-array-testing.html

4.3.3 경험 기반 기법(Experience-based)

▶ 경험 기반 테스팅
 - 이전에 테스터가 다루었던 유사 어플이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스 추출.
 - 공식적인 방식 아닌 특별한 테스트 케이스를 찾아내고 실행하는 데 유용 -- > 공식적인 기법과 같이 사용해야 효과적
 - 경험에 따라 효율성 및 효과성의 정도가 매우 달라짐(일관성 떨어짐)
 - 테스트 케이스를 문서화함
 - 또 다른 말로 에러 추정(Error guessing) 또는 탐색적 테스팅(Exploratory Testing) 접근법이라 함

4.3.3.1 탐색적 테스팅 기법

▶ 탐색적 테스팅 : 기법이 아닌 접근법
 - 테스트 케이스 작성 시간을 최소화하고 테스트 엔지니어의 발견적인(heuristic) 지적능력을 최대한 활용하여 테스트 수행
 - 다른 명칭으로 에드혹, 게릴라, 직관적 테스팅과 유사한 개념
   >> But, 정해진 임무와 목표, 결과물이 존재
 - 테스트를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서 익숙해지는 동시에 테스트를 설계하고 테스트를 계획한다.
   >> 테스트 차터를 기반으로 수행(60 ~ 120분 동안 몰입해서 수행)
   >> 제한된 시간(time-boxing)내에 테스팅의 목적을 정한 후  몰입하여 최소한의 설명 가능한 기록(note)을 남기며 테스트 수행하고, 수행 후 요약보고(debriefing)를 하는 것을 강조.
▶ 탐색적 테스팅
 - 경험적인 요소를 많이 반영하고 있는 체계화된 테스팅 접근법
 - 테스트 케이스 작성(문서화)하는데 들이는 노력을 최소화
 - 테스트 설계와 실행 최대화
 - 점진적 & 주기적 테스팅
▶ 탐색적 테스팅 절차
 - 제품의 목적 식별
 - 기능 식별
 - 잠재적으로 불안정한 부분 식별
 - 각각의 기능 테스트 및 문제점 기록
 - 일관성 검증 테스트 설계 및 기록
▶ 탐색적 테스팅의 구성 요소 (테스터 차터 >> 테스트 노트 >> 타임 박싱 >> 회고)
 - 테스터 차터
   >> 제품의 어느 부분을 어떻게 테스트하고 어떤 것을 중점적으로 봐야 할지 등을 기록한 테스트 명령지
   >> 각 세션에 대해 명확한 임무를 설정
 - 테스터가 수행할 내용
   >> 정확한 리포팅
   >> 유연성 있는 일정 관리
   >> 테스트 방향 정정
   >> 견고한 테스팅
   >> 효율적인 요약 보고
- 테스트 노트
   >> 테스트 실행과 동시에 계획, 설계, 테스트 케이스 작성 --> 노트화 함
   >> 테스트 기록 및 발견 특이사항과 실행시간 등 기재 --> 테스트 케이스
   >> 내용 : 테스트한 제품에 대한 노트 및 기록, 발견한 결함과 장애에 대한 노트 및 기록, 어떻게 테스트하였는지를 기술하는 요약된 문서.
- 타임 박싱(60분 ~ 120분)
   >> 테스트 집중력을 높이기 위해 테스트 시간을 제한
   >> 테스트 시간을 제한하면 집중력이 높아지며, 테스트 일정 수립도 쉬움
- 회고(요약보고 - debriefing)
   >> 테스트 중 발견했던 결함과 이슈사항에 대해 보고
   >> 테스터의 경험과 지식을 공유
   >> 문서화 
▶ 테스트 케이스 기반 테스팅과 탐색적 테스팅 비교
 - 테스트 제품을 파악해 가면서 테스트 실시
 - 탐색적 테스트는 테스터의 성향에 많이 의존적임
 - 문서화 정도와 지적 능력의 활용 정도에 따른 비교 

   >> 테스팅 케이스 기반(연설문을 만든다 -문서화하는 능력) - 문서화가 잘 돼있을수록 테스트케이스 기반 테스팅 할 수 있음.
   >> 탐색적 테스팅(경험에 의해 하는거 - 지적 능력) - 지적능력이 있을수록 탐색적 테스팅할 수 있음.
 - 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교 (밑에 표)

▶ 리스크 기반 테스팅과 연계한 탐색적 테스팅의 활용
 - 리스크 기반 전략에서의 탐색적 테스팅 접근법 활용 
테스트 전력 수립 시 제품의 리스크가 가장 높은 곳에 탐색적 테스팅을 추가, 그다음 높은 곳에 선택적 탐색적 테스팅 추가. 리스크가 가장 높은 곳에 테스팅 경험이 풍부하고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행하여야 함. 반대로 리스크가 가장 낮은 곳에 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행.
▶ 탐색적 테스팅 효과
 - 경험적 테스팅을 체계화 시킬 수 있음.
 - 테스트 케이스 작성 시간을 줄여 좀 더 많은 테스트 가능
 - 테스터 또는 테스트 엔지니어의 역량을 강화할 수 있음.
 - 적은 테스트 인력으로 많은 테스트를 수행할 수 있음.
 - 명세가 없고 시간 부족인 경우 테스트를 효과적으로 효율적으로 수행할 수 있음.

4.4.1 명세 기반 기법 - 분류 트리 기법

▶ 분류 트리 기법
 - 소프트웨어 일부 또는 전체를 트리구조로 분석 및 표현하고 이를 바탕으로 테스트 케이스를 도출하는 기법.

 < 분류 트리의 장점 >
1. 시각화해서 테스트 케이스 작성에 용이.
2. 트리 구조이므로 중복되거나 빠지는 테스트가 없음.
3. 복잡한 시스템이나 어플리케이션의 일부 또는 전체를 테스팅.
4. 개발 설계를 체크하는 용도로 사용이 가능함.
5. 테스트 케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능함.