카테고리 CTFL_Syll_4.0

경험 기반 테스트 기법은 테스터의 경험, 지식, 직관, 창의력에 의존하여 소프트웨어 시스템에서 결함을 발견할 가능성이 있는 테스트 케이스를 식별하고 실행하는 테스트 설계 기법입니다. 경험 기반 테스트 기법은 소프트웨어 시스템의 내부 구조나 구현을 고려하지 않고 외부 동작과 사양을 테스트 기준으로 삼는 테스트 설계 기법인 블랙박스 테스트 기법에서 발견하지 못한 숨겨진 결함을 발견하는 데 유용한 경우가 많습니다.
경험 기반 테스트 기법은 사용성, 보안, 안정성, 성능 등과 같이 명시적으로 지정되지 않은 측면을 다룸으로써 블랙박스 테스트 기법을 보완할 수 있습니다. 다른 진술은 거짓입니다:
* 경험 기반 테스트 기법은 테스터의 경험에 의존하여 블랙박스 테스트 기법으로 발견한 결함의 근본 원인을 파악하는 것이 아니라 자체적인 통찰력, 휴리스틱 또는 탐색적 테스트를 기반으로 결함의 잠재적 원인을 파악합니다. 결함의 근본 원인은 일반적으로 디버깅 또는 근본 원인 분석을 통해 식별되며, 이는 코드 또는 개발 프로세스를 검사하여 결함을 유발한 오류를 찾아 수정하는 활동입니다.
* 화이트박스 테스트 기법에서 사용하는 가장 일반적인 테스트 기반에는 소스 코드, 설계 문서, 아키텍처 다이어그램, 소프트웨어 시스템의 제어 흐름 그래프 등이 있습니다.
화이트박스 테스트 기법은 소프트웨어 시스템의 내부 구조와 구현을 테스트 기반으로 사용하는 테스트 설계 기법으로, 문, 분기, 경로 등과 같은 코드 요소를 기반으로 일정 수준의 테스트 커버리지를 달성하는 것을 목표로 합니다. 사용자 스토리, 사용 사례, 비즈니스 프로세스는 사용자 또는 이해관계자의 관점에서 소프트웨어 시스템의 기능적, 비기능적 요구 사항을 설명하는 것으로 블랙박스 테스트 기법에서 사용하는 테스트 기준의 예입니다.
* 경험 기반 테스트 기법의 주요 목표는 GUI 기반 테스트 자동화 도구를 사용하여 쉽게 자동화할 수 있는 테스트 케이스를 설계하는 것이 아니라 경계 값 분석, 등가 분할, 상태 전환 테스트 등 다른 테스트 기법으로는 쉽게 발견할 수 없는 결함을 발견할 수 있는 테스트 케이스를 설계하는 것입니다. 테스트 자동화는 사람의 개입 없이 소프트웨어 도구를 사용하여 테스트 케이스를 실행하고 실제 결과와 예상 결과를 비교하는 것을 말합니다. 테스트 자동화는 테스트 목표, 테스트 수준, 테스트 도구 및 테스트 리소스에 따라 다양한 유형의 테스트 기법에 적용될 수 있습니다. 그러나 경험 기반 테스트 기법으로 설계된 테스트 사례와 같이 사람의 판단, 창의성 또는 탐색이 필요한 테스트 사례의 경우 테스트 자동화가 항상 실현 가능하거나 유익한 것은 아닙니다. 참고 자료 ISTQB 공인 테스터 기초 수준(CTFL) v4.0 소스 및 문서:
* ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2.2.1장, 블랙박스 테스트 설계 기법
* ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2.2.2장, 화이트박스 테스트 설계 기법
* ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 2.2.3장, 경험 기반 테스트 설계 기법
* ISTQB 테스트 용어집 v4.0, 경험 기반 테스트 기술, 블랙박스 테스트 기술, 화이트박스 테스트 기술, 테스트 기준, 테스트 커버리지, 테스트 자동화

정적 테스트는 테스트 대상 소프트웨어나 시스템을 실행하지 않는 테스트의 한 형태입니다. 여기에는 문서, 코드 및 모델에 대한 검토, 검사, 연습, 분석 등의 활동이 포함됩니다. 정적 테스트는 개발 프로세스 초기에 결함을 발견하여 이후 단계에서 더 많은 비용이 들고 수정하기 어려워지기 전에 발견할 수 있습니다. 또한 정적 테스트는 처음부터 결함을 방지하여 소프트웨어 또는 시스템의 품질을 향상시킬 수 있습니다. 정적 테스트는 테스트 중인 소프트웨어 또는 시스템을 실행하고 예상 결과와 비교하여 결과를 확인하는 동적 테스트를 보완할 수 있습니다. 동적 테스트는 성능, 사용성 또는 통합 문제와 같이 정적 테스트에서 놓칠 수 있는 결함을 발견할 수 있습니다.
그러나 동적 테스트만으로는 가능한 모든 시나리오, 입력 또는 경로를 커버하지 못할 수 있으므로 품질을 보장하기에 충분하지 않습니다. 따라서 정적 테스트를 건너뛰기로 결정한 테스트 관리자는 정적 테스트의 이점을 무시하고 결함을 발견하고 예방하는 데 효과적이거나 효율적이지 않을 수 있는 동적 테스트에만 의존하는 잘못된 결정을 내리고 있는 것입니다. 참조 = ISTQB 공인 테스터 기초 레벨 강의 계획서, 버전 4.0, 2018, 섹션 2.1.1, 14페이지; ISTQB 테스트 용어집, 버전 4.0,
2018, 36페이지; ISTQB CTFL 4.0 - 샘플 시험 - 답안, 버전 1.1, 2023, 문제 3, 9페이지.

