1. 테스트 프로세스에서 테스트 분석가의 역할

목차

1. 테스트 프로세스에서 테스트 분석가의 역할 

1.1 소개 

1.2 소프트웨어 개발 수명주기에서의 테스팅

 - 서로 다른 소프트웨어 개발 수명주기 모델마다 테스트 분석가 참여 시기 및 수준이 어떻게 왜 다른지

1.3 테스트 분석

 - 분석 활동 진행 시 테스트 분석가의 적절한 업무 요약

1.4 테스트 설계

 - 이해관계자들이 테스트 컨디션을 이해해야 하는 이유

 - 주어진 프로젝트 시나리오에 적합한 테스트 케이스 설계 수준 선택

 - 테스트 케이스 설계에서 고려해야 할 문제 설명

1.4.1 하위 수준 및 상위 수준 테스트 케이스

1.4.2 테스트 케이스 설계

1.5 테스트 구현

 - 테스트 구현 활동 수행 시 테스트 분석가의 적절한 업무 요약

1.6 테스트 실행

 - 테스트 실행 활동 수행 시 테스트 분석가의 적절한 업무 요약

---

 

1.1 소개

ISTQB에서 테스트 프로세스는 다음 활동을 포함한다.

 - 테스트 계획, 테스트 모니터링 및 제어, 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행, 테스트 완료

이 시험에서는 테스트 분석가와 관련 있는 활동을 더 심도있게 다룬다. 

이를 통해 다양한 SDLC(소프트웨어 개발 수명주기) 모델에 보다 적합하도록 테스트 프로세스를 추가로 개선 가능

테스트 분석가가 일반적으로 더 중점을 두는 활동은 다음과 같다.

 - 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 

 

1.2 소프트웨어 개발 수명주기에서의 테스팅

테스트 전략 정의 시 전체 SDLC를 고려, 테스트 분석가의 참여 시기는 SDLC에 따라 달라진다. 

참여 수준, 소요 시간, 이용 가능한 정보나 기대값도 상당히 다를 수 있다.

테스트 분석가는 다음과 같은 조직 내 다른 역할 관련 부서에 전달하는 정보 유형에 대해 인지해야 한다. 

 - 요구 공학과 관리 (요구사항 리뷰 피드백)

 - 프로젝트 관리 (일정 입력)

 - 형상 및 변경 관리 (빌드 검증 테스팅 결과, 버전 관리 정보)

 - 소프트웨어 개발 (식별된 결함 알림)

 - 소프트웨어 유지보수 (결함, 결함 제거. 효율성 및 확인 테스팅에 대한 보고서)

 - 기술 지원 (해결 방법 및 알려진 문제에 대한 정확한 문서)

 - 기술 문서 작성 (설계 사양이나 테스트 환경 문서)

 

테스팅 활동은 그 특성이 순차적, 반복적, 점진적이거나 그 모든 것이 혼합으로 선택한 SDLC에 맞춰 조정 필요

 

예를 들어 순차적 v 모델에서 시스템 테스트 레벨에 적용된 테스트 프로세스는 다음과 같이 조정 가능하다.

 - 시스템 테스트 계획은 프로젝트 계획과 동시에 이루어지며 테스트 모니터링 및 제어는 테스트 완료시까지 계속

   이는 프로젝트 관리 목적으로 테스트 분석가가 제공하는 일정에 영향 받는다. 

 - 시스템 테스트 분석 및 설계는 시스템 요구사항 명세, 시스템 및 아키텍처 설계 명세, 컴포넌트 설계 명세등 문서에 맞춰 조정 가능

 - 시스템 테스트 실행 시작 전까지 시스템 테스트 구현 활동에 대한 작업이 자주 발생하며, 시스템 테스트 환경의 대부분은 일반적으로 코딩 및 컴포넌트 테스트와 동시에 시작되지만, 시스템 테스트 환경 구현은 시스템 설계 중 시작할 수 있다.

 - 시스템 테스트 시작 기준이 충족되면 시스템 테스트 실행이 시작되며, 이는 최소한 컴포넌트 테스팅 및 컴포넌트 통합 테스팅이 종료 기준 충족을 의미. 시스템 테스트 종료 기준이 충족될 때 까지 시스템 테스트 실행 계혹

 

