서론

테스트의 목적

1. 프로그램이 의도된 기능을 수행하는지 확인

   • 요구사항에 따라 테스트 케이스를 작성하고 실행.
   • Validation Testing: 시스템이 예상대로 동작하는지 확인.
     • 정상적인 입력 → 예상된 출력 확인.

2. 프로그램 결함(버그)을 발견

   • 입력 또는 입력 순서를 통해 오류, 비정상 동작 탐색.
   • Defect Testing: 결함을 노출할 수 있는 테스트 케이스 사용.
     • 결함이 포함된 입력 → 시스템 오류 탐지.

검증(Verification)과 확인(Validation)

• Verification:
  • 소프트웨어가 요구사항을 충족하는지 확인.
  • "Are we building the product right?".
  • 개발자 관점.
• Validation:
  • 소프트웨어가 사용자의 기대를 충족하는지 확인.
  • "Are we building the right product?".
  • 사용자 관점.

테스트의 한계

• 테스트는 오류의 존재를 입증할 수 있으나, 오류의 부재를 입증할 수 없음.

소프트웨어 적합성 (Fit for Purpose)

1. 소프트웨어 목적

   • 안전-critical 시스템 → 높은 신뢰성 필요.
   • 프로토타입 시스템 → 상대적으로 낮은 신뢰성 허용.

2. 사용자 기대

   • 초기 사용자는 실패를 용인할 수 있지만, 시간이 지나면서 더 높은 신뢰성 기대.

3. 마케팅 환경

   • 시장 경쟁에 따라 불완전한 소프트웨어라도 빠르게 출시할 수 있음.
   • 저가 소프트웨어 → 낮은 신뢰성 허용 가능.

V & V 과정의 정적 기법: 소프트웨어 검사 및 리뷰

소프트웨어 검사의 장점

1. 오류 간의 상호작용 방지

   • 테스트에서는 하나의 오류가 다른 오류를 숨길 수 있음.
   • 검사는 시스템 실행 없이 오류를 독립적으로 탐지.

2. 불완전한 시스템 검사 가능

   • 부분적으로 개발된 시스템은 별도의 테스트 하네스가 필요 없음.

3. 프로그램의 품질 속성 검토

   • 결함뿐만 아니라 표준 준수, 유지보수성, 비효율성 등도 점검 가능.

소프트웨어 검사의 특징

• Fagan (1976): 비공식 프로그램 검사를 통해 60% 이상의 오류 검출 가능.
• Cleanroom 프로세스: 검사로 90% 이상의 결함 발견 가능.
• 복잡한 상호작용이나 시스템 성능 문제 발견에는 적합하지 않음.
• 작은 개발 팀에서는 별도의 검사 팀 구성이 어려울 수 있음.

테스트 프로세스

1. 개발 테스트

   • 개발 중 버그와 결함 발견.
   • 설계자와 프로그래머가 테스트에 참여.

2. 릴리스 테스트

   • 별도 테스트 팀이 완성된 시스템을 검증.
   • 목표: 시스템이 이해관계자의 요구사항을 충족하는지 확인.

3. 사용자 테스트

   • 사용자 또는 잠재 사용자가 실제 환경에서 시스템 테스트.
   • Acceptance Testing: 고객이 시스템을 공식적으로 승인하기 위해 수행.

테스트 방식

수동 테스트

• 테스터가 프로그램을 실행하고 결과를 확인.
• 예상과 다를 경우 개발자에게 보고.

자동화 테스트

• 테스트를 코드로 작성해 자동 실행.
• 결과를 예상 출력과 비교해 차이점 자동 검출.
• 회귀 테스트: 변경 후 이전 테스트를 다시 실행해 새로운 버그 확인.
• GUI와 같이 시각적 요소를 확인하는 시스템 테스트에는 부적합.
• 의도하지 않은 부작용까지 검출하는 것은 불가능.

---

8.1 Development testing

개발 테스트

• 개발 테스트는 시스템을 개발하는 팀에서 수행하는 모든 테스트 활동을 포함.
• 소프트웨어 테스트의 테스터는 주로 개발자가 담당.
• 일부 개발 프로세스에서는 프로그래머-테스터 짝을 사용하여 프로그래머와 테스터가 협력하여 테스트 개발과 테스트 과정을 지원.
• 주요 목적은 소프트웨어의 버그 발견.
• 개발 테스트는 결함 테스트로 주로 이루어지며, 디버깅(코드 문제를 찾아 수정하는 과정)과 함께 진행됨.

