[D-1] 5.1 테스트 조직

ACAI BERRY DEVELOVER·2023년 8월 23일
0

시스템테스트 레벨에서 독립적인 테스터가 많이 쓰인다.

테스터의 독립성 구현은 사용중인 소프트웨어 개발 수명주기 모델에 따라 다르다.

-테스트 독립성 잠재적 이점

  • 개발자와는 다른 유형의 장애 찾아냄
  • 이해관계자가 정의한 시스템 명세나 테스트 오라클에 대해서 이의를 제기할 수 있다.
    testability를 평가하면서 테스트 베이시스에 대해 틀리고 옳음을 확인가능.
  • 아웃소싱 독립 테스터는 객관적 보고가 가능.

테스트 독립성의 잠재적 단점

  • 개발팀으로부터의 고립으로 협업이 어려움
  • 품질 책임감을 개발자가 잃을 수 있음
  • 병목 현상의 장본인으로 비쳐질 수 있음. (테스터가 일을 늦게 하는 것처럼 보여질 수 있음)-> 메트릭구성과 활용을 잘해서 오해를 풀수 있음

독립성의 단점이 있긴 하지만 최소화하면서 가지고 있는 장점을 극대화해서 성공적인 조직을 만들려고 노력해야한다.

5.1.2 테스트 관리자 및 테스터 역할

  • 테스트 프로세스에 대해 전반적 책임과 테스트 활동을 잘 이끌어가는것
  • 프젝 관리자, 개발 관리자, 품질 보증 관리자가 테스트 관리자를 맡을 수 있음
  • 큰 규모의 조직인 경우 중간관리자를 두어 분산하여 운영한다.

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

  • 테스트 정책과 전략을 개발하고 리뷰
  • 정황을 고려하고 테스트 목적, 리스크를 분석해 테스트 활동을 계획
  • 테스트 계획서 작성, 업데이트
  • 어플리케이션 통합 계획과 테스팅 관점 공유
  • 적절한 메트릭 도입(계획때)
  • 테스트 환경 구축에 관한 결정
    등등..

테스터의 역할은 소프트웨어 개발 수명주기 영향을 받는다.

관리자와 코치의 차이는?
관리자: 어떤 일을 하도록 시킴, 컨트롤,제어
코치 : 어떤 일을 하고자하는 사람에게 서포트

테스터의 역할과 업무

  • 테스터 계획 리뷰, 계획 작성에 참여
  • 테스트베이시스의 테스트 용이성을 분석, 리뷰, 평가
  • 테스트 컨디션 식별 및 기록, 추적성 설립
  • 테스트 환경을 설계, 구축, 검증 다른 팀과 협업
  • TC, 테스트 프로시저를 설계 및 구현
  • 테스트 데이터를 준비하고 획득
  • 상세 테스트 실행 일정 수립 (구현)
  • 테스트 실행, 테스트 로그에 결과 평가 및 기대 결과와 차이 기록

5.2 테스트 계획과 추정

5.2.1 테스트 계획의 목적과 내용

  • 테스트 계획은 개발 및 유지보수 프로젝트의 테스트 활동에 대한 전반적인 내용을 담고 있음.

한번에 작성하지 않는다. 개발 과 유지보수 프로젝트는 따로 만들어 지는 편이다.

  • 계획에 영향을 주는 요소 : 조직의 테스트 정책, 전략, 사용하는 개발 수명주기 방법, 테스팅의 범위, 목적, 리스크, 제약, 심각도 , 테스트 용이성, 자원의 가용성이 있다.
  • 프로젝트, 테스트 계획 작업을 진행함에 따라 많은 정보를 얻게 되고, 테스트 계획에 더 많은 세부 정보를 추가가능.
  • 테스트 계획 활동은 제품의 수명주기 전반에 이루어지는 지속적인 활동(유지보수단계까지 주기 확장 가능)
  • 테스트 활동의 피드백으로 리스크 변화 인지, 테스트 계획을 수정해야함.
  • 계획은 마스터 테스트 계획의 일부로 작성하거나 , 테스트 레별별 또는 테스트 유형별 테스트 계획으로 나눠 작성가능.

