Testing - 테스트 프로세스

Testing 기초

Posted by Yan on November 10, 2021

테스트 프로세스

설정한 목적의 달성 가능성을 높여주는 공통적인 활동 세트
주어진 상황에 맞는 구체적인 소프트웨어 테스트 프로세스는 다양한 변수에 따라 결정된다.

정황에 따른 테스트 프로세스

테스트 프로세스에 영향을 줄 수 있는 정황 요소들

  • 사용중인 소프트웨어 개발 생명주기 모델과 프로젝트 방법론
  • 적용하고자 하는 테스트 레벨과 테스트 유형
  • 제품 및 프로젝트 리스크
  • 비즈니스 도메인
  • 운영상의 제약사항
    • 예산과 자원
    • 일정
    • 복잡도
    • 계약 및 규제 요구사항
  • 운영 정책과 프랙티스
  • 준수해야 하는 내부 및 외부 표준

커버리지 조건

테스트 레벨, 유형과 상관 없이 테스트 베이시스에 대한 측정 가능한 커버리지 조건이 설정되어 있으면 매우 유용하다.
커버리지 조건: 소프트웨어 테스트의 목적 달성 여부를 보여주는 활동의 주요 성능 지표 KPI Key Performance Indicator로 사용하기에 용이하다.

조직 테스트 프로세스

1. 테스트 활동과 작업

테스트 프로세스를 구성하는 주요 활동

주요 활동들은 반복적으로 구현된느 경우가 많다.

  • 예를 들어, 애자일 개발은 소프트웨어 설계 - 빌드 - 테스트 주기를 반복해서 배치한다.
  • 테스트활동도 반복적, 지속적으로 이루어지게 된다.

순차적 소프트웨어 개발에서도 개별 활동의 논리적인 순서는 중첩overlap, 조합combination, 동시 실행concurrency되거나 누락되기 때문에, 시스템과 프로젝트의 정황에 따라 이런 주요 활동들을 어느정도 조정하는 것이 필요하다.

테스트 계획

테스팅의 목적과 정황으로 인한 제약 사항을 고려해, 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동을 포함

예를 들어,

  • 적합한 테스트 기법과 작업 명시
  • 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립 등

테스트 계획은 모니터링과 제어 활동에서 나온 피드백을 기반으로 수정할 수 있다.

테스트 모니터링과 제어

테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교하는 활동

테스트 제어: 시간이 지나면서 업데이트될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행하는 것

종료 조건 평가: 테스트 모니터링과 제어에 필요한 활동. 일부 소프트웨어 개발 수명주기 모델에서는 완료의 정의로 칭하기도 한다.

특정 테스트 레벨에서 이루어진 테스트 실행의 종료 조건 평가 예시

  • 명시된 커버리지 조건 대비 테스트 결과와 로그 확인
  • 테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가
  • 추가 테스트 필요 여부 결정
    • 예를 들어, 일정 수준의 제품 리스크 커버리지를 달성하고자 햇던 테스트가 그러지 못했을 경우, 추가적인 테스트 작성 및 실행 요구

계획 대비 테스트 진행 상황은 이해관계자에게 테스트 진행 상황 보고서의 형태로 전달된다. 보고서에는 계획대비 편차와 테스팅을 그만하기로 결정했다면 그것을 뒷받침해 줄 정보도 포함한다.

테스트 분석

측정 가능한 커버리지 조건의 측면에서 ‘무엇을 테스트할지’ 결정하는 것이다.

테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석한다.

테스트 분석의 주요 활동
  • 고려 중인 테스트 레벨에 적합한 테스트 베이시스 평가
    • 요구사항 명세
      • 비즈니스 요구사항
      • 기능 요구사항
      • 시스템 요구사항
      • 사용자 스토리
      • epic
      • 유스케이스
      • 요구되는 기능/비기능 컴포넌트나 시스템의 동작이 명시된 유사한 작업 산출물
    • 설계와 구현 정보
      • 시스템이나 소프트웨어 아키텍처 다이어그램 또는 문서
      • 설계 명세
      • 콜 흐름도 call flow graphs
      • 모델링 다이어그램 UML, entity-relationship diagrams
      • 인터페이스 명세
      • 컴포넌트나 시스템 구조를 명시하고 잇는 기타 유사한 작업 산출물
    • 구현한 컴포넌트나 시스템
      • 코드
      • 데이터베이스 메타데이터
      • 쿼리
      • 인터페이스
    • 컴포넌트나 시스템의 기능, 비기능, 구조 측면을 고려한 리스크 분석 보고서
  • 테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별
    • 모호함
    • 누락
    • 불일치
    • 부정확
    • 모순
    • 불필요한 구문
  • 테스트할 기능과 기능 세트 식별
  • 테스트 베이시스를 평가하고 기능, 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준 등을 고려해서 각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정
  • 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착

