개발자도 알아야 할 소프트웨어 테스팅 실무 요약 5

5.1 테스트 조직(Test Organization)

5.1.1 테스트 조직과 독립성(Test organization and independence)

오늘날 품질에 대한 기대가 높아져 많은 기업에서 테스트팀과 개발팀을 독립적으로 운영하려 한다.

특히 거대하고 복잡하거나 안전최우선(safety critical)인 시스템을 테스트하는 경우, 모든 테스트 레벨을 독립적인 테스터가 수행하게 할 수 있다. 

 

독립성(테스트 조직을 독립적으로 운영하는 것)의 장점

• 결함을 보는 시각, 결함을 발견하는 방법이 개발자와 달라 상대적으로 객관적이다.
• 개발단계에서 작성된 명세와 구현 산출물을 객관적으로 검증할 수 있다.
• 테스트 전문가로서 결함을 효과적이고 효율적으로 찾아내는 전략적 접근이 가능하다.
• 테스팅 프로세스 평가를 통해 테스팅을 개선할 수 있다.

 

테스트 조직의 독립성 수준이 높을 때 단점

• 제품관련 정보로부터 고립될 가능성 높다.
• 독립적 테스트를 마지막 체크포인트로 활용한다면 프로젝트의 병목으로 작용할 수 있다.
• 개발자가 품질에 책임지려 하지 않음
• 분리된 조직간 의사소통 심해질 수 있음
• 테스트 조직의 독립성은 조직의 문화와 추구 목적을 면밀히 고려하여 접근하는 것이 필요하다.

 

독립성 강한 테스트 조직 유지하면서 동시에 개발 조직과 밀착된 독립성이 낮은 소규모 조직 유지 사례 있다.

3~5명의 테스트 전담인력 두고, 개발 관련 모든 정보 공유하면서 개발 일정에 맞춰 짧은 주기로 단시간 내 집중적으로 테스팅 진행한다.

 

5.1.2 테스트 리더와 테스터의 임무(Tasks of the test leader and tester)

테스트 조직 직무 세분화하면 테스트 매니저, 테스트 팀 리더, 테스트 분석가, 테스트 수행가, 네비게이터 그리고 테스트 컨설턴트 등으로 분류할 수 있다. 

 

테스트 리더

테스팅 활동과 업무를 계획, 모니터링하고 제어하는 역할을 수행

프로젝트 관리자, 개발 관리자, 품질보증 관리자 또는 테스트 그룹 관리자가 테스트 리더의 역할을 수행할 수 있다. 

 

테스터

수립된 테스트 전략과 방향, 계획 및 테스트 리더의 지침에 따라 테스트 명세(설계) 를 구현하고 테스트를 실행하는 역할을 수행한다. 반복 테스트가 많은 경우 자동화하거나 일회성 성격 강한 테스트 경우 필요에 따라 테스트 수행 전문 외주 인력 관리 역할도 테스터의 업무에 해당한다.

 

테스터의 업무

• 테스트 환경 구축한다.
• 테스트 데이터 준비 및 획득을 담당한다.
• 컴포넌트나 시스템의 성능을 측정한다.
• 테스트 명세서를 리뷰한다.
• 테스트 구현, 실행, 로그 기록 및 테스트 실행 결과 평가, 결함 보고의 임무를 수행한다.

 

5.2 테스트 계획과 추정 (Test planning and estimation)

5.2.1 테스트 계획(Test planning)

테스트에 대한 정보가 상세화 될수록 테스트 계획 역시 상세화 된다.

 

5.2.2 테스트 계획 활동 내용(test planning activities)

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

 

테스트 범위(scope)와 리스크를 결정하고, 테스팅의 목적을 식별한다.

테스트의 총체적인 접근법(테스트 전략)을 정의한다.

sw의 획득, 공급, 개발, 운영, 유지보수 단계의 수명주기 활동을 통합하고 지정한다.

 

5.2.3 완료 조건(exit criteria)

하나의 테스트 레벨 또는 특정 목적의 테스팅이 언제 종료할지를 정의하는 것이다.

 

테스트 완료 조건의 사례

• 코드, 기능, 리스크 커버리지와 같은 보장성 또는 충분함에 대한 측정치(throughness measures)
• 추정된 결함 밀도 또는 신뢰성 측정치
• 잔존 리스크(예. 수정되지 않은 결함 또는 테스트 커버리지가 부족한 테스트 영역)
• 시간당 결함수
• 재테스트(re-test) 횟수
• 예방된 피해(damage)와 소요되는 테스트 비용 비교(예. 예방된 피해가 테스트 비용보다 적을 때)

 

