ISTQB/ SW 테스팅 ) 1장. 테스팅의 일반적인 원리 & 테스트 프로세스 기초 & 테스트 완료 조건.

< 테스팅의 일반적인 원리 >
원리 1. 테스팅은 결함이 존재함을 밝히는 것.
원리 2. 완벽한 테스팅은 불가능.
원리 3. 개발 초기에 테스팅 시작.
원리 4. 결함 집중.
원리 5. 살충제 패러독스.
원리 6. 테스팅은 정황에 의존적.
원리 7. 오류 - 부재의 궤변.

 

1.3 테스팅의 일반적인 원리

- 원리 1. 테스팅은 결함이 존재함을 밝히는 활동이다.

>> 잠재적으로 존재하는 결함 줄임. BUT, 결함이 없다고 증명할 수는 없음.

- 원리 2. 완벽한 테스팅은 불가능하다.

>> 한 프로그램 내에 내부 조건이 많음.

>> 입력이 가질 수 있는 모든 값의 조합이 무수히 많음. (실제로 발생하는 현상이 무수히 많음.)

>> 이벤트 발생 시 발생 순서에 대한 조합도 무수히 많음.

>> 리스크에 따라 테스트 강도 높게 수행 -- > 실제 완벽은 불가. >> 가능성이 높은 것부터 수정해 나가야 돼.

- 원리 3. 테스팅을 개발 초기에 시작한다.

>> 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근.

>> 요구사항 분석서와 설계서 등의 개발 산출물 분석 후 테스트 케이스 도출.

- 원리 4. 결함 집중

>> 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임.

>> 결함의 집중은 운영상의 장애를 초래. (리스크가 높은 애들 먼저 수정)

   >> 복잡한 구조의 모듈.

   >> 다른 모듈과 다량의 상호작용을 하는 모듈

   >> 개발 난이도가 높거나 최신 기술을 사용한 모듈

   >> 크기가 큰 모듈

   >> 경험이 미흡한 팀에서 개발한 모듈

   >> 새롭게 개발한 모듈

- 원리 5. 살충제 패러독스  (면역력이 높아져서 결함 찾기가  어려워지는 상황)

 >> 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함을 찾기 어려워짐.

 >> 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선.

- 원리 6. 테스팅은 정황에 의존적.

 >> 테스팅은 정황과 도메인에 따라 다르게 진행.

 >> 모든 테스트에 적용되어야 하는 것. -표준화된 적용 방 (상황이나 도메인에 맞춰서 적절하게 적용해야 됨.)

   >>  테스트 프로젝트 기획

   >> 표준적인 기법 적용.

   >> 독립적인 테스트 환경.

   >> 효율적/ 효과적 테스트 팀 조직

   >> 정식 리포팅 등

- 원리 7. 오류-부재의 궤변 (사용자의 요구 수준에 맞지 않는다면 버그 수정은 의미가 없다.)

 >> 개발된 소프트웨어가 사용자 요구 수준을 만족하지 않는다면 버그를 수정하는 것은 의미가 없음.

 

1.4 테스트 프로세스의 기초

 

▶ 테스트 프로세스

- 테스팅 관련 행동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 구성 요소를 엮어주는 역할.

>> 테스트 베이시스 -- > 계획 단계부터 필요설계 시 반드시 요구.

>> 테스트 조직 -- > 계획 단계부터 필요, 실행 단계에서 다수 인력 필요.

>> 테스트 전략

>> 테스트 기법 --> 분석 및 설계 단계에서 필요

>> 테스트 대상 --> SW는 가장 이른 시기 준비, 늦어도 실행 단계엔 필수.

>> 테스트 기반 설비 및 환경 --> 실행 단계 전에 구축

- 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언(분석한 리스크)을 제공.

 

1.4.1 테스트 계획과 제어(통제)

▶ 테스트 계획과 제어

- 주요 활동

>> 테스트 목적/ 목표 및 대상 연구.

>> 테스트 전략 개발

>> 테스트 완료 조건의 결정

>> 테스트를 추정

>> 테스트 조직 구성

>> 테스트 계획 활동

>> 테스트 관리 및 제어

>> 리포팅

▶테스트 제어

- 계획 대비 실제 진행 상황을 비교하는 지속적인 활동.

- 계획과의 차이 확인 > 지속적 모니터링

- 제어 작업 

   >> 테스트 결과에 대한 측정과 분석

   >> 테스트 진척사항, 완료조건의 모니터링과 문서화

   >> 테스트 계획과의 차이 교정

   >> 테스팅의 진행과 변경에 대한 의사 결정 활동.

   >> 테스팅 계획은 테스팅의 제어와 모니터링 활동으로부터 받은 피드백을 반영

 

1.4.2 테스트 분석과 설계

▶ 테스트 분석과 설계

- 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동.