상태 테스트 기법은 다양한 입력 조건과 이벤트에 대한 테스트 대상 시스템의 동작을 기반으로 하는 동적 테스트 기법의 한 유형입니다. 동적 테스트 기법은 테스트 케이스와 함께 시스템을 실행해야 하는 반면, 정적 테스트 기법은 그렇지 않습니다. 정적 테스트 기법은 코드가 실행될 준비가 되기 전에 검토, 검사, 연습 및 정적 분석과 같이 적용될 수 있습니다. 정적 테스트 기법은 개발 프로세스 초기에 결함을 발견하고 코드의 품질을 개선하며 동적 테스트의 비용과 노력을 줄이는 데 도움이 될 수 있습니다. 참조 = ISTQB 공인 테스터 기초 수준(CTFL) v4.0 강의 계획서, 4장 4.2.1절, 281페이지; ISTQB 테스트 용어집 v4.0, 292페이지

테스트 자동화를 사용하면 입력, 출력 및 예상 결과가 일관된 사전 정의된 테스트 스크립트 또는 테스트 케이스를 실행할 수 있으므로 인적 오류의 영향을 덜 받는 테스트를 생성할 수 있습니다. 또한 테스트 자동화는 회귀 테스트, 성능 테스트 또는 데이터 기반 테스트와 같이 반복적이거나 지루한 테스트를 실행하는 데 필요한 수동 작업과 시간을 줄일 수 있습니다. 테스트 자동화는 테스트 대상 시스템의 예상되는 동작만 확인할 수 있고 예상치 못한 동작이나 알려지지 않은 동작은 확인할 수 없으므로 결함이 없음을 증명하지는 않습니다. 탐색 테스트는 자동화된 테스트에서 다루지 않는 새로운 정보, 위험 또는 결함을 발견하는 데 유용한 기술이기 때문에 테스트 자동화는 탐색 테스트 수행을 피하지 않습니다. 결함 관리는 결함 보고, 추적, 분석 및 해결을 포함하는 별도의 활동이며 자동화 테스트와 관련이 있을 수도 있고 없을 수도 있기 때문에 테스트 자동화는 결함 관리를 용이하게 하여 테스트 프로세스 효율성을 높이지 않습니다. 참조: ISTQB 공인 테스터 기초 수준(CTFL) v4.0 소스 및 문서:
ISTQB® 공인 테스터 기초 레벨 강의 계획서 v4.0, 3.3.1장, 테스트 자동화1 ISTQB® 테스트 용어집 v4.0, 테스트 자동화2

정적 테스트는 테스트 대상 소프트웨어나 시스템을 실행하지 않는 테스트의 한 형태입니다. 여기에는 문서, 코드 및 모델에 대한 검토, 검사, 연습, 분석 등의 활동이 포함됩니다. 정적 테스트는 개발 프로세스 초기에 결함을 발견하여 이후 단계에서 더 많은 비용이 들고 수정하기 어려워지기 전에 발견할 수 있습니다. 또한 정적 테스트는 처음부터 결함을 방지하여 소프트웨어 또는 시스템의 품질을 향상시킬 수 있습니다. 정적 테스트는 테스트 중인 소프트웨어 또는 시스템을 실행하고 예상 결과와 비교하여 결과를 확인하는 동적 테스트를 보완할 수 있습니다. 동적 테스트는 성능, 사용성 또는 통합 문제와 같이 정적 테스트에서 놓칠 수 있는 결함을 발견할 수 있습니다. 그러나 동적 테스트만으로는 가능한 모든 시나리오, 입력 또는 경로를 커버하지 못할 수 있으므로 품질을 보장하기에 충분하지 않습니다. 따라서 정적 테스트를 건너뛰기로 결정한 테스트 관리자는 정적 테스트의 이점을 무시하고 결함을 발견하고 예방하는 데 효과적이거나 효율적이지 않을 수 있는 동적 테스트에만 의존하는 잘못된 결정을 내리고 있는 것입니다. 참조 = ISTQB 공인 테스터 기초 레벨 강의 계획서, 버전 4.0, 2018, 섹션 2.1.1, 14페이지; ISTQB 테스트 용어집, 버전 4.0, 2018, 36페이지; ISTQB CTFL 4.0 - 샘플 시험 - 답안, 버전 1.1, 2023, 질문 3, 9페이지.

* 소프트웨어 테스트는 결함이 없음을 입증하는 것이 아니라 결함의 존재 또는 소프트웨어가 지정된 요구사항에 부합함을 입증하는 것입니다1. 소프트웨어의 모든 가능한 시나리오, 입력, 출력 및 동작을 테스트하는 것은 불가능하기 때문에 테스트를 통해 소프트웨어에 결함이 없음을 증명할 수는 없습니다2. 테스트는 테스트 활동의 범위, 효과성 및 효율성을 기반으로 소프트웨어 품질에 대한 어느 정도의 신뢰도만 제공할 수 있습니다3.
* 다른 옵션이 올바른 이유는 다음과 같습니다:
* A. 적절하게 설계된 테스트를 통과하면 시스템이 예상 품질 속성을 충족하고 사용자와 고객의 요구와 기대를 충족하는지 확인하므로 시스템의 위험 수준이 감소합니다4. 위험이란 바람직하지 않은 이벤트의 발생으로 인한 손실 또는 피해의 가능성을 말합니다5. 테스트는 소프트웨어 제품 및 프로젝트와 관련된 위험을 식별, 분석, 우선순위를 정하고 완화하는 데 도움이 될 수 있습니다6.
* C. 소프트웨어 테스트는 소프트웨어의 품질과 개발 프로세스의 효과성에 대한 피드백을 제공하므로 개발 활동을 개선하는 데 사용할 수 있는 결함을 식별합니다7. 결함은 소프트웨어가 예상되거나 요구되는 결과 또는 동작에서 벗어나게 하는 결함 또는 오류입니다. 테스트를 통해 결함을 감지, 보고, 추적, 해결하고 향후 결함의 재발을 방지할 수 있습니다.
* D. 시스템을 구현하기 전에 요구사항 사양을 검토하면 요구사항이 명확하고 완전하며 일관되고 테스트 가능하며 사용자 및 고객의 요구와 기대에 부합하는지 확인할 수 있으므로 품질을 향상시킬 수 있습니다. 요구사항은 소프트웨어가 수행해야 하는 작업과 수행 방법에 대한 사양입니다. 테스트를 통해 소프트웨어가 요구 사항을 충족하는지 확인하고 소프트웨어가 요구 사항에 따라 구현되었는지 확인할 수 있습니다.
참조 = =
* 1 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 10페이지
* 2 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 11페이지
* 3 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 12페이지
* 4 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 13페이지
* 5 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, p. 97
* 6 ISTQB 공인 시험관 기초 레벨 강의 계획서 v4.0, 2023, 98페이지
* 7 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 14페이지
* [8] ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 15페이지
* [9] ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 16페이지
* [10] ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 17페이지
* [11] ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 18페이지
* [12] ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 19페이지