개발 테스트의 단계

1. 단위 테스트 (Unit Testing)

   • 개별 프로그램 단위 또는 객체 클래스를 테스트.
   • 개별 함수나 메소드는 가장 간단한 형태의 구성 요소.
   • 목표: 객체나 메소드의 기능 테스트.

2. 컴포넌트 테스트 (Component Testing)

   • 여러 개별 유닛을 통합하여 구성된 컴포넌트 테스트.
   • 목표: 컴포넌트 함수에 접근할 수 있는 인터페이스 테스트.

3. 시스템 테스트 (System Testing)

   • 시스템의 일부 또는 모든 컴포넌트를 통합하여 시스템 전체를 테스트.
   • 목표: 컴포넌트 간의 상호작용 테스트.

단위 테스트

• 객체의 모든 기능을 테스트(연관된 모든 연산 테스트, 속성의 값 설정 및 확인, 가능한 모든 상태 테스트)해야 함.
• 객체의 상태 변경을 유발하는 이벤트를 시뮬레이션하여 상태를 테스트.
• 예시: 날씨 관측기 객체의 테스트
  • 예: reportWeather, reportStatus 메소드 테스트.
  • 상태 모델을 사용하여 상태 전환 시퀀스를 테스트해야 함(예: Shutdown → Running → Shutdown).
• 상속을 통해 객체 클래스의 테스트가 복잡해지며, 부모 클래스에서 정의된 연산이 자식 클래스에서 예상대로 동작할지 테스트해야 함.

자동화된 단위 테스트

• JUnit과 같은 테스트 자동화 프레임워크를 사용하여 단위 테스트를 자동화
• 테스트는 3부분으로 나뉨:
  1. 셋업: 테스트 케이스에 필요한 시스템 초기화(입력 및 예상 출력).
  2. 호출: 테스트할 객체나 메소드 호출.
  3. 검증: 호출 결과와 예상 결과 비교 (성공: true, 실패: false)

모의 객체(Mock Objects)

• 모의 객체는 외부 객체의 기능을 시뮬레이션하는 객체로, 실제 구현을 대체.
• 예시: 데이터베이스 호출을 시뮬레이션하는 모의 객체는 데이터 액세스를 빠르게 처리하여 테스트 속도를 개선.
• 용도: 데이터베이스와 같은 외부 시스템을 호출할 때 발생하는 지연을 방지하고, 이상 상황이나 드문 이벤트를 시뮬레이션할 때 사용.

단위 테스트 사례 분류

1. 정상 동작을 확인: 테스트 사례가 예상대로 컴포넌트가 작동하는지 확인.
2. 결함을 발견: 컴포넌트에 결함이 있을 경우, 이를 발견할 수 있는 테스트 사례를 선택.

단위 테스트 케이스 선택 전략

• 정상적인 입력을 사용하여 컴포넌트가 정상적으로 동작하는지 확인하는 테스트.
• 비정상적인 입력을 사용하여 컴포넌트가 이를 제대로 처리하는지 확인하는 테스트.

단위 테스트 방법

1. 분할 테스트 (Partition Testing):
   • 공통된 특성을 가진 입력 그룹을 식별하여 각 그룹에서 테스트 사례를 선택.
   • 예시: 프로그램에서 두 개의 양수 숫자를 받는다면, 이들에 대해 동일한 방식으로 동작한다고 가정하고 테스트.
   • 입력 분할: 프로그램의 입력값이 특정 범위로 나뉠 때, 각 범위에서 테스트를 선택.
   • 출력 분할: 출력값 또한 유사한 특성을 가진 값들로 나누어 테스트.
   • 경계값 테스트: 경계값에 대해 특별히 테스트. (예: 0과 다른 음수/양수 값은 다르게 처리될 수 있음.)
2. 가이드라인 기반 테스트:
   • 이전 경험을 바탕으로 프로그래머들이 자주 실수하는 부분을 반영한 테스트 사례를 선택.
   • 예시: 프로그램이 배열, 리스트 등과 같은 시퀀스를 처리할 때, 특정 가이드라인을 따르도록 설계된 테스트가 결함을 더 잘 발견할 수 있음.

동등 클래스 분할 (Equivalence Partitioning)

• 동등 클래스는 동일한 처리 방식을 요구하는 입력/출력 값의 집합.
  • 예시: 숫자 범위 (예: 10,000 이상의 5자리 수), 메뉴 선택 등의 입력 값들이 특정 범위 내에서 동일하게 처리.
