테스트 활동 관리

테스트 계획

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

테스트 계획서

    - 테스트 목적 달성을 위한 방법과 일정을 문서화

    - 수행한 테스트 활동이 정해진 기준을 충족하는데 도움

    - 팀원과 기타 이해관계자의 의사소통 수단으로 사용

    - 테스팅이 수립한 테스트 정책 및 전략을 준수함

 

테스트 계획 활동 : 테스터가 리스크, 일정, 인력, 도구, 비용, 노력 등 향후 문제를 고민하도록 한다.

테스트 계획서를 준비하는 과정은 테스트 목적을 달성하는 데 필요한 노력을 추론하는 유용한 방법이다.

 

테스트 계획서의 포함 내용

    - 테스팅 정황(테스트 범위, 테스트 목적, 테스트 베이시스)

    - 테스트 프로젝트의 가정 및 제약 사항

    - 이해관계자(역함, 책임 등)

    - 의사소통(의사소통 방법 및 빈도, 문서 양식 등)

    - 리스크 목록

    - 테스트 접근법

    - 예산 및 일정

 

 

반복 주기와 릴리스 계획에 대한 테스터의 기여

SDLC에서 두가지의 계획, 릴리스 계획과 반복 주기 계획이 이루어진다.

 

릴리스 계획

제품 릴리스를 계획하는 단계로 제품 백로그를 정의하며, 큰 사용자 스토리를 작은 사용자 스토리들로 세분화 하는 작업을 포함할 수 있다. 개별 반복 주기의 테스트 접근법과 테스트 계획을 위한 기반이 된다.

 

반복 주기 계획

개별 반복 주기를 계획하는 것으로 반복 주기 백로그와 관련이 있다. 반복 주기 계획에 참여하는 테스터는 사용자 스토리의 구체적인 리스크 분석에 참여하고, 사용자 스토리의 테스트 용이성을 판단하고, 사용자 스토리를 업무 단위로 분류하고, 각 테스팅 업무에 필요한 테스트 노력을 추정한다.

 

 

시작 조건과 완료 조건

시작 조건 : 어떤 활동을 수행하기 위한 전제 조건을 정의, 시작 조건을 충족하지 못하면 해당 활동을 수행하는 것이 어려워져 들어가는 시간과 비용이 늘어난다.

--> 많이 사용하는 시작 조건 : 자원의 가용성, 테스트웨어 가용성, 테스트 대상의 초기 품질 수준

 

완료 조건 : 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항들을 정의한다.

--> 일반적인 테스트 완료 조건 : 커버리지 수준, 미해결 결함 수, 결함 밀도, 예/아니오로 판단되는 기준

 

시작 조건과 완료 조건은 각 테스트 레벨에 대해 정의해야 하며, 테스트 목적에 따라 달라진다.

 

*시간 및 예산의 소진도 유효한 완료 조건으로 볼 수 있다.

**애자일 소프트웨어 개발에서 완료 조건을 완료의 정의라고 하는 경우가 많으며 릴리스 가능 항목에 대해 메트릭을 정의한다.

 

 

추정 기법

테스트 프로젝트의 테스트 목적을 달성하는 데 필요한 테스트 관련 작업량을 예측하는 것이다.

추정에는 항상 오류가 있을 수 있다는 점을 이해관계자가 명확하게 알고 있어야 한다.

보통은 큰 규모가 작은 규모 작업보다 부정확하다.

 

추정 기법중 4가지는 다음과 같다.

비율 기반 추정 : 메트릭 기반 기법, 이전 프로젝트 수치를 수집해 표준 비율을 도출

 

외삽법 : 메트릭 기반 기법, 현재 프로젝트에서 데이터 수집을 위해 가능한 빨리 측정을 수행. 이후 외삽법을 적용해 남은 작업에

             필요한 근사치를 추정 -> 반복적 SDLC에 매우 적합

 

와이드밴드 델파이 : 반복적, 전문가 기반 기법으로 전문가의 경험을 기반으로 추정함.  각 전문가는 독립적으로 노력을 추정

                              합의된 범위를 벗어나는 편차가 없을 때까지 추정치를 논의 후 새로운 추정치를 제시, 플래닝 포커와 비슷

 

3점 추정 : 전문가 기반 기법, 전문가가 세개의 추정치를 도출. 낙관적, 확률적, 비관적 추정치를 가지고 계산

 

 