테스트 계획에는 다음과 같은 활동이 있고 테스트 계획서에 기록이 가능하다.

  • 테스팅의 범위 정의, 목적, 리스크 결정 (정황 먼저 파악)
  • 전반적인 테스팅 접근법 정의
  • 테스트 활동을 소프트웨어 수명주기 활동에 통합 , 조정
  • 테스트 대상 다양한 테스트 활동에 필요한 인력, 자원, 활동 수행방법 결정
  • 테스트 분석, 설계, 구현, 실행, 평가 활동의 일정 조정. 일정은 특정 날짜나 반복주기 단위로 편성 가능 (마일스톤관점의 일정이다. 상세테스트수립일정과 다르다)
  • 테스트 모니터링과 제어에 사용할 메트릭 선정

❖ 테스트 메트릭도 여러가지 관점이 나올 수 있다.
(생산성- 계획대로 잘 하고 있냐, 제품품질 관점-제품의 결함관련, 테스트를 충분히 하고 있는지에 대한 관점(커버리지) 커버리지는 생산성도 품질도 아니다.테스트 충분성, 보장성 = 커버리지, 테스트 효과성에 대한 모니터링도 필요(테스트를 잘하고 있냐!) 테스트 투자 대비 (시간, 비용, 인력 등 노력 투자) 결함을 얼마나 찾느냐.가 효과성

  • 테스트 활동 예산 결정 (공수비용- 사람을 얼마나 쓸거냐, 혹은 도구비용등, 교육비용)

  • 테스트 문서 구조와 상세화 정도 정의
    테스트 양식 정의(템플릿), 추적성 확보방법정의, 베이시스와 테스트웨어의 추적성 정의

5.2.2 테스트 전략과 테스트 접근법

테스트 전략은 제품이나 조직 수준에서 작성된다.

  • 분석적 : 특정 요소(요구사항, 리스크)에 대한 분석을 기반으로 한 테스트 전략.
    리스크 수준에 따라 테스트 설계, 우선순위 결정하는 리스크 기반 테스팅이 분석적 접근법의 예.

  • 모델 기반: 제품의 특정 측면에 대한 모델을 기반으로 만들어짐.
    비즈니스프로세스, 내부 구조, 기능, 비기능 특성등.
    비즈니스 프로세스 모델, 상태 모델, 신뢰성 성장 모델이 있음

  • 방법론적: 사전 정의한 테스트셋 , 테스트 컨디션을 체계적으로 사용하는데 의존.
    웹 접근성이 방법론적 테스트 전략을 주로 이용한다.

  • 프로세스 준수, 표준 준수 : 외부규정, 표준을 기반으로 테스트를 분석,설계,구현.

세이프티 영역이 특히 포함된다. 의료기기, 원자력, 공장자동화 각각 표준이 있다. 표준준수 여부를 테스팅하는것.

  • 전문가 조언 : 이해관계자, 비즈니스 도메인 전문가, 기술 전문가등의 조언,지시등으로 이루어짐.
  • 리그레션- 기피 : 리그레션되는 것을 회피하는 테스트.
  • 리액티브 어프로치 : 사후 조치. 사전계획에 따라 실행하는 테스트 전략과 달리 시스템에 따라 대응하고 발생하는 이벤트에 따라 반응적으로 수행하는 접근법.
    탐색적 테스팅이 반응적 전략의 예다.

앞의 것을 조합해 (다 조합 가능) 테스트 전략을 만든다. 리스크 기반 테스팅은 항상 포함이 되어있어야 한다.
테스트 접근법은 테스트 기법, 테스트 레벨, 테스트 유형을 선택하는 출발점.
시작조건, 종료조건을 정의하는 출발점.
테스트 접근법은 정황(우리제품의 사용context: 도메인 종류, 사용자 유형,리스크 수준,제품을 만드는 project context: 개발기간, 개발 수명주기)을 기반으로 선택, 리스크 안전사항 자원 역량 특성 목적 규정같은 요소를 고려한다.

profile
쓸때 대충 쓰지 말고! 공부하면서 써!

0개의 댓글