STQB_CTFL_파운데이션레벨(FL)_v.2018_실러버스_v3.1.1_한글_v1.0 요약 [시험 전 필독!!]

1. 테스팅이란?

1) 테스팅의 일반적인 목적

• 요구사항, 사용자 스토리,  설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
• 명시된 모든 요구사항이 충족됐는지 검증
• 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
• 테스트 대상의 품질 수준에 대한 자신감 획득
• 부적절한 소프트웨어 품질의 리스크 레벨 감소로 장애와 결함을 발견
• 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
• 계약/법률/규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인

 

2) 테스팅 / 디버깅 /  품질보증

• 테스팅 : 테스트를 실행하면 소프트웨어 결함으로 인한 장애를 찾아낼 수 있음
  ㄴ 품질 저하 리스크 수준을 낮춰줌
• 디버깅 : 장애 원인을 찾고 분석해서 수정하는 개발 활동이다.
• 품질 보증 : 표준을 준수했다는 것을 보증
  ㄴ 전반적인 프로세스의 올바른 수행 여부에 관심
  

3) 오류 / 결함 / 장애

• 오류 : 결함의 원인이 되는 것
  ㄴ 부정확한 결과를 초래하는 인간의 활동, 인간의 실수
• 결함 : 요구된 기능을 적절히 처리하지 못하는 것
  (e.g. 개발 시 프로젝트 요구사항에 잘못된 계산식으로 코딩)
• 장애 : 코드에 존재하는 결함(Defect)의 실행을 의미 (잘못된 코딩으로 인해 사용자에게 해당 결함이 보이는 것)
  ㄴ 테스트 결과가 기대한 것과 다르다고 해서 무조건 장애가 있다고 볼 수는없음.
      테스트 실행 방식의 오류나 테스트 데이터, 테스트 환경, 기타 테스트웨어에 결함이 있는 경우, 또는 그 외 다양한 이유로 거짓양성(false positive) / 거짓음성(false negative) 발생
   * 거짓양성 : 결함으로 보고됐지만 실제 결함이 아닌 경우
   * 거짓음성 : 테스트가 발견했어야 할 결함을 발견하지 못하는 경우

 

4) 테스팅의 7가지 원리

• 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다 (Testing shows the presence of defects, not their absence)
  ㄴ 테스팅은 결함이 존재한다는 것을 보여줄 수 있지만, 결함이 없다는 것을 증명할 수 없다.
• 완벽한(exhaustive) 테스팅은 불가능하다 (Exhaustive testing is impossible)
  ㄴ 모든 테스팅 한다는 것은 매우 간단한 소프트웨어를 제외하고는 불가능하다.
•  조기 테스팅(early testing)으로 시간과 비용을 절약할 수 있다 (Early testing saves time and money)
   ㄴ 초기에 결함을 찾기 위해서는 정적 및 동적 테스트 활동 모두 소프트웨어 개발 수명주기 중 가능한 이른 시점에 시작해야 한다. 초기부터 시작하는 테스팅을 시프트 레프트(shift left)라고도 부른다.
• 결함은 집중된다 (Defects cluster together)
  ㄴ 테스팅에서 발견하는 대부분의 결함은 소수의 모듈에 집중되어 발생하는 경향을 보이며, 운영상 장애의 대부분 역시 소수의 모듈에서 발생한다.
• 살충제 패러독스(pesticide paradox)에 유의하라
  ㄴ 같은 테스트를 계속해서 반복 실행한다면, 결국 해당 테스트로는 결함을 더 이상 발견할 수 없게 된다.
• 테스팅은 정황(context)에 의존적이다 (Testing is context dependent)
  ㄴ 테스팅은 정황에 따라 다르게 진행된다. 예를 들어, 안전 최우선 산업에서 사용하는 제어 소프트웨어는 이커머스 모바일 애플리케이션과는 다르게 테스트한다. 
  
• 오류 부재는 궤변이다 (Absence-of-errors is a fallacy)
  ㄴ 단순히 많은 결함을 발견하고 고쳤다고 해서 시스템의 성공이 보장된다고 생각하는 것은 궤변이다.
  
  

5) 테스트 활동과 작업

1. 테스트 계획 : 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동
   (e.g. 테스트 정책과 테스트 전략, 사용하는 개발 수명주기 및 방법, 테스팅의 범위, 목적, 리스크, 제약, 심각도, 테스트 용이성, 자원의 가용성)
   
   
2. 테스트 모니터링과 제어 : 테스트 모니터링은 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교
   1) 명시된 커버리지 조건 대비 테스트 결과와 로그 확인 
   2) 테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가
   3) 추가 테스트 필요 여부 결정칸
   
   