• 블랙박스 테스트: 시스템의 동작 원리에 대한 지식 없이, 시스템 명세서를 기반으로 테스트를 설계.
• 화이트박스 테스트: 코드 내부를 살펴보고 예외 처리나 오류 발생 가능한 부분을 테스트.

가이드라인 예시

1. 단일 값 시퀀스: 프로그램이 여러 값으로 이루어진 시퀀스를 처리한다고 가정하지만, 단일 값 시퀀스에 대한 처리가 제대로 되지 않을 수 있음.
2. 다양한 시퀀스 크기: 프로그램에 결함이 있어 우연히 정상 동작을 할 수 있는 경우를 방지하기 위해, 다양한 크기의 시퀀스로 테스트를 진행.
3. 시퀀스의 첫 번째, 중간, 마지막 요소 접근: 이는 경계값 테스트에 해당하며, 시퀀스의 시작과 끝 부분에서 발생할 수 있는 문제를 드러낼 수 있음.
4. 일반적인 테스트 가이드라인:
   • 오류 메시지를 모두 출력하도록 입력 설계.
   • 입력 버퍼 오버플로우를 유발하는 입력 설계.
   • 같은 입력을 여러 번 반복하여 테스트.
   • 유효하지 않은 출력을 강제로 생성하도록 테스트.
   • 연산 결과를 강제로 너무 크거나 너무 작도록 테스트.

컴포넌트 테스트

• 컴포넌트를 테스트할 때, 개별 객체가 아닌 컴포넌트의 인터페이스에 대해 테스트를 적용.
• 개별 객체에서 발생하는 인터페이스 오류는 이러한 객체들이 결합되어 동작할 때, 상호작용으로 인해 나타날 수 있음.

인터페이스 유형

1. 파라미터 인터페이스:
   • 데이터나 함수 참조가 한 컴포넌트에서 다른 컴포넌트로 전달되는 인터페이스.
   • 객체의 메소드들은 보통 이러한 파라미터 인터페이스를 가짐.
2. 공유 메모리 인터페이스:
   • 메모리 블록을 공유하여 데이터가 한 서브시스템에서 다른 서브시스템으로 전달되는 인터페이스.
   • 예를 들어, 센서 데이터가 공유 메모리를 통해 다른 컴포넌트에 전달되는 방식.
3. 절차적 인터페이스:
   • 한 컴포넌트가 다른 컴포넌트에서 호출할 수 있는 절차 집합을 캡슐화하는 방식의 인터페이스.
4. 메시지 전달 인터페이스:
   • 한 컴포넌트가 메시지를 보내어 다른 컴포넌트에서 서비스를 요청하고, 그 결과를 반환받는 방식의 인터페이스.
   • 객체 지향 시스템이나 클라이언트-서버 시스템에서 자주 사용.

인터페이스 오류 유형

1. 인터페이스 오용:
   • 호출된 컴포넌트의 인터페이스를 잘못 사용하는 오류.
   • 예를 들어, 파라미터의 순서나 타입이 잘못 전달되는 경우.
2. 인터페이스 오해:
   • 호출된 컴포넌트의 동작에 대한 잘못된 이해로 인해 예기치 않은 결과가 발생하는 오류.
   • 예를 들어, 정렬되지 않은 배열에 대해 이진 탐색을 수행하면 실패할 수 있음.
3. 타이밍 오류:
   • 실시간 시스템에서 데이터 생산자와 소비자의 속도가 달라서 발생하는 오류.
   • 이 경우, 데이터 소비자가 최신 정보를 받지 못할 수 있음.

인터페이스 결함 테스트의 어려움

• 인터페이스 결함은 특정한 조건에서만 나타날 수 있음.
• 예를 들어, 큐가 고정 크기로 구현된 객체에서 오버플로우가 발생하는 경우, 큐가 무한 크기의 자료구조라고 가정한 호출 객체는 오버플로우를 검사하지 않을 수 있음.
• 이런 상황은 테스트 시퀀스를 통해 강제로 큐가 오버플로우 되도록 설계하여 확인.

인터페이스 테스트를 위한 일반적인 가이드라인

