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 테스트 접근법, 전략
▶ 테스트 접근법 또는 전략
- 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정.
- 방법 :
>> 예방적 접근법 : 가능한 프로젝트 초반에 즉, 개발이 완료되기 전에 테스트를 설계
>> 사후 접근법 : 소프트웨어 또는 시스템이 개발된 이후에 테스트를 설계
'ISTQB > ISTQB_SW테스팅' 카테고리의 다른 글
ISTQB/ SW 테스팅 ) 6장. 테스트 지원 도구에 대해 알아보자 (1). (0) | 2024.03.28 |
---|---|
ISTQB/ SW 테스팅 ) 5장. 테스트 경과 모니터링, 결함 관리에 대해 알아보자. (0) | 2024.03.26 |
ISTQB/ SW 테스팅 ) 4장. 소프트웨어 품질 특성에 대해 알아보자. (0) | 2024.03.25 |
ISTQB/ SW 테스팅 ) 4장. 구조 기반 기법과 경험 기반 기법 - 오류 추정, 체크 리스트에 대해 알아보자. (0) | 2024.03.22 |
ISTQB/ SW 테스팅 ) 4장. 명세기반 기법 - 페어와이즈 조합 테스팅에 대해 알아보자. (0) | 2024.03.22 |