3. 테스트 분석 : 테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석한다. 즉, 측정 가능한 커버리지 조건의 측면에서 "무엇을 테스트할지"를 결정
   1) 고려 중인 테스트 레벨에 적합한 테스트 베이시스 평가
   2) 테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별
   3) 테스트할 기능과 기능 세트 식별
   4) 테스트 베이시스를 평가하고 기능, 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준 등을 고려해서 각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정
   5) 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착
   
   
4. 테스트 설계 : 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어(testware)를 생성. 즉, "어떻게 테스트할 것인가?"를 결정
   1) 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정
   2) 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별
   3) 테스트 환경 설계와 필요한 인프라 및 도구 식별
   4) 테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정
   
   
5. 테스트 구현 : 테스트 실행에 필요한 테스트웨어를 생성하고 완성, 즉 "테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?"의 답
   1) 테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성
   2) 테스트 프로시저와 자동 테스트 스크립트로부터 테스트 스위트(test suite) 생성
   3) 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치
   4) 테스트 환경 구축, 가능하다면 테스트 하네스(test harness), 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인
   5) 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인
   6) 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로 간의 양방향 추적성 검증과 업데이트
   
   
6. 테스트 실행 : 테스트 스위트를 테스트 실행 일정에 따라 실행
   1) 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
   2) 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
   3) 기대 결과와 실제 결과 비교
   4) 이상 현상(anomalies)을 분석해 원인 파악
   5) 관찰한 장애를 기반으로 결함 보고
   6) 테스트 실행 결과 기록
   
   
7. 테스트 완료 : 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동
   1) 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인
   2) 이해관계자에게 전달할 테스트 요약 보고서 생성
   3) 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관
   4) 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계
   5)완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복주기, 릴리스, 또는 프로젝트를 위해 수정해야 하는 사항 판단
   6) 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용
   
   
   

 

2. 소프트웨어 개발 수명주기 모델

1)  순차적(sequential) 개발 모델 vs 반복적 점진적(iterative and incremental) 개발 모델

• 순차적 개발 모델  : 개발 프로세스의 모든 단계는 이전 단계가 완료될 때 시작
  - 폭포수 모델(Waterfall model) :개발 활동(요구사항 분석, 설계, 코딩, 테스팅)이 순차적으로 진행
  - V-모델: 테스팅을 초기에 시작하면 좋다는 원리로 각 개발 단계에 테스트 레벨를 부여
  
• 점진적 개발 모델 : 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행
  
  
• 반복적 개발 모델 : 고정된 기간의 일련의 주기 안에서 같이 명시, 설계, 구축, 테스트할 때 발생
  - 래셔널 통합 프로세스(Rational Unified Process): 각 반복주기가 상당히 긴 경우가 많으며(예: 2, 3 개월), 따라서 기능 증분도 상당히 큼
  - 스크럼(Scrum): 각 반복주기가 짧은 성향을 가지며(예: 몇 시간, 며칠, 또는 몇 주) 따라서 기능 증분도 작음 
  - 칸반(Kanban): 반복주기 기간이 고정된 경우와 고정되지 않은 경우가 있으며, 각 반복주기는 완료 후 하나의 개선 사항이나 기능을 전달하거나 몇 개의 기능을 묶어 한번에 전달할 수도 있음
  - 나선형(Spiral): 실험적인 증분을 생성, 일부는 차후 개발 과정에서 상당 부분 수정되거나 심한 경우 폐기되기도 함
  
  

2) 테스트 레벨

• 컴포넌트 테스팅 : 개별적으로 테스트할 수 있는 컴포넌트에 초점
  - 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
  - 컴포넌트 품질 수준에 대한 자신감 획득
  - 컴포넌트에 존재하는 결함 발견
  
  ㄴ 컴포넌트 테스팅_테스트 베이시스 :  상세 설계, 코드, 데이터 모델, 컴포넌트 명세
  ㄴ 컴포넌트 테스팅_테스트 대상 : 컴포넌트, 단위, 모듈, 코드 및 데이터 구조, 클래스, 데이터베이스 모듈
  ㄴ 컴포넌트 테스팅_대표적인 결함과 장애 : 잘못된 기능 (e.g. 설계 명세의 설명과 다름), 데이터 흐름 문제, 잘못된 코드 및 논리
  
  
• 통합 테스팅 : 컴포넌트나 시스템 간의 상호작용에 초점
  - 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
  - 인터페이스 품질 수준에 대한 자신감 획득
  - 결함 발견 (결함은 인터페이스 자체 또는 컴포넌트나 시스템에 존재할 수 있다)
  
  ㄴ 통합 테스팅_테스트 베이시스 :  소프트웨어 및 시스템 설계, 시퀀스 다이어그램(sequence diagram), 인터페이스 및 통신 프로토콜 명세, 유스케이스, 컴포넌트나 시스템 레벨의 아키텍처, 워크플로우(workflow), 외부 인터페이스 정의서
  ㄴ 통합 테스팅_테스트 대상 : 서브시스템(subsystems), 데이터베이스(database), 인프라(infrastructure), 인터페이스(interfaces), APIs, 마이크로서비스(microservices)
  ㄴ 통합 테스팅_대표적인 결함과 장애 : 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩, 잘못된 인터페이스 콜 순서나 타이밍, 인터페이스 불일치, 통신 장애, 통신 실패처리 누락 및 오류, 데이터의 의미, 단위, 경계에 대한 잘못된 가정
  
  