테스트 케이스 우선 순위 지정

테스트 케이스와 테스트 절차를 도출해서 테스트 스위트로 조립하고 나면 테스트 스위트를 테스트 일정으로 구성할 수 있다.

테스트 일정은 테스트 실행 순서를 정의한다. 테스트 케이스의 우선 순위를 정할 때 다양한 요소를 고려할 수 있다.

 

- 리스크 기반 우선순위 지정 : 리스크 분석 결과에 따라 테스트 실행 순서를 결정한다.

- 커버리지 기반 우선순위 지정 : 가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행한다.

- 요구사항 기반 우선순위 지정 : 실행 순서를 테스트 케이스의 기반이 되는 요구사항의 우선순위에 따라 결정한다.

 

위에서 언급한 것 중 하나 또는 여러 전략을 사용해 우선순위를 지정해서 테스트 케이스 실행 순서를 도출하는 것이 이상적이다.

그러나 TC, 테스트 대상 기능이 종속성을 가진 경우 그렇게 하기 힘들 수 있다.

-> 테스트 실행 순서에는 자원의 가용성도 고려해야 한다.

 

 

테스트 피라미드

테스트 피라미드 : 테스트에 따라 세분화 수준이 다를 수 있다는 것을 보여주는 모델이다.

테스트 피라미드 모델은 다양한 테스트 목표가 서로 다른 테스트 자동화 수준에 따라 지원된다는 것을 보여줌으로써 팀의 테스트 자동화와 테스트 노력 할당을 지원한다.

 

층이 높아질수록 테스트 세분화 정도는 낮아지고, 격리는 낮아지며(시스템의 다른 요소에 대한 의존도), 테스트 실행 시간은 길어진다. 아래층에 있는 테스트는 규모가 작고, 독립적이며 빠르다.

아래층 테스트는 기능이 작기 때문에 적절한 커버리지를 달성하기 위해 많은 테스트가 필요한 경우가 많다.

높은 층은 복잡하고 상위 수준의 엔드 투 엔드 테스트를 대변한다.

 

 

테스팅 사분면

브라이언 마릭이 정의한 테스팅 사분면은 애자일 소프트웨어 개발에서 테스트 레벨을 적합한 테스트 유형, 활동, 테스트 기법, 작업 산출물과 묶고 있다.

이 모델은 이런 사항들을 시각화해서 테스트 관리자가 필요한 모든 테스트 유형과 테스트 레벨을 소프트웨어 개발수명주기에 포함한다.

 

네개의 사분면은 다음과 같다

- 1사분면(기술 측면, 팀 지원) : 컴포넌트 테스트 및 컴포넌트 통합 테스트를 포함한다. 자동화 해야하며 CI에 포함되어야 한다.

- 2사분면(비즈니스 측면, 팀 지원) : 기능 테스트, 예제, 사용자 스토리 테스트 등을 포함한다. 인수 조건을 확인

- 3사분면(비즈니스 측면, 제품 평가) : 사용성, 사용자 인수테스팅 포함, 사용자 중심으로 이루어지며 수동으로 실행이 많다.

- 4사분면(기술 측면, 제품 평가) : 스모크 테스트와 비기능 테스트를 포함한다. 자동화 되는 경우가 많다.

 

 

 

 

리스크 관리

리스크 관리 : 조직이 목표를 달성할 가능성과 제품의 품질을 높이고, 이해관계자의 신뢰와 믿음을 얻을 수 있게 한다.

 

리스크 관리 활동은 다음과 같다

- 리스크 분석

- 리스크 제어

 

리스크 분석과 리스크 제어를 기반으로 텍스트 활동을 선택하고, 우선순위를 정해 관리하는 테스트 접근법을 리스크 기반 테스팅이라고 한다.

 

 

리스크의 정의와 리스크의 속성

리스크는 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황을 말한다.

리스크는 두가지 요소로 특정 지을 수 있다.

    - 리스크 발생 가능성 : 리스크 발생 확률(0보다 크고 1보다 작음)

    - 리스크 영향(피해) : 발생했을 때 생기게 될 피해

 

두가지 요소로 리스크 수준을 표현한다. 리스크 수준은 리스크를 측정한 값이 된다.

 

 

프로젝트 리스크와 제품 리스크

일반적으로 소프트웨어 테스팅에서 두가지 유형의 리스크가 있다.

 