5.2.4 테스트 추정(test estimation)

테스트 프로세스에 관여하는 모든 작업들에 대한 비용, 노력, 기간을 결정하는 것이다.

 

테스트 추정 방법 중 대표적인 접근법

메트릭 기반(metrics-based) 접근법 : 과거 프로젝트나 유사프로젝트의 메트릭을 근거로 또는 전형적인 가치를 근거로 테스트 노력 또는 업무량(effort) 예측

전문가 기반(expert-based) 접근법 : 전문가나 업무(tasks) 수행 주체에 의한 예측

 

어떤 접근법이든 리스크 분석과 테스트 전략을 근거로 산정해야 하며, 수행할 예정인 업무를 세분화하여 각 업무에 자원을 배분하고 수렴하는 WBS(Work Breakdown Structure) 방식을 택할 수 있다.

 

테스팅 활동의 비용, 노력, 기간을 추정할 때 고려해야 할 요소들

테스트를 시작할 수 있는 시점

테스트 용이성

잠재결함이 얼마나 많은가

테스트웨어의 재사용성

제품의 특성 : 테스트 베이시스의 품질, 제품 사이즈, 도메인 복잡성, 신뢰성 및 보안성 요구사항 문서화 요구 등

 

sw 개발 사이즈 분석 도구인 기능 점수(function point)와 유사한 테스트 추정을 지원하는 도구인 TPA(Test Point analysis) 가 존재한다. 개발의 어려움을 반영한 것이 기능점수라면 TPA는 테스팅의 어려움을 분석하여 테스트의 노력을 체계적으로 산정한다.

 

5.2.5 테스트 접근법, 전략(Test approach, test strategies)

테스트 접근법 또는 전략이란 테스트 레벨, 유형, 사람, 도구, 절차, 방법, 자원 등과 같은 테스트 필요 요소들에 대한 접근 방법을 타당한 근거를 기반으로 결정하는 것을 의미한다. 개발과정 중에 결함을 발견하는 예방적 접근법과 개발 이후에 테스트 실행을 통해 결함을 발견하는 사후적 접근법으로 분류할 수 있다.

 

예방적 접근법(preventative approaches) : 가능한 프로젝트 초반에 테스트 설계

사후(행동)적 접근법(reactive approaches) : sw 또는 시스템이 개발된 이후 테스트 설계

 

방법론적 접근법

프로세스 및 표준 준수 접근법

동적/발견적(dynamic and heuristic)

자문기반(consultive)

리그레션 기피형(regression-averse)

 

5.3 모니터링과 제어

5.3.1 테스트 경과 모니터링

테스트 모니터링의 목적은 테스트 활동에 대한 피드백과 가시성(visibility)을 제공하여 테스트 계획 또는 조직차원의 정책이나 전략을 준수하여 테스팅이 수행되는지를 관찰하는 것이다. 

 

모니터링 활동

테스트 진행 보고서(test status report) 검토

수집도니 테스트 메트릭(test metrics) 분석

이해관계자 공유 미팅 수행

 

모니터링 대상이 되는 일반적인 테스트 메트릭 

 

5.3.2 테스트 리포팅

테스트 보고서의 종류

테스트 진행 보고서(test status report) :테스트 계획서에 계획된 업무들을 수행하는 동안 주요 시점에 현재 상황 보고

테스트 종료 보고서(test completion report) : 특정 테스트 유형 및 테스트 레벨이 종료되는 시점에 테스트 결과를 보고

 

 

테스트 보고서에 포함 요소

잔존 결함의 평가

테스팅 수행의 경제적 이득

부각된 리스크

테스트된 sw에 대한 자신감 척도

 

테스트 보고서의 계획 및 설계 시 추가적 고려 요소

요구사항 별 테스트 일 수 (days test effort per requirement)

해결되지 않은 결함과 그 영향(hot spot analysis)

오랫동안 수정되지 않은 결함 분석(defect age analysis)

결함 원인 분석

테스팅의 상태

sw 사이즈 대비 결함 수 (코드 라인 당 결함 수)

 

테스트 종료 보고서(test completion report)

특정 테스트 유형 또는 테스트 레벨의 종료 시점에 작성하는 보고서

전체 프로젝트 종료 시점에 작성되는 최종 보고서

 

 