• 시스템 테스팅 : 시스템 테스팅은 전체 시스템 또는 제품의 동작이나 능력에 초점
  - 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는지 검증 
  - 완성된 시스템이 기대한 대로 동작하는지 확인
  - 전체 시스템 품질에 대한 자신감 획득
  
  ㄴ 시스템 테스팅_테스트 베이시스 :  시스템 및 소프트웨어 요구사항 명세 (기능/비기능, 리스크 분석 보고서, 유스케이스, 에픽(epic)과 사용자 스토리, 시스템 동작 모델, 상태 다이어그램, 시스템 및 사용자 매뉴얼
  ㄴ 시스템 테스팅_테스트 대상 : 애플리케이션, 하드웨어/소프트웨어 시스템, 운영 시스템, 테스트 대상 시스템, 시스템 설정과 설정 데이터
  ㄴ 시스템 테스팅_대표적인 결함과 장애 : 잘못된 연산, 시스템의 잘못되거나 예상치 못한 기능/비기능 동작, 시스템 내 잘못된 제어 및 데이터 흐름 , 엔드-투-엔드 기능 작업 수행 실패,시스템 환경에서 시스템의 정상 동작 실패, 시스템 및 사용자 매뉴얼대로의 시스템 동작 실패
  
  
• 인수 테스팅 : 시스템 테스팅과 마찬가지로 인수 테스팅도 전체 시스템 또는 제품의 동작이나 능력에 초점
  단, 인수 테스팅의 결과로 시스템을 배포하거나 고객(최종 사용자)이 사용할 준비가 어느 정도 됐는지 평가
  - 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는지 검증 
  - 완성된 시스템이 기대한 대로 동작하는지 확인
  - 전체 시스템 품질에 대한 자신감 획득
  ㄴ 인수 테스팅_테스트 베이시스 :  비즈니스 프로세스, 사용자 또는 비즈니스 요구사항, 규제, 법적 계약, 표준, 유스케이스 및 사용자 스토리, 시스템 요구사항, 시스템 또는 사용자 문서, 설치 절차, 리스크 분석 보고서
  ㄴ 인수 테스팅_테스트 대상 : 테스트 대상 시스템, 시스템 설정과 설정 데이터, 완전히 통합된 시스템의 비즈니스 프로세스, 복원 시스템이나 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트 (hot site), 운영 및 유지보수 프로세스 , 양식 , 보고서, 기존 및 전환된 생산 데이터
  ㄴ 인수 테스팅_대표적인 결함과 장애 : 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우 (workflow), 잘못 구현된 비즈니스 규칙, 계약 혹은 규제 요구사항을 충족하지 못하는 시스템, 보안 취약성, 많은 부하가 걸렸을 때 성능 효율성 저하, 비기능 장애
  
  

3) 테스트 유형

• 기능 테스팅 (Functional Testing) : 시스템이 수행해야 하는 기능을 평가하기 위한 테스트를 포함
• 비기능 테스팅 (Non-functional Testing) : 사용성, 성능 효율성 또는 보안성과 같은 시스템 특성을 평가, "얼마나 잘" 동작하는지에 대한 테스팅
  
• 화이트박스 테스팅 (White-box Testing) : 시스템의 내부 구조나 구현을 기반으로 테스트를 도출
• 변경 관련 테스팅 (Change-related Testing) : 결함 수정 또는 기능을 추가 및 개선하기 위해서시스템이 변경되면, 해당 변경이 결함을 제대로 수정했는지, 기능을 올바르게 구현했는지 또 예상하지 못한 부작용이 발생하지 않았는지 확인
• 리그레션 테스팅(Regression testing): 코드의 특정 부분에 대한 변경으로 의도하지 않은 부작용을 발견하기 위한 테스트를 수행
  
  
  

3. 정적 테스팅

1) 정적 테스팅의 효과
    - 동적 테스트 실행 전에 보다 효율적으로 결함을 발견하고 수정
    - 동적 테스팅으로 발견이 쉽지 않은 결함 식별 
    - 요구사항 불일치, 애매 모호함, 모순, 누락, 부정확, 중복 등을 식별해서 설계나 코딩의 결함 예방
    - 개발 생산성 향상 (e.g. 설계 개선, 향상된 코드 유지보수성)
    - 개발 비용 및 기간 단축
    - 테스팅 비용 및 기간 단축
    - 수명주기 후반 또는 출시 후 운영 과정에서 발견되는 장애 감소로 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소
    - 리뷰에 참여하는 팀원 간의 의사소통 개선