반복적, 점진적 모델은 동일한 활동 순서를 따르지 않을 수 있으며 일부 활동은 제외될 수 있다. 

 

애자일 소프트웨어 개발에서는 

 

적용되는 SDLC가 무엇이든, 테스트 분석가는 참여에 대한 기대와 참여 시기를 이해한다.

테스트 분석가는 사전에 정의된 역할 모델을 고수하는 대신 특정 SDLC에 대한 활동과 참여 시점을 조정해 소프트웨어 품질에 기여

 

1.3 테스트 분석

테스트 계획 중 테스트 프로젝트의 범위가 정해진다. 

테스트 분석 중에 테스트 분석가는 정의된 범위에 다음을 수행한다.

 - 테스트 베이시스 분석

 - 테스트 베이시스에서 다양한 유형의 결함 식별

 - 테스트 컨디션과 테스트 대상 기능을 정하고 우선순위화

 - 테스트 베이시스 각 요소와 관련된 테스트 컨디션 간 양방향 추적성 설정

 - 리스크 기반 테스팅과 관련된 작업 수행 

 

테스트 분석가가 테스트 분석을 효과적으로 수행하려면 다음과 같은 시작 조건 충족 필요

 - 테스트 베이시스 역할을 할 수 있는 테스트 대상을 기술한 지식 체계 필요 (요구사항, 사용자 스토리 등)

 - 테스트 베이시스는 합리적인 결과와 함께 리뷰를 통과하고, 리뷰 후 필요에 따라 업데이트

   상위 수준 테스트 케이스 정의해야 하는 경우, 테스트 베이시스를 완전히 정의하지 않아도 괜찮다.

   애자일 소프트웨어 개발은 반복이 시작될 때마다 사용자 스토리가 구체화되므로 리뷰 주기가 반복

 - 이 테스트 대상에 대한 나머지 테스팅 작업을 마치는 데 사용 가능한 승인된 예산과 일정이 있다. 

 

테스트 컨디션은 일반적으로 테스트 계획에 정의된 대로 테스트 목적과 함께 테스트 대상을 분석해 식별

문서가 오래되거나 존재하지 않는 경우 관련 이해관계자와 논의 후 테스트 컨디션 식별

애자일 소프트웨어 개발에서는 사용자 스토리 일부로 정의한 인수 기준은 종종 테스트 설계의 베이시스로 사용

테스트 컨디션은 보통 테스트 대상에 따라 다르지만 테스트 분석가에게는 몇 가지. 표준 고려사항이 존재

 - 여러 단계로 테스트 컨디션 정의. 처음에는 테스트 일반 대상을 파악하기 위한 상위 수준의 조건 식별. 최종적으로는 특정 테스트 케이스의 베이시스로 정의되는 보다 상세한 조건 식별. 테스트 컨디션을 정의하기 위해 이런 유형의 계층적 접근법을 사용하면 상위 항목에 커버리지가 충분하도록 보장할 수 있다. 이런 접근법으로 테스트 분석가는 아직 구체화되지 않은 사용자 스토리에 대한 상위 수준 테스트 컨디션을 정의하는 작업을 시작 가능

 - 제품 리스크가 정의된 경우 각 제품 리스크를 해결하는 데 필요한 테스트 컨디션을 식별하고 해당 리스크 항목을 추적

 

테스트 기법(테스트 전략이나 테스트 계획 내에서 식별된)의 적용은 테스트 분석 활동에 도움이 될 수 있으며 다음의 목적을 지원한다.

 - 테스트 컨디션 식별

 - 중요한 테스트 컨디션에 누락될 가능성 감소

 - 보다 정밀하고 정확한 테스트 컨디션 정의

 - 테스트 컨디션을 식별하고 정의한 후 요구사항을 명확하게 이해하고 테스팅이 프로젝트 목적과 일치하는 지 확인하기 위해 이해관계자와 이런 조건 리뷰 가능

 

 특정 영역에 대한 테스트 분석 활동이 끝나면 테스트 분석가는 해당 영역에 대해 어떤 테스트를 설계해야 하는 지 알아야 한다. 

 

