전체 개념 정리 (X)
샘플 문제 풀고 헷갈리는 개념 정리 (O)
제 1장 테스팅의 기초
1.1. 테스팅이란 무엇인가?
- 검증, 베리피케이션(verification) : 개발자의 시각에서 제품의 생산 과정 테스트 ex. 단위, 통합, 시스템 테스트
- 확인, 벨리데이션(validation) : 사용자의 시각에서 생산된 제품의 결과 테스트 ex. 인수 테스트
1.1.2. 테스팅과 디버깅
- 디버깅 : 결함 찾고 원인 찾고 분석, 테스터는 디버깅 X
- 테스팅 : 결함 식별
1.2.2. 테스팅과 품질 보증(QA)
- 품질 제어 : 적합한 수준의 품질 달성을 지원하는 활동에 초점을 맞춘 제품 중심의 교정 접근법, 결함을 수정하는데 사용
- 테스팅은 품질제어(QC)다.
- 품질 보증 : 프로세스 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법, 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용
1.2.3. 오류, 결함, 장애, 근본 원인
사람은 오류를 저지르며 -> 이에 따라 결함이 발생하고 -> 이는 결국 장애로 이어질 수 있다.
- 결함은 산출물에서 나올 수 있다. 항상 장애를 일으키거나 / 특정 상황에서만 장애를 일으키거나 / 장애로 이어지지 않는 결함도 있다.
- 장애의 원인에는 오류와 결함뿐만 아니라 환경 조건도 있다.
- 근본 원인은 문제 발생의 근본적인 이유를 말한다.
1.3. 테스팅의 원리
1. 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지는 않는다.
4. 결함은 집중된다.
대부분의 결함은 소수의 시스템 컴포넌트에 집중되어 발생하는 경향을 보인다. = 파레토 원리
5. 테스트 효과는 줄어든다.
같은 테스트를 계속해서 반복하면 해당 테스트의 신규 결함 식별 효과는 점점 줄어들게 된다. = 살충제 패러독스
7. 결함-부재는 궤변이다.
요구사항에 따른 정확성 보장이 시스템의 사용자 만족을 보장하지 않는다.
1.4.1. 테스트 활동과 업무 & 1.4.3 테스트웨어
*테스트웨어 : 테스트를 계획, 설계, 실행하는 테스트 프로세스 동안 생성된 산출물
테스트 계획
테스트 목적 정의
목적을 잘 달성할 수 있는 접근법 선택
산출물 : 테스트 계획, 테스트 일정, 리스크 관리 대장
테스트 모니터링과 제어
모든 테스트 활동 점검
진행상황을 계획과 비교
산출물 : 테스트 진행상황 보고서, 제어 지침 문서, 리스크 정보
테스트 분석
무엇을 테스트할 것인가
테스트 베이시스를 분석해 테스트 가능한 기능 식별, 테스트 컨디션 정의, 우선순위 선정
테스트 베이시스와 테스트 대상 평가해 결함 식별 및 테스트 용이성 평가
산출물 : (우선순위가 지정된) 테스트 컨디션, 테스트 베이시스의 결함에 관한 결함 보고서
테스트 설계
어떻게 테스트할 것인가
테스트 컨디션 -> 테스트 케이스, 테스트 웨어(ex. 테스트 데이터 요구사항, 탐색적 테스팅을 위한 테스트 차터)
필요 인프라와 도구를 포함한 테스트 환경 요구사항도 명시
산출물 : (우선순위가 지정된) 테이스 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항
테스트 구현
테스트 실행에 필요한 테스트웨어(ex.테스트 데이터)를 만들거나 획득하는 작업
테스트 케이스 -> 테스트 절차로 구성 혹은 테스트 스위트로 조합
테스트 스크립트 제작
테스트 절차 정리
테스트 환경 구축 및 확인
산출물 : 테스트 절차, 자동 테스트 스크립트, 테스트 스위트, 테스트 데이터, 테스트 실행 일정, 테스트 환경 요소(ex. 스텁, 드라이버, 시뮬레이터, 서비스 가상화)
테스트 실행
테스트 실행 일정에 따라 테스트를 수행하는 것
관찰된 장애를 기반으로 이상 현상 보고
산출물 : 테스트 로그, 결함 보고서
테스트 완료
마일스톤에서 수행
재사용 가능한 테스트웨어 식별, 인계
테스트 활동 분석 후 교훈, 개선 사항 파악
산출물 : 테스트 완료 보고서, 향후 프로젝트 또는 반복 주기 때 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서(ex. 제품 백로그 항목)
1.4.5. 테스팅에서의 역할
테스트 관리 역할 : 테스트 모니터링, 제어, 완료
ex. 애자일 소프트웨어 개발
- 여러 팀에 걸친 테스트 관리 활동은 팀 외부의 테스트 관리자가 주로 처리
- 일부 테스트 관리 활동은 팀 자체에서 처리
테스팅 : 테스트 설계, 구현, 실행
테스팅 역할을 하는 사람 = 테스터
역량
- 제품 비전 수립 능력 = 비즈니스
- 팀이 수행하는 일의 계획 및 구성 능력 = 관리자
1.5.2. 전체 팀 접근법
필요 지식과 기술을 갖춘 팀원이라면 누구나 모든 작업을 수행할 수 있고, 모든 팀원이 품질에 대해 책임진다.
팀의 활력 ⬆️, 팀 내 의사소통과 협업 ⬆️, 프로젝트 성공을 위해 팀이 가진 다양한 기술을 활용해 시너지 창출
테스터는 테스팅 지식을 다른 팀원과 공유하게 되며, 제품 개발에 영향을 주게 된다.
안전이 치명적인 경우에는 높은 수준의 테스트 독립성이 필요 = 전체 팀 접근법 적절 X
제 2장 소프트웨어 개발 생명주기(SDLC)와 테스팅
2.1.5. 시프트-레프트 접근법
조기 테스팅의 원리는 소프트웨어 개발주기(SDLC) 초기에 수행하도록 하는 접근법 = 시프트-레프트라고 지칭
의미
테스트를 더 일찍 수행해야한다를 의미(ex. 코드가 구현되거나 컴포넌트가 통합될 때까지 기다리지 않고)
소프트웨어 개발 주기(SDLC) 후반의 테스트를 무시해도 된다는 의미는 X
사례
조기리뷰, TDD, 조기 비기능 테스팅
조기 테스팅 : 초안이 가용해지는 즉시 작업 산출물 리뷰
2.2.2. 테스트 유형
기능 테스팅
컴포넌트 또는 시스템이 수행해야 하는 기능 평가(기능 성숙도, 기능 정확성, 기능 타당성)
무엇을 해야하는지
비기능 테스팅
기능 특성 이외의 속성 평가(수행 효율성, 호환성, 유용성, 신뢰도, 보안, 유지 가능성, 이동성)
시스템이 얼마나 잘 동작하는지
블랙박스 테스팅
- 명세 기반
- 명세와 비교해 동작 확인
화이트박스 테스팅
- 구조 기반
- 전체 소프트웨어 구현을 고려
- 구현 누락 식별 X
2.2.3. 확인 테스팅 및 리그레션 테스팅
- 확인 테스팅 : 문제가 제대로 수정되었는가
- 리그레션 테스팅 : 결함을 고치고 전체를 돌렸을 때 사이드 이펙트가 나는가
제 3장 정적 테스팅
3.2.2. 리뷰 프로세스 활동
1. 계획
목적,리뷰 일정, 리뷰의 범위 정의
2. 리뷰 착수
모든 사람과 사항이 리뷰를 시작한 준비가 되었는지 확인한다.
모든 참가자가 작업 산출물과 필요한 자원에 접근할 수 있으며, 자신의 역할과 책임을 명확히 이해하고 있는지 확인한다.
3. 개별 리뷰
모든 검토자는 작업 산출물에 대한 건의 사항과 질문을 도출하고, 이상현상을 식별하기 위해 각종 기법을 사용한다.
체크리스트 기반 또는 시나리오 기반 리뷰와 같은 리뷰 기법을 사용해 작업 산출물의 품질을 평가하고, 이상 사항, 권고 사항, 의문 사항을 식별 및 기록한다.
4. 논의 및 분석
감지된 이상현항에 대해 논의하고 이들 각각의 상태, 소유권, 필요 추가 조치에 관한 결정을 내린다.
5. 수정 및 보고
결함 보고서를 작성해 후속 조치가 추적 가능하도록 한다.
완료 조건을 충족하면 작업 결과물을 승인할 리뷰 결과를 보고한다.
3.2.4. 리뷰 유형
비공식 리뷰
이상사항 식별이 목적
워크쓰루(Warkthrough)
저자가 리더
요구사항 명세서 미리 배포 후 짧은 검토 회의 진행
기술 리뷰
중재자가 리더
기술 문제에 대한 합의 도출 등이 목적
인스펙션(Inspection)
가장 공식적인 리뷰 유형
이상사항을 최대한 많이 찾는 것이 목적
저자가 리뷰 리더나 서기가 될 수 없음
작성자 제외한 다른 전문가들이 결함 검토
제 4장 테스트 분석과 설계
블랙박스 테스트 기법 : 동등 분할, 경계값 분석, 결정 테이블 테스팅, 상태 전이 테스팅
화이트박스 테스트 기법 : 분기 테스팅
경험 기반 테스트 기법 : 오류 추정, 탐색적 테스팅, 체크리스트 기반 테스팅
4.4.1. 오류 추정
테스터의 지식을 기본으로 오류, 결함, 장애 발생을 예측하는 데 사용하는 기법
- 애플리케이션의 과거 동작
- 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형
- 다른 유사 애플리케이션에서 발생한 장애 유형
과거에 식별한 결함 (O), 개인적인 경험 (X)
4.5.2. 인수 조건
사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야하는 조건
작성법
- 시나리오 기반 (ex. BDD에서 사용하는 given when then)
- 규칙 기반 (ex. 베리피케이션이 필요한 목록 또는 표로 표현된 입력-출력 매핑)
제 5장 테스트 활동 관리
5.1.4. 추정 기법
3점 추정
E = (a+4*m+b)/6
a = 가장 낙관적인 추정치
m = 가장 유력한 추정치
b = 가장 비관적인 추정치
5.1.5. 테스트 케이스 우선순위 지정
- 리스크 기반 우선순위 지정
- 커버리지 기반 우선순위 지정 : 가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행된 이후, 가장 높은 추가 커버리지를 달성하는 것
- 요구사항 기반 우선순위 지정
5.2.1. 리스크의 정의와 리스크의 속성
리스크 : 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황
- 리스크 발생 가능성 : 리스크 발생 확률
- 리스크 영향(피해) : 발생했을 때 생기게 될 피해
- 리스크 수준 = 리스크 발생 가능성 * 리스크 영향 ( 수 = 발 * 영)
5.2.4. 제품 리스크 제어
리스크 완화 : 리스크 평가 때 제안된 조치를 실행해 리스크 수준을 낮추는 활동
- 리스크 완화 : 해결
- 리스크 수용 : 무시
- 리스크 전가 : 제 3자에게
- 대안 계획
리스크 모니터링 : 리스크 완화 조치가 효과적인지 확인하고, 리스크 평가 개선을 위해 추가로 필요한 정보를 확보하고, 새롭게 나타난 리스크를 식별
5.3.1. 테스팅에 사용하는 메트릭
테스트 메트릭
- 제품 품질 메트릭 : 가용성, 응답 시간, 평균 장애 시간
- 결함 메트릭 : 식별된 결함 수, 결함 탐지율
- 커버리지 메트릭 : 요구사항 커버리지
5.3.2. 테스트 보고서의 목적, 내용, 대상
테스트 진행 상황 보고서
- 테스트 기간
- 테스트 진행 상황
- 테스팅 진행 방해 요소와 대응 방법
- 테스팅 중 식별한 신규 및 변경된 리스크
- 다음 주기에 예정된 테스팅
테스트 완료 보고서
반복 주기가 끝나야 만들 수 있기 떄문에 반복 주기 동안의 작업 진행상황을 보여주진 않음
- 테스트 요약
- 원래 테스트 계획에 기반한 테스팅 및 제품 품질 평가
- 테스트 계획과의 편차
- 테스팅 방해 요소와 대응 방법
- 테스트 진행 상황 보고서를 기반으로 한 테스트 메트릭
- 완화되지 않은 리스크, 수정되지 않은 결함
- 테스팅 관련 교훈
5.3.3. 테스팅 상황 전달
- 팀원 및 기타 이해관계자와의 대화
- 대시보드 ex. 번다운차트 : 남은 시간 대비 작업량을 시각적으로 보여준다. 매일 업데이트
- 전자 통신 채널 ex. 이메일, 채팅
- 온라인 문서
- 공식 테스트 보고서
5.4. 형상관리
- 복잡한 환경 (ex. 테스트 환경) : 항목의 구성 요소, 그 관계, 각각의 버전
- 테스트 케이스 실행 x, 커버리지 계산 x
제 6장 테스트 도구
6.1.1. 테스팅 지원 도구
관리 도구 : 소프트웨어 개발수명주기(SDLC), 요구사항, 테스트, 결함, 형상관리 용이 = 테스트 프로세스 효율성 ⬆️
정적 테스팅 도구 : 테스터의 리뷰와 정적 분석 수행 지원
테스트 설계 및 구현 도구 : 테스트 케이스, 테스트 데이터, 테스트 절차 생성 용이
테스트 실행 및 커버리지 도구 : 자동 테스트 실행 및 커버리지 측정 지원
비기능 테스팅 도구 : 수동으로 실행하기 어렵거나 불가능한 비기능 테스트를 테스터가 수행할 수 있게 함 = 테스트 실행 ⬆️
데브옵스 도구 : 배포 파이프라인, 작업 흐름 추적, 자동 빌드 프로세스, 지속적인 통합 및 배포 = 테스트 실행 ⬆️
협업 도구 : 원활한 의사소통 ⬆️
확장성 및 배포 표준화 지원 도구 : ex. 가상 머신, 컨테이너화 도구
기타 도구 : ex. 스프레드 시트