2) 정적 테스팅으로 발견되는 일반적인 결함
    - 요구사항 결함 (e.g.  불일치, 모호함, 모순, 누락, 부정확, 중복 등)
    - 설계 결함 (e.g.  비효율적인 알고리즘(algorithm)이나 데이터베이스 구조, 높은 결합도(coupling), 낮은 응집도(cohesion)) 등
    - 코딩 결함 (e.g. 정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
    - 표준과의 차이 (e.g.  코딩 표준 미준수 등)
    - 잘못된 인터페이스 명세 (e.g. 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
    - 보안 취약점 (e.g. 버퍼 오버플로우에 대한 취약성)
    - 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성

3) 리뷰 프로세스

• 계획 (Planning)
  - 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
  - 노력과 기간 추정
  - 리뷰 유형에 따라 결정되는 역할, 활동, 체크리스트와 같은 리뷰 특성의 식별
  - 리뷰에 참석할 인원을 선정하고 역할 할당
  - 인스펙션과 같은 보다 공식적인 리뷰의 경우에는 시작 및 종료 조건 정의 
  - (공식적인 리뷰 유형의 경우) 시작 조건이 충족되는지 확인
• 리뷰 착수 (Initiate review)
  - 작업 산출물과 이슈 기록(issue log) 양식, 체크리스트, 관련된 작업 산출물과 같은 기타 자료 배포
  - 참가자에게 범위, 목적, 프로세스, 역할, 작업 산출물을 설명
  - 참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변
• 개별 리뷰 (Individual review 또는 개별 준비)
  - 작업 산출물 전체 혹은 부분 리뷰
  - 잠재 결함, 권고사항, 질문 기록
• 이슈 논의 및 분석 (Issue communication and analysis)
  - 식별한 잠재 결함 전달 (리뷰 회의 중 전달)
  - 잠재 결함 분석 및 담당자 및 상태 할당
  - 품질 특성 평가 및 문서화
  - 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정 (거부(reject), 주요 수정 필요, 약간의 수정 후 수락 등)
• 수정 및 보고 (Fixing and reporting)
  - 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
  - 리뷰한 작업 산출물에서 발견한 결함 수정 (일반적으로 저자가 수정)
  - 결함 정보를 적절한 사람이나 팀과 공유 (리뷰한 작업 산출물과 연관된 다른 작업 산출물이 있는 경우) 
  - 필요한 경우 주석 작성자(comment originator)의 동의를 포함해 (공식적인 리뷰 유형인 경우) 업데이트 된 결함 상태 기록 
  - 메트릭 수집 (공식적인 리뷰 유형인 경우)
  - 종료 조건의 충족여부 확인 (공식적인 리뷰 유형인 경우)
  - 종료 조건이 충족되면 해당 작업 산출물 인수
  

4) 공식 리뷰에서의 역할과 책임

• 저자 (Author) - 
  - 리뷰 대상 작업 산출물 작성
  - 리뷰 대상 작업 산출물 결함 수정 (필요한 경우)
• 관리자 (Management) - 경영진
  - 리뷰 계획 담당
  - 리뷰 실행 결정
  - 인력, 예산, 시간 할당
  - 진행 비용 대비 효과 모니터링
  - 결과가 만족스럽지 않은 경우 제어 결정(control decisions) 실행
• 촉진자 (Facilitator, 종종 중재자(moderator)로 부름)
  - 리뷰 회의 진행 시 효과적 회의 진행 보장
  - 필요한 경우 다양한 관점들에 대한 중재
  - 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람
• 리뷰 리더 (Review leader)
  - 전반적으로 리뷰에 대한 책임을 지는 사람
  - 참여자를 결정하고 언제 어디서 진행할지 결정
• 검토자 (Reviewers)
  - 해당 주제에 대한 전문가, 프로젝트 참여 인원, 작업 산출물에 관심이 있는 이해관계자나 특정 기술 혹은 비즈니스 배경을 가진 사람 등
  - 리뷰 대상 작업 산출물의 잠재적 결함 식별
  - 다양한 관점을 대표할 수 있음 (예: 테스터, 개발자, 사용자, 운영자, 비즈니스 분석가, 사용성 전문가 등)
• 서기 (Scribe, 또는 기록자 (Recorder))
  - 개별 리뷰 활동에서 발견한 잠재 결함 수집
  - 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정 사항 기록

5) 리뷰 유형

• 비공식 리뷰 (Informal review) (e.g. 버디 체크 (buddy check), 페어링 (pairing), 짝 리뷰 (pair review))
  - 주요 목적: 잠재적 결함 발견
  - 기타 목적: 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결
  - 공식 (문서화된) 프로세스를 기반으로 하지 않음
  - 결과는 문서로 기록할 수 있음
  - 검토자에 따라 성과가 달라짐
  - 애자일 개발에서 매우 일반적으로 사용됨
  
  