1.4 테스트 설계

테스트 계획 중 결정된 범위를 여전히 준수하면서 테스트 분석가가 구현하고 실행할 테스트를 설계함에 따라 테스트 프로세스는 계속 진행된다. 테스트 설계는 다음 활동이 포함된다. 

 - 하위 수준 또는 상위 수준 테스트 케이스의 적용이 적합한 테스트 영역을 결정

 - 필요한 커버리지를 달성할 수 있는 테스트 기법 결정. 적용 가능한 기법은 테스트 계획 중 확립

 - 식별된 테스트 컨디션을 포함하는 테스트 케이스와 테스트 케이스 세트를 설계 기법으로 설계

 - 테스트 컨디션과 테스트 케이스를 지원하기 위해 필요한 테스트 데이터 식별

 - 테스트 환경 설계 및 필요한 인프라 식별 (도구 등)

 - 양방향 추적성 결정 (테스트 베이시스, 테스트 컨디션 및 테스트 케이스 건)

 

리스크 분석 및 테스트 계획 중 식별된 우선순위 기준은 분석/설계에서 구현/실행에 이르기까지 프로세스 전체에 적용

설계 중인 테스트 유형에 따라 테스트 설계 시작 기준의 하나가 설계 작업에 사용할 도구의 가용성일 수 있다. 

 

테스트 설계 중 테스트 분석가는 다음을 고려한다.

 - 일부 테스트 항목은 테스트 실행에 필요한 일련의 명령을 제공하는 테스트 스크립트의 정의로 진행하기 보다 테스트 컨디션만 정의함으로써 더 잘 다루어진다. 이 경우 테스트 컨디션은 스크립트되지 않은 테스팅을 위한 가이드로 사용되도록 정의한다.

 - 합격/불합격 기준을 명확하게 식별한다.

 - 테스트는 저자뿐만 아니라 다른 테스터가 이해할 수 있도록 설계돼야 한다. 저자가 테스트를 수행하는 사람이 아닌 경우 다른 테스터는 테스트 목적과 테스트의 상대적 중요성을 이해하기 위해 이전에 지정된 테스트를 읽고 이해해야 한다. 

 - 테스트를 리뷰할 개발자나 테스트를 승인해야 하는 감시자와 같은 다른 이해관계자도 테스트를 이해할 수 있어야 한다. 

 - 테스트는 사용자가 인식할 수 있는 인터페이스를 통한 사람들 사이의 상호작용만으로 제한돼서는 안되며, 테스트 대상과의 모든 유형의 상호작용을 다루어야 한다. 예를 들어, 다른 시스템과의 상호작용이나 기술 또는 물리적 이벤트가 테스트에 포함될 수 있다.

 - 테스트는 다양한 테스트 아이템 간 인터페이스는 물론, 아이템 자체 동작을 테스트하도록 설계한다.

 - 리스크 수준과 비즈니스 가치에 맞도록 테스트 설게 노력의 우선순위를 정하고 균형을 유지한다. 

 

1.4.1 하위 수준 및 상위 수준 테스트 케이스

테스트 분석가 역할 중 하나는 주어진 상황에 가장 적합한 테스트 케이스 설계 수준을 결정하는 것.

하위 수준 및 상위 수준 테스트 케이스는 ISTQB FL SYL에서 다룬다. 

이들을 사용하는 장점과 단점 중 일부는 다음과 같다.

 