비밀번호 길이에 적용된 두 값 경계 값 분석의 올바른 결과는 옵션 D로 표시된 테스트 사례 집합입니다.
경계 값 분석은 최소값과 최대값 또는 경계 바로 위와 아래의 값과 같이 등가 파티션의 경계에 있는 값에 초점을 맞추는 테스트 설계 기법입니다. 두 값 경계 값 분석은 각 경계에 대해 유효한 값과 유효하지 않은 값을 나타내는 두 값을 사용합니다. 예를 들어 유효한 값 범위가 4에서 7 사이인 경우 하한 경계에 대한 두 값은 3과 4이고 상한 경계에 대한 두 값은 7과 8입니다. 옵션 D의 테스트 케이스에서는 이러한 값을 비밀번호 길이에 사용하는 동시에 숫자 1개, 대문자 1개, 소문자 1개 이상 포함 등 비밀번호의 다른 요건도 충족합니다. 옵션 D의 테스트 케이스는 다음과 같습니다:
1RhT: 유효한 4자 비밀번호입니다.
rSp53: 유효한 5자 비밀번호입니다.
3N3e10: 유효한 6자 비밀번호입니다.
8sBdby: 유효하지 않은 8자 비밀번호 다른 옵션의 테스트 케이스는 비밀번호 길이의 경계에 있지 않은 값을 사용하거나 비밀번호의 다른 요구 사항을 충족하지 않기 때문에 올바르지 않습니다. 예를 들어 옵션 A의 테스트 케이스는 다음과 같습니다:
1xA: 유효하지 않지만 대문자가 포함되지 않은 3자 비밀번호 aB11: 유효한 4자 비밀번호 Pq1ZZab: 유효한 7자 비밀번호
7iDD0a1x: 유효하지 않은 참조인 8자 비밀번호입니다: ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 소스 및 문서:
ISTQB® 공인 테스터 기초 레벨 강의 계획서 v4.0, 2.2.1장, 블랙박스 테스트 설계 기법1 ISTQB® 테스트 용어집 v4.0, 경계값 분석, 동등성 파티션2

테스트할 테스트 대상의 기능과 테스트에서 제외되는 기능은 일반적으로 테스트 계획에 포함되는 정보를 나타내며, 주어진 테스트 계획에서는 언급된 다른 두 섹션보다는 '테스트 범위'에 명시될 가능성이 높습니다. 테스트 범위는 테스트 항목, 테스트할 기능, 테스트하지 않을 기능, 테스트 목표, 테스트 환경, 테스트 리소스, 테스트 가정, 테스트 위험 등과 같은 테스트 활동의 경계와 한계를 정의합니다. 테스트 범위는 테스트에 포함되는 항목과 제외되는 항목에 대한 공통된 이해를 확립하고 이해관계자 간의 모호함, 혼동 또는 오해를 방지하는 데 도움이 됩니다. 다른 두 섹션인 '테스트 커뮤니케이션'과 '이해관계자'도 테스트 계획의 중요한 부분이지만 테스트 대상의 기능을 직접 다루지는 않습니다. 테스트 커뮤니케이션에서는 테스트 진행 상황, 상태, 문제 및 결과에 대한 커뮤니케이션 및 보고의 방법, 빈도 및 책임에 대해 설명합니다. 이해관계자는 테스트 관리자, 테스트 팀, 프로젝트 관리자, 개발자, 고객, 사용자 등 테스트 활동에 관여하거나 영향을 받는 사람들의 역할과 책임을 식별합니다. 참조: ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 소스 및 문서:
ISTQB® 공인 테스터 기초 레벨 강의 계획서 v4.0, 2.1.1장, 테스트 계획1 ISTQB® 테스트 용어집 v4.0, 테스트 계획, 테스트 범위2

설명
제품 위험은 결함, 장애, 요구 사항 또는 표준 미준수 등 소프트웨어 제품의 품질에 영향을 미치는 위험이므로 이 답이 정답입니다. 프로젝트 위험은 지연, 비용 초과, 기술 격차 또는 범위 변경과 같이 프로젝트의 일정, 예산, 리소스 또는 범위에 영향을 미치는 위험입니다. 이 경우 [I] 및 [IV]는 품질 속성인 소프트웨어 제품의 접근성 및 보안과 관련된 제품 위험입니다. [II] 및 [III]은 프로젝트 요소인 납기 및 테스트 팀의 테스트 자동화 기술과 관련된 프로젝트 위험입니다. 참조: ISTQB 테스트 용어집 v4.0, ISTQB 기초 수준 강의 계획서 v4.0, 섹션 2.1.1.1.