좋은 리포팅의 요건

테스트 목적 및 요구사항과 일치

경향(trend)을 리포팅

리포트 분량의 제한

'측정'의 의미를 설명

테스트 전체와의 연계성

 

5.3.3 테스트 제어

테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행되도록 가이드 하거나 정정하는 활동이다. 테스팅 전 영역을 범위로 하며 sw 수명주기 활동/업무에 영향을 줄 수 있다.

 

수정사항을 빌드에 반영하기 전에 해당 수정사항을 개발자가 재테스트하도록 요구사흔ㄴ 것과 같은 테스트 시작 조건(entry criteria)을 정한다.

 

5.3.4 테스트 완료

테스트 계획서, 자동화 테스트 절차 및 매뉴얼, 테스트 환경 구성과 같은 테스트 자산을 식별하고, 형상관리 등을 통해 보존한다.

테스트 환경을 다음 단계 사용자 위해 정제(clean up)한다.

재사용 가능한 테스트 자산을 식별한다.

교훈(lesson learned)을 공유한다.

테스트 완료보고서에 테스트 계획대비 실적, 결함 상태, 리스크 와 테스트 자산의 보존 상황 및 교훈을 기록하고 이해관계자에 보고한다.

 

5.4 형상 관리(configuration management)

형상 관리 보증 항목

테스트웨어 식별, 버전 관리, 변경 추적, 상호 연관성, 개발 아이템과 연계 관리 등을 통해 테스트 프로세스 전반에 걸친 추적성 확보

테스트 문서에서 참조하고 있는 모든 관련 문서 또는 sw 아이템이 모호하지 않게 관리됨

 

테스터는 형상 관리를 통해 테스트된 품목, 문서, tc와 테스트 하네스 를 혼선없이 관리하고 효율적으로 재사용할 수 있다.

 

5.5 리스크와 테스팅

레이놀즈는 리스크를 장애(failure)로 인해 주어진 기간에 발생 가능한 비용으로 정의하고 리스크를 다음과 같이 산출하고자 했다.

 

리스크 = 장애 가능성(failure) x 손실(damage)

 

 

리스크 = 사용 빈도(frequency of use) x 결함 가능성(chance of defect) x 손실(damage)

 

 

5.5.1 프로젝트 리스크

다음과 같은 리스크 존재

조직적인 요소

정치적인 이슈

- 테스터가 자신의 요구(needs)와 테스트 결과를 커뮤니케이션 하는데 있어서의 문제

- 테스팅과 리뷰에서 발견된 정보를 개발 프로젝트에 반영하는 것에 실패

테스팅에 대한 비현실적 태도나 기대치(테스팅 중에 검출한 결함 가치 인정하지 않음)

 

공급자 이슈(supplier issues)

공급자인 제 3자 협력업체(third party) 가 역할 수행에 실패

계약상의 이슈

 

5.5.2 제품 리스크

개발팀에서 전달 받은 장애 가능성이 높은 sw

 

리스크 식별 단계

 

리스크 식별요구사항 분석서에 상위레벨 테스트를 필요로 하는 항목과 아키텍처에서 하위 레벨 테스트가 필요한 항목들을 도출하면 리스크 아이템이 된다.

 

리스크 분석

결국, 장애 발생 빈도(likelihood) 와 장애로 인한 영향(impact)을 분석

 

장애 발생 가능성

- 복잡성, 새로운 개발의 정도, 상호관계(인터페이스 개수), 프로그램 소스 코드의 크기

- 사용된 기술 난이도, 개발팀 경험 미흡

 

장애로 인한 영향

- 사용자에 의한 취급 중요도(잘 팔리는 아이템), 경제적, 안전적, 회사 이미지 피해, 사용 빈도(usage intensity), 외부적 가시성(external visibility) 

리스크의 우선순위를 결정

 

리스크 계획 활동 : 리스크 정보를 근거로 대처 방안 수립(테스트 전략 수립)

리스크 분석 결과를 근거로 대처 방안 수립, 리스클르 줄이는 테스트 생성

분석 단계에서 결정된 리스크 요소의 점수 이용하여 매트릭스에 표시

 

리스크 추적(risk trace) : 리스크 완화 활동에 대한 모니터링 및 제어

 

5.6 인시던트 관리

인시던트 관리의 목적은 테스트에서 발견한 이슈에 대해 추가적으로 수행해야 할 일에 대해 보고하고 추적하기 위함이다.