하위 수준 테스트 케이스는 다음과 같은 장점을 제공한다.

 - 경험이 없는 테스터는 프로젝트에서 제공하는 상세 정보에 의존할 수 있다. 하위 수준 테스트 케이스는 테스터가 테스트 케이스를 실행하고 실제 결과를 확인하는 데 필요한 모든 특정 정보와 절차를 제공한다.

 - 다른 테스터가 테스트를 재실행할 수 있으며 동일한 테스트 결과를 얻어야 한다.

 - 테스트 베이시스에서 불분명한 결함이 드러날 수 있다.

 - 필요한 경우 상세 수준은 감사(audit)와 같은 테스트의 독립적인 검증을 가능하게 한다.

 - 자동화된 테스트 케이스 구현에 소요되는 시간을 줄일 수 있다. 

 

하위 수준 테스트 케이스는 다음과 같은 단점을 제공한다.

 - 작성과 유지 관리에 많은 노력이 필요하다.

 - 실행하는 동안 테스터의 독창성을 제한하는 경향

 - 테스트 베이시스를 잘 정의해야 한다.

 - 테스트 컨디션에 대한 추적성은 상위 수준 테스트 케이스보다 더 많은 노력이 필요하다.

 

상위 수준 테스트 케이스는 다음과 같은 장점을 제공한다.

 - 테스트 대상에 대한 지침을 제공하고 테스트 분석가가 실제 데이터 또는 테스트를 실행할 때 따라야 하는 절차를 변경 가능

 - 실행할 때마다 조금씩 다를 수 있기 때문에 하위 수준 테스트 케이스보다 더 나은 리스크 커버리지 제공 가능

 - 요구사항 프로세스 초기에 정의 가능

 - 테스트가 실행될 때 테스팅과 테스트 대상에 대한 테스트 분석가의 경험을 활용

 - 상세하고 공식적인 문서가 필요하지 않을 때 정의할 수 있다.

 - 서로 다른 테스트 데이터를 사용할 수 있는 경우 다른 테스트 주기에서 재사용하기에 더 적합

 

상위 수준 테스트 케이스는 다음과 같은 단점이 있다.

 - 재현성이 떨어지기에 검증이 어렵다. 하위 수준 테스트 케이스에 대한 자세한 설명이 없기 때문이다.

 - 실행 시 보다 숙련된 테스터가 필요할 수 있다.

 - 상위 수준 테스트 케이스를 기반으로 자동화 할 때 세부 정보의 부족으로 잘못된 실제 결과를 검증하거나 검증해야 할 항목이 누락될 수 있다. 

 

요구사항이 더 상세하게 정의되고 안정화되면 상위 수준 테스트 케이스를 사용해 하위 수준 테스트 케이스를 개발할 수 있다.

이 경우 상위 수준에서 하위 수준으로 순차적으로 작성하며, 하위 수준의 테스트 케이스만 실행에 사용하게 된다. 

 

1.4.2 테스트 케이스 설계

테스트 케이스는 테스트 기법을 사용해 파악한 테스트 컨디션을 단계별로 정교화하고 세분화 해 설계한다.

테스트 케이스는 반복 가능하고 검증 가능하며 테스트 베이시스까지 추적할 수 있어야 한다. 

테스트 설계에는 다음 사항이 포함된다.

 - 목적 

 - 프로젝트 또는 현지화된 테스트 환경 요구사항과 전달 계획, 테스트 실행 전 시스템 상태 등 사전 조건

 - 테스트 데이터 요구사항 (테스트 케이스의 입력 데이터 및 테스트 케이스 실행을 위해 시스템에 존재해야 하는 데이터)

 - 명시적인 합격/불합격 기준을 가지는 예상 결과

 - 영향을 받는 데이터, 테스트 실행 후 시스템 상태, 후속 처리를 위한 트리거 등 사후 조건

 

특정 문제는 하나의 테스트에 대한 예상 결과를 정의하는 것이다.

예상 결과를 확인하는 데 있어 테스터는 화면의 출력뿐 아니라 데이터와 환경적 조건에도 관심을 가져야 한다.

테스트 베이시스가 명확하게 정의되면 올바른 결과를 식별하는 것이 이론적으로 간단해야 한다.

