용어
커버리지: 특정한 커버리지 항목이 테스트 스위트에 의해 이행되는 백분율 정도
디버깅: 소프트웨어에서 장애의 원인을 발견하고, 분석하여 제거하는 절차.
오류: 결함을 발생 시키는 인간의 실수
결함: 코드 또는 작업 산물의 결점이나 버그
장애: 결함 실행 및 환경 조건으로 인해 발생하는 눈에 확연히 띄는 문제
근본 원인: 해당 결함을 만들어낸 최초의 행동이나 조건
품질 : 컴포넌트나 시스템이 다양한 이해관계자의 명시적/묵시적 요구를 충족시키는 정도
품질 보증: 품질 요구사항이 충족될 것이라는 신뢰감 제공에 집중하는 품질 관리의 한 부분
테스트 베이시스: 요구사항을 내포하는 모든 문서
테스트 케이스: 테스트 컨디션(test conditions)에 기초해 개발한 일련의 사전조건, 입력, 행동, 예상 결과 및 사후조건
테스트 컨디션: 테스팅의 기초(basis)로 파악된 컴포넌트나 시스템의 테스팅 가능한 측면
테스트 제어: 테스트 프로젝트에 계획 대비 차이가 나타나면 계획대로 진행되도록 정정 행동을 전개하고 적용하는 테스트 관리 업무
테스트 데이터: 테스트가 실행되기 이전에 데이터베이스와 같은 곳에 존재하며 테스트 대상 컴포넌트나 시스템에 영향을 주거나 영향을 받는 데이터
테스트 설계: 테스트 아이템의 테스트 상황(커버리지 항목)과 상세한 테스트 접근법을 명세화하고 이와 연계된 상위 수준 테스트 케이스를 식별하는 활동
테스트 실행: 테스트 대상 컴포넌트나 시스템에 대해 테스트를 수행하여 실제 결과를 생성하는 절차.
테스트 모니터링: 테스트 프로젝트의 상태를 정기적으로 점검하는 것과 관련된 활동을 다루는 테스트 관리 업무. 리포트는 실제(결과)를 계획된 것과 비교하여 준비된다.
테스트 대상: 테스트 되는 컴포넌트나 시스템.
테스트 목적: 테스트를 설계하고 실행하기 위한 근거 또는 목적
테스트 오라클: 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거. 테스트 오라클은 (벤치마크를 위한) 기존 시스템, 사용자 매뉴얼, 또는 개인의 전문 지식일 수 있으나 코드(code)가 될 수는 없다.
테스트 계획: 의도된 테스트 활동의 범위, 접근법, 자원 그리고 일정을 기술하는 문서. 테스트 계획은 다른 테스트 항목, 테스트 대상의 기능 및 특성, 테스팅 업무, 업무 담당 배정, 테스터의 독립성 정도, 테스트 환경, 사용할 테스트 설계 기법과 테스트 측정 기법, 선택의 근거, 그리고 긴급 대책을 요하는 모든 리스크를 식별한다.
테스트 절차: 테스트를 수행할 때 따라야 할 순서.
테스트 프로세스: 기본적인 테스트 프로세스는 테스트 기획, 명세, 실행, 기록 그리고 완료 여부의 점검으로 구성된다.
테스트 스위트: 테스트 대상 컴포넌트나 시스템에 사용되는 여러 테스트 케이스의 집합.
테스팅: 소프트웨어 제품과 관련 작업 산출물이 특정 요구명세를 만족하는지 결정하고, 목적에 부합하는지 입증하고 결함을 찾아내기 위해 해당 산출물을 계획, 준비, 평가하는 정적/동적인 모든 수명주기 활동으로 구성된 프로세스.
테스트웨어: 테스트를 계획, 설계, 실행하는 테스트 프로세스 동안 생성된 산출물. 테스트웨어는 테스팅에 사용되는 문서, 스크립트, 입력값, 예상 결과, 시작과 마무리 절차, 파일, 데이터베이스, 환경, 그리고 모든 추가적인 소프트웨어 또는 유틸리티를 포함한다.
추적성: 요구사항과 이와 연관된 테스트 같이 문서나 소프트웨어에서 연관된 항목을 식별하는 능력.
밸리데이션(확인): 요구사항이 컴포넌트나 시스템을 특정하게 의도적으로 사용 또는 활용하는 것을 충족시키는지 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.
베리피케이션(검증): 명세된 요구사항이 충족되었는지를 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.
테스트 분석: 테스트 컨디션을 기반으로 테스트 케이스 생성하는 활동
테스트 완료: 테스트 웨어 축적을 하는 활동
테스트 구현: 테스트 제어 생성 및 완성
1.1.1 테스팅의 목적 (테스팅의 일반적인 목적을 파악한다.)
일반적인 프로젝트에서의 테스팅 목적
- 결함 예방
- 요구사항 충족 검증
- 완성 여부 확인 및 기대치 대로 동작하는지 확인
- 품질 수준에 대한 자신감 획득
- 장애 및 결함 발견
- 품질 수준을 결정하는 데 필요한 정보 제공
- 계약/법률/규제/요구사항과 표준을 준수하는지 확인
1.1.2 테스팅과 디버깅 (테스팅과 디버깅의 구분할 수 있다.)
테스팅
- SW 결함으로 인한 장애 찾기.
- 동적 테스팅을 통해 장애의 발생을 보여줄 수 있음
- 테스팅은 결함 원인 식별x
- 직접적인 예방x 단지 결함의 존재를 찾는 것
디버깅
- 장애의 원인을 찾고 분석하여 수정하여 결함 제거
- 디버깅은 결점의 원인이 되는 결함을 제거하는 활동
1.2.1 성공을 위한 테스팅의 기여 (테스팅이 왜 필요한지 예를 들 수 있다.)
대표적인 예시
- 테스터를 통해 작업 산출물에서 결함 발견. 이를 통해 사전에 잘못된 프로그램 배제
- 테스터와 설계자의 협업시 이해도가 올라가 설계에 결함이 유입되는 리스크 감소 및 필요 테스트를 좀 더 일찍 식별 가능
- 테스터와 개발자의 협업으로 이해도가 올라가 코드와 테스트에서의 결함 리스크 감소
- 릴리스 전에 장애를 발견하여 요구사항을 충족 가능
- sw 개발과 유지보수 전반의 성공 확률을 높여준다.
1.2.2 품질 보증과 테스팅 (QA와 테스팅의 관계를 설명, 품질 확보에 테스팅이 어떻게 기여하는지 예를 들 수 있다.)
QA
- 적절한 품질을 달성했는지 확신을 얻기 위해 프로세스를 준수하도록 하는 것에 초점을 둠
- 조직이 표준을 준수했는가?
테스팅
- 품질 목표 달성에 기여.
- sw의 개발 및 유지보수 프로세스의 일부
- 품질 저하 리스크 수준을 낮춰줌
1.2.3 오류, 결함, 장애 (오류, 결함, 장애를 구별할 수 있다.)
오류 : 결함을 발생 시키는 실수
결함 : 코드 또는 작업 산물의 결점이나 버그
장애 : 결함 실행 및 환경 조건(방사능, 오염등의 HW 변화)으로 인해 발생하는 눈에 확연히 띄는 문제
오류의 발생 원인
- 시간적 압박
- 사람의 실수
- 의사소통 문제
- 기술의 복잡도
- 신기술
- 많은 인터페이스
1.2.4 결함, 근본원인, 결과(결함의 근본 원인과 그것의 영향을 구별 가능하다.)
근본 원인 : 해당 결함을 만들어낸 최초의 행동이나 조건. 결함을 분석하여 찾기 가능( 예) 잘못 된 이자 지급 오류)
결과 : 소비자의 불만
장애 : 잘못된 이자 지급
결함 : 코드에 잘못된 계산식
최초 결함 : 사용자 스토리의 모호성
근본원인 : 제품 소유자의 지식
1.3.1 테스팅의 7가지 원리(테스팅의 7가지 원리를 설명 가능하다.)
테스팅의 7가지 원리
- 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다.
- 완벽한 테스팅은 불가능하다.
- 조기 테스팅으로 시간과 비용을 절약할 수 있다.
- 결함은 집중된다.
- 살충제 패러독스에 유의하라
- 테스팅은 정황에 의존적이다.
- 오류 부재는 궤변이다. : 충분히 오류를 수정해도 충족시키지 못할 수 있음
1.4.1 정황에 따른 테스트 프로세스(정황이 테스트 프로세스에 미치는 영향 설명 가능하다.)
조직의 테스트 프로세스에 영향을 줄 수 있는 정황 요소
- SW 개발 수명주기 모델과 프로젝트 방법론
- 테스트 레벨과 테스트 유형
- 제품 및 프로젝트 리스크
- 비즈니스 도메인
- 운영상의 제약사항(예산, 일정, 복잡도, 계약 및 규제 요구사항)
- 운영 정책과 프랙티스
- 준수해야 하는 내부 및 외부 표준
조직 테스트 프로세스의 일반적인 요소
- 테스트 활동과 작업
- 테스트 작업 산출물
- 테스트 베이시스(요구사항을 내포하는 모든 문서)와 테스트 작업 산출물 간의 추적성
1.4.2 테스트 활동과 작업(테스트 프로세스의 테스트 활동과 연관 된 작업에 대해 설명 가능하다.)
| 용어 | 정의 | 주요활동 |
| 테스트 계획 | 테스트 계획서의 수립 또는 수정 활동 (계획서 : 테스트 활동 조정에 사용되며 ,달성할 목표와 방법 일정을 설명하는 문서) |
적합한 테스트 기법과 작업 명시 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립 |
| 테스트 모니터링과 제어 | 테스트 모니터링 : 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교하는 활동 테스트 제어 : 시간이 지나면서 업데이트될 수 있는 테스트 계획의 목적 달성을 위해 필요한 행동을 취하는 활동 |
종료 조건 평가 명시된 커버리지 조건 대비 테스트 결과와 로그 확인 테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가 추가 테스트 필요 여부 결정 |
| 테스트 분석 | 무엇을 테스트할 것인가? : 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어를 생성한다. | 적합한 테스트 베이시스 평가 테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별 테스트할 기능과 기능 세트 식별 테스트 컨디션의 정의 및 우선순위 선정 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착 |
| 테스트 설계 | 어떻게 테스트할 것인가? : 테스트 설계에서 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어 생성한다. | 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별 테스트 환경 설계와 필요한 인프라 및 도구 식별 |
| 테스트 구현 | 테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가? : 테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치하여 테스트 프로시저를 만듬 | 테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성 테스트 프로시저와 자동 테스트 스크립트로부터 테스트 스위트 생성 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치 테스트 환경 구축, 가능하다면 테스트 하네스, 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로간의 양방향 추적성 검증과 업데이트 |
| 테스트 실행 | 테스트 스위트를 테스트 실행 일정에 따라 실행한다. | 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행 기대 결과와 실제 결과 비교 이상현상을 분석해 원인 파악 관찰 장애를 기반으로 결함 보고 이상 형상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복(ex. 수정된 테스트 실행, 확인테스팅,리그레션 테스팅등) 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성 검증과 업데이트 |
| 테스트 완료 | 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동 | 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인 이해관계자에게 전달할 테스트 요약 보고서 생성 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복주기, 릴리스, 또는 프로젝트를 위해 수정해야 하는 사항 판단 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용 |
1.4.3 테스트 작업 산출물 (테스트 프로세스를 지원하는 작업 산출물을 구별할 수 있다.)
| 용어 | 산출물 |
| 테스트 계획 | 하나 이상의 테스트 계획(테스트 베이시스에 대한 정보 포함) |
| 테스트 모니터링과 제어 | 테스트 요약 보고서와 같은 여러 형태의 테스트 보고서 산출물은 작업완료, 리소스 할당과 사용, 공수등과 같이 프로젝트 관리에서 관심을 가지는 사항에 대해서도 다뤄야 함. |
| 테스트 분석 | 분석을 통해 식별되고 우선순위가 선정된 테스트 컨디션은 테스트 분석 작업 산출물 이상적으로는 각 테스트 컨디션과 그것이 커버하는 테스트 베이시스 요소와의 양방향 추적성이 성립 되어야함. 탐색적 테스팅에서는 테스트 분석 중 테스트 차터를 생성할 수 있음. 테스트 베이시스의 결함을 발견 보고 가능. |
| 테스트 설계 | 테스트 케이스와 테스트 케이스 세트 |
| 테스트 구현 | 테스트 프로시저와 이 프로시저의 배열. 테스트 스위트 테스트 실행 일정 |
| 테스트 실행 | 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서 |
| 테스트 완료 | 테스트 요약 보고서 차후 프로젝트나 반복주기의 개선을 위한 액션 아치템 수정요청서 혹은 제품 백로그 항목 완성된 테스트웨어 등 |
1.4.4 테스트 베이시스와 테스트 작업 산출물 간의 추적성(테스트 베이시스와 테스트 작업 산출물 간의 추적성을 유지하는 것이 어떻게 도움이 되는지 설명할 수 있다.)
장점
- 수정으로 인한 영향 평가를 가능하게 한다.
- 테스팅에 대한 감사를 가능하게 한다.
- IT 통제 조건을 충족할 수 있게 한다.
- 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함함으로써 테스트 진행 상황 보고서와 테스트 요약 보고서를 좀 더 쉽게 이해할 수 있게 한다.
- 테스팅의 기술적인 내용을 관계자가 이해할 수 있는 형태로 전달한다.
- 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등의 정보를 제공한다.
1.5.1 인간 심리학과 테스팅(테스팅의 성공에 영향을 주는 심리 요인을 식별할 수 있다.)
의사소통에 도움을 주는 예제
- 다툼보다는 협력으로 시작하라
- 테스팅의 이점을 강조하라
- 테스트 결과와 발견 사항을 중립적 사실에 기반으로 전달해야 한다.
- 상대방이 부정적으로 반응하는 이유가 뭔지를 이해하려고 해야 한다.
- 상대방이 한 말을 이해했는지 확인해야 한다.
1.5.2 테스터와 개발자의 사고 방식(테스트 활동에 필요한 사고방식과 개발 활동에 필요한 사고방식을 구별할 수 있다.)
테스터 : 호기심, 전문적인 비평, 비판적 시각, 세밀한 것에 주목하는 태도, 긍정적인 의사소통 관계 수립
개발자 : 개발자들은 종종 어떤 부분이 잘못 될 수 있다는 생각보다는 제품/서비스를 설계하고 구축하는 것에 더 관심이 있다.
'ISTQB CTFL' 카테고리의 다른 글
| 5. 테스트 관리 (0) | 2021.05.26 |
|---|---|
| 4. 테스트 기법 (0) | 2021.05.25 |
| 3. 정적 테스팅 (0) | 2021.05.24 |
| 2. 소프트웨어 개발 수명주기와 테스팅 (0) | 2021.05.23 |
| 0. ISTQB CTFL 합격후기 (1) | 2021.03.31 |
댓글