• 워크쓰루 (Walkthrough)
  - 주요 목적: 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가
  - 기타 목적: 다양한 기술이나 스타일에 대한 아이디어 교환, 참여자 교육, 합의 도출
  - 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도
  - 서기 참여 필수
  - 잠재 결함 로그와 리뷰 보고서 작성
  
  
• 기술 리뷰 (Technical review)
  - 주요 목적: 합의 도출, 잠재적 결함 발견
  - 기타 목적: 작업 산출물의 품질 평가 및 자신감 획득, 새로운 아이디어 도출, 저자가 미래의 작업 산출물을 개선하도록 지원하고 동기를 부여, 다른 구현 방법 고려 
  - 검토자는 저자의 기술 동료이면서, 동일 분야 또는 다른 분야의 기술 전문가여야 함
  - 이상적으로는 훈련된 촉진자가 주도  (일반적으로 저자가 아님)
  - 서기 참여 필수 이상적으로는 저자가 아닌 사람이 수행
  
  
• 인스펙션 (Inspection)
  - 주요 목적: 잠재적 결함 발견, 작업 산출물의 품질 평가 및 자신감 획득, 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방
  - 기타 목적: 저자가 앞으로의 작업 산출물과 소프트웨어 개발 프로세스를 개선하고 합의를 이끌어 내도록 동기를 부여
  - 규칙 및 체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행
  - 낭독자(리뷰 회의 중 작업 산출물을 종종 자신의 말로 의역하고 소리 내어 읽는 사람)의 참여 가능
  - 검토자는 저자의 동료 또는 작업 산출물과 연관된 분야의 전문가
  - 명시된 시작 및 종료 조건을 사용
  - 서기 참여 필수
  - 리뷰 회의는 훈련받은 촉진자가 주도 (저자가 아닌 사람)
  - 저자는 리뷰 리더, 글을 읽는 사람 또는 서기가 될 수 없음
  - 인스펙션 프로세스 포함 전체 소프트웨어 개발 프로세스를 개선하기 위해 메트릭을 수집하고 사용
  
  

6) 리뷰 기법 적용

• 애드혹 (Ad hoc): 검토자에게 리뷰 수행 방법에 대한 안내가 거의 또는 전혀 제공되지 않음. 검토자는 대부분의 경우 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록한다.
  애드혹 리뷰는 특별한 준비 없이 일반적으로 사용되는 기법이다. 이 기법은 검토자의 능력에 크게 의존하며, 여러 검토자가 동일한 문제를 보고할 수 있다
• 체크리스트 기반 (Checklist based): 검토자는 리뷰 시작 시점에 배포된 체크리스트를 기반으로 이슈를 식별한다. 리뷰 체크리스트는 잠재 결함을 식별하기 위해 경험에서 도출한 일련의 질문으로 구성된다.
  체크리스트 기반 기법의 주요 장점은 일반적인 결함 유형에 대한 체계적인 커버리지를 갖는다는 점이다. 개별 리뷰를 수행할 때 검토자는 체크리스트를 단순히 실행하는 것뿐만 아니라, 체크리스트로 식별할 수 없는 결함도 찾기 위해 특별히 주의를 기울여야만 한다.
• 시나리오 및 드라이 런 (Scenarios and dry runs) : 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공받는다. 시나리오 기반 리뷰는 (작업 산출물이 유스케이스와 같은 적절한 형식으로 문서화된 경우)
  작업 산출물의 예상되는 용도를 기반으로 작업 산출물에 대해 “드라이런”을 수행할 수 있도록 검토자를 지원한다. 이러한 시나리오는 검토자에게 단순한 체크리스트 항목보다 특정 결함 유형을 식별하는 방법에 대한 좀 더 나은 지침을 제공한다.
• 관점 기반 (Perspective-based):  검토자가 개별 리뷰 중 다양한 이해관계자의 관점을 사용하게 된다. 일반적으로 사용되는 이해관계자 관점에는 최종 사용자, 영업, 설계자, 테스터, 운영자 등이 있다.
  서로 다른 이해관계자 관점을 사용하면, 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행된다. 또한, 관점 기반 읽기에서는 검토자가 리뷰 대상 작업 산출물로부터 이해관계자의 관점을 기반으로 하는 산출물을 작성해야 한다.
  예를 들어, 테스터가 필요한 모든 정보가 존재하는지 확인하기 위해 요구사항 명세에 대한 관점 기반 읽기를 수행하면서 인수 테스트 초안을 작성을 시도할 수 있다. 또한 관점 기반 읽기에서는 체크리스트도 활용한다.
• 역할 기반 (Role-based) : 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법이다.
  일반적인 역할에는 특정 최종 사용자 유형(경험 많은, 경험 적은, 노인, 아동 등)과 조직 내 특정 역할(사용자 관리자, 시스템 관리자, 성능 테스터 등)이 있다. 역할이 비슷하기 때문에 같은 원칙이 관점 기반 읽기에도 적용된다.

 

 