그러나 테스트 베이시스 문서는 모호하거나 모순되거나 주요 영역에 대한 커버리지가 없거나 완전히 누락됐을 수 있다.

이 경우 테스트 분석가는 전문 지식을 갖추고 있거나 전문 지식에 접근할 수 있어야 한다.

 

테스트 베이시스가 명확하게 정의돼 있어도 복잡한 입출력의 상호작용은 예상 결과 정의를 어렵게 만들 수 있다.

따라서 테스트 오라클이 필수적이다. 애자일 소프트웨어 개발에서 테스트 오라클은 프로젝트의 제품 오너가 될 수 있다.

실제 결과의 정확성을 판단할 방법이 없는 테스트 케이스 실행은 부가가치나 이점이 매우 낮을 수 있으며, 종종 시스템에 잘못된 테스트 보고서 또는 잘못된 신뢰를 생성한다.

 

테스트 베이시스는 달라질 수 있지만 위에서 설명한 활동은 모든 테스트 레벨에 적용할 수 있다.

테스트를 분석하고 설계할 때 테스트의 목적뿐 아니라 목표 수준을 기억하는 것이 중요하다.

이는 요구되는 세부사항 수준 뿐 아니라 필요한 도구를 결정하는 데 도움이 된다. 

 

테스트 컨디션과 테스트 케이스를 개발하는 동안 일반적으로 어느 정도의 문서화가 진행돼 테스트 작업 산출물이 생성된다.

실제로 테스트 작업 산출물이 문서화되는 정도는 상당히 다양하며, 이는 다음 중 하나에 의해 영향을 받을 수 있다.

 - 프로젝트 리스크 (문서화 필수거나 필수가 아닌 대상)

 - 문서화가 프로젝트에 제공하는 부가가치

 - 준수해야 할 표준이나 규정

 - SDLC 또는 적용된 접근법

 - 테스트 베이시스에서 테스트 분석과 설계를 통한 추적성 요구사항

 

테스팅 범위에 따라 테스트 분석과 설계는 테스트 대상의 품질 특성을 다룬다. (ISO25010 표준은 유용한 참조 자료 제공)

하드웨어 / 소프트웨어 시스템을 테스트 할 때 추가 특성이 적용될 수 있다.

 

테스트 분석과 설계 활동은 리뷰 및 정적 분석과 함께 향상될 수 있다.

실제로, 테스트 분석과 테스트 설계 수행은 이런 활동 중 테스트 베이시스 문서에서 문제가 발견될 수 있기 때문에 정적 테스팅의 한 형태인 경우가 많다. 요구사항 명세에 따른 테스트 분석과 테스트 설계는 요구사항 리뷰 회의를 준비하는 훌륭한 방법이다. 

테스트 작성에 사용할 요구사항을 읽으려면 요구사항을 이해하고 요구사항 충족을 평가하는 방법을 결정할 수 있어야 한다.

이런 활동에는 종종 누락되거나, 불문명하거나, 테스트할 수 없거나, 인수 기준이 정의되지 않은 요구사항이 있을 수 있다.

비슷한 방법으로 테스트 케이스, 리스크 분석 및 테스트 계획과 같은 테스트 작업 산출물을 검토할 수 있다. 

 

쉽게 사용할 수 없는 인프라가 테스트에 필요한 경우, 테스트 분석가는 테스트 설계 중 상세한 테스트 인프라 요구사항을 정의한다.

이런 요구사항이 제시간에 완성되지 않으면 테스트 구현에 들어가는 시간과 노력이 예기치 않게 초과될 위험에 처한다.

테스트 인프라에는 테스트 대상과 테스트웨어 이상의 것이 포함돼야 한다는 것을 기억해야 한다.

인프라 요구사항에는 장소, 장비, 인력, 소프트웨어, 도구, 주변 장치, 통신 장비, 사용자 권한 부여 및 테스트를 실행하는 데 필요한 기타 모든 항목이 포함될 수 있다.

 

