//구글콘솔 광고 추가가
728x90
반응형
들어가기 전 알아둬야 할 5.3 용어 설명
마일스톤 : 프로젝트 진행 과정에서 특정할 만한 건이나 표를 말함. 프로젝트 계획에서 진척 상황을 나타내는 강력한 이정표.

메트릭 : 측정에 쓰이는 측정 척도와 방법.

번다운 차트 : 잔여 작업량과 잔여 시간을 세부적으로 비교해 애자일 팀이 기한까지 어떻게 작업하고 있는지를 시각적으로 나타냄. == 시간에 따라 남아있는 작업의 양을 보여주는 시각적 표현. (팀이 업무를 완료하는 데 충분한 시간이 있는지 효율적으로 계산하기 위해 사용. 일반적으로 짧은 반복 작업을 할 때 사용 된다.)

 

5.3 테스트 모니터링, 테스트 제어, 테스트 완료
테스트 모니터링 : 테스팅에 대한 정보 수집과 관련이 있다. 이 정보는 테스트 진행 상황을 판단하고 테스트 완료 조건 또는 완료 조건과 관련된 테스트 업무가 충족됐는지 측정하는 데 사용.

테스트 제어 : 테스트 모니터링에서 얻은 정보로 가장 효과적이고 효율적인 테스팅을 위한 제어 지침/지도/필요 수정 조치 등을 제공.
제어지침 ex.
1. 식별된 리스크가 발현될 경우 테스트 우선순위 재지정.
2. 재작업 이후 테스트 항목이 시작 조건 및 완료 조건을 충족하는지 재평가.
3. 테스트 환경 인도 지연에 대응하기 위한 테스트 일정 조정.
4. 필요한 지점과 시기에 신규 자원 추가.

테스트 완료 : 끝난 테스트 활동에서 데이터를 수집하여 경험, 테스트웨어, 기타 관련 정보를 수집하는 단계.
테스트 완료 활동은 어떤 프로젝트 마일스톤에 도달했을 때 이루어짐. 테스트 레벨이나 애자일 반복 주기의 끝, 테스트 프로젝트를 완료(또는 취소)한 시점, 소프트웨어를 배포했거나 유지보수 릴리스를 끝냈을 때 등이 여기에 해당.

 

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

테스트 모니터링은 테스트 제어 및 테스트 완료 활동을 지원하는 다양한 메트릭을 수집한다.
< 많이 사용하는 테스트 메트릭 7가지 >
프로젝트 진행 상황 메트릭 ex. 작업 완료율, 자원 사용률, 테스트 노력 투입률
테스트 진행 상황 메트릭 ex. 테스트 케이스 구현 진행률, 테스트 환경 준비 진행률, 실행/미실행 및 합격/불합격 테스트 케이스 수, 테스트 실행 시간.
제품 품질 메트릭 ex. 가용성, 응답 시간, 평균 장애 시간.
결함 메트릭 ex. 발견/수정한 결함의 수와 우선순위, 결함 밀도, 결함 발견 비율.
리스크 메트릭 ex. 잔여 리스크 수준.
커버리지 메트릭 ex. 요구사항 커버리지, 코드 커버리지.
비용 메트릭 ex. 테스팅 비용, 조직의 품질 비용.

 

5.3.2 테스트 보고서의 목적, 내용, 대상
테스트 보고 : 테스팅 도중과 이후에 테스트 정보를 요약해 전달하는 활동.

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

테스트 완료 보고서
: 테스팅의 특정 단계(ex. 테스트 레벨, 테스트 주기, 반복 주기)를 요약하고, 후속 테스팅을 위한 정보를 제공할 수 있다.

>> 테스트 진행 상황 보고서는 테스트 모니터링, 제어 과정에서 작성을 하고 테스트 완료에서 가장 많이 활용함.

 

▶ 테스트 모니터링 및 제어 과정 중 테스트팀은 이해관계자에게 정보를 제공하기 위해 테스트 진행 상황 보고서를 작성한다. 일반적으로 테스트 진행 상황 보고서는 정기적으로 작성한다.