인시던트는 발견되어 분류되는 시점부터 수정되고 확인될 때까지 추적되어야 할 대상이다.

 

인시던트가 발생 되는 곳은 운영 중인 시스템, 요구사항 문서, 개발 문서, 테스트 문서, 도움말이나 설치 가이드(사용자용 정보 또는 문서) 등이 있다.

 

 인시던트 리포트에 포함되는 내용

테스트 항목(configuration item)과 환경 식별

결함이 시스템에 미치는 심각도

변경이력

 

5.7 테스트 프로세스 평가

테스트 매니지먼트 프로세스

sw 개발 프로젝트에서 총괄적으로 수행해야 할 테스팅을 레벨 별로 또는 유형 별로 수행되도록 관리하고 통제 하는 프로세스를 의미한다.

 

테스트 프로세스 성숙도가 높을 때 기대효과

정렬되고 조직화되며 반복적이 된다.

테스트 비용 절감, 조직 구성원의 만족감 고취시킨다.

결함발견 활동에서 결함 예방 활동으로 변화된다.

정량적으로 측정되며, 관련 데이터가 축적되며 프로세스 문제점 파악할 수 있다.

 

테스트 프로세스 평가 및 개선 모델 - TMMi(Test maturity model integration)와 TPI(Test process improvement)

	TMMi	TPI
(커버하는) 테스트 레벨	하위 레벨과 상위 레벨 테스팅을 유사한 수준으로 다룸	상위레벨 테스팅에 보다 집중
성숙도 평가 접근법	하향식 개선 프로세스를 지향하는 조직차원에서 성숙도 평가(5가지 레벨 평가, 테스트 매니지먼트 영역)	상향식 모델로 특정 프로세스나 프로그램에 대한 테스트 개선을 적절하게 조언(프로세스 별 차별적 평가, 테스트 엔지니어링 영역)
테스트 핵심영역 간 의존성 여부	핵심 영역가 ㄴ의존성 정의하지 않음	핵심 영역간 의존성 정의
모델의 태생(Origin)	학계 개발 업계에서 발전시킴	시스템 테스팅 전문 업체 개발 확산
공식 레벨 부여	TMMi Foundation 공식인증제도(선임심사원 운영)	부여하지 않음
관련 모델	CMMI	TMap 테스트 방법론 강한 연결 고리

 

레벨1 : 레벨2 달성 못하면 레벨1

레벨2 : 테스트 단계 정의하고 체계적으로 테스팅 진행, 테스트 전략 접근법이 테스트 계획에 반영됭어ㅑ 한다. 테스팅이 테스트 계획을 기반으로 모니터링 및 제어(control) 되어야 한다.

문서화 절차에 따라 테스트 환경을 확보하고 관리하여야 한다.

 

조직 구성원들의 의식전환을 요구하기 때문에 가장 어렵고 시간이 많이 소요될 수 있다.

 

레벨3 : 요구사항 정의 단계에 수립이 되어야 한다. 조직 차원의 테스트 표준을 갖도록 하여 보다 일관성 있고 견고한 프로세스를 갖추도록 한다.

 

레벨4 : 테스트를 관리하고 측정하는 단계, 정량적인 측정을 통해 sw 품질 평가 및 테스팅 평가

 

레벨 5: 테스트 프로세스를 최적화하고 지속적으로 개선 단계

 

TPI / TPI Next(새롭게 개정된 tpi 최근 모델)

소제티라는 회사에서 개발하고 현재까지도 지속적으로 발전시키고 있는 모델, 테스트 프로세스의 핵심영역을 20ㄱ로 나누고 각 핵심영역별 수준을 평가하는 테스트 프로세스 심사 프레임워크

 

테스트 성숙도 평가 구조도는 16개 핵심영역(key areas)로 테스트 수행에 직접적으로 관여하는 영역과 간접적으로 관여하는 영역 을 포함한다. 

기존 TPI의 4등급 체계를 통제(CONTROL), 효율, 최적화 수준으로 조직의 성숙도를 표현한다.

이들은 비즈니스 영역 내의 중요성을 감안한 핵심영역간 집합체(Clusters)를 관리한다.

 

 

핵심영역이 특정 수준의 레벨에 도달하기 위해서는 테스팅 자체만으로는 그 효과가 극대화될 수 없다. 관련 프로세스에 대한 개선을 조력(enablers)을 통하여 조언한다.