테스트 분석과 테스트 설계의 종료 기준은 프로젝트 파라미터에 따라 다르지만 이 두 섹션에서 논의한 모든 항목이 정의된 종료 기준에 들어가도록 고려해야 한다. 종료 기준이 측정 가능해야 하며, 후속 단계에 필요한 모든 정보가 제공돼야 하고, 모든 필수적인 준비가 진행되야 한다. 

 

1.5 테스트 구현

테스트 구현은 테스트 분석과 설계를 기반으로 테스트 실행에 필요한 테스트웨어를 준비하는 것이며, 다음과 같은 활동이 포함된다. 

 - 테스트 프로시저 개발, 그리고 자동화된 테스트 스크립트 작성이 필요할 수 있음

 - 테스트 프로지저 및 자동화된 테스트 스크립트를 특정 테스트 진행 시 실행할 테스트 스위트로 편성

 - 실행할 테스트 케이스와 테스트 스위트의 우선순위를 정하기 위해 테스트 관리자에게 자문

 - 테스트 실행을 시작할 수 있도록 자원 할등을 포함한 테스트 실행 일정 만들기

 - 테스트 데이터와 테스트 환경 준비 마무리

 - 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스크립트 및 테스트 스위트와 같은 테스트웨어 간 추적성 업데이트

 

테스트 구현 중 테스트 분석가는 테스트 케이스의 효율적인 실행 순서를 식별하고 테스트 프로시적 작성

테스트 프로시저를 정의하기 위해서는 테스트 실행 순서에 영향을 줄 수 있는 제약 조건과 종속성을 신중하게 식별

테스트 프로시저는 모든 초기 전제조건과 실행에 따라오는 모든 활동을 문서화

 

테스트 분석가는 그룹화할 수 있는 테스트 케이스와 자동화된 테스트 스크립트를 식별하고 테스트 스위트로 구성

이것이 관련 테스트 케이스를 함께 실행할 수 있게 해준다.

 

테스트 분석가는 테스트 실행을 효율적으로 진행하기 위해 테스트 실행 일정 안에 테스트 스위트를 정렬한다.

리스크 기반 테스트 전략을 사용하는 경우 테스트 케이스의 실행 순서 결정에 리스크 수준이 주요 고려사항이 된다.

적합한 인력, 장비, 데이터의 가용성 및 테스트 대상 기능과 같은 테스트 케이스 실행 순서를 결정하는 다른 요소가 있을 수 있다.

 

코드가 섹션별로 릴리스 되는 것은 흔한 일이며, 테스트 노력은 소프트웨어를 테스트할 수 있는 순서에 따라 조정

특히 반복/점진적 개발 모델에서 테스트 분석가는 소프트웨어가 테스트 가능한 순서로 릴리스 될 수 있도록 개발팀과 협력

 

테스트 구현 과정에서 수행하는 작업의 상세 수준과 관련 복잡성은 테스트 컨디션과 테스트 케이스의 세부 사항에 영향

경우에 따라 규제/규칙이 적용되며 테스트 작업 산출물은 ~ 해당 표준에 준수한다는 증거를 제공

 

대부분 테스팅에는 테스트 데이터가 필요하며 경우에 따라 이런 데이터 세트가 상당히 클 수도 있다.

구현하는 동안 테스트 분석가는 입력과 환경 데이터를 작성해 데이터 베이스와 기타 저장소에 저장한다.

결함을 찾아낼 수 있도록 이 데이터는 "목적에 적합"해야 한다.

테스트 분석가는 수동 테스트 뿐만 아니라 데이터 주도와 키워드 주도 테스트도 함께 사용할 데이터를 생성할 수 있다.

 

테스트 구현은 테스트 환경과 관련 있다.

이 활동 중에 환경을 완벽히 설정하고 테스트 실행 전 확인해야 한다.

"목적에 맞는" 테스트 환경이 필수적이다. 