< 테스트 진행 상황 보고서에 들어가는 내용 >
- 테스트 기간
- 테스트 진행 상황, 주목할 만한 편차 포함.
- 테스팅 진행 방해 요소와 대응 방법.
- 테스트 메트릭.
- 테스팅 중 식별할 신규 및 변경된 리스크.
- 다음 주기에 예정된 테스팅.

 

▶ 테스트 완료 보고서는 프로젝트, 테스트 레벨, 테스트 유형이 끝나고, 이상적으로는 완료 조건도 충족된 상황에서 이루어지는 테스트 완료 활동 중 작성한다. 이 보고서는 테스트 진행 상황 보고서와 기타 데이터를 기반으로 작성한다.

< 테스트 완료 보고서에 들어가는 내용 >
- 테스트 요약.
- 원래 테스트 계획에 기반한 테스팅 및 제품 품질 평가.
- 테스트 계획과의 편차.
- 테스팅 방해 요소와 대응 방법.
- 테스트 진행 상황 보고서를 기반으로 한 테스트 메트릭.
- 완화되지 않은 리스크, 수정되지 않은 결함.
- 테스팅 관련 교훈.

 

5.3.3 테스팅 상황 전달
테스트 상황을 전달하는 가장 좋은 의사소통 방법 테스트 관리자의 관심, 조직의 테스트 전략, 규제 표준, 자체 조직 팀일 경우 팀 자체에 따라 달라진다.
< 좋은 의사 소통 방법 >
- 팀원 및 기타 이해관계자와의 대화.
- 대시보드(ex. "지속적 통합"/ "지속적 전달" 대시보드, 태스크 보드, 번다운 차트)
- 전자 통신 채널(ex. 이메일, 채팅)
- 온라인 문서.
- 공식 테스트 보고서.

 

 

728x90
반응형
728x90
반응형
들어가기 전 알아둬야 할 5.1 용어 설명
: 이해 중심! 부족하면 용어 설명 글 참고.
테스트 프로세스 : 테스트 계획, 테스트 모니터링 및 제어, 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행, 테스트 완료로 상호 연관되어 구성된 활동들의 집합.

제품 백로그 : 제품을 개발하기 위해 수행할 작업의 목록과 우선순위. 제품 소유자가 관리하며 고객의 언어로 기록된다.

스모크 테스트 : 소프트웨어가 기본적인 기능을 수행할 수 있는지, 즉 연기를 내지 않는지 확인하는 테스트를 의미.

메트릭 : 측정을 위해 사용되는 측정 척도 및 방법.

테스트 피라미드 : 레벨별 테스트 양의 관계를 나타내는 시각적 모델로, 테스트 양은 상단보다 하단에 더 많이 분표 돼 있음.
입도 : 세분화된 수준, 상세화 수준.

테스팅 사분면 : 특정 이해관계자 대상으로 하는 등의 여러기준에 따라 테스트 레벨과 테스트 유형을 그룹화한다.

 

5.1 테스트 계획
- 5.1.1 테스트 계획서의 목적과 내용
테스트 계획서란?
: 테스트 프로젝트의 목적, 자원, 프로세스를 설명한다.

< 테스트 계획서의 목적 >
- 테스트 목적 달성을 위한 방법과 일정을 문서화한다.
- 수행한 테스트 활동이 정해진 기준을 충족하는 데 도움을 준다.
- 팀원과 기타 이해관계자의 의사소통 수단으로 사용된다.
- 테스팅이 수립한 테스트 정책 및 전략을 준수함을 보여준다.( or 테스팅이 그것을 준수하지 않는 이유를 설명.)

테스트 계획 활동은 테스터가 리스크, 일정, 인력, 도구, 비용, 노력 등 향후 문제를 고민하도록 함.
테스트 계획서를 준비하는 과정은 테스트 프로젝트의 목적을 달성하는 데 필요한 노력을 추론하는 유용한 방법이다.