1. 외부 컴포넌트 호출 코드 검토: 각 외부 컴포넌트 호출을 식별하고, 해당 컴포넌트에 전달되는 파라미터 값들이 범위의 극단값에 해당하는지 확인하는 테스트 설계.
2. 널 포인터 테스트: 포인터가 인터페이스를 통해 전달될 경우, 널 포인터 파라미터를 테스트.
3. 절차적 인터페이스 실패 테스트: 컴포넌트를 호출할 때 의도적으로 실패를 유발하여 실패 처리를 테스트.
4. 메시지 전달 시스템의 스트레스 테스트: 예상보다 많은 메시지를 생성하여 타이밍 문제를 발견할 수 있도록 테스트.
5. 공유 메모리 시스템의 순서 변경 테스트: 여러 컴포넌트가 공유 메모리를 통해 상호작용하는 경우, 컴포넌트가 활성화되는 순서를 변경하여 테스트.

시스템 테스트

1. 시스템 테스트에서는 별도로 개발된 재사용 가능한 컴포넌트나 상용 시스템이 새로 개발된 컴포넌트와 통합되며, 그런 다음 전체 시스템이 테스트.
2. 시스템 테스트는 여러 팀원 또는 하위 팀이 개발한 컴포넌트들이 통합되는 과정으로 시스템 테스트는 개별적인 작업이 아니라 집단적인 과정이며, 일부 회사에서는 시스템 테스트가 별도의 테스트 팀에 의해 이루어지기도 함.

시스템의 emergent behavior

-모든 시스템은 컴포넌트를 결합했을 때 시스템의 기능이나 특성이 명확해지는 경우를 의미하는 emergent behavior를 가짐

• 예를 들어, 인증 컴포넌트를 데이터베이스 업데이트 컴포넌트와 통합하면, 인증된 사용자만 시스템 정보를 업데이트할 수 있도록 제한하는 기능이 생기는 경우.
• 때로는 이러한 emergent behavior가 예기치 않거나 원치 않는 결과를 초래할 수도 있으므로, 시스템 테스트는 시스템이 의도한 대로만 동작하는지 확인하는 데 초점을 맞춤.

시스템 테스트의 주요 목표

• 시스템 테스트는 주로 컴포넌트 간 상호작용을 테스트하는 데 집중.
• 재사용 가능한 컴포넌트나 시스템이 새로 통합된 컴포넌트와 함께 잘 동작하는지 확인.
• 이 상호작용 테스트는 컴포넌트가 다른 컴포넌트와 결합될 때만 드러나는 버그, 다른 컴포넌트에 대한 잘못된 이해로 인해 발생하는 오류를 찾아낼 수 있음.

유스케이스 기반 테스트

• 시스템 내 여러 컴포넌트나 객체가 하나의 유스케이스를 구현하기 때문에, 유스케이스를 테스트하면 이러한 상호작용이 발생.
• 유스케이스 구현을 모델링한 시퀀스 다이어그램을 활용하면 상호작용에 관련된 객체나 컴포넌트를 확인할 수 있음.

• 시퀀스 다이어그램은 필요한 입력과 생성된 출력을 확인하는 데 도움.
• 예: 날씨 관측 시스템
  

시스템 테스트의 범위

• 모든 실행 경로를 테스트하는 철저한 테스트는 불가능.
• 테스트는 가능한 테스트 케이스의 부분 집합에 기반하여 진행해야 함.
• 소프트웨어 회사는 이러한 부분 집합을 선택하는 정책을 가져야 함.
• 예:
  1. 메뉴를 통해 접근할 수 있는 모든 시스템 기능은 테스트.
  2. 같은 메뉴를 통해 접근할 수 있는 기능들의 조합은 테스트.
  3. 사용자 입력이 제공될 때, 모든 기능은 올바른 입력과 잘못된 입력 모두를 테스트.

시스템 테스트에서 발생하는 문제

• 시스템의 기능이 단독으로는 잘 동작하지만, 덜 사용되는 기능들의 조합에서 문제가 발생할 수 있음.
• 자동화된 시스템 테스트는 자동화된 단위 테스트나 컴포넌트 테스트보다 더 어려운 경우가 많음.
• 시스템 테스트의 경우 출력값이 크거나 예측하기 어려운 경우가 많으므로, 출력을 미리 생성하기보다는, 생성된 출력을 검토하여 신뢰성을 확인.

---

8.2 Test-driven development

TDD 프로세스 단계

1. 기능 요구사항 확인
   • 작은 단위로 나누어 필요한 기능을 결정.
2. 테스트 작성
   • 해당 기능을 검증하는 자동화 테스트를 작성.
3. 테스트 실행
   • 처음 실행 시 기능이 없기 때문에 테스트 실패가 발생.
4. 기능 구현
   • 테스트를 통과하도록 기능을 구현 및 기존 코드 리팩토링.