코드 내의 모든 의사 결정에 대해 적어도 하나의 의사 결정 결과를 실행하면 전체 분기 커버리지를 달성할 수 있으며, 이는 코드의 제어 흐름에서 모든 분기가 테스트 케이스에 의해 적어도 한 번 이상 실행되어야 하는 테스트 커버리지 기준입니다. 브랜치는 하나의 시작점과 하나의 종료점이 있는 기본 코드 블록이며, 결정은 if-then-else 문, 스위치 케이스 문, 루프 문 등과 같이 제어 흐름이 둘 이상의 방향을 취할 수 있는 코드의 한 지점입니다. 결정 결과는 결정에서 취할 수 있는 가능한 경로입니다(예: then 분기 또는 else 분기, case 분기 또는 기본 분기, 루프 본문 또는 루프 종료 등). 다른 문은 거짓입니다:
* 전체 분기 커버리지를 달성하는 데 필요한 최소 테스트 케이스 수는 일반적으로 코드의 모든 실행 가능한 문이 테스트 케이스에 의해 적어도 한 번 이상 실행되어야 하는 테스트 커버리지 기준인 전체 문 커버리지를 달성하는 데 필요한 테스트 케이스 수보다 높습니다. 이는 분기 커버리지가 문 커버리지보다 더 강력한 기준이기 때문인데, 이는 분기 커버리지가 문 커버리지를 의미하지만 그 반대는 아니기 때문입니다. 예를 들어, 단일 테스트 케이스로 if-then-else 문에 대한 전체 문 커버리지를 달성할 수 있지만, 전체 분기 커버리지를 달성하려면 then 분기와 else 분기를 모두 실행해야 하므로 두 개의 테스트 케이스가 필요합니다.
* 무조건 분기는 어떤 결정에 의존하지 않고 항상 실행되는 분기(예: goto 문, break 문, return 문 등)이므로 전체 분기 커버리지가 달성된 경우 코드 내의 모든 무조건 분기가 반드시 실행되지 않은 것은 아닙니다.
무조건 분기는 코드의 제어 흐름에서 다른 경로를 나타내지 않으므로 분기 커버리지 기준의 일부가 아닙니다. 그러나 코드에서 실행 가능한 문이므로 문 커버리지 기준의 일부입니다.
* 결정 테이블은 여러 조건과 해당 동작 간의 논리적 관계를 표 형식으로 나타내는 테스트 설계 기법이기 때문에 전체 분기 커버리지가 달성된 경우, 결정 테이블의 모든 조건 조합이 반드시 실행된 것은 아닙니다. 의사 결정 테이블은 각 조건이 참 또는 거짓, 예 또는 아니오 등과 같이 두 개 이상의 가능한 값을 가질 수 있으므로 코드의 의사 결정 결과 수보다 더 많은 조건 조합을 가질 수 있습니다. 예를 들어 조건이 4개인 의사 결정 테이블에는 16개의 조건 조합이 있을 수 있지만 해당 코드에는 통과 또는 실패와 같은 두 가지 의사 결정 결과만 있을 수 있습니다. 의사 결정 테이블의 모든 조건 조합을 실행하려면 코드에서 가능한 모든 조건 결과 조합이 테스트 케이스에 의해 적어도 한 번 이상 실행되어야 하는 조건 조합 커버리지와 같은 더 강력한 테스트 커버리지 기준이 필요합니다. 참조: ISTQB 공인 테스터 기초 수준(CTFL) v4.0 소스 및 문서:
* ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2.3.1장, 소프트웨어 구조에 따른 테스트 범위 기준
* ISTQB 테스트 용어집 v4.0, 분기 커버리지, 문 커버리지, 분기, 결정, 결정 결과, 무조건 분기, 결정 테이블, 조건 조합 커버리지

경계 값 분석에는 파티션 간 경계에서 테스트하는 작업이 포함됩니다. 테스트하기에 가장 효율적인 경계 값은 입력 범위의 가장자리에 있는 값입니다:
* 최소값(9) 바로 아래
* 최소값(10)
* 최소값(11) 바로 위
* 최대값(4999) 바로 밑에 있습니다.
* 최대값(5000)
* 최대값(5001) 바로 위
이러한 값을 테스트하면 프로그램이 유효한 입력 시나리오와 유효하지 않은 입력 시나리오를 모두 포함하여 경계를 올바르게 처리하는지 확인할 수 있습니다.
양식 상단
양식 하단

오류 추측은 테스터의 경험과 직관을 사용하여 오류, 결함 및 실패가 발생했거나 발생할 가능성이 있는 위치를 예측하고 이를 노출하기 위한 테스트 케이스를 설계하는 테스트 설계 기법이므로 이 답은 정답입니다. 오류 추측은 시스템 또는 구성 요소의 복잡성, 시스템 또는 구성 요소의 알려진 또는 의심되는 약점, 이전 결함 이력, 도메인 또는 기술에서 흔히 발생하는 오류 유형 등의 요소를 기반으로 할 수 있습니다. 오류 추측은 다른 보다 체계적이거나 공식적인 기법을 보완하는 기법으로 사용하거나 이를 적용할 정보나 시간이 부족할 때 사용할 수 있습니다. 참조: ISTQB 테스트 용어집 v4.0, ISTQB 기초 수준 강의 계획서 v4.0, 섹션 2.3.2.5

