//구글콘솔 광고 추가가
5.1.1 테스트 조직과 독립성
장점 단점
- 독립적 테스터는 개발자와 다른 시각에서 다른 종류의 결함을 발견 가능.
- 개발자가 가질수 있는 선입관이 적음.
- 개발 수명주기(요구사항 정의, 설계, 구현 단계 등)에서의 산출물과 모델 검증.
- 독립성이 높아질수록 개발팀과 개발 및 제품 관련 정보로부터 단절.
- 독립적 테스터가 출시 권한을 가지면 전체 개발 일정의 병목이 되거나 출시 연기의 원인으로 지목될 수 있음.
- 개발자가 품질에 대한 책임감을 잃을 수 있음.

** 테스팅은 테스터 뿐만 아니라 프로젝트 관리자, 품질 관리자, 비즈니스와 해당 분야 전문가, 인프라 또는 IT 운영자 등 다른 조직에 의해서도 수행 가능.

테스트 조직 생성 및 운영 시 고려할 사항

 - 개발 프로젝트와 조직의 목적에 부합하는 독립성 수준을 결정

 - 개발팀과 테스트 팀과의 의사소통 계획이 적절하게 수립

 - 독립성 수준을 정할 때 개발 산출물의 오픈 가능성을 고려

 - 조직의 규모에 따라 여러 형태의 독립성 수준의 테스트 조직을 운영

 - 개발팀과 테스트팀 간의 갈등을 초례할 수 있는 부분을 고려하여 테스트 정책을 수립하고 배포

 

5.1.2 테스트 리더와 테스터의 임무

 테스트 리더(테스트 매니저, 팀 리더, 분석가)

 - 테스팅 활동과 업무를 계획하고 모니터링하고 제어하는 역할.

   >> 테스트 전략과 계획을 프로젝트 관리자 및 이해 관계자와 조정

   >> 프로젝트 테스트 전략과 조직의 테스트 정책을 작성하고 검토

   >> 테스팅 관점으로 통합적인 계획 활동 등 프로젝트 활동에 기여

   >> 정황과 테스트 목적, 리스크를 고려해 테스트 계획을 수립

   >> 테스트 명세(설계), 준비, 구현과 실행, 테스트 모니터링 및 완료 조건 평가등의 시작을 주도

   >> 테스트 결과와 진척에 따라 계획을 조정하고 문제점 보안을 위해 제어 활동 수행

   >> 추적성 확보에 필요한 테스트웨어 형상 관리 체계(시스템)를 구성

   >> 테스트 진척 및 품질 평가에 필요한 메트릭(점수를 도입할수 있는 평가표)을 도입
   >> 테스트 자동화 대상, 범위 방법을 결정
   >> 테스트 자동화 도구를 선택하고 관련 교육을 계획
   >> 테스트 환경 관련 사항을 결정
   >> 수집한 정보를 근거로 테스트 요약 보고서 작성

테스터(테스트 분석가, 수행가, 네비게이터)

 - 수립된 테스트 전략과 방형, 계획 및 테스트 리더의 지침에 따라 테스트 명세(설계)를 구현하고 실행하는 역할 수행

   >> 테스트 계획을 검토하고 테스트 계획을 이행

   >> 사용자 요구사항, 명세, 모델 등을 분석하여 테스트 용이성을 평가

   >> 테스트 명세를 작성

   >> 필요시 시스템 또는 네트워크 관리 조직과 협의하여 테스트 환경 구축

   >> 테스트 데이터를 준비하고 수집

   >> 모든 테스트 레벨에서 테스트를 구현하고, 테스트를 실행하고 기록하며, 실행 결과를 분석하여 기대 결과와의 차이를 문서화.

   >> 필요시 테스트 운영 및 관리 도구, 테스트 모니터링 도구를 사용.

   >> 테스트를 자동화(개발자나 테스트 자동화 전문가로부터 지원받음)

   >> 컴포넌트나 시스템의 성능을 측정(성능 측정 결과가 필요한 경우)

   >> 동료가 작성한 테스트를 리뷰

5.2.1 테스트 계획

테스트 계획

 - 테스팅 목적, 테스트 범위, 필요한 자원 그리고 일정을 결정하는 등의 업무를 수행하는 활동

 - 조직 차원의 테스트 정책 및 전략, 테스트 범위, 목적, 제품의 리스크, 프로젝트 리스크, 제약사항, 심각성, 테스트 용이성 그리고 자원의 가용성에 영향을 받음

 - 테스트 생명주기 전반에 관여하는 지속적인 작업

- 테스트 목적/ 목표 설정 및 대상 연구
- 테스트 전략 개발 : 리스크 분석, 전략 수립
- 테스트 종료 조건
- 테스트 추정
- 조직 구성
- 테스트 계획
- 테스트 관리 및 제어
- 모니터링(리포팅) : 리포팅 계획 / 설계, 진행 리포팅 

 - 여러 레벨의 테스팅 또는 비기능 테스팅 등을 총괄적으로 지휘하고 조율하며 통제하는 목적을 가짐.

 

레벨 테스트 계획

 - 마스터 테스트 계획 (인수 테스트, 시스템 테스트, 통합 테스트, 단위 테스트, 이식성 테스트, 성능 테스트, 사용성 테스트, 보안 테스트)

 - 각 테스트 레벨에서 수행할 테스트 활동을 기술(마스터 테스트 계획의 내용을 상세하게 기술, 테스트 레벨의 계획서를 별도로 작성)

 - 마스터 테스트 계획에서 다루지 않는 세부 스케줄, 업무, 마일스톤 등을 작성.

 - 각 테스트 레벨에서의 테스트 세부사항은 각각의 레벨 테스트 계획에서 다룸.

 - 비공식적인 프로젝트나 운영환경에서는 주로 하나의 테스트 레벨만 운용하며 이러한 경우 하나의 테스트 계획 문서에 레벨 테스트 계획과 마스터 테스트 계획 내용이 모두 다루어짐. 