5. 테스트 재실행
   • 모든 테스트가 통과하면 다음 기능을 구현.

TDD의 주요 이점

1. 코드 커버리지
   • 모든 코드 세그먼트는 최소 하나의 테스트와 연결.
   • 모든 코드가 실행되고 검증됨.
2. 회귀 테스트
   • 기존 테스트를 빠르고 저렴하게 재실행 가능.
   • 코드 변경 후 새로운 버그가 도입되지 않았는지 확인.
3. 디버깅 간소화
   • 실패한 테스트는 새로 작성된 코드에 문제가 있다는 것을 의미.
   • 문제 위치를 빠르게 파악 가능.
4. 시스템 문서화
   • 테스트 코드가 문서 역할을 수행.
   • 코드가 수행해야 할 작업을 명확히 설명.

TDD를 사용할 때의 유의 사항

• 레거시 코드
  • 기존 시스템이나 대형 코드 컴포넌트 재사용 시 TDD 비효율적.
  • 시스템을 분리하여 테스트 작성이 어렵기 때문.
• 멀티스레딩 시스템
  • 테스트 실행 시 스레드의 동작 순서가 달라질 수 있어 결과가 일관되지 않을 수 있음.
• 시스템 테스트
  • TDD로 작성된 코드라도 시스템 전체의 성능, 신뢰성 검증은 별도의 시스템 테스트가 필요.
  • 시스템 테스트는 TDD와 보완 관계에 있음.

---

8.3 Release testing

Release Testing과 System Testing의 차이점

1. 책임 주체
   • System Testing: 시스템 개발 팀이 수행.
   • Release Testing: 시스템 개발 팀이 아닌 독립된 테스트 팀이 수행.
2. 목적
   • System Testing: 버그를 발견하는 데 중점을 둠. (결함 테스트)
   • Release Testing: 시스템이 요구사항을 충족하고, 사용하기 적합한지 검증함. (검증 테스트)

배포 테스트 방법

1. 블랙박스 테스트

• 시스템의 입력과 출력만을 기반으로 테스트를 수행.
• 시스템 내부 구현에는 관심이 없음.

2. 기능 테스트 (Functional Testing)

• 테스트의 초점은 기능적 요구사항이 제대로 작동하는지 확인하는 데 있음.
• 시스템이 정의된 스펙을 따라 기대한 결과를 출력하는지를 검증.

요구사항 기반 테스트

• 요구사항은 테스트 가능해야 함.
  • 즉, 요구사항이 명확히 작성되어야 해당 요구사항에 대한 테스트 설계가 가능.
• 결함 테스트(Defect Testing)가 아닌 검증 테스트(Validation Testing)를 수행.
  • 요구사항이 제대로 구현되었는지를 증명하려 함.
• 여러 개의 테스트 케이스 필요.
  • 단일 요구사항에 대해 하나의 테스트만 작성하지 않음.
  • 요구사항의 다양한 상황과 조건을 모두 커버해야 함.
• 추적성(Traceability).
  • 각 테스트 케이스를 관련된 요구사항과 연결하는 추적성 기록을 유지.
  • 이를 통해 테스트가 요구사항을 완벽히 검증했는지 확인할 수 있음.

예시: Mentcare 시스템 요구사항

1. 요구사항 1: 환자가 특정 약물에 알레르기가 있는 것으로 기록된 경우, 해당 약물을 처방하면 경고 메시지가 표시되어야 함.
2. 요구사항 2: 처방자가 경고를 무시하는 경우, 그 이유를 입력해야 함.

요구사항에 대한 테스트 케이스

1. 테스트 케이스 1:
   • 시나리오: 알레르기 기록이 없는 환자에 대해 알레르기 약물을 처방.
   • 기대 결과: 경고 메시지가 표시되지 않아야 함.
2. 테스트 케이스 2:
   • 시나리오: 환자 기록에 특정 약물에 대한 알레르기가 기록되어 있다. 해당 약물을 처방.
   • 기대 결과: 경고 메시지가 표시됨.
3. 테스트 케이스 3:
   • 시나리오: 두 개 이상의 약물에 대한 알레르기 기록이 있는 환자에게 각 약물을 개별적으로 처방.
   • 기대 결과: 각각의 약물에 대한 올바른 경고 메시지가 표시됨.
4. 테스트 케이스 4:
   • 시나리오: 두 가지 약물을 동시에 처방. 두 약물 모두에 대해 알레르기가 기록되어 있음.
   • 기대 결과: 두 개의 경고 메시지가 각각 올바르게 표시됨.