설명
선택한 소프트웨어 개발 모델에 관계없이 적용해야 할 좋은 테스트 관행을 언급하는 문장은 옵션 D로, 조기 테스트 원칙을 활용하기 위해 가능한 한 빨리 테스터가 작업 제품 리뷰에 참여해야 한다는 내용입니다. 작업 제품 리뷰는 요구 사항, 디자인, 코드, 테스트 케이스 등과 같은 소프트웨어 개발 프로세스의 작업 제품을 작성자의 유무에 관계없이 한 명 이상의 리뷰어가 결함, 위반 또는 개선 사항을 식별하기 위해 검사하는 정적 테스트 기법입니다. 테스터가 작업 제품 리뷰에 참여하면 테스트 품질, 테스트 효율성 및 테스트 커뮤니케이션을 개선하는 등 테스트 프로세스에 다양한 이점을 제공할 수 있습니다. 조기 테스트 원칙에 따르면 테스트 활동은 소프트웨어 개발 수명 주기에서 가능한 한 일찍 시작해야 하며 수명 주기 내내 반복적이고 지속적으로 수행되어야 합니다. 조기 테스트 원칙을 적용하면 결함을 더 쉽고 저렴하고 빠르게 수정할 수 있는 초기 단계에서 결함을 예방, 발견 및 제거할 수 있을 뿐만 아니라 테스트 프로세스의 위험, 비용 및 시간을 줄이는 데 도움이 될 수 있습니다. 다른 옵션은 선택한 소프트웨어 개발 모델에 관계없이 적용해야 하는 좋은 테스트 관행이 아니라 테스트 활동의 상황과 목표에 따라 테스트에 적용하거나 적용하지 않을 수 있는 특정 테스트 관행입니다:
테스트는 코드가 작성되기 전에 실행 가능한 형식으로 작성되어야 하며 코딩을 유도하는 실행 가능한 사양으로 작동해야 합니다: 이는 개발자가 소스 코드를 작성하기 전에 자동화된 단위 테스트를 작성한 다음 테스트가 통과될 때까지 코드를 리팩터링하는 소프트웨어 개발 및 테스트 접근 방식인 테스트 중심 개발과 관련된 특정 테스트 관행입니다.
테스트 중심 개발은 코드의 품질, 디자인 및 유지보수성을 개선하고 개발자에게 빠른 피드백과 지침을 제공하는 데 도움이 될 수 있습니다. 그러나 테스트 중심 개발은 요구 사항이 불분명하거나 불안정하거나 복잡한 경우, 테스트 자동화 도구나 기술을 사용할 수 없거나 적절하지 않은 경우, 테스트 목표나 수준이 단위 테스트와 일치하지 않는 경우 등과 같은 일부 상황이나 상황에서는 테스트에 적합하지 않거나 효과적이지 않을 수 있으므로 선택한 소프트웨어 개발 모델에 관계없이 적용할 수 있는 좋은 테스트 관행이 아닙니다.
테스트 레벨은 한 레벨의 종료 기준이 다음 레벨의 진입 기준의 일부가 되도록 정의되어야 합니다: 이는 소프트웨어 개발 및 테스트 활동이 잘 정의된 단계, 결과물 및 종속성을 가지고 선형적이고 순차적인 순서로 수행되는 워터폴 모델, V 모델 또는 W 모델과 같은 순차적 소프트웨어 개발 모델과 연관된 특정 테스트 관행입니다. 테스트 수준은 구성 요소 테스트, 통합 테스트, 시스템 테스트 및 수락 테스트와 같이 소프트웨어 시스템의 통합 수준에 해당하는 테스트 단계입니다. 테스트 레벨에는 명확하고 측정 가능한 진입 기준과 종료 기준이 있어야 하며, 이는 테스트 레벨을 시작하거나 완료하기 전에 충족해야 하는 조건입니다. 순차적 소프트웨어 개발 모델에서 한 테스트 레벨의 종료 기준은 일반적으로 다음 테스트 레벨의 진입 기준의 일부가 되어 소프트웨어 시스템이 다음 테스트 레벨을 위한 준비와 안정성을 보장합니다. 그러나 스크럼, 칸반 또는 XP와 같은 애자일 소프트웨어 개발 모델에서처럼 소프트웨어 개발 및 테스트 활동이 반복적이고 점진적인 순서로 수행되고 변경, 피드백 및 조정이 빈번한 경우, 테스트 레벨이 명확하게 정의되거나 구분되지 않는 경우, 테스트 레벨이 병렬 또는 동시에 수행되는 경우 등과 같이 일부 상황이나 상황에서는 테스트에 적절하거나 유연하거나 효율적이지 않을 수 있으므로 선택한 소프트웨어 개발 모델에 관계없이 적용하기 좋은 테스트 관행이 아닙니다.
테스트 목표는 모든 테스트 수준에서 동일해야 하지만, 다양한 수준에서 설계된 테스트의 수는 크게 다를 수 있습니다: 이는 나선형 모델, 점진적 모델 또는 프로토타이핑 모델과 같이 소프트웨어 개발 및 테스트 활동이 유사한 단계, 결과물 및 프로세스를 사용하여 주기적이고 반복적인 방식으로 수행되는 통일된 소프트웨어 개발 모델과 관련된 특정 테스트 관행입니다. 테스트 목표는 테스트의 목표 또는 목적을 의미하며 테스트 수준, 테스트 유형, 테스트 기술, 테스트 환경, 테스트 이해 관계자 등에 따라 달라질 수 있습니다. 테스트 목표는 테스트 기준, 테스트 범위, 테스트 품질, 테스트 위험, 테스트 비용, 테스트 시간 등의 측면에서 정의할 수 있습니다. 테스트 목표는 구체적이고, 측정 가능하며, 달성 가능하고, 관련성이 있고, 시간 제한이 있어야 하며, 프로젝트 목표 및 품질 특성과 일치해야 합니다. 획일적인 소프트웨어 개발 모델에서는 테스트 프로세스가 각 주기 또는 반복마다 반복되고 테스트의 초점, 범위 및 관점이 비슷하기 때문에 테스트 목표가 모든 테스트 레벨에서 동일할 수 있습니다. 그러나 순차적 소프트웨어 개발 모델에서와 같이 소프트웨어 개발 및 테스트 활동이 단계, 결과물, 종속성이 다른 계층적 및 모듈식 방식으로 수행되는 경우와 같이 일부 상황이나 상황에서는 테스트에 적절하지 않거나 현실적이지 않거나 효과적이지 않을 수 있으므로 선택한 소프트웨어 개발 모델에 관계없이 적용하는 것은 좋은 테스트 관행이 아닙니다, 워터폴 모델, V 모델 또는 W 모델과 같이 테스트 목표가 구성 요소 테스트, 통합 테스트, 시스템 테스트 및 수락 테스트와 같이 테스트 수준에 따라 달라지거나 스크럼, 칸반 또는 XP와 같은 애자일 소프트웨어 개발 모델처럼 피드백, 학습 또는 테스트 프로세스의 적응에 따라 테스트 목표가 변경되는 경우 등과 같은 맥락이나 상황에 따라 테스트가 수행될 수 있습니다.참조: ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 소스 및 문서:
1, 테스트와 소프트웨어 개발 수명주기1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 1.1.1장, 테스트 원칙1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 1.2.1장, 테스트 원칙1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 1.2장.2, 테스트 정책, 전략 및 테스트 접근 방식1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 1.3.1장, 소프트웨어 개발 라이프사이클에서의 테스트1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 2.1.1장, 테스트 계획1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 2.1장.2, 테스트 모니터링 및 제어1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 2.1.3장, 테스트 분석 및 설계1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 2.1.4장, 테스트 구현1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 2.1장.5, 테스트 실행1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 2.1.6장, 테스트 종료1 ISTQB 테스트 용어집 v4.0, 작업 제품 검토, 정적 테스트, 초기 테스트, 테스트 중심 개발, 테스트 수준, 진입 기준, 종료 기준, 테스트 목표, 테스트 근거, 테스트 범위, 테스트 품질, 테스트 위험, 테스트 비용, 테스트 시간2