- 주요 작업

 >> 테스트 베이시스 리뷰(가장 기초 문서 - 요구사항 명세서, 설계 계획서 등)

 >> 테스트 상황 / 테스트 케이스 / 필요한 테스트 데이터 식별

 >> 테스트 케이스 설계와 우선순위 선정★

 >> 테스트 기법 할당

 >> 테스트 용이성 평가

 >> 테스트 환경 구축(실제 환경과 동일)

 >> 필요한 도구 식별 

 

1.4.3 테스트 구현과 실행

▶ 테스트 구현과 실행

- 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저 또는 테스트 스크립트를 명세화.

- 테스트에 필요한 환경이 구축되어야 함.

- 주요 작업

 >> 테스트 케이스 개발, 구현과 우선순위 설정

 >> 자동화 테스트 스크립트 작성

 >> 테스트 하네스 준비 (환경 준비)

 >> 효율적인 테스트 실행을 위해 테스트 수트(테스트 케이스 묶음) 생성

 >> 선행 테스트

 >> 테스팅 실행(결과 기록 - 식별과 버전 관리)

 >> 기대 결과와 비교 -- > 예상 결과와 실제 결과 간의 차이에서 오는 불일치를 인시던트 또는 결함으로 보고 - > 불일치 원인 파악. 

- 예상과 실제의 불일치

 >> 테스트 케이스 결함

 >> 테스트 정황 결함

 >> 어플리케이션 결함

- 불일치를 조치한 결과를 확인하기 위한 테스트 활동 반복.

 >> 수정이 되었는지 테스트 실행  -- > 확인 테스팅

 >> 수정으로 새로운 버그가 발생하지 않았는지 테스트 실행 -- > 회귀 테스팅

- 결함의 유형

 >> 기획 시 유입된 결함 - 요구사항의 표준 미준수, 테스트 불가능 등

 >> 설계 시 유입된 결함 - 설계의 표준 미준수, 테스트 불가능 등

 >> 코딩 시 유입된 결함 - 코드의 표준 미준수 등

 >> 테스트 부족으로 유입된 결함

 >> 마무리 부족

 >> 팀간 의사소통 부족

 >> 코딩 실수

- 결함 심각도에 따른 결함 유형

 >> 치명적 결함, 매우심각, 심각, 보통, 경미 (-> 4단계)

 >> 치명적 결함, 주요 결함,  일반 결함, 사소한 결함, 개선 사항( -> 5단계)

- 결함 유형으로 부적절한 경우

 >> Major, Minor, Trifle(Minor를 결함의 심각도가 낮은 것으로 인식 가능 - 다 문제가 있어)

 >> A,B,C(어느 것이 결함이 높은 것인지 알 수 없음)

- 결함의 우선 순위 표현

 >> 즉시 해결, 주의 요망, 대기, 낮은 순위

1.4.4 테스트 완료 조건과 리포팅

▶ 테스트 완료 조건의 평가

 - 초기 목표 대비 완료 조건의 달성 여부 확인(->95% 만족 시)

 - 테스트 레벨에 따라 다 수행함.

 - 완료 조건 작업

 >> 테스트 실행 결과인 테스트 로그가 테스트 계획에 명시된 완료 조건을 만족하는지 확인.

 >> 추가 테스트 필요 여부 및 명세화된 테스트 완료 조건 변경 여부

 >> 이해관계자들에게 배포할 테스트 요약 보고서 작성. 

▶리포팅에 표현되는 내용

 -  발견된 결함과 미해결 된 결함의 추이 및 우선순위

 -  테스트 진척도

 - 리스크 및 메트릭으로 실증된 조건

 - 테스트 환경의 가용성(다음에 사용 가능한지 여부)

   >> 테스트 커버리지(참 인지 거짓인지 다 훑고 넘어가는 테스트)

   >> 결함 발견 효율성/ 효과성

   >> 품질 평가 결과

   >> 결함 상태별 결함수

   >> 소프트웨어 사이즈 대비 결함수

   >> 요구사항별 테스트 일수

   >> 해결되지 않은 결함과 영향 및 오래 수정되지 않은 결함 

1.4.5 테스트 마감 활동

▶ 테스트 마감 활동

 - 산출물 확인, 테스트웨어(산출물) 보관(-> 다음 프로젝트를 위해)

 - 테스트 프로세스 평가 심사

 - 주요 활동

   >> 테스트 결과 마감(예정된 산출물, 인시턴트(결) 레포트 종료, 해결되지 않은 요구사항에 대한 처리, 시스템 인수에 대한 문서화 등)

   >> 테스트웨어, 테스트 환경, 테스트 기반설비를 차후에 사용 위해 마감, 보관

   >> 테스트웨어를 유지보수 조직에 이관

   >> 테스트 프로세스 심사 및 개선 사항

   >> 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석.