실라버스는 고봉밥이기에.. 임의로 요약했습니다
마치 비문학 지문 같은
• 1.1장
sw 테스팅 - 결함 식별, sw 산출물 품질 평가
sdlc - sw 개발수명주기
verification - sw가 명세( 법률, 규제등)와 기술 요구사항을 충족시키는지
validation - 사용자의 요구사항을 충족시키는지
동적 테스팅 - sw를 실제로 실행 하고 분석
정적 테스팅 - sw를 실행하지 않고 리뷰하고 정적으로 분석, tc를 도출하기 위해 여러 기법과 접근법을 사용
- 테스트 목적
작업 산출물 평가
장애 및 결함 식별
테스트 대상 커버리지 보장
베리피케이션, 밸리데이션
- 테스팅과 디버깅
테스팅은 sw 결함으로 인한 장애를 유발(동적 테스팅)하거나 결함을 직접 식별(정적 테스팅)
- 동적 테스팅 중 디버깅
동적 테스팅 과정 중 장애가 유발됐을때 디버깅은 장애의 원인을 찾아서 제거
디버깅 과정은 장애 재현 -> 분석 -> 원인해결 순으로 진행
디버깅 후 확인 테스팅으로 문제 수정여부 확인(확인 테스팅시 처음 테스트 수행자가 하는게 바람직)
수정 사항이 sw의 다른 부분에 장애를 유발하지 않았는지 리그레션 테스팅을 추가로 수행 가능
- 정적 테스팅 중 디버깅
정적 테스팅 중 디버깅은 결함을 제거하는데 중점, 장애를 유발하지 않고 직접 결함 식별
• 1.2장
-QA와 QC의 차이
테스팅은 QC(품질 제어), QA(품질 보증과 다름)
QC(QUALITY CONTROL, 품질 제어)
QC는 적절 품질을 달성하기 위한 제품 중심의 교정 접근법
테스팅, 정형 기법(모델 확인, 정확성 증명)시뮬레이션, 프로토타이핑은 QC(품질 제어)에 속함
QA(QUALITY ASSURANCE, 품질 보증)
QA는 프로세스 구현/개선에 초점을 위한 프로세스 중심의 예방법
TC는 QA와 QC 모두에 사용, QC는 결함 수정, QA는 개발/테스트 프로세스 동작 확인 피드백에 사용
- 오류, 결함, 장애, 근본 원인
사람이 오류를 저지름 -> 결함 발생 -> 장애
결함
요구 명세서나 테스트 스크립트, 소스코드, 빌드 파일 등에서 결함 발생
초기 산출물 결함을 찾지 못하면 이후 결함이 있는 산출물로 이어지는 경우가 많음
소스코드에 있는 결함이 실행되면 작업 수행이 안되거나, 수행하지 않아야 할 작업을 실행
항상 장애를 일으키는 결함, 특정 상황에서 장애 유발하는 결함, 장애로 이어지지 않는 결함
장애
오류, 결함 두 가지 원인 이외에도 환경 조건 때문에 장애가 발생할수도 있음
방사선, 전자기장 등 환경 조건도 원인이 될 수 있음
근본 원인(오류로 이어지는 상황등)은 근본 원인 분석을 통해 식별
장애 발생 / 결함 식별시 수행
근본 원인을 처리하면 유사한 장애/결함을 예방하거나 빈도를 줄일 수 있다
• 1.3장
테스팅 원리 7가지 <- 중요
1. 테스팅은 결함 존재를 밝히는 활동, 결함이 없음은 증명하지 않음
테스팅을 통해 결함이 있다는걸 찾을 수 있지만, 결함이 없다는걸 증명하는 건 불가능
2. 완벽한 테스팅은 불가능
모든 것을 테스팅하는건 불가능하니 테스트 기법, TC 우선순위 지정, 리스크 기반 테스팅을 사용해 테스트에 노력
3. 조기 테스팅으로 시간과 비용 절약
프로세스 초기에 발견해서 제거한 결함은 연관된 다른 산출물의 후속 결함으로 이어지지 않는다
4. 결함 집중
대부분의 결함과 운영 장애가 소수의 컴포넌트에 집중되서 발생(파레토 원리)
예상 결함 집중 영역과, 실제 운영/테스트 중 관측한 결함 집중 영역은 리스크 기반 테스팅의 주요 입력
5. 테스트 효과는 줄어듬
같은 테스트를 계속 하면 신규 결함 식별 효과는 줄어든다.
기존 테스트와 테스트 데이터의 수정, 새로운 테스트 작성이 필요
! 자동 리그레션 테스팅 같이 테스트 반복하는게 유익한 경우도 있음
6. 테스팅은 정황에 의존적
모든 상황에 적용 가능한 테스팅 접근법은 없음, 정황에 따라 다르게 테스팅 진행
7. 결함 부재는 궤변이다
SW 베리피케이션이 되었다고 시스템이 성공하는건 보장할 수 없음
사용자의 요구나 기대에 못 미치거나, 비즈니스나 경쟁 SW에 비해 부족할 수 있음
따라서, 베리피케이션과 밸리데이션을 함게 수행
• 1.4
- 테스트 활동과 업무 7가지
테스트 프로세스 구성 활동들, 아래 활동들은 반복, 병렬적으로 구현되는 경우가 많다
1. 테스트 계획
테스트 목적을 정의하고 전반적인 상황에 따른 제약 조건 중 목적을 가장 잘 달성할수 있는 접근법 선택
2. 테스트 모니터링과 제어
테스트 모니터링은 지속적으로 테스트 활동을 점검, 실제 진행과 계획을 비교
테스트 제어는 테스트 목적 달성에 필요한 조치를 하는 활동
3. 테스트 분석
테스트 베이시스를 분석해 테스트 가능한 기능을 식별, 테스트 컨디션 정의, 우선순위를 정하는 활동
리스크와 리스크 수순도 고려
테스트 베이시스와 테스트 대상을 평가해 결함 식별/테스트 용이성 평가
테스트 분석은 측정할 수 있는 커버리지 조건으로 무엇을 테스트 할 지에 대한 답을 제공
4. 테스트 설계
테스트 컨디션을 테스트 케이스와 테스트웨어로 구체화
테스트 케이스 입력값을 구체화하기 위해 커버리지 항목의 식별을 포함, 테스트 기법 활용
테스크 데이터 요구사항 정의, 테스트 환경 설계, 인프라와 도구 식별
어떻게 테스트 할지 설계하는 과정
5. 테스트 구현
테스트웨어(테스트 케이스 등)을 만들거나 획득
테스트 케이스는 테스트 절차로 묶을수 있고, 테스트 스위트로 조합
수동/자동 테스트 스크립트 작성
테스트 절차 정리
6. 테스트 실행
테스트 실행 일정에 따라 테스트를 실행
지속적 테스팅, 페어 테스팅 세션 등 다양한 형태로 이루어진다
테스트 결과를 기대값과 비교하고 기록
이상 현상을 분석해 원인을 파악
분석을 통해 관찰한 장애를 기반으로 이상 현상을 보고
7. 테스트 완료
프로젝트 마일스톤(릴리즈,반복주기 완료, 테스트 완료)에서 수행, 해결되지 않은 결함은 변경 요청서나 백로그를 만들고
유용한 테스트웨어를 식별해서 보관 후 인계
테스트 환경을 합의하고 종료. 테스트활동 분석해 반복주기, 릴리즈, 개선사항 등을 파악
테스트 완료 보고서를 작성해서 이해관계자에게 전달
1.4.2절 정황에 따른 테스트 프로세스
테스팅은 조직에서 수행하는 개발 프로세스의 필수적인 부분.
테스팅의 목표는 이해곤계자의 비즈니스 목표 달성을 지원하는 것
• 테스트에 수행에 영향을 끼지는 정황 요소들
이해관계자(필요, 기대, 요구사항, 협력의지)
팀원(기술, 지식, 경험, 가용성)
비즈니스 도메인(테스트 대상 중요도, 식별된 리스크, 시장 요구사항, 법적 규제)
기술적 요인(SW 유형, 제품 아키텍쳐, 사용한 기술)
프로젝트 제약 조건(범위, 시간, 예산, 자원)
조직적 요인(조직 구조, 기존 정책, 적용한 실천법)
SDLC - 소프트웨어 개발수명주기(공학적 실천법, 개발 방법론)
도구(가용성, 사용성, 규정 준수)
위 요소들은 테스트 전략, 적용 된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트 문서 상세화 수준
보고 등 많은 테스트 관련 문제에 영향을 끼친다
1.4.3 테스트웨어
테스트웨어는 테스트 활동의 결과물로 만들어지고 조직마다 테스트웨어를 생성/구체화/명명/구성/관리하는데 차이가 잇음
테스트 계획 산출물 - 테스트 계획,일정,리스크 관리 대장, 시작 및 완료 조건
테스트 모니터링과 제어 작업 산출물 - 진행 상황 보고서, 제어 지침, 리스크 정보
테스크 분석 작업 산출물 - 테스트 컨디션, 테스트 베이시스의 결함 보고서
테스트 설계 작업 산출물 - tc, 커버리지, 테스트 데이터 요구사항
테스트 구현 작업 산출물 - 테스트 절차, 자동화 스크립트, 테스트 환경 요소(스텁,드라이버 등)
테스트 실행 작업 산출물 - 로그, 결함 보고서
테스트 완료 작업 산출물 - 완료 보고서, 개선 실천 항목, 교훈, 변경 요청서
1.4.4
테스트 베이시스와 테스트웨어 간의 추적성
1.4.5 테스팅에서의 역할
테스트 관리 역할 - 테스트 프로세스, 활동, 팀에 대한 전반적인 책임을 지는 것
테스팅 역할 - 테스트의 공학적인 측면에 책임, 테스트 분석 설계 구현 실행에 초점을 둔다
• 전체 팀 접근법
XP에서 시작된 전체 팀 접근법, 테스트 독립성이 낮고 다른 팀원과 긴밀하게 협력
• 테스트 독립성
저자가 직접 - 독립성 x
동료가 테스트 - 일정 수준
팀 외부, 조직 내 - 높은 독립성
조직 외부 - 매우 높은 독립성
여러 수준의 독립성으로 테스팅을 수행하는게 좋다
ex - 개발자가 컴포넌트, 컴포넌트 통합 테스트 / 시스템과 시스템 통합 테스팅은 테스트팀 / 비즈니스 담당이 인수 테스트
2장
순차적 개발 모델 - 개발 후반에 실행 가능한코드가 생성, 동적 테스팅을 초기에 하기 어려움
반복적, 점진적 개발 모델 - 반복주기의 모든 테스트 레벨에서 정/동 테스팅을 수행
빠른 피드백과 광범위한 리그레션 테스팅이 필요
애자일 sw 개발에서는 가벼운 작업 산출물과 테스트 자동화를 선호
• 우수한 테스팅 프랙티스
모든 sw 개발에 상응하는 테스트로 모든 활동이 품질 제어의 대상이 되게
독립적인 테스트 목적으로 중복을 피하고 적절하면서 포괄적인 테스팅
조기 테스팅, 테스터가 즉시 작업 산출물 리뷰에 참여
• sw 개발 주도를 위한 테스팅
TDD - 테스트 케이스를 통해 주도, 테스트를 충족하는 코드를 작성해 리팩토링
ATDD(인수 테스트 주도 개발) - 인수 조건에서 테스트 도출, 테스트는 앱 영역 개발 전에 작성
BDD - given/when/then 형태 사용, 자연어로 작성해 테스트 후 자동 실행 가능한 테스트로 변환
중요! 시프트 레프트 접근법
조기 테스팅 원리라고 하고, SDLC 초기에 테스트를 접근
테스팅 관점에서 명세를 리뷰, 빠른 피드백, 소스코드 정적 분석, 컴포넌트 테스트부터 비기능 테스팅
• 회고 밎 개선
프로젝트나 반복주기가 끝날때, 릴리스 마일스톤, 필요시에 진행한다
! 중요
테스트 레벨
컴포넌트 테스팅(단위 테스팅)
컴포넌트를 개별적으로 테스팅, 테스트 하네스나 단위 테스트 프레임워크를 사용해서
개발자가 자신의 개발 환경에서 수행한다
컴포넌트 통합 테스팅(단위 통합 테스팅)
상향식, 하향식, 빅뱅 등의 접근법으로 컴포넌트 간의 인터페이스와 상호 작용을 테스트한다
시스템 테스팅 <- 다른 시스템이나 와부는 시스템이 아닌 시스템 통합 테스팅임!
전체 시스템이나 제품의 동작과 기능에 중점
엔드투엔드 동작 기능 테스팅과 품질에 대한 비기능 테스팅
독립 테스트팀이 수행 가능하고 명세와 관련있다
시스템 통합 테스팅
다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트, 운영 환경과 유사한 테스트 환경 사용
인수 테스팅
비즈니스에 필요한 사항을 확인, 실제 사용자가 하는게 이상적
알파,베타,사용자 인수 등
! 중요
테스트 유형(기능/비기능/블박/화박)
기능 테스팅 - 컴포넌트 또는 시스템이 수행해야하는 기능을 평가
기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)
뭘 하는지를 의미한다
비기능 테스팅 - 얼마나 잘 동작하는지 테스트
효율, 호환, 유용, 신뢰, 보안, 유지가능, 이동성
SDLC 초기에 비기능 테스팅을 시작할 수 있고, 기능에서 비기능 테스트를 도출하는 경우도 많다
• 블박/화박
블랙박스 테스팅 - 명세를 기반으로 테스트 대상 외부에서 테스트를 도출
명세와 비교해서 동작 확인
화이트박스 테스팅 - 구조 기반으로 시스템의 구현 또는 내부 구조에서 태스트를 도출
내부 구조를 인수에 필요한 수준까지 커버하는 것
• 확인 테스팅 / 리그레션 테스팅
확인 테스팅 - 결함이 성공적으로 수정되었는지 확인
결함으로 인해 실패한 테케를 실행, 결함 수정을 위해 변경한 사항을 확인하는 테케 추가
시간 비용 부족시 장애 발생 여부만 확인하고 끝날 수 잇음
리그레션 테스팅 - 변경으로 부정적인 영향이 없었는지 확인하는 것
변경은 연결된 시스템에 영향을 미칠 수 있기에 리그레션 테스트의 범위를 최적화하기 위해 영향도 분석을 먼저 수행
리그레션 테스팅은 반복적으로 실행하고 테케 수가 계소 증가하므로 자동화하기 적합하다
• 유지보수 테스팅
문제나 환경, 성능, 유지보스 개선 등 이유로 연관된 분야가 많은 테스팅
변경 리스크/ 기존 시스템 크기/ 변경된 크기에 다라 범위가 달라진다
유지보수 테스팅의 계기
계획된 개선사항,변경,핫픽스 등의 수정사항
환경 업그레이드나 마이그레이션
데이터 보관, 복원 및 복구 절차 테스팅
3장
• 정적 테스팅
정적 테스팅은 테스트 대상 sw를 실행하지 않고도 가능하다
정적 테스트를 사용해서 거의 대부분의 작업 산출물을 검토 가능하다
! 중요 정적 테스팅과 동적 테스팅의 차이
정적 테스팅은 결함을 직접 식별, 동적 테스팅은 장애를 일으킨 후 결함을 후에 분석
정적 테스팅은 비 실행 상태로 가능
정적 테스팅은 유지보수성을, 동적 테스팅은 성능 효율성을 측정할 수 있다
• 정적 테스팅을 통해 식별할 수 있는 결함
요구사항, 설계, 코딩결함, 표준 위반, 인터페이스 명세, 보안 취약성
테스트 베이시스 커버리지 차이, 부정확성
리뷰 프로세스
계획 - 리뷰 착수 - 개별 리뷰 - 논의/분석 - 수정/보고
리뷰하는 사람&역할
관리자
저자
중재자
서기
리뷰어
리뷰 리더
! 중요
• 리뷰 유형
비공식 - 프로세스 없음, 결과 요구도 안함, 이상 식별을 위해 하는 것
워크스루 - 저자가 리더
기술리뷰 - 기술 자격을 갖춘 리뷰어가 수행, 중재자가 리더
인스펙션 - 공식적, 저자가 리더가 될 수 없음
4장
테스트 기법 - 블박, 화박, 경험 기반, 협업 기반
블랙박스 (명세 기반) - 동작에 대한 분석
화이트박스 - 내부 설계에 의존
경험 기반 - 테스터의 지식과 경험을 활용, 블박과 화박을 보완
• 블랙박스 4가지
- 동등분할
데이터를 일정 범위로 분할해서 범위별로 하나의 테스트만 처리
각 분할별로 한번씩은 다뤄서 모든 분할이 실행되게
이치 초이스 커버리지 - 모든 분할 집합을 한번씩(입력변수가 2개.. 3개.. 늘어나면 경우의 수가 늘어남)
- 경계값 분석
동등 분할의 경계에서 실행하는 테스트
2-value 3-value 경계값 분석이 있음
두개 선택은 경계값과 가장 가까운 두개의 값
세개 선택은 각 경계값에 대해서 세게의 항목을 도출한다. 경계값, 이웃한 값 2개를 포함해서 총 3개를 테스트
- 결정 테이블 테스트
다중 조건으로 테이블 형태로 표기한다
T, F, '-', 'N/A', 'X', 공백으로 표기
- 는 결과에 영향이 없음을 의미
N/A는 해당 규칙에서 조건 실행이 불가능을 의미
X는 동작이 발생해야 함을 의미
공백은 동작이 발생하지 않아야 함을 의미
- 상태 전의 테스팅
가능한 상태와 유효한 상태 전이를 표시한다
- 상태 전이 테스팅 커버리지 측정 기준 3가지
모든 상태 커버리지 : 테케의 모든 상태를 확인해야됨
유효 전의 커버리지(0 스위치 커버리지) : 각 유효 전이가 커버리지, 모든 유효 전이를 실행해야됨
모든 전이 커버리지 : 유효하거나 비유요한 전이도 실행한다
• 화이트박스 테스트 기법 두가지
- 구문 테스팅
모든 실행가능 구문을 한번 이상 실행, 데이터 종속 결함은 식별 불가능함( div 0 ) 등
- 분기 테스팅
제어 흐름 그래프에서 두 노드간 제어의 이동으로 소스코드의 실행 가능 순서를 보여준다
조건문이나 스위치 루프 등으로 분기를 실행
-화박의 특징
누락된 요구사항은 식별하지 못할 수 있음
수도 코드나 제어 흐름 그래프로 논리 검토 가능
실제 코드 커버리지 측정치를 얻을 수 있음
• 경험 기반 테스트 기법
오류 추정 : 테스트 지식 기반으로 오류등을 예측
탐색적 테스팅 : 테스터가 테스트 대상에 대해 배워가면서 테스트 설계,실행,평가를 하는 방식 시간/명세가 삐리할때 사용
체크리스트 기반 테스팅 : 질문 형태의 체크리스트를 이용한 테스트, 항목은 정기적으로 업데이트 하자
• 협업 기반 테스트 접근법
사용자 스토리 - 3C, 스토리 작성을 위해 브레인스토밍, 마인드 매핑 등 기법을 사용해 비즈니스 개발 테스팅 3가지를 고려
카드 - 사용자 스토리 설명 메체
대화 - sw 사용법 설명
확인 - 인수 조건
역할 -> 목표 -> 역할이 얻게 될 비즈니스 가치
• 인수 조건
보통 3c 중 대화를 통해 결정된다
스토리 범위 정의
이해관계자 간 합의 도출
긍정 부정 시나리오 설명
인수 테스팅 베이시스 제공
계획 및 추정
사용자 서터리 인수 조건 작성법 2가지
g/w/t 형식의 시나리오 기반
목록 또는 표로 표현된 규칙 기반
• 인수 테스트 주도 개발 ATTD
서로 다른 관점을 가진 팀원들이 사용자 스토리 구현 전에 만든 테케로 테스트 우선 접근하는 방식
테케 -> 사용자 스토리 보완,완성
긍정/유효 테스트 -> 비유효/부정 테스트 -> 비기능 품질 특성 테스트
조건을 포함한 자연어로 표기
5장 테스트 활동 관리
• 테스트 계획서의 목적, 내용
목적 달성을 위한 방법과 일정 문서화
테스트 계획서 내용
테스팅 정황, 제약사항, 이해관계자, 의사소통, 리스크 목록, 접근법, 예산 및 일정
• 시작 조건과 완료 조건
시작 조건 - 활동 수행을 위한 전제 조건을 정의
자원/테스트웨어 가용성, 테스트 대상 초기 품질 수준
완료 조건 - 충분항에 대한 측정, 종료기준, 시간/예산 소진
애자일에서는 완료 조건을 완료의 정의라고 하고, 시작 조건을 준비의 정의라고 한다네요
• 추정 기법 4가지
비율 기반 추정 : 이전 프로젝트 수치를 수집해 유사한 프로젝트에서 사용할 표준 비율을 도출
외삽법 : 현재 프로젝트에서 가능한 빨리 측정, 남은 작업에 필요한 노력의 근사치를 추정, 반복적 SDLC에 적합
와이드밴드 델파이 : 반복적, 전문가 기반 기법, 전문가의 경험을 기반으로 추정
변형으로 에자일에서 사용하는 플래닝 포커가 있음, 플래닝 포커는 노력 수치 카드를 사용해서 추정함
3점 추정 : 낙관 + 비관 + 확률적으로 가장 높은 추정치 * 4 / 6
• 테스트 케이스 우선순위 지정
테스트 케이스 / 절차 -> 테스트 스위트 -> 테스트 일정 -> 테스트 실행 순서
• 테스트 우선순위지정법 3가지
리스크 기반 : 가장 중요한 리스크를 다루는 테스트 케이스를 먼저 실행
커버리지 기반 : 테스트 순서를 구문 커버리지 등에 따라 가장 높은 커버리지부터 우선 실행
요구사항 기반 우선순위 지정 : 테스트케이스의 기반이 되는 요구사항의 우선순위에 따라서 결정
요구사항 우선순위는 이해관계자가 정의
위의 전략 하나 이상을 사용하지만 유도리 있게 쓴다
• 테스트 피라미드
테스트에 따라 입도?가 다르다는 모델
테스트 자동화 수준에 따라 지원하는 목표가 다를 수 있다는 것을 보여줌
고층은 입도가 낮고, 격리가 어렵고, 실행 시간이 김, 복잡한 상위의 엔드투엔드 테스트, 큰 규모, 적은 테스트 수
아래층은 규모가 작고, 독립적, 빠름, 기능이 작기에 많은 테스트가 필요함
• 테스팅 사분면
테스트 유형, 활동, 기법, 산출물로 묶어서 비즈니스나 기술에 대한 테스트
팀을 지원하는 개발 지침 / 제품 평가(기대치 대비 동작 측정)
두가지 조합으로 4개의 사분면이 결정됨
1사분면 - 기술/팀 지원 : 컴포넌트/컴포넌트 통합 테스트, 자동화,CI에 포함
2사분면 - 비즈니스/팀지원 : 인수 조건 확인, 기능 테스트, 예제, 사용자 스토리 테스트, 수동 실행 or 자동화
3사분면 - 비즈니스/제품평가 : 탐색적,사용성,사용자 인수 테스팅, 사용자 중심 수동
4사분면 - 기술/제품평가 : 스모크,비기능 테스트 , 자동화
• 리스크 관리
리스크 분석(리스크 식별 / 리스크 평가)
리스크 제어(리스크 완화 / 리스크 모니터링)
리스크의 발생확률과 영향으로 리스크 수준을 표기
• 프로젝트 리스크
프로젝트 관리/제어에 관련됨
조직, 인력, 기술적, 공급업체 문제
• 제품 리스크
사용자 불만족, 기업에 손실, 3자피해, 유지보수 비용, 불법 등
• 제품 리스크 분석
SDLC 초기에 제품 리스크 분석을 시작해 잔존 제품 리스크를 최소화하는 방향
리스크 식별과 평가로 이루어짐
- 리스크 식별
포괄적인 리스크 목록을 생성, 이해관계자가 다양한 기법과 도구를 사용해 리스크를 식별
-리스크 평가
리스크 분류, 발생가능성/영향/수준 결정, 우선조치를 정하기
같은 범위로 분류된 리스크는 유사한 접근법으로 완화할 수 있음
정량적/정성적/둘다 로 리스크 평가 진행
정량적 리스크 평가 : 발생 가능성 * 영향
정성적 리스크 평가 : 리스크 행렬 사용
• 제품 리스크 제어
식별 및 평가된 제품 리스크에 대응해 취하는 조치
리스크 완화, 리스크 모니터링 2가지로 이루어짐
리스크 완화 : 리스크 평가 때 제안된 조치를 실행해 리스크 수준을 낮추는 활동
리스크 모니터링 : 리스크 완화 조치의 효과 확인, 평가 개선을 위해 필요한 정보 확인, 새 리스크 식별
리스크를 분석해서 테스팅을 통한 리스크 완화, 리스크 수용, 리스크 전가, 대안 계획 등의 완화 방안 수립
테스트 모니터링 : 테스트 진행 상황을 판단, 테스트 업무가 충족되었는지 측정
테스트 제어 : 테스트 모니터링 정보를 바탕으로 제어지침 / 지도/ 필요 수정 조치를 제공
테스트 완료 : 끝난 테스트에서 경험, 테스트웨어, 기타 정보를 수집
프로젝트 마일스톤에 도달했을때 테스트 완료가 이루어짐
• 테스트 메트릭
계획한 일정/예산 대비 진행상황, 테스트 대상 품질, 테스트 활동 효과를 보여주기 위해 수집
테스트 모니터링을 통해 테스트 제어/완료를 지원하는 다양한 메트릭을 수집
프로젝트 진행상황, 테스트 진행상황, 제품 품질, 결함, 리스크, 커버리지, 비용 메트릭 등
• 테스트 보고
테스팅 도중과 이후에 테스트 정보를 요약해서 전달
테스팅의 지속적인 관리를 지원하고 테스트 관련 사항을 수정해야 할 때 정보를 제공
테스팅의 특정 단계를 요약, 후속 테스팅을 위한 정보 제공
테스트 진행 보고서 : 테스트팀이 이해관계자에게 정기적으로 작성
테스트 완료 보고서 : 테스트 완료 활동 중 작성, 진행 보고서 등 데이터 기반으로 작성
완료된 프로젝트에 대한 테스트 보고는 정해진 양식으로 한번만
• 테스팅 상황 전달
대화,대시보드,전자통신,온라인문서,테스트 보고서 등
• 형상 관리
작업 산출물을 형상 항목으로 식별,제어,추적
• 결함 관리
테스트의 주요 목적 중 하나는 결함 식별
결함 관리 프로세스에는 개별 이상을 발견부터 종료까지 처리하는 작업흐름과 분류규칙이 포함
6장
• 테스트 자동화의 효과와 리스크
반복 수작업을 줄이고 일관성 및 재현성을 향상시킬 수 있다
객관적, 접근성 향상, 결함 조기 식별, 빠른 피드백, 테스트 실행시간 단축, 테스트 설계시간 확보 등..
리스크
자동화에 너무 많은 기대, 추정, 오용, 의존, 호환성, 규제/안전 부적합
• 데브옵스와 테스팅
데브옵스 : 조직 차원의 접근법, 개발과 운영이 협력함
CICD, 피드백, 통합 도구, 파이프라인 등
CI는 시프트 레프트 접근법, 파이프라인 자동화로 수동 테스팅을 줄임
자동 리그레션 테스트 범위가 늘어나 리그레션 발생 리스크를 최소화시킴
'자격증 > istqb' 카테고리의 다른 글
| ISTQB CTFL 후기 (4) | 2024.10.31 |
|---|