즉, 테스트 환경은 제어된 테스팅 중 존재하는 결함의 노출을 가능하게 하고, 장애가 발생하지 않을 때 정상적으로 동작하며, 필요한 경우 더 높은 테스트 수준을 위해 생산 과정이나 최종 사용자 환경을 적절히 복제할 수 있어야 한다.

예상치 못한 변경, 테스트 결과 또는 기타 고려사항에 따라 테스트 실행 중 테스트 환경을 변경해야 할 수도 있다.

실행 중에 환경이 바뀌면 변경이 이미 실행된 테스트에 미치는 영향을 평가하는 것도 중요하다. 

 

테스트 구현 중 테스트 분석가는 테스트 환경의 생성과 유지보수 담당자가 있고 가용한지, 모든 테스트 웨어와 테스트 지원 도구 및 관련 프로세스를 사용할 수 있는지 확인해야 한다. 여기에는 형상 관리, 결함 관리 및 테스트 로깅/관리가 포함된다. 테스트 분석가는 종료 조건에 대한 현재 상태 평가를 위한 데이터 수집과 테스트 결과 보고에 대한 절차를 확인해야 한다.

 

테스트 계획 중에 정해진 대로 테스트 구현을 위해 균형 잡힌 접근법을 적용하는 것이 좋다.

예를 들어, 리스크 기반 분석 테스트 전략은 종종 반응적 테스트 전략과 함께 적용된다.

이 경우, 테스트 구현 노력의 일부는 미리 결정된 스크립트를 따르지 않는 테스트에 할당돼야 한다.

 

스크립팅되지 않은 테스트는 필요한 시간과 커버리지를 예측하기 힘들고 결함 발견율이 낮을 수 있으므로 무작위로 또는 목적없이 수행하지 않아야 한다. 오히려 테스트 차터에 의해 초기 방향이 제시된 시간이 정해진 세션에서 시행해야 하지만, 세션 과정에서 더 생산적인 테스트 잠재성이 발견될 경우, 차터의 초기 방향에서 벗어날 수 있는 자유가 주어져야 한다.

 지난 수년간 테스터는 공격, 오류 추정, 탐색적 테스팅과 같은 다양한 경험 기반 테스트 기법을 개발했다.

테스트 분석, 설계 및 구현은 여전히 일어나지만 주로 테스트 실행 중에 이루어 진다.

이런 반응적 테스트 전략을 따르는 경우 각 테스트 결과는 후속 테스트의 분석, 설계 및 구현에 영향을 준다.

이런 전략은 가볍고 결함을 찾아내는 데 효과적이지만 다음과 같은 몇 가지 단점이 있다.

 - 테스트 분석가의 전문 지식 필요

 - 기간을 예측하기 어려움

 - 커버리지를 추적하기 어려움 

 - 좋은 문서 또는 도구 지원이 없다면 반복성을 잃을 수 있음

 

1.6 테스트 실행

테스트 실행은 실행 일정에 따라 수행되며 다음 작업을 포함한다.

 - 탐색적 테스팅을 포함한 수동 테스트 실행

 - 자동화 테스트 실행

 - 실제 결과와 예상 결과 비교

 - 이상 현상에 대한 원인 분석

 - 관찰한 장애를 기반으로 결함 보고

 - 테스트 실행 실제 결과 기록

 - 테스트 결과를 고려하기 위해 테스트 베이시스와 테스트웨어 사이의 추적성 업데이트

 - 리그레션 테스트 실행

 

위에 나열한 테스트 실행 작업은 테스터나 테스트 분석가가 수행 가능

테스트 분석가가 수행할 수 있는 일반적인 추가 작업은 다음과 같다.

 - 테스트 대상 특정 부분에 대한 추가 테스트 필요성을 시사하는 결함 클러스터 인식

 - 탐색적 테스팅 결과를 바탕으로 향후 탐색적 테스팅 세션에 대한 제안

 - 테스트 실행 작업 수행 시 얻은 정보에서 새로운 리스크 식별

 - 테스트 구현 활동에서 작업 산출물 개선을 위한 제안