4. 테스트 기법

1) 블랙박스 테스트 기법

•  동등 분할 (Equivalence Partitioning) : 동등 분할은 특정 파티션(partitions)의 모든 변수는 동일한 방식으로 처리된다는 가정
• 경계값 분석 (Boundary Value Analysis) : 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다. 분할의 최소값과 최대값(또는 첫 번째값과 마지막값)은 해당 분할의 경계값이 된다
• 결정 테이블 테스팅 (Decision Table Testing) : 시스템의 조건(주로 입력)과 예상 동작(주로 출력)을 식별함
  - Y, 조건이 참이라는 것을 의미 (T 또는 1 로 표기할 수 있음)
  - N, 조건이 거짓이라는 것을 의미 (F 또는 0 으로도 표기할 수 있음)
  - —, 조건의 값이 중요하지 않다는 것을 의미 (N/A 로 표기할 수 있음)
  
  - X, 행동이 일어난다는 것을 의미 (Y, T, 1 로 표기할 수 있음)
  - 공백(blank), 행동이 일어나지 않음을 의미 (—, N, F, 0 으로 표기할 수 있음)
• 상태 전이 테스팅 (State Transition Testing) : 컴포넌트나 시스템은 현재 조건이나 기존 이력에 따라 이벤트에 대해 다르게 반응
  
• 유스케이스 테스팅 (Use Case Testing) : 유스케이스에서 테스트를 도출할 수 있으며, 이것은 소프트웨어 항목 간의 상호작용을 설계하는 특정 방법이다. 유스케이스는 소프트웨어 기능에 대한 요구사항을 통합함
  
  

2) 화이트박스 테스트 기법

• 구문 테스팅과 커버리지 : 구문 테스팅은 코드의 잠재적으로 실행 가능한 구문을 실행한다. 커버리지는 일반적으로 백분율로 표기
• 결정 테스팅과 커버리지  : 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행되는 코드를 테스트한다. 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다
  (e.g. IF 문에서 결과가 참인 경우와 거짓인 경우; CASE 문에서 기본 결과를 포함한 가능한 모든 결과를 필요로 하는 테스트 케이스).
  
  
• 구문 및 결정 테스팅의 가치 :  100% 결정 커버리지는 100% 구문 커버리지를 보장하지만, 반대의 경우는 성립하지 않는다.
  
  

3) 경험 기반 테스트 기법

• 오류 추정 (Error Guessing) : 테스터의 지식을 기반으로 오류, 결함 및 장애 발생을 예측하는 데 적용하는 기술이며 다음을 포함한다
  (애플리케이션의 과거 동작,  발생하기 쉬운 오류의 유형, 다른 애플리케이션에서 발생한 장애)
•  탐색적 테스팅 (Exploratory Testing): 비공식 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가한다. 더 많은 테스트가 필요한 영역에 대한 테스트를 작성하는 데 활용된다.
  세션 기반 테스팅에서는 탐색적 테스팅을 정해진 시한(time-box)동안 수행하며, 테스터는 테스트 목적이 포함된 테스트 차터(test charter)를 활용해 테스팅 방향을 설정한다.
  테스터는 테스트 세션 시트에 수행 단계와 발견 사항을 기록한다. 탐색적 테스팅은 명세가 충분하지 않거나 적은 경우 또는 테스팅에 상당한 시간적 압박이 있을 때 가장 유용하다. 
• 체크리스트 기반 테스팅 (Checklist-based Testing):  체크리스트 기반 테스팅에서는 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 

 

 

5. 테스트 관리

1) 테스트 관리자의 역할과 업무

• 조직의 테스트 정책과 테스트 전략을 개발하고 리뷰
• 정황을 고려한 테스트 활동과 테스트 목적과 리스크 이해를 바탕으로 테스트 활동을 계획. 테스트 접근법 선택, 테스트 추정(테스트 시간, 노력, 비용), 리소스 획득, 테스트 레벨과 테스트 주기 정의, 결함 관리 등이 계획에 포함될 수 있다.
• 테스트 계획서 작성과 업데이트
• 프로젝트 관리자, 제품 책임자, 기타 관계자와 테스트 계획 관련 협의
• 통합 계획 등과 같은 다른 프로젝트 활동과 테스팅 관점 공유
• 테스트 분석, 설계, 구현, 실행 활동을 개시하고, 테스트 진행과 결과를 모니터링하며 종료 조건(또는 종료 조건 정의)의 상태를 점검하고 테스트 완료 활동을 촉진
• 수집한 정보를 바탕으로 테스트 진행 상황 보고서와 테스트 요약 보고서 작성과 배포
• 테스트 결과와 진행 상황(테스트 진행 상황 보고서나 이미 완료된 다른 테스트 프로젝트의 테스트 요약 보고서에서 문서화된)에 따라 계획을 조정하고 테스트 제어에 필요한 모든 조치를 취함 
• 결함 관리 시스템과 테스트웨어에 적합한 형상 관리 체제 구축 지원
• 테스트 진척 상황 측정과 테스팅 및 제품 품질 평가를 위한 적절한 메트릭 도입 
• 테스트 프로세스 지원용 도구 선택과 구현 지원.
• 테스트 환경 구축에 관한 결정
• 조직에 테스터, 테스트팀, 테스트 활동을 홍보하고 지지를 요청 
• 테스터의 역량과 경력 개발
  
  

