인수 조건 :사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준. 인수 테스트 주도 개발 :팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.
경계값 분석 :경계값을 기반으로 테스트 케이스를 설계하는 블랙박스 테스트 기법.
분기 커버리지 :==결정 커버리지. 결정된 결과값에 대한 커버리지.
체크리스트 기반 테스팅 :경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 및 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.
커버리지 :커버리지 항목이 식별되거나 테스트 스위트에 의해 수행된 정도를 백분율로 표시한 것. 커버리지 항목 :테스트 실행의 완전성을 측정할 수있는 테스트 기법을 사용해 하나 이상의 테스트 컨디션에서 도출하는 속성 또는 속성들의 결합체.
결정 테이블 테스팅 :테스트 케이스가 결정 테이블에 표시된 조건과 결과 행위 조합을 실행하도록 설계하는 블랙박스 설계 기법.
동등 분할 :명세에 따라 모든 값이 동일하게 취급될 것으로 예상되는 컴포넌트 또는 시스템 내의 변수 값 도메인의 하위 집합.
오류 추정 :과거 장애에 대한 테스터의 지식이나 장애 형태에 대한 일반적인 지식에 기초하여 테스트 케이스를 도출하는 테스트 기법.
탐색적 테스팅 :테스터가 자신의 지식, 테스트 항목에 대한 탐색과 이전 테스트 결과를 기반으로 테스트를 동적으로 설계하고 실행하는 테스트 접근 방식. 상태 전이 테스팅 :테스트 케이스가 상태 전이 모델의 개별 요소를 실행하도록 설계된 블랙박스 테스트 기법.
구문 커버리지 :실행 가능한 구문에 대한 커버리지.
테스트 기법 :테스트 조건을 정의하고, 테스트 케이스를 설계하고, 테스트 데이터를 지정하는 데 사용되는 절차.
블랙박스 테스트 기법 :컴포넌트나 시스템의 명세에 대한 분석을 기반으로 하는 테스트 기법.
화이트박스 테스트 기법 :컴포넌트 또는 시스템의 내부 구조에만 기반을 둔 테스트 기법.
경험 기반 테스트 기법 :테스터의 경험, 지식, 직관에만 기반을 둔 테스트 기법.
4장의 내용은 엄청 많으면서 엄청 중요한 내용이다. 테스트 기법에 대해서도 알아야 되고 분석 문제도 풀 줄 알아야 된다.
샘플문제도 많이 풀어보고 발품팔아 구글링이랑 네이버 블로그 뒤적거려서 문제도 많이 찾아보고 풀어보는 게 좋다.
들어가기 전 알아둬야 할 3.1 용어, 3.2 용어 설명. : 사전적으로 설명정리한 건 바로 앞에 적어둔 블로그 용어 설명ㄱㄱ
사용자 스토리 : 일상 또는 비즈니스 언어로 사용자가 필요로 하는 기능, 그것의 이유, 비기능 조건, 인구 조건 등을 포착하는 한 문장으로 구성된 사용자 또는 비즈니스 요구사항. 백로그 : 프로젝트 관리, 소프트웨어 개발, 업무 관리 등 다양한 분야에서 사용되는 용어로, 완료되지 않은 작업 항목들의 리스트나 목록을 가리킴.
공식 리뷰 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형. 리뷰어 : == 검토자. 작업 산출물의 이슈를 식별하는 리뷰 작업 참여자.
워크스루 : 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의 진행.(비형식적인 검토기법.) 인스펙션 : 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제 해결.(형식적 검토기법.)
퍼실리테이션 : 직역- 용이성,편리성. 집단의 공동의 목적을 쉽게 달성할 수 있도록 도구와 기법을 활용하여 절차를 설계하고 중립적인 태도로 진행 과정을 돕는 활동을 일컬음.
3.1 정적 테스팅의 기초
정적 테스팅은 테스트 대상 소프트웨어를 실행하지 않아도 된다. 테스팅의 목표는 품질 개선, 결함 식별, 또한 가독성/완전성/정확성/테스트 용이성/일관성과 같은 특성을 평가하는 것이며 베리피케이션과 밸리데이션 모두에 적용할 수 있다. 사용자 스토리가 완전하고 이해하기 쉬우며, 테스트 가능한 인수 조건을 가지고 있는지 확인하기 위해 리뷰 기법을 적용할 수 있다. 적절한 질문을 통해 테스터는 제안된 사용자 스토리를 탐색하고, 문제를 제기하며 개선하는 데 도움을 준다. 정적 분석은 테스트 케이스가 필요 없고, 도구를 사용하는 경우가 많기 때문에 상대적으로 적은 노력으로 동적 테스팅 전에 문제를 식별할 수 있다. 정적 분석은 주로 구체적인 코드 결함을 식별하는 데 사용하지만, 유지보수성과 보안을 평가하는 데도 사용된다. 맞춤법 검사기나 가독성 도구로 정적 분석 도구의 예라 할 수 있다.
3.1.1 정적 테스팅으로 검사 가능한 작업 산출물
정적 테스트를 사용해 거의 모든 작업 산출물을 검토할 수 있다. ex> 요구사항 명세서, 소스 코드, 테스트 계획서, 테스트 케이스, 제품 백로그 항목, 테스트 차터, 프로젝트 문서, 계약서, 모델 등이 그 대상이 될 수 있다.
읽고 이해할 수 있는 모든 작업 산출물은 리뷰 대상이 될 수 있다. But, 정적 분석의 경우, 작업 산출물을 검토할 수 있는 기준이 되는 어떤 구조가 필요하다. ex> 모델, 공식 문법이 정해진 코드나 텍스트.
사람이 해석하기 어려운 것과 도구로 분석해서는 안 되는 작업 산출물(ex> 법적으로 문제가 되는 타사의 실행 코드)은 정적 테스트에 적합하지 않은 작업 산출물이다.
3.1.2 정적 테스팅의 가치
소프트웨어 개발수명주기 초기 단계에서 결함을 식별하기 때문에 조기 테스팅 원리를 지킬수 있게 한다.
동적 테스팅으로 식별할 수 없는 결함(ex> 도달 불가능한 코드)을 찾을 수도 있다.
작업 산출물의 품질을 평가하고 신뢰를 쌓을 방법을 제공한다.
문서화된 요구사항을 확인함으로써 이해관계자는 요구사항이 실제로 자기가 필요한 것을 묘사하고 있는지 확인할 수 있다.
소프트웨어 개발수명주기 초기에 수행할 수 있으므로 관련된 이해관계자 간 공통된 이해를 형성할 수 있다. 관련된 이해관계자 간의 의사소통도 개선된다. 때문에 정적 테스팅에 다양한 이해관계자가 참여하는 것이 권장됨.
리뷰를 구축하는 비용은 클수 있지만, 프로젝트 후반에 결함을 수정하는 시간과 노력이 줄어들어 리뷰를 수행하지 않을 때보다 전체 프로젝트 비용이 훨씬 낮아지는 경우가 많다.
동적 테스팅 보다 효율적으로 코드 결함을 식별할 수 있으며, 대부분의 경우 결과적으로 코드 결함이 줄고, 전반적인 개발 노력도 감소한다.
3.1.3 정적 테스팅과 동적 테스팅의 차이 : 정적 테스팅과 동적 테스팅은 서로를 보완한다.
< 정적 테스팅과 동적 테스팅의 차이 > - 모두 결함을 식별한다는 것은 같지만, 정적 테스팅이나 동적 테스팅 중 한 가지로만 식별할 수 있는 결함 유형도 있다.
정적 테스팅
동적 테스팅
- 결함을 직접 식별한다.
- 장애를 일으킨 후 연관된 결함을 후속 분석을 통해 찾아낸다.
- 거의 실행되지 않거나 동적 테스팅으로 도달하기 어려운 코드 경로에 있는 결함을 더 쉽게 발견할 수 있다.
- 비 - 실행 작업 산출물에도 적용할수 있다.
- 실행 가능한 작업 산출물에만 적용할 수있다.
- 코드 실행에 의존하지 않는 품질 특성(ex>유지보수성)을 측정할 수있다.
- 코드 실행에 의존적인 품질 특셩(ex> 성능 효율성)을 측정할 수 있다.
< 정적테스팅을 통해 더 쉽게, 적은 비용으로 식별할 수 있는 대표적인 결함 >
- 요구사항 결함(ex> 불일치, 모호성, 모순, 누락, 부정확성, 중복) - 설계 결함(ex> 비효율적인 데이터 베이스 구조, 모듈화 불량) - 특정 유형의 코딩 결함(ex> 정의되지 않은 값을 가진 변수, 선언되지 않은 변수, 도달할 수 없거나 중복된 코드, 과도한 코드 복잡성) - 표준위반(ex> 코딩 표준 명명 규칙을 준수하지 않는 경우) - 잘못된 인터페이스 명세(ex> 매개변수의 개수, 유형, 순서 불일치) - 특정 유형의 보안 취약성(ex> 버퍼 오버플로우) - 테스트 베이시스 커버리지의 차이 또는 부정확성(ex> 인수 조건 하나에 대한 테스트 누락)
3.2 피드백과 리뷰 프로세스 - 3.2.1 이해관계자 피드백을 조기에 받을 때의 이점
1. 잠재적인 품질 문제를 조기에 파악할 수 있음. 2. 요구사항에 대한 오해를 방지하고 요구사항 변경을 조기에 이해하고 구현할 수 있음. 이를 통해 개발팀은 구현 중인 제품에 대한 이해도를 높일 수 있다. And 이해 관계자에게 가장 중요하고, 식별한 리스크에 가장 긍정적인 영향을 미치는 기능에 집중할 수 있음.
3.2.2 리뷰 프로세스 활동
계획 :계획 단계에서목적, 리뷰 대상 작업 산출물, 평가할 품질 특성, 집중할 영역, 완료 조건, 표준과 같은 추가 정보, 공수, 리뷰 일정 등으로 구성되는리뷰의 범위를 정의해야 함.
리뷰 착수 : 리뷰 착수의 목표는 관련된 모든 사람과 사항이 리뷰를 시작할 준비가 되었는지 확인하는 것.여기엔모든 참여자가 리뷰 중인 작업 산출물에 접근할 수 있는지, 자신의 역할과 책임을 이해하고 있는지, 리뷰를 수행하는 데 필요한 것들을 받았는지 확인하는 과정이 포함됨.
개별 리뷰 :모든 검토자(리뷰어)는 하나 이상의 리뷰 기법(ex> 체크리스트 기반 리뷰, 시나리오 기반 리뷰)을 적용해리뷰 중인 작업 산출물의 품질을 평가하고, 이상 사항, 권장 사항, 의문 사항을 식별하기 위해개별 기뷰를 수행함.검토자(리뷰어)는 식별한 모든 이상 사항, 권장 사항, 의문 사항을 기록.
논의 및 분석 :리뷰 중에 확인한 이상 사항이 반드시 결함은 아니므로 모든 이상 사항에 대해 분석하고 논의할 필요가 있음.각 이상 사항의 상태, 담당자, 필요 조치를 판단해야 함.일반적으로 리뷰 회의에서 이루어지며, 회의에 참가자들은 리뷰한 작업 산출물의 품질 수준과 필요한 후속 조치도 결정. 조치를 완료하기 위해 후속 리뷰가 필요할 수 있음.
수정 및 보고:모든 결함에 대한 결함 보고서를 작성해 후속 조치가 추적 가능하도록 함. 완료 조건을 충족하면 작업 결과물을 승인할 수 있으며 리뷰 결과를 보고 한다.
3.2.3 리뷰에서의 역할과 책임
리뷰에는 다양한 이해관계자가 참여하며, 한명이 여러 역할을 동시에 맡을 수도 있다.
주요 역할
책임
관리자
리뷰할 내용을 결정, 리뷰에 필요한 사람과 시간 등 자원을 제공.
저자
리뷰 대상 작업 산출물을 작성하고 수정.
중재자(==퍼실리테이터)
중재, 시간 관리, 모든 사람이 자유롭게 발언할 수 있는 안전한 리뷰 환경 조성 등 리뷰 회의의 효과적인 운영을 담당.
서기(==기록자)
리뷰어로부터 이상 사항을 수집하고, 결정 사항이나 리뷰 회의 중에 발견한 새로운 이상 사항 등 리뷰 정보를 기록.
리뷰어(==검토자)
리뷰를 수행한다. 리뷰어는 프로젝트에 참여하는 사람 또는 주제 전문가, 기타 이해관계자가 될 수 있음.
리뷰 리더
리뷰에 참여할 사람을 결정하고, 리뷰 시간과 장소를 협의하는 등 리뷰에 대한 전반적인 책임을 짐.
3.2.4 리뷰 유형
비공식 리뷰부터 공식 리뷰까지 다양한 리뷰 유형이 있다. 필요한 리뷰 목적을 달성하려면 적절한 리뷰 유형을 선택하는 것이 중요!
< 많이 사용하는 4가지 리뷰 유형 >
리뷰 유형
특징
KeyWord
비공식 리뷰
정의된 프로세스를 따르지 않으며, 공식적인 결과 문서도 요구하지 않음. 주요 목적 : 이상 사항을 식별하는 것.
문서작성X
워크쓰루
저자가 리더가 되는 워크쓰루를 통해 품질 평가 및 작업 산출물에 대한 신뢰 구축, 리뷰어 교육, 합의 도출, 새로운 아이디어 창출, 저자가 개선할 수 있도록 동기 부여 및 지원, 이상 사항 발견 등 여러가지 목적을 달성할 수있음. 리뷰어는 워크쓰루 전에 개별 리뷰를 수행할 수도 있지만, 반드시 해야하는 것은 아님.
저자가 리더, 리뷰어 훈련
기술 리뷰
기술적인 자격을 갖춘 리뷰어가 수행하고 중재자가 리더가 됨. 주요 목적 : 기술 문제에 대한 합의를 도출하고 결정을 내리며, 이상 사항 식별, 품질 평가 및 작업 산출물에 대한 신뢰 구축, 새로운 아이디어 창출, 저자가 개선할 수 있도록 동기를 부여하고 지원하는 것.
중재자가 리더, 저자의 개선의지 향상
인스펙션
가장 공식적인 리뷰 유형. 보편적으로 프로세스를 철저히 따라야 함. 주요 목적 : 이상 사항을 최대한 많이 찾는 것. 기타 목적 : 품질 평가, 작업 산출물에 대한 신뢰 구축, 저자가 개선할 수있도록 동기 부여 및 지원. 메트릭을 수집해 리뷰 프로세스를 포함한 전체 소프트웨어 개발수명주기를 개선하는 데 사용. +잠재적 결함 식별. 저자가 리뷰 리더나 서기가 될수 없음
저자가 리뷰리더나 서기가 될 수 없음, 프로세스 개선에 사용
3.2.5 리뷰의 성공 요소
명확한 목표와 측정 가능한 완료 조건을 정의. 참가자의 평가나 목적이 되어서는 절대 X.
주어진 목표를 달성할 수 있으면서 작업 산출물 유형, 리뷰 참여자, 프로젝트 요구사항 및 정황에 맞는 리뷰 유형 선택.
리뷰어가 개별 리뷰 또는 리뷰 회의에서 집중력을 잃지 않도록 작은 단위로 리뷰 진행.
이해관계자와 저자에게 리뷰 피드백 제공 >> 제품 및 활동을 개선할 수 있도록 함.
참가자가 리뷰를 준비할 수 있는 충분한 시간 제공.
리뷰 프로세스를 관리층이 지원.
학습 및 프로세스 개선 촉진을 위해 리뷰가 조직 문화의 일부가 되도록 한다.
모든 참가자가 자신의 역할을 어떻게 충족해야 하는지 알수 있도록 적절한 교육 제공.
회의에 퍼실리테이션을 적용.
여기서는 정적 테스팅과 동적테스팅의 차이를 알아야 되며, 리뷰 역할과 책임, 리뷰 유형, 리뷰 성공 요소는 꼭 알아둬야 한다. 샘플 문제에서도 이 부분들의 문제는 하나씩 꼭 등장함!
이상 사항: ==이상 현상. 요구사항 명세서, 설계 문서, 사용자 문서, 표준 또는 누군가의 인식이나 경험 등에 기반한 기댓값에서 벗어난 상태를 말한다. 이상 현상은 리뷰, 테스팅, 분석, 비교, 혹은 소프트웨어 제품이나 해당 문서의 사용 도중에 발견할 수 있지만, 이에 국한되지는 않음.
동적 테스팅: 테스팅 항목의 실행과 관련된 테스트.
공식 리뷰 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형. 비공식 리뷰: 정의된 프로세스를 따르지 않고 문서화된 공식 결과가 없는 리뷰 유형.
인스펙션: 작업 산출물의 이슈를 식별하기 위한 공식리뷰 유형. 리뷰 프로세스와 소프트웨어 개발 프로세스를 개선하는 데 필요한 정보를 제공.
리뷰: 결함을 발견하거나 개선 사항을 제공하기 위해 한 명 이상의 개인이 작업 산출물 또는 프로세스를 평가하는 정적 테스팅 유형.
정적 분석: 형식이나 구조, 내용, 문서를 기반으로, 컴포넌트나 시스템을 실행하지 않으면서 평가하는 프로세스.
정적 테스팅: 테스트 항목의 실행을 수반하지 않는 테스팅.
기술 리뷰: 작업 산출물의 품질을 검사하고 명세 및 표준과의 불일치를 식별하는 기술 전문가의 공식 리뷰.
위크 쓰루: == 워크스루. 작성자가 작업 산출물에 대한 리뷰를 주도하고, 참가자들은 발생 가능 이슈에 대한 질문과 의견을 제시하는 리뷰 유형.
3장은 공부시간이 80분으로 6장 테스트 지원도구(20분) 외에 가장 짧은 시간이 필요하다. 읽어보면서 이해하고 넘어가야 80분의 시간 안에 끝낼 수 있다. 아무 생각 없이 읽기만 반복한다면 뫼비우스의 띠처럼 글씨, 글씨, 글씨로 시간이 줄줄이 흘러가 버려지는 시간이 늘어날 수 있다. 도저히 집중이 안된다 싶다면 문제를 풀어보면서 해설을 읽으며 공부해도 좋은 구역이다.
ISTQB가 4.0 버전으로는 정리되있는게 잘 보이지 않길래 직접 정리해 보면서 공부를 해보려 한다.
용어 정리를 시작으로 중간중간 이해되지 않았던 단어들 정리, 이론 정리, 샘플 문제 오답풀이, 문배 풀이 순서로 진행.
처음부터 이렇게 공부하고 싶었지만 시간이 없었던 관계로 시간이 생긴 지금 내방식대로 정리 Start!
혼자 하는 공부가 제일 잘되는 나로서는 오늘도 역시 혼자 공부하겠지만 이 글을 보는 누구든 같이 공부해서 합격해 보자!
혹시나 나같이 취업을 준비하고 있는 경우라면 우리 모두 취준 화이팅!
++ 이 블로그를 보시는 모두가 제가 정리해 둔 내용으로 합격된다면 그 또한 기분 째질 것 같으니 혹시나 합격하면 댓글 달아주기!
용어 정리 : 용어부터 찬찬히 알아둬야 문제에서 뭐라는지 알 수 있음. ▼ ISTQB에서 알려주는 용어 사전. 혹시나 모르는 단어가 있다면 Search해보라구. 영어로도 가능. ▼ ++ https://glossary.istqb.org/ko_KR/
커버리지 : 커버리지 항목이 식별되거나 테스트 스위트에 의해 수행된 정도를 백분로 표시한 것.
디버깅 : 컴포넌트 또는 시스템에서 장애의 원인 찾고 분석하고 제거하는 프로세스.
결함 : 요구사항이나 명세를 충족시키지 못하는 작업 산출물의 불완전함 또는 결점. 문배에서의 "결함" 설명 : 일반적으로 버그, 결함, 결정은 동의어로 사용될 수 있으며 요구된 기능을 적절히 처리하지 못하는 것. 즉 장애를 발생시키는 것.
오류 : 부정확한 결과를 만들어내는 인간의 행동. 문배에서의 "오류" 설명 : 잘못된 결과를 낳는 인간의 행위, 실수와 동의어.
장애 : 지정된 범위 내에서 요구되는 기능을 컴포넌트나 시스템이 수행하지 못하는 경우. 문배에서의 "장애" 설명 : 코드에 존재하는 결함의 실행.
품질 : 컴포넌트 또는 시스템이 다양한 이해관계자의 명시적 및 암시적 요구를 충족시키는 정도.
품질 보증: 품질 요구사항이 충족될 것이라는 확신을 제공하는 데 초점을 둔 활동.
근본 원인 : 결함의 원인 중 제거되면 해당 결함유형 발생이 감소하거나 제거될 수 있는 원인.
테스트 분석 : 테스트 베이시스를 분석하여 테스트 컨디션을 식별하는 활동.
테스트 베이시스 : 테스트 분석 및 설계의 기초로 사용하는 지식 체계.
테스트 케이스 : 테스트 컨디션을 기반으로 개발된 사전 조건, 입력값, 행동(해당하는 경우), 기대 결과, 사후조건의 집합.
테스트 완료 : 테스트웨어를 나중에 사용할 수 있도록 만들고 테스트 환경을 만족스러운 상태로 남겨놓고 관련 이해관계자에게 테스트 결과를 전달하는 활동.
테스트 컨디션: 테스팅의 베이시스로 식별된 컴포넌트 또는 시스템의 테스트 가능한 측면.
테스트 제어 : 테스트 프로젝트가 계획을 벗어났을 때 예정대로 진행되도록 시정 조치를 개발하고 적용하는 활동.
테스트 데이터 : 테스트 실행에 필요한 데이터.
테스트 설계 : 테스트 컨디션에서 테스트 케이스를 도출하고 명시하는 활동.
테스트 실행 : 컴포넌트 또는 시스템에서 테스트를 실행하여 실제 결과를 도출하는 활동.
테스트 구현 : 테스트 분석과 설계를 기반으로 테스트 실행에 필요한 테스트웨어를 준비하는 활동.
테스트 모니터링 : 테스트 활동의 상태를 확인하고 계획 또는 예상과의 차이를 식별하고 이해관계자에게 상태를 보고하는 활동.
테스트 대상: 테스트할 작업 산출물.
테스트 목적 : 테스팅의 이유 또는 목적.
테스트 계획 : 테스트 계획서의 수립 또는 수정 활동.
테스트 절차 : 실행 순서로 나열된 테스트 케이스 순서. 초기 사전 조건을 설정하는 데 필요한 모든 관련 동작과 실행 이후의 모든 마무리 활동까지 포함.
테스트 결과 : 테스트 실행의 결과 또는 결괏값. 화면 출력과 데이터 변경, 보고서, 전송된 통신 메시지 등이 여기에 포함.
테스팅 : 소프트웨어 제품 및 관련 작업 산출물이 특정 요구사항을 충족하는지 확인하고, 목적에 부합하는지 여부를 입증하고, 결함을 발견하기 위해 정적/ 동적의 모든 계획, 준비, 평가와 관련된 수명주기 활동으로 구성된 프로세스
테스트웨어 : 테스팅에 대한 계획, 설계, 실행, 평가, 보고 등에 활용하기 위한 목적으로 테스트 프로세스 동안 생성되는 작업 산출물.
밸리데이션 : 의도된 특정 용도 또는 용도에 대한 요구사항이 충족되었음을 보증하기 위해 객관적 증거와 조사를 통해 확인하는 것.
베리피케이션 : 특정 요구사항이 모두 구현되었는지를 객관적 증거와 조사를 통해 확인하는 것.
자주 나오는 테스팅의 종류 : ISTQB 공부하면 적어도 한번 이상 접하는 애들이니까 잘 읽어봐.
기능 테스팅 : 컴포넌트 또는 시스템이 기능 요구사항을 충족하는지 평가하기 위해 수행되는 테스트. 비기능 테스팅 : 컴포넌트 또는 시스템이 비기능적 요구사항을 충족하는 지 평가하기 위해 수행되는 테스트.
정적 테스팅 : 테스트 항목의 실행을 수반하지 않는 테스팅. 동적 테스팅 : 테스트 항목의 실행과 관련된 테스트.
화이트박스 테스팅 : 컴포넌트나 시스템의 내부구조 분석에 기반한 테스팅. 경험 기반 테스팅 : 테스터의 경험, 지식, 직관에 기반한 테스팅. 리스크 기반 테스팅 : 연관된 리스크 유형과 리스크 수준을 기반으로 테스트 활동 및 리소스의 이용, 관리, 선택, 우선순위 등을 다루는 테스팅.
베타 테스팅 : 개발 조직에 속하지 않는 인원에 의해 개발자의 테스트 환경과 다른 외부 사이트에서 수행되는 인수 테스트 유형. 사용자 인수 테스팅 : 의도된 사용자가 시스템을 승인하는지 확인하기 위해 수행되는 인수 테스트 유형. 운영 인수 테스팅 : 운영 및 시스템 관리 직원이 시스템을 인수할 수 있는지 확인하기 위해 수행되는 인수 테스트 유형.
리그레션 테스팅 : 소프트웨어의 변경되지 않은 영역에 결함이 도입 또는 발현되었는지 여부를 감지하기 위한 변경 관련 테스트 유형. 확인 테스팅 : 결함을 수정한 후 해당 결함으로 인해 발생한 장애가 다시 나타나지 않는지 확인하기 위해 수행하는 변경 관련 테스트 유형.
애자일 테스팅 사분면 : 4 사분면으로 구성된 테스트 유형/ 레벨 분류 모델로, 테스트 목표의 두 가지 차원(팀 지원 대 제품 비평, 기술대면 대 비즈니스 대면)과 관련됨.
시스템 테스팅 : 전체로 봤을 때 시스템이 명시된 요구사항을 충족하는지 확인하는 데 초점을 둔 테스트 레벨. 시스템 통합 테스팅 : 시스템 간의 상호작용에 초점을 둔 테스트 레벨. 통합 테스팅 : 컴포넌트 또는 시스템 간의 상호작용에 중점을 둔 테스트 레벨. 컴포넌트 테스팅 : 개별 하드웨어 또는 소프트웨어 컴포넌트에 초점을 둔 테스트 레벨.
탐색적 테스팅 : 테스터가 자신의 지식, 테스트 항목에 대한 탐색과 이전 테스트 결과를 기반으로 테스트를 동적으로 설계하고 실행하는 테스트 접근 방식. 요구사항 기반 테스팅 : 테스트 케이스를 요구사항을 기반으로 설계하는 테스트 접근 방식.
컴포넌트 통합 테스팅 : 테스트 항목이 통합된 다른 컴포넌트와 인터페이스하고 상호 작용하는 테스트. 통합된 컴포넌트 간의 인터페이스와 상호작용에서의 결함을 노출시키기 위한 테스팅.
화이트박스 테스트 기법 : 컴포넌트나 시스템의 내부 구조 분석에만 기반을 둔 테스트 기법. 블랙박스 테스트 기법 : 컴포넌트나 시스템의 명세에 대한 분석을 기반으로 하는 테스트 기법. 경험 기반 테스트 기법 : 테스터의 경험, 지식, 직관에만 기반을 둔 테스트 기법.
조건 테스팅 : 테스트 케이스가 원자 조건의 결과를 실행하도록 설계된 화이트박스 테스트 기법. 결정 테스팅 : 테스트 케이스가 결정 결괏값을 실행하도록 설계하는 화이트박스 테스트 기법.
조합 테스팅 : 테스트 케이스가 복수의 매개변수 값의 특정 조합을 실행하도록 설계되는 블랙박스 테스트 기법. 유스케이스 테스팅 : 유스케이스 동적을 수행하도록 테스트 케이스를 설계하는 블랙박스 테스트 기법. 사용자 스토리 테스팅 : 사용자 스토리를 기반으로 테스트 케이스를 설계하여 올바르게 구현되었는지를 확인하는 블랙박스 테스트 기법. 상태 전이 테스팅 : 테스트 케이스가 상태 전이 모델의 개별 요소를 실행하도록 설계된 블랙박스 테스트 기법. 동등 분할 기법 : 각 도메인의 구성 데이터 중 하나를 사용하여 테스트 케이스가 동등 분할을 실행하도록 설계하는 블랙박스 테스트 기법.
구문 테스팅 : 테스트 케이스가 구문을 실행하도록 설계하는 화이트박스 테스트 설계 기법. 결정 테이블 테스팅 : 테스트 케이스가 결정 테이블에 표시된 조건과 결과 행위 조합을 실행하도록 설계하는 블랙박스 설계기법.
체크리스트 기반 테스팅 : 경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 및 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.