< 테스트 계획서의 내용 >
내용 예시
테스트 정황. ex. 범위, 테스트 목적, 제약 사항, 테스트 베이시스.
테스트 프로젝트의 가정 및 제약 사항.  
이해관계자. ex. 역할, 책임, 테스팅 관련성, 채용 및 훈련 요구사항.
의사소통. ex. 의사소통 방법 및 빈도, 문서 양식.
리스크 목록. ex. 제품 리스크, 프로젝트 리스크.
테스트 접근법. ex. 테스트 레벨, 테스트 유형, 테스트 기법, 테스트 산출물, 시작 조건 및 완료 조건, 테스팅의 독립성, 수집할 메트릭, 테스트 데이터 요구사항, 테스트 환경 요구사항, 조직의 테스트 정책 및 테스트 전략과의 편차.
예산 및 일정.  

 

5.1.2 반복 주기와 릴리스 계획에 대한 테스터의 기여
반복적 소프트웨어 개발수명주기에서의 두가지 계획
릴리스 계획 제품 릴리스를 계획하는 단계.

>> 제품 백로그를 (재)정의하며, 큰 사용자 스토리를 작은 사용자 스토리들로 세분화하는 작업을 포함할 수 있다.
>> 개별 반복 주기의 테스트 접근법과 테스트 계획을 위한 기반이 된다.
릴리스 계획에 참여하는 테스터는 
1. 테스트 가능한 사용자 스토리와 인수 조건이 작성되도록 함.
2. 프로젝트 및 품질 리스크 분석에 참여.
3. 사용자 스토리와 관련된 테스트 노력을 추정.
4. 테스트 접근법을 결정.
5. 릴리스를 위한 테스팅을 계획.
반복 주기 계획 개별 반복 주기를 계획하는 것.

>> 반복 주기 백로그와 관련이 있다.
반복 주기 계획에 참여하는 테스터는
1. 사용자 스토리의 구체적인 리스크 분석에 참여.
2. 사용자 스토리의 테스트 용이성을 판단.
3. 사용자 스토리를 업무(특히 테스팅 업무) 단위로 분류.
4. 각 테스팅 업무에 필요한 테스트 노력을 추정.
5. 테스트 대상의 기능 및 비기능적 측면을 식별하고 구체화.

 

5.1.3 시작 조건과 완료 조건

 

시작 조건과 완료 조건은 각 테스트 레벨에 대해 정의해야 하며 테스트 목적에 따라 달라진다.
시작 조건( == 준비의 정의) 어떤 활동을 수행하기 위한 전제 조건을 정의한다.
가장 많이 사용하는 시작 조건
1. 자원의 가용성.(ex. 인력, 도구, 환경, 테스트 데이터, 예산, 시간)
2. 테스트웨어 가용성.(ex. 테스트 베이시스, 테스트 가능한 요구사항, 사용자 스토리, 테스트 케이스)
3. 테스트 대상의 초기 품질 수준.(ex. 모든 스모크 테스트가 합격함)
완료 조건( == 완료의 정의) 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항을 정의한다.
널리 활용하는 완료 조건
1. 충분함에 대한 측정.(ex. 달성한 커버리지 수준, 해결되지 않은 결함 수, 결함 밀도, 실패한 테스트 케이스 수)
2. 종료 기준.(ex. 계획한 모든 테스트 실행, 정적 테스트 수행, 발견한 모든 결함 보고, 모든 리그레션 테스트 자동화 완료)
3. 시간 및 예산의 소진 : 이때 이해관계자들이 추가 테스트 없이 배포하는 리스크를 검토하고 수용했다면, 다른 완료 조건이 충족되지 않더라도 테스트를 종료할 수 있다.

 

5.1.4 추정 기법
테스트 노력 추정은 테스트 프로젝트의 목적을 달성하는 데 필요한 테스트 관련 작업량을 예측하는 것이다.
추정에는 항상 오류가 있을 수 있다는 점을 이해관계자가 명확히 이해하도록 하는 것이 중요하다.