2) 테스터의 역할과 업무

• 테스트 계획을 리뷰하고 계획 작성에 참여 
• 요구사항, 사용자 스토리와 인수 조건, 명세, 모델(즉, 테스트 베이시스)의 테스트 용이성을 분석, 리뷰, 평가
• 테스트 컨디션을 식별 및 기록하고, 테스트 케이스, 테스트 컨디션, 테스트 베이시스 간의 추적성 설정
• 테스트 환경을 설계, 구축, 검증하고 필요한 경우 시스템 관리자, 네트워크 관리자와 협업
• 테스트 케이스와 테스트 프로시저를 설계 및 구현
• 테스트 데이터를 준비하고 획득
• 상세 테스트 실행 일정 수립
• 테스트를 실행하고 결과를 평가해, 기대 결과와 차이 기록
• 테스트 프로세스에 적합한 도구 사용
• 필요한 경우 테스트 자동화 (개발자나 테스트 자동화 전문가의 도움을 받을 수 있음)
• 수행 효율성, 신뢰성, 사용성, 보안성, 호환성, 이식성과 같은 비기능 품질 특성 평가
• 테스트 산출물 리뷰
  
  

3) 테스트 전략과 테스트 접근법

• 분석적 (Analytiacl): 특정 요소에 대한 분석을 기반으로 한 테스트 전략. 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅이 분석적 접근법
• 모델 기반 (Model-Based): 테스트는 요구되는 제품의 특정 측면에 대한 모델을 기반으로 만들어진다. 특정 측면에는 기능, 비즈니스 프로세스, 내부 구조, 비기능 특성 등이 있다. 모델에는 비즈니스 프로세스 모델, 상태 모델, 신뢰성 성장 모델 등이 있다. 
• 방법론적 (Methodical): 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는 데 의존한다. 예를 들어, 보편적이고 발생 가능성이 높은 장애 분류, 주요 품질 특성 목록, 모바일 애플리케이션이나 웹페이지에 대한 전사 룩앤필(look-and-feel) 표준 등이 있다. 
• 프로세스 준수 ((Process-compliant), 또는 표준 준수(standard-compliant)): 외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현한다.
  예를 들어, 특정 산업 표준에서 제시하는 규정이나 표준, 프로세스의 문서화, 테스트 베이시스의 엄격한 식별과 사용, 조직이 강제하거나 조직에 강요된 모든 프로세스나 표준을 기반으로 한다.
• 전문가 조언 ((Directive), 또는 자문(consultative)): 주로 이해관계자, 비즈니스 도메인 전문가, 기술 전문가 등의 조언, 지도, 지시를 바탕으로 이루어진다. 
• 리그레션-기피 (Regression-averse): 기존 기능에 대한 리그레션 테스트 기피를 목표로 한다. 이 테스트 전략에는 기존 테스트웨어(특히 테스트 케이스와 테스트 데이터)의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함된다.
• 반응적 (Reactive): 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트 접근법이다. 이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행할 수 있다. 탐색적 테스팅이 반응적 전략에서 일반적으로 사용

 

4) 시작 조건

• 테스트 가능한 요구사항, 사용자 스토리나 모델(예: 모델 기반 테스트 전략을 따르는 경우)의 가용 여부 
• 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부
• 테스트 환경 가용 여부
• 필요한 테스트 도구 가용 여부
• 테스트 데이터와 기타 필요한 자원의 가용 여부
  
  

5) 종료 조건

• 계획한 테스트 실행 완료
• 정의한 커버리지 수준 (e.g. 요구사항, 사용자 스토리, 인수 조건, 리스크, 코드 등의 커버리지)의 도달
• 해결하지 못한 결함 수가 합의된 수보다 적음 
• 추정 잔존 결함의 수가 충분히 적음 
• 신뢰성, 수행 효율성, 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달
  
  

6)  테스트 추정 기법 (Test Estimation Techniques)

• 메트릭 기반 기법: 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측
• 전문가 기반 기법: 테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측

 

7) 일반적인 테스트 메트릭