5.2.2 테스트 계획 활동 내용

테스트 계획의 주요 활동

 - 테스트를 성공적으로 수행하기 위한 전략을 수립하는 것과 소프트웨어 생명주기 단계별로 적합한 테스팅 관련 작업들을 결정하고, 테스트 대상, 범위 그리고 전략에 기반한 투입자원 및 일정을 계획하는 활동을 포함.

   >> 테스트 범위와 리스크, 테스팅의 목적을 식별 및 결정

   >> 테스트 접근법 정의(테스트 레벨, 테스트 시작/ 종료 조건)

   >> 테스트에 필요한 리소스의 결정(인원, 테스트 환경, PC 등)

   >> 테스트 분석과 설계 작업의 스케줄링

   >> 테스트 구현, 실행 및 평가의 스케쥴링

   >> SW 개발주기(계획)에 테스트 활동 통합(구매, 공급, 개발, 운영, 유지보수)

   >> 테스트 업무와 역할, 테스트 대상, 테스트 업무 종료 방법, 테스트 결과 평가 방법 등 결정

   >> 테스트 문서의 분량, 상세 정도, 문서 구조와 템플릿 정의

   >> 테스트 준비와 실행, 결함 해결과 발생 등의 프로젝트 리스크에 대한 모니터링과 제어에 필요한 메트릭(평가방법 표) 결정

   >> 원활한 테스트 준비와 실행을 위해 테스트 프로시저(절차) 상세 수준을 결정

5.2.3 완료 조건

 - 테스트 시작 기준 : 테스트 수행 시작 시점과 테스트 수행 준비 조건을 정의

범주 사례 예시
테스트 환경의 준비와 가용성 - 테스트 서버 정상가동
- 유무선 인터넷 연결 정상
테스트 환경에서의 테스트 도구 준비 - 성능 측정 도구 셋업 및 정상 동작 확인.
- 동적 분석 도구 라이선스 확보.
테스트 대상 코드의 가용성 - 단위 테스트 결과 구문 커버리지 80%완료
- 형상 관리 서버로 통합된 소스
테스트 데이터 가용성 - 신규 고객 데이터 50건 확보
- 해지된 고객 데이터 20건 확보

 - 테스트 종료 기준: 테스팅 종료 시점과 테스트 수행 목표 달성 조건 정의

 - 리스크 레벨(수준) 별로 테스트 종료 기준 수립

 - 각 테스트 레벨 별로 종료 기준 수립

범주 사례 예시
보장성 또는 완전성 측정치 - 코드 커버리지, 기능 커버리지
- 모든 테스트 케이스를 1회이상 수행
(리스크  & 커버리지 적용) + No 심각 결함
- 수정되지 않은 결함 수(심각도 등급별)
- 시간당 결함 수 --> 0(인수테스트 출하 전 모듈당)
- 예방된 피해 < 테스트 비용
- 수정되지 않은 결함 개수
- 테스트 커버리지
-리스크 수치 추이(리스크 기반 테스트 전략 참조)
- 재테스트(Re- Test) 횟수
추정된 결합 밀도 또는 신뢰성 측정치
테스트 비용과 예산
잔존 리스크
시장 출시시기에 따른 일정

 

5.2.4 테스트 추정

테스트 추정

 - 테스트 노력을 산정

 - 테스트 매니지먼트의 일환으로, 테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정.

메트릭 기반 접근법 - 과거 프로젝트나 유사 프로젝트의 메트릭 근거
- 전형적인 비율 적용(e.g. 프로젝트 전체 대비 20%)
전문가 기반 접근법
(전문가나 업무 주체에 의한 예측)
- 테스트 임무, 리스크 분석, 테스트 전략에 근거
- 업무 세분화해 업무 수행 당사자와 전문가의 경험기반 의견 수렴
- 전문가와 업무 수행 주체가 모여서 합
분류 테스팅 업무량에 영향을 주는 요소들
제품의 특성 - 테스트 베이시스의 품질
- 제품 사이즈
- 문제 도메인의 복잡성
- 신뢰성 및 보안성 요구 수준
- 문서화 요구수준
개발 프로세스의 특성 - 개발 조직의 안정성
- 개발에 사용한 툴
- 테스트 프로세스
- 개발팀의 스킬 수준
- 개발 시간 압박 정도
테스팅 결과물 - (계획한 발견) 결함 수
- 요구되는 (예상) 재 작업량
리스크 수준 맟 테스트 강도 - 선택된 테스트 설계 기법( 개수 및 지식 수준)
- (예상되는) 테스트 케이스 수

기능 정수 TPA

 - 기능 점수 : 개발에 어려움 정도를 반영 ( 라인수, 비용 사정에 사용 )

 - TPA(Test Point Analysis): 테스트의 어려움 분석( 어려움을 분석하여 테스트의 노력을 체계적으로 산정 )

5.2.5 테스트 접근법, 전략

테스트 접근법 또는 전략

 - 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정.

 - 방법 : 

   >> 예방적 접근법 : 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계

   >> 사후 접근법 : 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계

 

 

728x90

+ Recent posts