5. 테스트 케이스 5:
   • 시나리오: 환자가 알레르기 경고를 무시하고 처방을 강행.
   • 기대 결과: 시스템이 경고를 무시한 이유를 입력하도록 요구.

시나리오 테스트

• 현실적이어야 함.
  • 실제 시스템 사용자들이 공감하고 이해할 수 있는 시나리오를 작성.
• 복합적인 스토리로 작성.
  • 하나의 시나리오에서 여러 기능과 요구사항을 동시에 테스트할 수 있어야 함.
• 평가가 용이해야 함.
  • 문제가 발생하면 테스트 팀이 이를 쉽게 인식하고 기록할 수 있어야 함.

• 장점:
  1. 복합적 테스트: 여러 기능과 요구사항을 결합하여 동시 테스트가 가능.
  2. 실제 사용 사례 검증: 현실적 시나리오를 통해 사용자가 시스템을 어떻게 사용할지 검증.
  3. 요구사항 간 상호작용 확인: 개별 요구사항은 정상적으로 동작하더라도, 요구사항 간의 조합된 사용에서 발생하는 문제를 확인.
  

시나리오 테스트 설계 원칙 (Kaner, 2003)

1. 신뢰성 있는 이야기: 시나리오는 사용자와 이해관계자들이 믿을 수 있어야 함.
2. 복잡성: 단순한 테스트를 넘어 여러 기능이 통합된 복합적인 시나리오를 설계함.
3. 동기 부여: 이해관계자들이 시나리오의 중요성에 공감하고 시스템의 통과 여부에 관심을 가져야 함.
4. 평가의 용이성: 문제가 발생하면 쉽게 식별하고 기록할 수 있어야 함.

Mentcare 시스템 예시 시나리오

시나리오: 정신 건강 케어 시스템(Mentcare)을 사용하는 George라는 사용자가 환자 집 방문 중에 시스템을 사용하는 상황을 설명.

• 주요 기능:
  1. 시스템 인증: George가 시스템에 로그인.
  2. 데이터 다운로드 및 업로드: 환자 기록을 노트북에 다운로드하고 업데이트된 정보를 업로드.
  3. 방문 일정 관리: 홈 방문 일정을 시스템에서 관리.
  4. 암호화 및 복호화: 환자 기록이 노트북에서 암호화 및 복호화.
  5. 기록 검색 및 수정: George가 환자 기록을 검색하고 필요한 정보를 수정.
  6. 약물 데이터베이스 연동: 약물 부작용 정보가 시스템에서 조회.
  7. 콜 프롬프트 시스템: 시스템이 George에게 다음 방문.

시나리오 테스트 실행 방법

• 테스터 역할 수행: 테스트 담당자가 사용자의 역할(예: 'George')을 맡아 시나리오를 수행.
• 에러 시나리오 확인: 사용 중 일부러 오류를 유발하여 시스템의 대응을 테스트.
  • 예: 잘못된 키 입력으로 환자 기록 복호화 시도를 통해 오류 처리 여부 확인.
• 문제 기록: 기능적 오류뿐만 아니라 성능 문제도 기록.
  • 예: 암호화 과정이 너무 느리다면, 사용자가 암호화를 건너뛰는 등의 문제가 발생.

---

8.4 User testing

유형

알파 테스트

• 소수 사용자와 개발자가 협력하여 테스트함.
• 초기 버전 문제와 이슈를 찾음.
• 애자일에서는 사용자도 테스트 설계에 참여함.

베타 테스트

• 초기 버전을 대규모 사용자에게 배포해 테스트함.
• 호환성 문제와 상호작용 문제를 찾음.
• 마케팅 도구로도 사용됨.

인수 테스트

• 고객이 테스트를 통해 시스템 인수 여부를 결정함.

단계

1. 인수 기준 정의: 인수 기준을 정의하고 승인함.
2. 테스트 계획: 시간, 자원, 범위를 수립함.
3. 테스트 설계: 요구사항을 검증할 테스트를 설계함.
4. 테스트 실행: 정의된 테스트를 환경에서 실행함.
5. 결과 협상: 테스트 실패 시 해결 방안을 논의함.
6. 인수/거부: 최종 인수 여부를 결정함.

애자일 환경

• 사용자가 개발 팀의 일부로 참여함.
• 자동화된 테스트를 통해 스토리를 검증함.
• 환경 재현이 어렵고, 테스트 유연성이 부족함.

출처: Ian Sommerville - Software Engineering