• 계획 대비 테스트 케이스 준비 작업 완료율 (또는 계획 대비 테스트 케이스 작성률)
• 계획 대비 테스트 환경 준비 작업 완료율
•  테스트 케이스 실행률 (e.g. 수행한/수행하지 않은 테스트 케이스 수, 테스트 케이스 합격/불합격 수, 테스트 컨디션 합격/불합격 수)
•  결함 정보 (e.g. 결함 밀도, 발견한 결함, 수정한 결함, 실패율, 확인 테스트 결과)
•  요구사항 커버리지, 사용자 스토리 커버리지, 인수 기준 커버리지, 리스크 커버리지, 코드 커버리지
•  작업 완료, 자원 할당과 사용, 노력
•  다음 결함을 발견하면 얻는 이익 대비 비용이나 테스트를 계속 실행해 얻게 되는 이익 대비 비용 등을 포함하는 테스팅 비용
•  

8) 일반적인 테스트 요약 보고서

• 테스팅 수행 내용 요약
• 테스트 기간 도중에 발생한 상황 정보
•  계획 대비 편차 (e.g. 일정, 기간, 테스팅 활동 노력)
•  종료 조건 및 완료의 정의에 대한 테스팅 현황과 제품 품질
•  진행을 방해했거나 계속해서 방해하고 있는 요소
•  메트릭, 잔존 리스크, 재사용 가능한 테스트 작업 산출물

 

9) 형상관리 : 변경사항을 체계적으로 추적, 통제

• 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록한다. 형상 관리에서 테스트 항목은 서로 연관돼 있다.
• 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경사항을 추적하고, 서로 연결해 테스트 항목 버전과도 연결되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 한다.
•  식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

 

10) 제품 리스크: 작업 산출물(명세, 컴포넌트, 시스템, 테스트 등)이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성

• 소프트웨어가 명세에서 의도한 기능을 수행하지 못함
•  소프트웨어가 사용자, 고객이나 이해관계자가 요구하는 기능을 수행하지 못함
•  시스템 아키텍처가 일부 비기능 요구사항을 충분히 지원하지 못함
•  특정 계산식이 특정 상황에서 올바르게 수행되지 못함
•  루프(loop) 제어 구조 코딩이 잘못됨
•  고성능 거래 처리 시스템의 응답 시간이 적절하지 않음
•  사용자 경험(UX, User eXperience) 피드백이 제품 기대치에 미치지 못함

 

6. 테스트 지원도구

1) 테스트 도구

• 정적 테스팅 지원 도구 : 정적 분석 도구
• 테스트 설계 및 구현 지원 도구 : 모델 기반 테스팅 도구, 테스트 데이터 준비 도구
• 테스트 실행 및 로깅 지원 도구 : 테스트 실행 도구(리그레션 테스트), 커버리지 도구(요구사항 커버리지, 코드 커버리지), 테스트 하네스
• 성능 측정과 동적 분석 지원 도구 : 성능 테스팅 도구, 동적 분석 도구

 

2) 테스트 실행 도구 가치

• 반복적인 수동 업무 감소로 시간 절약(e.g. 리그레션 테스트 수행, 환경 구축/해체 작업, 같은 테스트 데이터 재입력, 코딩 표준 준수 여부 점검 등)
• 월등한 일관성과 반복성 제공 (e.g. 일관성 있는 테스트 데이터 생성, 같은 순서와 간격의 테스트 실행, 요구사항으로부터의 지속적인 테스트 도출)
• 객관적인 평가 기준 제공 (e.g. 정적 테스팅 측정치, 커버리지)
• 테스팅 관련 정보에 접근이 쉬움 (e.g. 테스트 진척도, 결함율, 성능 통계와 그래프)

 

3) 테스트 실행 도구 리스크

• 도구에 대한 비현실적인 기대 (e.g.도구의 기능과 사용성)
• 초기 도구 도입에 필요한 시간, 비용, 노력에 대한 과소평가 (e.g. 교육, 외부 전문가 비용)
•  도구로 의미 있고 지속적인 효과를 얻는 데 필요한 시간과 노력을 과소평가 (e.g. 테스트 프로세스의 수정과 도구의 사용법에 대한 지속적인 개선)
•  도구가 생성하는 테스트 작업 산출물을 유지하기 위한 노력의 과소평가
• 도구에 대한 지나친 의존 (테스트 설계나 실행을 대체한다고 생각하거나 수동 테스팅이 더 효과적인 경우에 자동 테스팅 사용)
•  테스트 작업 산출물에 대한 버전의 관리 소홀
• 요구사항 관리 도구, 형상 관리 도구, 결함 관리 도구, 다수의 공급 업체에서 제공하는 도구 환경에서 주요 도구 간의 관계와 상호운용성 이슈를 관리하지 않음
• 도구가 새로운 플랫폼이나 기술을 지원하지 않음

 

 

출처 : http://www.kstqb.org/board_skin/board_view.asp?idx=433&page=2&bbs_code=5&key=0&word=&etc=