보통은 규모가 큰 작업보다 작은 작업에 대한 추정치가 정확.
따라서 큰 작업에 대해 추정할 때는 우선 여러개의 작은 작업으로 나눈 다음 추정.
< 4가지 추정 기법 > 
메트릭 기반 기법 비율 기반 추정 조직에서 수행한 이전 프로젝트 수치를 수집해 유사 프로젝트를 위한 "표준" 비율을 도출.
보통, 조직에서 직접 수행한 프로젝트에서 수집한 비율이 추정 과정에 사용하기 가장 좋은 자료로 이런 표준 비율을 가지고 새로운 프로젝트에 필요한 테스트 노력을 추정할 수 있다.
ex. 이전 프로젝트에서 개발 노력 대 테스트 노력의 비율이 3:2였고, 현재 프로젝트에서 개발 노력을 600MD로 예상한다면, 테스트 노력은 400MD로 추정할 수있음.
외삽법 현재 프로젝트에서 데이터 수집을 위해 가능한 빨리 측정을 수행.
관찰 결과가 충분히 쌓이면 이 데이터를 가지고 외삽법을 적용해 남은 작업에 필요한 노력의 근사치를 추정할 수 있다.
이 방법은 반복적 소프트웨어 개발수명주기에 매우 적합.
ex. 팀이 지난 세번의 반복 주기에 들인 평균 노력으로 다음 반복 주기의 테스트 노력을 추정할 수 있다.
반복적, 전문가 기반 기법 와이드밴드 델파이 반복적, 전문가 기반 기법으로 전문가의 경험을 기반으로 추정한다.
각 전문가는 독립적으로 노력을 추정. 결과를 수집해서 합의된 범위를 벗어난 편차가 있다면 전문가들이 각자의 추정치에 대해 논의한다. 그 다음 각 전문가에게 논의 결과를 바탕으로 다시 한번 새로운 추정치를 제시하도록 한다.
합의에 도달할 때까지 이과정을 반복한다.
ex. 플래닝 포커는 애자일 소프트웨어 개발에서 많이 사용하는 와이드밴드 델파이의 변형이다. 플래닝 포커는 보통 노력의 규모를 나타내는 숫자가 적힌 카드를 사용해 추정한다.
전문가 기반 기법 3점 추정 전문가가 세개의 추정치를 도출한다.
추정치는 가장 낙관적인 추정치(a), 확률적으로 가장 높은 추정치(m), 가장 비관적인 추정치(b)이며 최종 추정치(E)는 이들의 가중 산출 평균이 된다.
>> 계산식 : E = (a + 4*m + b)/6
     표준 편차(SD) 계산식 : SD = (b-a)/6 
ex. 추정치(MH)가 a=6, m=9, b=18인 경우, E = (6 + 4*9 +18) / 6 =10,
SD = (18 - 6) / 6 = 2 이므로 최종 추정치는 10±2(즉 8과 12 사이의 맨아워)가 됨.

 

5.1.5 테스트 케이스 우선순위지정
테스트 케이스와 테스트 절차를 도출해서 테스트 스위트로 조립하고 나면 테스트 스위트를 테스트 일정으로 구성할 수 있다. 테스트 일정은 테스트 실행 순서를 정의한다.
< 많이 사용하는 테스트 케이스 우선순위지정법 3가지 >
리스크 기반 우선순위지정 리스크 분석 결과에 따라 테스트 실행 순서를 결정.
가장 중요한 리스크를 다루는 테스트 케이스를 먼저 실행.
커버리지 기반 우선순위지정 테스트 실행 순서를 커버리지에 따라 결정.
가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행.
"추가 커버리지 우선순위지정"이라는 다른 변형에서는, 가장 높은 커버리지를 달성하는 테스트 케이스가 먼저 실행된다. 이후에 실행하는 각각의 테스트 케이스는 가장 높은 추가 커버리지를 달성하는 것이다.
요구사항 기반 우선순위지정 테스트 실행 순서를 해당 테스트 케이스의 기반이 되는 요구사항의 우선순위에 따라 결정.
요구사항의 우선순위는 이해관계자가 정의.
가장 중요한 요구사항 관련 테스트 케이스를 먼저 실행.
>> 위에서 언급한 3가지 중 하나, 또는 여러 전략을 사용해 우선순위를 지정해서 테스트 케이스 실행 순서를 도출하는 것이 이상적이다. But, 테스트 케이스 또는 테스트 대상 기능이 종속성을 가진 경우 그렇게 하기 힘들 수 있다.