테스트에서 전체 팀 접근 방식은 테스터뿐만 아니라 모든 팀원이 테스트에 대한 책임을 공유한다는 것을 의미합니다. 이 개념은 협업과 품질에 대한 집단적 소유권을 핵심 원칙으로 삼는 애자일 방법론에서 강조됩니다. 개발자, 비즈니스 분석가, 테스터를 포함한 각 팀원은 테스트 프로세스에 기여하여 처음부터 제품에 품질이 내장되도록 합니다.
참조:
* 테스트에 대한 팀의 공동 책임을 설명하는 '전체 팀 접근 방식'에 대한 ISTQB CTFL 강의 계획서 V4.0, 섹션 1.5.2를 참조하세요.

추적성은 요구 사항, 설계, 위험 등과 같은 테스트 기준의 항목과 테스트 케이스, 테스트 결과, 결함 등과 같은 테스트 아티팩트 간의 관계를 추적할 수 있는 기능입니다. 추적성은 테스트 커버리지, 테스트 품질, 테스트 효율성 및 테스트 커뮤니케이션을 개선하는 등 테스트 프로세스에 다양한 이점을 제공할 수 있습니다. 그러나 테스트 기준과 테스트 결과물 간의 추적성 유지의 가치에 대해 주어진 진술이 모두 참인 것은 아닙니다. 사실이 아닌 진술은 옵션 C로, 다양한 수준에서 설계된 테스트의 수는 크게 다를 수 있지만 테스트 목표는 모든 테스트 수준에서 동일해야 한다고 말합니다. 테스트 목표는 테스트의 목표 또는 목적이며 테스트 수준, 테스트 유형, 테스트 기술, 테스트 환경, 테스트 이해 관계자 등에 따라 달라질 수 있으므로 이 진술은 거짓입니다. 테스트 목표는 테스트 기준, 테스트 범위, 테스트 품질, 테스트 위험, 테스트 비용, 테스트 시간 등의 측면에서 정의할 수 있습니다. 테스트 목표는 구체적이고, 측정 가능하며, 달성 가능하고, 관련성이 있고, 시간 제한이 있어야 하며, 프로젝트 목표 및 품질 특성과 일치해야 합니다. 구성 요소 테스트, 통합 테스트, 시스템 테스트, 수락 테스트 등 테스트 수준마다 테스트의 초점, 범위, 관점이 다르기 때문에 테스트 목표는 모든 테스트 수준에서 동일해서는 안 됩니다. 테스트 기준과 테스트 작업 결과물 간의 추적성을 유지하는 것의 가치에 대한 다른 진술은 다음과 같이 사실입니다:
추적성은 테스트 기준 항목의 변경이 해당 테스트에 미치는 영향을 평가하는 데 유용할 수 있습니다: 추적성은 새로운 요구 사항, 수정된 설계, 수정된 위험 등과 같은 테스트 기준의 변경으로 인해 영향을 받는 테스트를 식별하고 테스트를 업데이트, 재실행 또는 재평가하는 데 필요한 조치를 결정하는 데 도움이 될 수 있기 때문에 이 진술은 사실입니다. 추적성은 또한 변경 사항을 구현하는 데 필요한 노력, 비용 및 시간을 추정하고 소프트웨어 시스템에 미치는 영향을 검증하는 데 도움이 될 수 있습니다.
추적성은 해당 테스트에서 얼마나 많은 테스트 기준 항목을 다루는지 결정하는 데 유용할 수 있습니다: 추적성은 테스트 케이스에 의해 테스트 기준이 실행되는 정도인 테스트 커버리지를 측정하는 데 도움이 될 수 있기 때문에 이 진술은 사실입니다. 추적성은 어떤 테스트 기준 항목이 테스트에서 커버되는지, 부분적으로 커버되는지 또는 커버되지 않는지 식별하고 테스트 프로세스의 적절성, 완전성 및 효과를 평가하는 데 도움이 될 수 있습니다. 또한 추적성은 테스트 범위의 격차, 중복 또는 중복을 식별하고 테스트 케이스의 우선 순위를 지정, 최적화 또는 개선하는 데 도움이 될 수 있습니다.
추적성은 테스트 감사에 필요한 요구 사항을 지원하는 데 유용할 수 있습니다: 추적성은 테스트 활동, 결과 및 결과에 대한 증거, 문서화 및 정당성을 제공하는 데 도움이 될 수 있기 때문에 이 진술은 사실입니다. 추적성은 테스트 프로세스가 소프트웨어 시스템, 프로젝트 또는 조직에 적용되는 표준, 규정, 정책 및 모범 사례를 따르고 있음을 입증하는 데 도움이 될 수 있습니다. 또한 추적성은 테스트 프로세스가 사용자와 이해 관계자의 기대, 요구 및 만족도를 충족하는지 확인하는 데 도움이 될 수 있습니다. 참조: ISTQB 공인 테스터 기초 수준(CTFL) v4.0 소스 및 문서:
1, 테스트 정책, 전략 및 테스트 접근 방식1 ISTQB® 공인 테스터 기초 레벨 강의안 v4.0, 1.2.2장, 테스트 정책, 전략 및 테스트 접근 방식1 ISTQB® 공인 테스터 기초 레벨 강의안 v4.0, 2.1.1장, 테스트 계획1 ISTQB® 공인 테스터 기초 레벨 강의안 v4.0, 2.1.2, 테스트 모니터링 및 제어1 ISTQB® 공인 시험관 기초 레벨 강의안 v4.0, 2.1.3장, 테스트 분석 및 설계1 ISTQB® 테스트 용어집 v4.0, 추적성, 테스트 근거, 테스트 아티팩트, 테스트 목표, 테스트 수준, 테스트 범위, 테스트 품질, 테스트 위험, 테스트 비용, 테스트 시간2