프로젝트 리스크 : 프로젝트 관리 및 제어와 관련이 있다. 프로젝트 리스크는 다음이 포함된다.

    - 조직 문제

    - 인력 문제

    - 기술적 문제

    - 공급업체 문제

 

제품 리스크 : 제품 품질 특성과 관련이 있다. 제품리스크가 발현되면 다음과 같은 부정적 결과를 초래할 수 있다.

    - 사용자 불만족

    - 매출, 신뢰, 평판 손실

    - 제 3자 피해

    - 높은 유지보수 비용, 고객지원 부서의 과부화

    - 형사 처벌

    - 극단적 경우 신체적 손상, 부상, 사망

 

 

제품 리스크 분석

테스팅 관점에서 제품 리스크 분석의 목표는 제품 리스크를 인식함으로써 잔존 제품 리스크 수준을 최소화하는 방향으로 테스트 노력을 집중할 수 있도록 하는 것이다. 제품 리스크 분석은 소프트웨어 개발수명주기 초기에 하는 것이 이상적이다.

 

제품 리스크 분석은 식별과 평가로 이루어진다.

리스크 식별 : 포괄적인 리스크 목록을 생성, 우선순위를 결정, 조치 방법 포함

리스크 평가 : 정략적 또는 정성적 접근법 사용, 정량적 접근법 리스크 발생 가능성과 리스크 영향을 곱함, 정성적 리스크 행렬 사용

 

제품 리스크 분석은 테스팅의 철저함 정도와 테스트 범위에 영향을 미칠 수 있다. 분석 결과는 다음과 같이 활용한다.

    - 수행할 테스트 범위 결정

    - 테스트 레벨 결정 및 수행할 테스트 유형 제안

    - 사용할 테스트 기법과 달성할 커버리지 결정

    - 업무별 필요 테스트 노력 추정

    - 중요 결함을 가능한 한 빨리 식별하기 위한 테스트 우선순위지정

    - 리스크를 줄이기 위해 테스팅 외 다른 활동을 할 수 있는지 판다

 

 

제품 리스크 제어

제품 리스크 제어 : 식별 및 평가된 제품 리스크에 대응해 취하는 모든 조치를 말한다.

 

제품 리스크 완화를 위해 취할 수 있는 조치는 다음과 같다.

    - 주어진 리스크 유형에 적절한 경험과 기술을 갖춘 테스터 선정

    - 적절한 수준의 테스팅 독립성 적용

    - 리뷰 및 정적 분석 수행

    - 적절한 테스트 기법 및 커버리지 수준 적용

    - 영향을 받는 품질 특성을 다루는 적절한 테스트 유형 적용

    - 리그레션 테스팅을 포함한 동적 테스팅 수행

 

 

 

 

테스트 모니터링, 테스트 제어, 테스트 완료

테스트 모니터링 : 테스팅에 대한 정보 수짐 -> 테스트 진행 상황 평가 및 완료 조건 관련된 테스트 작업이 충족되었는지 측정에 사용

테스트 제어 : 테스트 모니터링에서 얻은 정보를 기반으로 효과적이고 효율적인 테스팅을 위한 제어 지침 등을 제공

테스트 완료 : 끝난 테스트 활동에서 데이터를 수집하여 경험, 테스트웨어, 기타 관련 정보를 수집

 

 

테스팅에 사용하는 메트릭

테스트 메트릭 : 계획한 테스트 일정 및 예산 대비 현재 진행 상황, 테스트 대상의 현재 품질, 테스트 목적이나 반복 주기 목표 대비 테스트 활동의 효과를 보여주기 위해 수집한다.

 

많이 사용하는 테스트 메트릭은 다음과 같다

    - 프로젝트 진행 상황 메트릭

    - 테스트 진행 상황 메트릭

    - 제품 품질 메트릭

    - 결함 메트릭

    - 리스크 메트릭

    - 커버리지 메트릭

    - 비용 메트릭

 

 

테스트 보고서의 목적, 내용, 대상

테스트 보고 : 테스팅 도중과 이후에 테스트 정보를 요약하고 전달하는 활동

테스트 진행상황 보고서 : 테스트 제어를 지원하며, 계획에서 벗어나거나 상황이 바뀌어 테스트 일정, 자원 테스트 계획을 수정해야 할 경우 그것을 할 수 있는 충분한 정보를 제공해야 한다.

 