테스트 실행 순서에는 자원의 가용성도 고려해야 한다.
ex. 필요한 테스트 도구, 테스트 환경, 인력이 가용한 시기가 따로 있을 수 있다.

 

5.1.6 테스트 피라미드

< 테스트 피라미드 >
- 테스트에 따라 입도가 다를 수 있다는 것을 보여주는 모델.
- 테스트 피라미들 모델 : 테스트 자동화 수준에 따라 지원하는 목표가 다를 수 있다는 것을 보여줌으로써 팀의 테스트 자동화와 테스트 노력 할당을 도와준다.
- 피라미드 각 층은 하나의 테스트 그룹을 나타냄. 층이 올라갈 수록 테스트 입도가 낮고, 테스트 격리가 어려워지며, 테스트 실행 시간도 길어진다.

아래층 아래층에 있는 테스트는 규모가 작고, 독립적이며, 빠르고, 대상이 되는 기능이 작기 때문에 적절한 커버리지를 달성하기 위해 많은 테스트가 필요한 경우가 많다.
높은 층 복잡하고 상위 수준의 엔드-투-엔드 테스트를 대변한다. 이런 상위 수준 테스트는 보통 하위층의 테스트보다 속도가 느리며, 큰 규모의 기능을 확인하기 때문에 적은 수로 적절한 커버리지를 달성할 수 있다.
층의 수와 각 층의 명칭은 다를 수 있다.
ex. 최초의 테스트 피라미드 모델은 "단위 테스트", "서비스 테스트", "UI 테스트"라는 세 개의 층을 정의했다. 단위(컴포넌트) 테스트, 통합(컴포넌트 통합) 테스트, 엔드-투-엔드 테스트로 정의하는 모델도 많이 알려져 있다. 

 

5.1.7 테스팅 사분면

1 사분면 (기술, 팀) 컴포넌트 및 컴포넌트 통합 테스트를 포함.
이런 테스트는 자동화해야 하며, 지속적인 통합 프로세스에 포함돼야 함.
2 사분면 (비즈니스, 팀) 기능 테스트, 예제, 사용자 스토리 테스트, 사용자 경험 프로토타입, API 테스팅, 시뮬레이션 등 포함.
이런 테스트는 인수 조건을 확인하며, 수동으로 실행하거나 자동화할 수 있다. 
3 사분면 (비즈니스, 제품 평가) 탐색적 테스팅, 사용성 테스팅, 사용자 인수 테스팅을 포함.
이런 테스트는 사용자를 중심으로 이루어지며, 수동으로 실행하는 경우가 많다.
4 사분면 (기술, 제품 평가) 스모크 테스트, 비기능 테스트(사용성 테스트 제외)를 포함.
이런 테스트는 자동화되는 경우가 많다.

 


테스팅 사분면은 반드시 나올 테니 꼭 외워야 함.

나의 경우 1기팀자컴, 2비팀자수기능사용자스토리, 3비제수탐색인수, 4기제자스모크비기능으로 외웠다.

기술 측면인지 비즈니스 측면인지, 팀지원인지 제품 평가인지, 자동화인지 수동인지, 예시로 무슨 테스팅이 들어가는지 찾을 수 있어야 한다. 그냥 간단하게 저 4분면을 그릴 수 있게 외우면 만사가 해결된다. 외울게 많은 5장이다. 잘 알아두자.

 

 

728x90
반응형

+ Recent posts