테스트의 왼쪽 이동은 소프트웨어 개발 수명 주기에서 가능한 한 빨리 테스트 활동을 수행하여 결함을 더 빠르고 저렴하게 찾아 수정하고 소프트웨어 제품의 품질을 개선하는 것을 목표로 하는 접근 방식이므로 이 답은 정답입니다. 지속적 통합은 자동화된 도구와 프로세스를 사용하여 소프트웨어 구성 요소를 하루에 여러 번씩 자주 통합하고 테스트하는 것으로, 테스트의 시프트 레프트 방식을 지원하는 관행입니다. 지속적 통합은 결함 발생과 발견 사이의 시간을 단축하여 결함 수정에 드는 비용과 소프트웨어 제품의 기능이나 성능에 영향을 줄 수 있는 결함 누적 위험을 줄일 수 있습니다. 참조: ISTQB 기초 수준 강의 계획서 v4.0, 섹션 3.1.1.3, 섹션 3.2.1.3

테스트 중심 개발(TDD)에는 리팩터링이 핵심 관행으로 포함되어 있습니다. 테스트를 작성하고 해당 테스트를 만족하는 코드를 작성한 후에는 기능을 변경하지 않고 코드와 테스트 품질을 개선하기 위해 리팩터링을 수행합니다. 이 지속적인 프로세스는 깔끔하고 효율적이며 관리하기 쉬운 코드를 유지하는 데 도움이 됩니다.
참조:
* ISTQB CTFL 강의 계획서 4.0, 2.1.3장, 25페이지: TDD, ATDD 및 BDD 사례

설명
장애는 결함뿐만 아니라 환경 조건에 의해서도 발생할 수 있습니다. 장애란 소프트웨어 시스템이 필요한 기능을 수행하지 않거나 예상 동작에 따라 기능을 잘못 수행하는 경우를 말합니다. 결함은 소프트웨어 시스템의 결함 또는 요구 사항이나 사양에서 벗어나는 것으로 장애를 일으킬 수 있습니다. 그러나 하드웨어 오작동, 네트워크 중단, 정전, 호환되지 않는 구성 등과 같은 환경 조건으로 인해 일부 장애가 발생할 수 있으므로 모든 장애가 결함으로 인해 발생하는 것은 아닙니다. 환경 조건은 소프트웨어 시스템의 작동에 영향을 미치는 요소이지만 소프트웨어 시스템 자체의 일부가 아닙니다. 다른 진술은 거짓입니다:
결함이 항상 장애를 일으키는 것은 아니지만 버그는 항상 장애를 일으킵니다. 결함은 소프트웨어 시스템의 입력, 출력, 상태 또는 시나리오에 따라 장애를 일으킬 수도 있고 그렇지 않을 수도 있으며 버그는 결함의 다른 용어일 뿐이므로 결함과 장애를 일으킬 가능성은 동일합니다. 예를 들어, 거의 사용되지 않는 기능이나 코드의 숨겨진 브랜치의 결함은 장애를 일으키지 않을 수 있지만 자주 사용되는 기능이나 코드의 중요한 경로의 결함은 장애를 자주 일으킬 수 있습니다. 버그는 결함과 다른 개념이 아니라 결함의 구어적 용어의 동의어이므로 결함과 정의 및 의미가 동일합니다.
결함으로 인해 오류가 발생할 수 있으며, 오류가 발생하면 항상 오류가 발생합니다. 오류는 장애의 결과가 아니라 결함의 원인이기 때문에 이 진술은 잘못된 것입니다. 오류는 오타, 논리 결함, 요구 사항 오해 등과 같이 소프트웨어 시스템에 결함을 발생시키는 사람의 행동이나 실수를 말합니다. 오류는 소프트웨어 시스템에서 관찰할 수 있는 것이 아니라 코드, 디자인, 문서 등과 같은 인간의 마음이나 인간의 작업 결과물에서 관찰할 수 있습니다. 실패는 오류의 원인이 아니라 오류의 결과인 결함의 결과입니다. 예를 들어 코드의 오류로 인해 소프트웨어 시스템에 결함이 발생하여 소프트웨어 동작에 장애가 발생할 수 있습니다.
버그는 컴포넌트 테스트 중에 발견되는 결함이고, 실패는 더 높은 테스트 수준에서 발견되는 결함입니다.
버그와 장애는 서로 다른 유형의 결함이 아니라 결함 및 그 증상을 나타내는 다른 용어이기 때문에 이 진술은 잘못된 것입니다. 앞서 언급했듯이 버그는 결함의 다른 말일 뿐이며, 장애는 결함으로 인해 소프트웨어 시스템이 예상대로 작동하지 않는 현상을 말합니다.
버그와 오류는 컴포넌트 테스트나 상위 테스트 수준뿐만 아니라 모든 테스트 수준에서 발견될 수 있습니다. 테스트 수준은 구성 요소 테스트, 통합 테스트, 시스템 테스트 및 수락 테스트와 같이 소프트웨어 시스템의 통합 수준에 해당하는 테스트 단계입니다. 테스트 목표, 테스트 기준, 테스트 기술 및 테스트 환경에 따라 모든 테스트 수준에서 결함 및 실패가 발생하고 감지될 수 있습니다. 참조: ISTQB 공인 테스터 기초 수준(CTFL) v4.0 소스 및 문서:
ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 1.1.2장, 테스트 및 품질1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 1.2.1장, 테스트 원칙1 ISTQB 공인 테스터 기초 레벨 강의안 v4.0, 1.3.1장, 소프트웨어 개발 수명 주기에서의 테스트1 ISTQB 테스트 용어집 v4.0, 실패, 결함, 버그, 환경 조건, 오류, 테스트 수준2