테스트 진행 상황 보고서의 포함 내용은 다음과 같다

    - 테스팅 기간

    - 테스팅 진행 상황

    - 테스팅 진행 방해 요소와 대응 방법

    - 테스트 메트릭

    - 테스팅 중 식별한 신규 및 변경된 리스크

    - 다음 주기에 예정된 테스팅

 

테스트 완료 보고서 : 프로젝트, 테스트 레벨, 테스트 유형이 끝나고 작성된다.

테스트 완료 보고서의 포함 내용은 다음과 같다.

    - 테스트 요약

    - 원래 테스트 계획에 기반한 테스팅 및 제품 품질 평가

    - 테스트 계획과의 편차

    - 테스팅 방해 요소와 대응 방법

    - 테스트 진행 상황 보고서를 기반으로 한 테스트 메트릭

    - 완화되지 않은 리스크, 수정되지 않은 결함

    - 테스팅 관련 교훈

보고하는 대상에 따라 보고서에 들어갈 정도가 달라지고, 보고의 형식과 빈도도 달라진다. 같은 팀 구성원에게 테스트 진행 상황을 보고할때는 빈번하고 비공식적인 경우가 많지만, 테스트완료 보고는 정해진 템플릿을 따르며 한 번만 이루어지는 것이 일반적이다.

 

 

테스팅 상황 전달

테스트 상황을 전달하는 가장 좋은 의사소통 방법은 테스트 관리자의 관심, 조직의 테스트 전략, 규제 표준 등에 따라 달라진다.

    - 팀원 및 기타 이해관계자와의 대화

    - 대시보드

    - 전자 통신 채널

    - 온라인 문서

    - 공식 테스트 보고서

이런 선택지 중 하나  이상을 사용할 수 있다. 물리적 거리나 시차로 인해 직접적인 대화가 어려운 팀은 더욱 공식적인 의사소통 방법을 사용하는 것이 적합할 수 있다.

 

 

 

 

형상 관리

형상 관리 : 테스트 계획서, 테스트 전략서, 테스트 컨디션, 테스트 케이스, 테스트 스크립트 등 작업 산출물을 형항 항목으로 식별, 제어, 추적한다.

 

형상관리는 새 베이스라인을 만들 때 변경된 형상 항목에 대한 기록을 유지한다. 이전 베이스라인으로 되돌리면 이전 테스트 결과를 재현할 수 있게 된다.

 

테스팅을 적절히 지원하기 위해 형상 관리는 다음을 보장한다

    - 테스트 항목을 포함한 모든 형상 항목에는 고유한 식별자가 부여되고, 버전이 관리되며, 변경사항이 있는지 추적된다

    - 식별된 모든 문서와 소프트웨어 항목은 테스트웨어 내에 명확하게 참조되어야 한다.

 

 

 

 

결함 관리

*테스트의 주요 목적 중 하나가 결함 식별이므로 잘 확립된 결함 관리 프로세스가 필요하다. 여기서 '결함'이라고 부르고 있지만, 보고된 이상 사항은 실제로 결함일수도 아닐수도 있다. 이 문제는 결함 보고서를 처리하는 과정에서 해결된다.

이상 사항은 소프트웨어 개발수명주기 모든 단계에서 보고될 수 있으며, 그 양식은 소프트웨어 개발수명주기에 따라 달라진다.

 

일반적인 결함 보고서는 다음과 같은 목적을 가진다.

    - 결함을 처리 및 해결하는 책임을 진 사람에게 문제 해결을 위한 충분한 정보 제공

    - 작업 결과물의 품질을 추적할 수 있는 수단 제공

    - 개발 및 테스트 프로세스 개선을 위한 아이디어 제공

 

일반적으로 동적 테스팅 중에 작성하는 결함 보고서는 다음을 포함한다.

    - 고유 식별자

    - 보고하는 이상 사항을 요약하는 제목

    - 이상 사항이 관찰된 날짜, 보고 주체 조직, 작성자

    - 테스트 대상 및 테스트 환경 식별 정보

    - 결함의 정황

    - 이상 사항을 발견한 절차, 관련 테스트 로그, 데이터베이스 덤프, 스크린샷, 녹음 파일 등

    - 기대 결과와 실제 결과

    - 결함이 이해관계자의 이익 또는 요구사항에 끼치는 영향의 심각도

    - 수정 우선순위

    - 결함 상태

    - 참조 사항

이런 데이터 중 일부는 결함 관리 도구를 사용하면 자동으로 포함된다.