테스트 분석에 블랙박스, 화이트박스, 경험 기반 기법을 적용하면 주요 테스트 컨디션의 누락을 방지하고, 더 정확하고 정밀한 테스트 컨디션 도출에 도움이 될 수 있다.

테스트 차터test charter: 일부 경험 기반 테스팅 유형에서 사용하는 작업 산출물. 테스트 분석의 결과로 테스트 차터의 테스트 목적으로 사용할 테스트 컨디션이 생성되는 경우도 있다.

테스트 목적과 테스트 베이시스 간의 추적성을 확인할 수 잇는 경우, 이런 경험 기반 테스팅으로 달성하는 커버리지를 측정할 수 있다.

결함 식별

테스트 분석 중 결함 식별은 큰 잠재적 이점이다.

테스트 분석 활동은 요구사항이 일관성 있게 제대로 설명되고 완성되었는지 검증할 뿐만 아니라,

요구사항이 고객, 사용자, 기타 이해관계자의 요구를 제대로 반영하고 있는지 확인하게 해준다.

예시

  • 행위 주도 개발 BDD Behavior Driven Development, 인수 테스트 주도 개발 ATDD Acceptance Test Driven Development: 사용자 스토리와 인수 조건으로부터 테스트 컨디션과 테스트 케이스를 도출. 사용자 스토리와 인수 조건에 대해서도 검증, 확인, 결함 발견 활동을 수행
테스트 설계

테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어 생성.

어떻게 테스트할 것인지 다룬다.

  • 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정
  • 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별
  • 테스트 환경 설계와 필요한 인프라 및 도구 식별
  • 테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정

테스트 설계에서도 테스트 베이시스에서 유사한 유형의 결함을 식별할 수 있다. 결함 식별은 큰 잠재적 이점이다.

테스트 구현

테스트 실행에 필요한 테스트웨어를 생성하고 완성하는 것

테스트 케이스를 배치해서 테스트 프로시저를 만드는 것

테스트를 실행하기 위한 모든 것이 갖춰져 있는가를 다룬다.

  • 테스트 프로시저의 개발과 우선순위 선정. 가능하다면 자동 테스트 스크립트 생성.
  • 테스트 프로시저와 자동 테스트 스크립트로부터 테스트 스위트 생성
  • 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치
  • 테스트 환경 구축, 테스트 하네스, 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목, 필요한 모든 사항을 제대로 구현했는지 확인
  • 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인
  • 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로 간의 양방향 추적성 검증과 업데이트
테스트 실행

테스트 스위트를 테스트 실행 일정에 따라 실행한다.

  • 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
  • 테스트를 수동으로/테스트 실행 도구를 활용해서 실행
  • 기대 결과와 실제 결과 비교
  • 이상 현상을 분석해 원인 파악(코드 결함인지 거짓양성인지 등)
  • 관찰한 장애를 기반으로 결함 보고
  • 테스트 실행 결과 기록
  • 이상 현상 때문에 취한 활동의 결과로 인해/계획된 테스팅의 일부로 테스트 활동 반복 (수정된 테스트 실행, 확인 테스팅이나 리그레션 테스팅 등)
  • 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성 검증과 업데이트
테스트 완료

완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동

소프트웨어 시스템을 릴리즈 했을 때, 테스트 프로젝트를 완료 했을 때, 애자일 반복주기가 끝났을 때, 특정 테스트 레벨을 완료했을 때, 유지보수 릴리즈를 완료했을 때와 같은 프로젝트 마일스톤 시점에 테스트 완료가 된다.

  • 모든 결함 보고 처리를 완료했는지, 테스트 실행 수 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인
  • 이해관계자에게 전달할 테스트 요약 보고서 생성
  • 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관
  • 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계
  • 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복주기, 릴리즈, 또는 프로젝트를 위해 수정해야하는 사항 판단
  • 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용
reference

ISTQB Certified Tester Foundation Level Syllabus 201