소프트웨어 회사의 사고 프로세스는 각 아티팩트를 하나의 검토 방법만을 사용하여 검토할 수 있고 검토 방법은 아티팩트의 중요도에만 의존한다고 가정하기 때문에 잘못된 것입니다. 이는 다양한 검토 방법의 장점과 한계, 검토의 맥락과 목적, 여러 검토를 통해 얻을 수 있는 피드백 및 개선 기회를 고려하지 않는 단순하고 경직된 접근 방식입니다. CTFL 4.0 강의 계획서에 따르면 검토 방법의 선택은 아티팩트의 유형과 세부 수준, 검토자의 가용성 및 역량, 시간 및 예산 제약, 예상되는 결함 및 위험, 원하는 결과 및 품질 기준 등 여러 요소를 기반으로 이루어져야 합니다. 또한 개발 수명 주기의 여러 단계에서 서로 다른 검토 방법을 사용하여 동일한 아티팩트를 검토하여 아티팩트가 변화하는 요구 사항, 표준 및 이해 관계자의 기대치를 충족하는지 확인할 수 있습니다. 예를 들어, 요구 사항 사양은 사용자와 개발자로부터 초기 피드백을 얻기 위해 워크스루와 같은 비공식 검토 방법을 사용하여 검토한 다음 사양의 완전성, 정확성 및 일관성을 확인하기 위해 검사와 같은 공식 검토 방법을 사용하여 검토할 수 있습니다. 따라서 소프트웨어 회사는 고정적이고 임의적인 규칙을 따르기보다는 다양한 아티팩트에 대한 검토 방법을 선택하고 적용하는 데 있어 보다 유연하고 상황에 맞는 접근 방식을 채택해야 합니다. 참조 = CTFL 4.0 강의 계획서, 섹션 3.2.1, 31-32페이지, 섹션 3.2.2, 33-34페이지, 섹션 3.2.3, 35-36페이지.

테스트 피라미드는 테스트의 다양한 수준과 상대적인 수량을 설명하는 개념입니다. 피라미드는 높은 수준의 엔드투엔드 테스트보다 낮은 수준의 단위 테스트가 더 많아야 함을 나타냅니다. 피라미드 위로 올라갈수록 각 테스트의 범위가 증가하므로 일반적으로 각 상위 레벨 테스트는 프로덕션 코드의 더 많은 부분을 다룹니다.
* 단위 테스트: 피라미드의 기초를 형성하고 개별 코드 단위를 다룹니다. 작성 및 실행이 빠르기 때문에 많이 사용됩니다.
* 서비스/통합 테스트: 피라미드의 중앙에 앉아 통합된 단위 또는 서비스 간의 상호 작용을 다룹니다.
* UI/엔드투엔드 테스트: 피라미드의 최상단에 있는 이 테스트는 전체 워크플로와 사용자 상호 작용을 다루기 때문에 복잡성과 실행 시간으로 인해 그 수가 적습니다.
옵션 B는 테스트 피라미드의 계층이 높을수록 단위 테스트에 비해 더 광범위한 기능과 상호 작용을 포함하므로 단일 자동화된 테스트가 더 많은 프로덕션 코드를 다루는 경향이 있다는 것을 정확하게 설명합니다.

설명
이 시나리오와 관련된 전체 의사 결정 테이블을 커버하는 데 필요한 최소 테스트 케이스 수는 6개입니다.
이는 결정 테이블에 4개의 조건(고객 유형 및 판매 금액)과 4개의 액션(보너스 비율)이 있기 때문입니다. 조건에는 각각 2개의 가능한 값(기본 또는 프리미엄, G1, G2 또는 G3)이 있으므로 총 조합 수는 2 x 2 x 2 x 2 = 16개입니다. 그러나 일부 조합은 모순되거나 불가능하기 때문에 모든 조합이 유효한 것은 아닙니다. 예를 들어, 300유로 미만과 2000유로 이상의 판매가 동시에 이루어질 수는 없습니다. 따라서 유효하지 않은 조합은 제거하고 유효한 조합만 유지해야 합니다.
유효한 조합은 다음과 같습니다:
고객 유형
판매 금액
보너스 비율
기본
G1
3%
기본
G2
5%
기본
G3
7%
프리미엄
G1
5%
프리미엄
G2
7%
프리미엄
G3
10%
이 6가지 조합은 조건과 동작의 가능한 모든 값을 포함하며, 전체 의사 결정 테이블을 커버하는 데 필요한 최소 테스트 케이스 수입니다.
참조: ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 소스 및 문서,

테스트할 테스트 대상의 기능과 테스트에서 제외되는 기능은 일반적으로 테스트 계획에 포함되는 정보를 나타내며, 주어진 테스트 계획에서는 언급된 다른 두 섹션보다는 '테스트 범위'에 지정될 가능성이 높습니다. 테스트 범위는 테스트 항목, 테스트할 기능, 테스트하지 않을 기능, 테스트 목표, 테스트 환경, 테스트 리소스, 테스트 가정, 테스트 위험 등과 같은 테스트 활동의 경계와 한계를 정의합니다. 테스트 범위는 테스트에 포함되는 항목과 제외되는 항목에 대한 공통된 이해를 확립하고 이해관계자 간의 모호함, 혼동 또는 오해를 방지하는 데 도움이 됩니다. 다른 두 섹션인 '테스트 커뮤니케이션'과 '이해관계자'도 테스트 계획의 중요한 부분이지만 테스트 대상의 기능을 직접 다루지는 않습니다. 테스트 커뮤니케이션에서는 테스트 진행 상황, 상태, 문제 및 결과에 대한 커뮤니케이션 및 보고의 방법, 빈도 및 책임에 대해 설명합니다. 이해관계자는 테스트 관리자, 테스트 팀, 프로젝트 관리자, 개발자, 고객, 사용자 등 테스트 활동에 관여하거나 영향을 받는 사람들의 역할과 책임을 식별합니다. 참조: ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 소스 및 문서:
* ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2.1.1장, 시험 계획1
* ISTQB 테스트 용어집 v4.0, 테스트 계획, 테스트 범위2