카테고리 ISTQB

상태 전환 테스트는 테스트 케이스가 상태 머신의 상태와 전환을 다루도록 설계된 블랙박스 테스트 기법입니다.
다음과 같은 전환이 있는 상태 모델이 주어집니다:
* 배치됨 -> 생산 중
* 생산 중 -> 취소됨
* 생산 중 -> 배송
* 배송 -> 송장 발행
* 청구 -> 취소
* 취소됨 -> 배치됨
모든 전환을 한 번 이상 포함하려면 6개의 전환을 모두 포함하는 시퀀스를 만들어야 합니다.
옵션 A: 생산 중 -> 취소 -> 배치 -> 생산 중 -> 취소 -> 배치- 배송 -> 송장 발행 및 송장 발행 -> 취소 전환이 누락됩니다.
옵션 B: 생산 중 -> 배송 -> 송장 발행 -> 취소 -> 배치 -> 생산 중- 모든 전환을 포함합니다.
옵션 C: 배치됨 -> 제작 중 -> 배송됨 -> 취소됨 (ISTQB 비영리 협회) (Udemy)sses INVOICED -> 취소됨으로 전환.
옵션 D: 배치됨 -> 취소됨 -> 배치됨 -> 취소됨 -> 배치됨 -> 생산 중 -> 취소됨- 배송됨 -> 발송됨 및 발송됨 -> 취소됨 전환 누락.
이러한 점을 고려할 때 옵션 B는 모든 전환6†소스9†소스를 포함합니다.
참조:
* 공인 테스터 파운데이션 레벨 v4.0
* 10개의 샘플 시험 ISTQB 기초 레벨(CTFL) v4.0

테스트하는 방식과 테스트 대상 제품의 콘텐츠를 일치시켜야 하므로 테스트 기법을 선택해야 합니다. 테스트 기법은 몇 가지 기준이나 규칙에 따라 테스트 케이스를 도출하고 선택하는 방법 또는 프로세스입니다. 소프트웨어 제품의 특성, 기능, 요구 사항, 사양, 위험 등에 따라 각기 다른 테스트 기법이 제품 유형에 적합합니다. 테스트 기법을 선택하면 테스트 케이스가 테스트 대상 제품에 관련성 있고 효과적이며 효율적인지 확인하는 데 도움이 됩니다. 다른 옵션은 테스트 기법을 선택해야 하는 올바른 이유가 아닙니다. 시간 제약은 테스트 기법을 선택하는 요소가 아니라 테스트 활동의 우선 순위를 정하거나 최적화하는 요소입니다. 제품 기능의 전체 범위를 커버하는 것은 테스트 기법 선택의 보장이 아니라 테스트의 목표입니다. 테스트 기법을 선택하는 것은 소프트웨어 테스트에서 일반적인 관행이 아니라 전문적인 기술이자 책임입니다. 검증된 참고 자료: ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거, 31페이지.

컴포넌트 테스트는 테스트 수준입니다. 테스트 수준은 몇 가지 공통된 특성이나 목표에 따라 함께 조직되고 관리되는 테스트 활동 그룹입니다. 테스트 레벨은 테스트 범위 및 대상, 개발 단계 및 모델, 테스트에 관련된 이해 관계자 및 역할 등 다양한 요소에 따라 정의할 수 있습니다. 구성 요소 테스트(단위 테스트 또는 모듈 테스트라고도 함)는 개별 소프트웨어 구성 요소(예: 모듈, 클래스, 함수, 메서드 등)의 기능과 품질을 검증하는 데 중점을 둔 테스트 수준입니다. 구성 요소 테스트는 구성 요소의 유형과 복잡성에 따라 개발자 또는 테스터가 다양한 기술과 도구를 사용하여 수행할 수 있습니다. 다른 옵션은 테스트 레벨이 아닙니다. 통합 테스트는 서로 또는 외부 시스템과 상호 작용하는 소프트웨어 구성 요소 그룹의 기능과 품질을 검증하는 데 중점을 두는 또 다른 테스트 수준입니다. 기능 테스트는 테스트 대상 시스템이 요구 사항이나 사양에 따라 의도한 기능을 수행하는지 확인하는 블랙박스 동적 테스트의 한 유형입니다. 경험 기반 테스트는 테스터의 지식과 직관에 의존하여 유사한 시스템, 기술, 도메인, 위험 등에 대한 경험을 바탕으로 테스트 사례를 도출하고 선택하는 테스트 설계 기법의 한 범주입니다. 검증된 참조: ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거, 19페이지.

100% 문 커버리지를 달성하려면 주어진 의사 코드의 모든 문이 적어도 한 번 이상 실행되도록 테스트 케이스를 설계해야 합니다. 의사 코드를 분석해 보면 두 가지 변수에 기반한 조건이 있음을 알 수 있습니다: 성별과 나이. 모든 문을 다루기 위해서는 신발 크기 변수의 각 할당으로 이어지는 경로를 고려해야 합니다.
* 성별 = 남아, 나이 <= 3(신발 사이즈 할당에 도달하지 못했지만 조건이 평가됨)
* 성별 = 남아, 연령 > 3세 및 연령 < 5세 (신발 사이즈 = 1)
* 성별 = 남아, 나이 >= 5, 나이 < 7 (신발 사이즈 = 2)
* 성별 != 남아, 나이 <= 3(다시, 신발 사이즈 할당에 도달하지 않았지만 조건이 평가됨)
* 성별!= 남아, 나이 > 3 및 나이 < 5 (신발 사이즈 = 0)
* 성별!= 남아, 나이 >= 5 및 나이 < 7 (신발 사이즈 = 1)
그러나 자세히 살펴보면 테스트 1과 4는 신발 크기 할당으로 이어지지 않기 때문에 문 커버리지에 기여하지 않는다는 것을 알 수 있습니다. 따라서 100% 문 커버리지를 달성하려면 4개의 테스트 케이스만 필요하므로 옵션 B가 정답입니다.

이전 시스템과 비교한 새로운 내비게이션 시스템은 사용자와 시스템 간의 높은 수준의 상호 작용을 포함하며 시스템의 예상 동작과 결과가 사용자의 요구와 목표에 기반하기 때문에 사용 사례별 테스트에 가장 적합한 애플리케이션입니다. 사용 사례는 목적지 입력, 경로 선택, 경로 따라가기, 알림 수신 등 새 내비게이션 시스템의 기능 요구 사항을 지정하는 데 도움이 될 수 있습니다. 또한 사용 사례는 성공 및 실패 시나리오, 전제 조건과 후제 조건, 각 사용 사례의 대체 흐름을 정의하여 새 시스템의 정확성과 유용성을 이전 시스템과 비교하는 데 도움이 될 수 있습니다. 또한 사용 사례는 각 사용 사례의 주요 경로와 예외 경로를 포함하는 테스트 사례를 설계 및 실행하고 사용자의 기대치를 충족하는지 검증하는 데 도움이 될 수 있습니다.
다른 옵션은 사용자와 시스템 간의 상호 작용 수준이 높지 않거나 시스템의 예상 동작 및 결과가 사용자의 요구와 목표에 기반하지 않기 때문에 사용 사례별 테스트에 가장 적합한 애플리케이션이 아닙니다. 많은 수의 가입자 매개 변수를 기반으로 월별 요금을 계산하는 데 사용되는 과금 시스템은 대량의 입력 및 출력 데이터 세트를 사용하여 시스템 또는 구성 요소의 기능과 성능을 테스트하는 기술인 데이터 기반 테스트에 더 적합합니다. 새로운 위협을 탐지하고 격리하는 바이러스 백신 패키지의 기능은 테스터의 경험과 직관에 따라 비공식적이고 유연한 접근 방식을 사용하여 시스템 또는 구성 요소의 기능과 보안을 테스트하는 기법인 탐색적 테스트에 더 적합합니다. 멀티미디어(오디오 비디오 기반) 시스템의 새로운 운영체제에 대한 적합성 및 성능은 서로 다른 하드웨어, 소프트웨어 또는 네트워크 환경을 사용하여 시스템 또는 구성 요소의 기능 및 성능을 테스트하는 기법인 호환성 테스트에 의해 테스트하는 것이 더 적합합니다. 참조 = CTFL 4.0 강의 계획서, 섹션 3.1.1, 28-29페이지, 섹션 4.1.1, 44-45페이지, 섹션 4.2.1, 47-48페이지.

이미지의 결정 표에 따르면, 실버 객실을 보유한 프리퍼드 게스트 카드 소지자는 골드 럭셔리(예)로 업그레이드할 수 있는 반면, 객실 유형에 관계없이 프리퍼드 게스트 카드가 아닌 고객은 업그레이드할 수 없습니다(아니오). 따라서 고객 A(실버 객실을 보유한 프리퍼드 게스트 카드 소지자)는 골드 럭셔리로 업그레이드가 제공되고, 고객 B(플래티넘 객실을 보유한 비프리퍼드 게스트 카드 소지자)는 업그레이드가 제공되지 않습니다. 참고 = 답변은 이미지에 제공된 결정 표에서 직접 파생된 것으로, 특정 ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 문서는 참조되지 않았습니다.

회귀 테스트는 이전에 테스트한 소프트웨어가 변경 후에도 여전히 올바르게 작동하는지 확인하는 테스트 유형입니다. 회귀 테스트는 이전에 수정한 결함이 새로운 오류나 부작용을 일으키지 않는지 확인하여 결함의 재발을 방지하는 데 도움이 될 수 있습니다. 회사에 가장 먼저 권장하는 것은 기존 회귀 테스트 스위트가 적절한지 확인하고, 필요한 경우 이를 보강하여 이전에 수정된 결함이 이후의 각 빌드에서 다시 테스트되도록 하는 것입니다. 이렇게 하면 회귀 테스트의 적용 범위와 효과를 개선하고 회귀 결함을 최대한 빨리 발견할 수 있습니다. 기존 테스트 스위트를 자동화하는 것도 회귀 테스트에 필요한 시간과 노력을 줄이는 데 도움이 될 수 있지만 모든 테스트 케이스에 자동화가 실현 가능하거나 비용 효율적이지 않을 수 있으므로 이것이 첫 번째 권장 사항은 아닙니다. 최대 결함이 포함된 제품 모듈을 분석하여 일회성 활동으로 철저하게 테스트하고 결함을 수정하는 것도 결함 밀도를 줄이고 해당 모듈의 품질을 개선하는 데 도움이 될 수 있지만 이전에 수정된 결함이 다시 발생하는 근본 원인을 해결하지 못하기 때문에 첫 번째 권장 사항은 아닙니다. 결함이 가장 많이 포함된 모듈의 개발 및 테스트를 담당하는 팀을 교육하거나 교체하는 것도 기술 또는 성능 향상에 도움이 될 수 있지만 모든 팀에 필요하거나 적절하지 않을 수 있으므로 첫 번째 권장 사항은 아닙니다.
검증된 참고 자료: [ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거], 2장, 19페이지; 4장, 45페이지.

각 사례에 주어진 규칙을 적용하여 정답을 도출할 수 있습니다:
* A는 ST 인증을 받았으며 테스트 경력이 12년으로 10년 이상입니다. 따라서 A는 규칙 중 어느 것과도 일치하지 않으며 결과를 알 수 없습니다.
* B는 ST 인증을 받지 않았으며 테스트 경력이 5년에서 10년 사이인 7년입니다. 따라서 B는 규칙 3과 일치하며 그 결과 액세스가 제한됩니다.
* C는 ST 인증을 받지 않았으며 테스트 경험이 3년으로 5년 미만입니다. 따라서 C는 규칙 중 어느 것과도 일치하지 않으며 결과를 알 수 없습니다.검증된 참조: 이 문제는 논리적 추론에 기반하므로 외부 참조가 필요하지 않습니다.

결함, 테스트 결과 및 기타 테스트 정보에 대한 테스터의 커뮤니케이션은 품질 향상 및 위험 감소와 같은 테스트의 이점을 강조해야 합니다. 이러한 긍정적인 프레임워크는 테스트의 가치를 강화하고 이해관계자가 테스트가 전체 프로젝트 성공에 기여하는 바를 이해하도록 하는 데 도움이 됩니다(ISTQB 비영리 협회).참고:
* ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0:
https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB_CTFL_Syllabus-v4.0.pdf

시스템에서 결함을 찾으려면 시스템 세부 사항을 무시하는 것이 아니라 주의를 기울이고 시스템의 품질, 기능 및 사용성에 어떤 영향을 미치는지 이해해야 합니다. 시스템 세부 사항을 무시하면 중요한 결함을 놓치거나 시스템의 관련 없는 측면을 테스트할 수 있습니다.
결함을 식별하는 것은 특히 제품의 성공에 투자한 개발자나 이해관계자에게 제품에 대한 비판으로 인식될 수 있습니다. 그러나 결함을 식별하는 것은 인신 공격이 아니라 제품을 개선하고 사용자 및 고객의 요구 사항과 기대에 부합하도록 하는 데 도움이 되는 건설적인 피드백입니다.
시스템의 결함을 찾으려면 테스터는 시스템이 실패하거나 오작동하거나 예기치 않게 작동할 수 있는 가능한 방법을 예상하고 탐구해야 하므로 전문적인 비관주의와 호기심이 필요합니다. 직업적 비관주의는 시스템의 품질과 신뢰성에 대해 회의적이고 비판적인 태도를 의미하며, 호기심은 결함의 근본 원인과 결과를 찾는 데 열의와 관심을 갖는 것을 의미합니다.
테스트는 시스템을 만들거나 개선하는 것이 아니라 시스템의 결함과 약점을 찾아 보고하는 것이기 때문에 건설적인 활동이 아니라 파괴적인 활동으로 여겨지는 경우가 많습니다. 그러나 테스트는 시스템의 개선, 검증, 검증 및 최적화에 기여하고 궁극적으로 사용자와 고객의 요구와 기대를 충족하는 고품질의 제품을 제공하는 데 기여하기 때문에 실제로는 건설적인 활동입니다.

"추적 기능은 변경 사항의 영향을 이해하기 어렵게 만들 수 있다"는 진술은 올바르지 않습니다. 테스트의 추적 기능은 실제로 테스트 사례를 요구 사항에 연결하여 변경의 영향을 이해하는 데 도움이 됩니다. 이러한 연결은 요구 사항의 변경 사항이 테스트 케이스에 적절하게 반영되고 검증되도록 하여 변경 사항을 효과적으로 관리하고 개발 중인 시스템 또는 제품의 무결성을 유지하도록 지원합니다(ISTQB 비영리 협회)(ISTQB 메인 웹).참조:
* ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0:
https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB_CTFL_Syllabus-v4.0.pdf
* ISTQB 공식 웹사이트 - CTFL 인증:
https://www.istqb.org/certifications/certified-tester-foundation-level/

ISTQB 공인 테스터 기초 수준(CTFL) v4.0에 따르면 결함의 수명 주기는 일반적으로 발견부터 종결까지의 순서를 따릅니다. 제공된 그림에서는 S0(신규)에서 시작하여 S1(할당됨)으로 이동한 다음 S2(해결됨), 그리고 S3(확인됨)으로 이어집니다. 결함이 해결되지 않으면 다시 열리고(S5) 검증을 위해 다시 돌아갑니다(S3). 확인이 완료되면 닫힘(S4)이 됩니다. 참조: ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 강의 계획서, 섹션 1.4.3, 17페이지.

테스트 관리 도구는 테스트 프로세스의 계획, 실행 및 모니터링을 지원하도록 설계되었습니다.
테스트 케이스 관리, 테스트 실행, 결함 추적 및 테스트 활동 보고를 위한 기능을 제공합니다.
그러나 옵션 C의 문장은 테스트 관리 도구를 테스트 활동 중 시스템의 동작을 모니터링하고 보고하는 것으로 설명하는데, 이는 정확하지 않습니다. 테스트 관리 도구는 테스트 대상 시스템의 동작보다는 테스트 프로세스 자체에 중점을 둡니다.
* 테스트 데이터 준비 도구(A)는 실제로 테스트 실행 중에 사용할 테스트 데이터를 생성하고 관리합니다.
* 테스트 실행 도구(B)는 테스트 케이스의 실행과 예상 결과와 실제 결과의 비교를 자동화합니다.
* 테스트 비교기(D)는 실제 결과와 예상 결과를 비교하여 차이를 강조하는 도구입니다.
따라서 옵션 C는 테스트 관리 도구의 기능을 부정확하게 설명하므로 정답입니다.

유지 관리 테스트는 소프트웨어 제품을 배송한 후 결함을 수정하거나 성능 또는 기타 속성을 개선하기 위해 수행하는 테스트입니다. 유지 관리 테스트는 출시된 소프트웨어 또는 시스템의 수정, 시스템 데이터를 대체 시스템으로 마이그레이션하거나 소프트웨어 또는 시스템을 폐기하는 등 다양한 상황에 의해 트리거될 수 있습니다. 개발 단계에서 유지 관리 요구 사항에 대한 업데이트가 있을 때는 유지 관리 테스트가 실행되지 않으며, 이는 유지 관리 상황이 아니라 개발 프로세스에서 처리해야 하는 변경 요청이기 때문입니다. 검증된 참고 자료: [ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거], 2장, 18~19페이지.

정적 분석 도구는 프로그램을 실행하지 않고 프로그램의 소스 코드를 검사하는 소프트웨어 도구입니다. 구문 오류, 코딩 표준 위반, 보안 취약성, 잠재적 버그 등 다양한 유형의 문제를 탐지할 수 있습니다12. 그러나 정적 분석 도구는 매우 낮은 MTBF(평균 고장 간격)3와 같이 프로그램의 런타임 동작이나 성능에 의존하는 문제는 식별할 수 없습니다. MTBF는 시스템 또는 구성 요소의 신뢰성을 나타내는 척도입니다. 총 작동 시간을 장애 횟수로 나누어 계산합니다. MTBF는 시스템 또는 구성 요소가 예상 수명 동안 얼마나 자주 고장나는지를 반영합니다. 정적 분석 도구는 프로그램을 실행하거나 장애를 관찰하지 않기 때문에 MTBF를 측정할 수 없습니다. 다양한 조건에서 프로그램을 실행하고 장애에 대한 데이터를 수집하는 동적 테스트를 통해서만 MTBF를 추정할 수 있습니다4. 따라서 매우 낮은 MTBF는 정적 분석 도구로는 파악할 수 없는 문제입니다.
무한 루프 가능성, 정의되지 않은 값의 변수 참조, 보안 취약점 등은 정적 분석 도구로 식별할 수 있는 문제입니다. 정적 분석 도구는 프로그램의 제어 흐름과 데이터 흐름을 분석하고 절대 거짓이 될 수 없는 조건을 확인하여 잠재적 무한 루프를 탐지할 수 있습니다5. 정적 분석 도구는 변수의 범위와 초기화를 확인하고 초기화되지 않은 변수의 사용을 보고함으로써 정의되지 않은 값으로 변수를 참조하는 것을 탐지할 수 있습니다6. 정적 분석 도구는 버퍼 오버플로, SQL 삽입, 크로스 사이트 스크립팅, 취약한 암호화 등 안전하지 않은 코드의 일반적인 패턴을 확인하여 보안 취약점을 탐지할 수 있습니다. 참고자료 = 정적 분석이란 무엇인가요? 정적 코드 분석 도구 - Perforce 소프트웨어, 정적 코드 분석의 작동 방식 | Perforce, 정적 코드 분석: 기술, 5가지 장점과 3가지 도전 과제, MTBF란 무엇인가요? 평균 고장 간격 설명 | Perforce, 정적 분석 도구 - 소프트웨어 테스트 MCQ - 커리어라이드, ISTQB_Chapter3 | 퀴즈, [보안 취약점을 위한 정적 코드 분석 | Perforce].

회귀 테스트는 이전에 테스트한 소프트웨어가 변경 후에도 여전히 올바르게 작동하는지 확인하는 테스트 유형입니다. 회귀 테스트는 이전에 수정한 결함이 새로운 오류나 부작용을 일으키지 않는지 확인하여 결함의 재발을 방지하는 데 도움이 될 수 있습니다. 회사에 가장 먼저 권장하는 것은 기존 회귀 테스트 스위트가 적절한지 확인하고, 필요한 경우 이를 보강하여 이전에 수정된 결함이 이후의 각 빌드에서 다시 테스트되도록 하는 것입니다. 이렇게 하면 회귀 테스트의 적용 범위와 효과를 개선하고 회귀 결함을 최대한 빨리 발견할 수 있습니다. 기존 테스트 스위트를 자동화하는 것도 회귀 테스트에 필요한 시간과 노력을 줄이는 데 도움이 될 수 있지만 모든 테스트 케이스에 자동화가 실현 가능하거나 비용 효율적이지 않을 수 있으므로 이것이 첫 번째 권장 사항은 아닙니다. 최대 결함이 포함된 제품 모듈을 분석하여 일회성 활동으로 철저하게 테스트하고 결함을 수정하는 것도 결함 밀도를 줄이고 해당 모듈의 품질을 개선하는 데 도움이 될 수 있지만 이전에 수정한 결함이 다시 발생하는 근본 원인을 해결하지 못하기 때문에 첫 번째 권장 사항은 아닙니다. 결함이 가장 많이 포함된 모듈의 개발 및 테스트를 담당하는 팀을 교육하거나 교체하는 것도 기술이나 성능을 개선하는 데 도움이 될 수 있지만 모든 팀에 필요하거나 적절하지 않을 수 있으므로 첫 번째 권장 사항은 아닙니다. 검증된 참고 자료: [ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거], 2장, 19페이지; 4장, 45페이지.

검수는 공식적인 참여 및 퇴장 기준과 참여자의 역할 및 책임이 정해진 프로세스를 따르는 검토의 한 유형입니다. 검수는 중재자, 작성자, 검토자, 서기 등 다양한 역할을 맡은 동료가 수행할 수 있습니다. 검수에 관한 다음 진술은 사실이 아닙니다:
* B) 검사의 주된 목적은 문제에 대한 해결책을 찾는 것이다. 검사의 주된 목적은 문제에 대한 해결책을 찾는 것이 아니라 작업 결과물에서 결함이나 문제를 찾는 것이므로 이 진술은 사실이 아닙니다. 문제에 대한 해결책을 찾는 것은 일반적으로 작성자나 개발자가 검사 보고서를 받은 후 수행하는 디버깅 또는 문제 해결 활동입니다. 검사에 대한 다음 진술은 사실입니다:
* A) 검사는 작성자가 아닌 훈련된 중재자가 주도할 수 있습니다. 검사에는 검사 프로세스를 이끌고 규칙과 표준을 준수하는지 확인하는 중재자 역할이 필요하기 때문에 이 진술은 사실입니다. 중재자는 편견이나 이해 상충을 피하기 위해 검사 기법에 대한 교육을 받아야 하며 검사 대상 업무 결과물의 작성자가 아니어야 합니다.
* C) 검수는 동료에 의해 수행될 수 있습니다. 검수에는 동료 검토가 포함되므로 이 진술은 사실이며, 이는 작성자와 비슷한 역할이나 전문성을 가지고 있지만 작업 결과물을 만들거나 수정하는 데 직접 관여하지 않은 사람들이 검사 대상 작업 결과물을 평가한다는 의미입니다.
* D) 검사는 진입 및 퇴장 기준이 있는 규칙과 체크리스트에 따라 공식적인 절차를 따라야 합니다.
검사는 6가지 주요 단계로 구성된 공식적인 절차를 따르므로 이 진술은 사실입니다:
계획, 킥오프 회의, 개별 준비, 검토 회의, 재작업 및 후속 조치. 각 단계에는 참가자를 안내하고 일관성과 품질을 보장하기 위해 정의된 규칙과 체크리스트가 있습니다. 또한 각 단계에는 다음 단계로 넘어가기 전에 전제 조건과 목표가 충족되었는지 확인하기 위한 진입 및 종료 기준이 있습니다. 검증된 참고 자료: ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거, 3장, 28~29페이지.

* 노력 추정치는 프로젝트의 예산이 아니라 소프트웨어 제품의 범위, 복잡성, 품질 및 테스트 활동에 따라 달라집니다1. 예산은 노력 추정치의 타당성과 정확성에 영향을 줄 수 있는 제약 조건이지만 노력 추정치를 결정하는 요소는 아닙니다. 노력 추정치는 테스트 활동을 완료하는 데 필요한 작업량으로, 인시, 인일 또는 인월2로 측정됩니다.
* 다른 옵션이 올바른 이유는 다음과 같습니다:
* A. 테스트 노력이 추정되면 테스트 계획 프로세스의 상호 연관된 측면인 리소스를 식별하고 일정을 작성할 수 있습니다3. 리소스는 테스트 활동을 수행하는 데 필요한 인력, 도구, 장비 및 시설입니다4. 일정은 테스트 활동의 시간 프레임과 순서로, 프로젝트 마일스톤 및 마감일에 맞춰 조정됩니다5.
* B. 테스트 중인 제품의 품질은 발견될 수 있는 결함의 수와 심각도, 결함을 수정하기 위해 필요할 수 있는 재작업에 영향을 미치기 때문에 노력 추정치는 정확하지 않을 수 있습니다6. 품질은 소프트웨어 제품이 지정된 요구 사항을 충족하고 사용자와 고객의 요구와 기대를 충족하는 정도입니다7.
* 경험 기반 추정은 테스터 및 기타 프로젝트 이해관계자의 판단과 전문 지식에 의존하여 과거에 수행한 유사한 프로젝트 또는 작업을 기반으로 테스트 노력을 추정하는 추정 기법 중 하나입니다. 경험 기반 추정은 과거 데이터, 공식적인 방법 또는 소프트웨어 제품 및 테스트 활동에 대한 자세한 정보가 부족할 때 유용할 수 있습니다.
참조 = =
* 1 ISTQB 공인 시험관 기초 레벨 강의 계획서 v4.0, 2023, 154페이지
* 2 ISTQB 공인 시험관 기초 레벨 강의 계획서 v4.0, 2023, 155페이지
* 3 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 156 페이지
* 4 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, p. 157
* 5 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, p. 158
* 6 ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 159 페이지
* 7 ISTQB 공인 시험관 기초 레벨 강의 계획서 v4.0, 2023, 16페이지
* [8] ISTQB 공인 시험관 기초 레벨 강의 계획서 v4.0, 2023, p. 160
* [9] ISTQB 공인 테스터 기초 레벨 강의 계획서 v4.0, 2023, 161페이지

테스트 케이스는 특정 목표 또는 테스트 조건에 맞게 개발된 입력 값, 실행 전제 조건, 예상 결과 및 실행 후 조건의 집합입니다. 테스트 케이스는 테스터 또는 테스트 자동화 도구가 따를 수 있는 테스트 실행을 위한 일련의 작업입니다. 테스트 케이스는 테스트 실행에 필요한 테스트웨어를 준비하는 활동인 테스트 구현 활동 중에 지정됩니다. 테스트 케이스는 테스트 실행 중에 얻은 결과를 예상 결과와 비교하기 때문에 실제 결과는 포함하지 않습니다. 테스트 케이스는 테스트 분석 활동 중에 테스트 기준에서 파생되므로 테스트할 항목이나 이벤트를 설명하지 않습니다. 테스트 설계 활동은 테스트해야 하는 테스트 조건이나 목표를 지정하는 활동이므로 테스트 케이스는 테스트 설계 활동 중에 도출되지 않습니다. 검증된 참조: [ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거], 3장, 23-24페이지, 4장, 34페이지.

시스템 테스트는 전체 소프트웨어 제품 또는 시스템의 동작과 품질을 평가하기 위해 수행되는 테스트 수준입니다. 시스템 테스트에는 다음과 같은 다양한 유형의 테스트가 포함될 수 있습니다:
* I) 사용성 테스트: 사용자 관점에서 소프트웨어 제품이나 시스템을 사용하는 것이 얼마나 쉽고 효율적이며 만족스러운지 평가하는 테스트 유형입니다.
* II) 요구사항 기반 시나리오 테스트: 실제 시나리오 또는 워크플로를 실행하여 소프트웨어 제품 또는 시스템이 지정된 요구 사항 또는 사용자 스토리를 충족하는지 검증하는 테스트 유형입니다.
다음 유형의 테스트는 단위 테스트나 통합 테스트와 같은 낮은 수준의 테스트에 더 적합하므로 시스템 테스트에는 포함되지 않습니다:
* III) 코드의 일부를 분리하여 테스트: 개별 소프트웨어 구성 요소 또는 단위를 다른 구성 요소 또는 단위와 분리하여 기능과 품질을 검증하는 테스트 유형입니다.
* IV) API 호출의 올바른 매개변수 순서: API 호출에서 파라미터의 올바른 순서와 형식을 확인하여 애플리케이션 프로그래밍 인터페이스(API)를 통해 서로 통신하는 소프트웨어 구성 요소 또는 단위의 기능과 품질을 검증하는 테스트 유형입니다. 검증된 참조 자료: [ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거], 2장, 20-21페이지; 4장, 34-35페이지.

경험 기반 기법(EBT)은 테스트 엔지니어의 지식, 직관 및 기술을 사용하여 테스트를 설계하고 실행하는 기법입니다. EBT는 테스트 엔지니어가 유사한 기술, 도메인, 애플리케이션 또는 시스템에 대한 이전 경험에서 파생된 테스트를 사용합니다. EBT는 테스트 엔지니어의 다양한 테스트 기법을 구현하는 능력이 아니라 개인적인 판단과 창의력에 기반합니다. EBT는 비경험 기반 테스트가 수행된 후 테스트의 두 번째 단계로 수행되는 것이 아니라 다른 기술에 대한 보완 또는 대안적 접근 방식으로 수행됩니다. EBT는 테스트 엔지니어가 잠재적인 위험, 시나리오 또는 결함을 식별하는 데 도움이 될 수 있으므로 테스트와 애플리케이션 또는 기술 영역 모두에 대한 폭넓고 깊은 지식이 필요합니다. 검증된 참고 자료: [ISTQB 기초 레벨 2018 강의 계획서 학습 가이드 - 스프링거], 5장, 48-49페이지.

테스트 상태 보고서에는 미결 및 종료된 총 결함 수, 실제 소요된 노력, 실행, 실패 및 차단된 테스트 수 등이 포함되어야 합니다. 테스트 상태 보고서는 특정 기간 또는 단계에 대한 테스트 활동의 결과 및 상태에 대한 정보를 제공하는 문서입니다. 테스트 상태 보고서에는 의도된 대상과 목적에 적합하고 정확하며 시의적절한 정보가 포함되어야 합니다. 테스트 상태 보고서에 포함되어야 하는 정보로는 소프트웨어 제품의 결함 추세 및 결함 밀도를 나타낼 수 있는 총 미결 및 종료 결함 수, 테스트 프로세스의 생산성 및 효율성을 나타낼 수 있는 실제 소요 노력, 소프트웨어 제품의 테스트 진행률 및 테스트 범위를 나타낼 수 있는 실행, 실패 및 차단된 테스트의 수 등이 있습니다. 테스트 상태 보고서에는 추정 세부 정보, 결함 보고서 및 영향 분석은 포함되지 않아야 합니다. 추정 세부 정보는 테스트 상태 보고서의 일부가 아니라 테스트 계획 또는 테스트 추정 문서의 일부입니다. 예상 세부 정보는 테스트 활동의 실제 결과나 상태가 아니라 테스트 활동에 대한 예상 시간, 리소스 및 비용에 대한 정보를 제공합니다. 결함 보고서는 테스트 상태 보고서의 일부가 아니라 테스트 중에 발견된 개별 결함에 대한 자세한 정보를 제공하는 별도의 문서입니다. 결함 보고서에는 결함 설명, 결함 심각도, 결함 우선 순위, 결함 상태, 결함 해결 등의 정보가 포함됩니다. 결함 보고서는 테스트 상태 보고서에서 참조하거나 요약할 수 있지만 전체 내용이 포함되지는 않습니다. 영향 분석은 테스트 상태 보고서의 일부가 아니라 위험 평가 또는 우선순위 지정 프로세스의 일부입니다. 영향 분석은 소프트웨어 제품 또는 프로젝트에 대한 변경 또는 결함의 잠재적 영향 또는 결과에 대한 정보를 제공합니다.
영향 분석은 수행해야 할 테스트의 양이나 범위를 평가하는 데 사용할 수 있지만 테스트 활동의 결과나 상태를 보고하는 데는 사용할 수 없습니다. 검증된 참조: ISTQB 기초 레벨에 대한 학습 가이드
2018 강의 계획서 - 스프링거, 141페이지.

ISTQB 기초 시험 프로세스는 ISTQB 기초 레벨 강의 계획서, 버전 4.0, 2018, 섹션 2.2, 15페이지에 설명된 대로 5가지 주요 단계로 구성됩니다:
* 테스트 계획 및 제어: 이 단계에서는 테스트 목표, 범위, 전략, 리소스, 일정, 위험 및 지표를 정의하고 테스트 프로세스 전반에 걸쳐 테스트 활동과 결과를 모니터링 및 제어합니다.
* 테스트 분석 및 설계: 이 단계에서는 테스트 기반(요구 사항, 사양 또는 사용자 스토리 등)을 분석하여 테스트해야 하는 테스트 조건(특징, 기능 또는 시나리오 등)을 식별하고 테스트 조건을 포괄하는 테스트 케이스 및 테스트 절차(입력, 예상 결과 및 실행 단계 등)를 설계합니다. 또한 이 단계에는 테스트 기반 및 테스트 항목(예: 소프트웨어 또는 시스템 구성 요소)의 테스트 가능성을 평가하고 테스트 목표를 달성하고 테스트 범위와 효율성을 최적화하기 위한 테스트 기법(예: 동등성 분할, 경계 값 분석 또는 상태 전환 테스트)을 선택 및 구현하는 작업도 포함됩니다.
* 테스트 구현 및 실행: 이 단계에서는 테스트 실행을 위한 테스트 환경(하드웨어, 소프트웨어, 데이터, 도구 등)과 테스트 소프트웨어(테스트 케이스, 테스트 절차, 테스트 데이터, 테스트 스크립트 등)를 준비하고 테스트 계획과 일정에 따라 테스트 절차 또는 스크립트를 실행합니다. 또한 이 단계에는 테스트 실행 결과를 기록하고, 실제 결과와 예상 결과를 비교하며, 불일치하는 부분을 인시던트(결함, 오류 또는 실패 등)로 보고하는 작업도 포함됩니다.
* 종료 기준 평가 및 보고: 이 단계에서는 계획된 테스트 활동이 완료되었는지, 종료 기준(예: 품질, 커버리지 또는 위험 수준)이 충족되었는지 확인하고 테스트 결과 및 결과를 이해 관계자에게 보고합니다. 또한 이 단계에서는 테스트 결과 및 결과를 바탕으로 출시 또는 승인 결정을 위한 권장 사항을 만들고, 해결하거나 완화해야 하는 잔여 위험(예: 알려진 결함 또는 테스트되지 않은 영역)을 식별합니다.
* 테스트 종료 활동: 이 단계에서는 향후 재사용을 위해 테스트 소프트웨어와 테스트 환경을 마무리하고 보관하며, 테스트 목표 및 테스트 계획에 따라 테스트 프로세스와 테스트 프로젝트를 평가합니다. 또한 이 단계에서는 배운 교훈과 모범 사례를 파악하고 관련 당사자에게 결과와 개선 제안을 전달합니다.
참조 = ISTQB 공인 테스터 기초 레벨 강의 계획서, 버전 4.0, 2018, 섹션 2.2, 15페이지; ISTQB 시험 용어집, 버전 4.0, 2018, 37-38페이지; ISTQB CTFL 4.0 - 샘플 시험 - 정답, 버전 1.1, 2023, 문제 88, 32페이지.

이 문제는 더 높은 품질에 기여하는 테스트의 예를 찾는 것입니다. 품질이란 구성 요소, 시스템 또는 프로세스가 지정된 요구 사항 및/또는 사용자/고객의 요구와 기대를 충족하는 정도를 말합니다1. 테스트는 소프트웨어 제품 및 관련 작업 제품의 계획, 준비 및 평가와 관련된 정적 및 동적 모든 수명 주기 활동으로 구성된 프로세스로, 지정된 요구 사항을 충족하는지 확인하고 목적에 맞는지 입증하며 결함을 감지하는 것입니다2.
따라서 테스트는 소프트웨어 제품 및 관련 작업 제품이 지정된 요구 사항을 충족하고 목적에 적합하며 결함이 없거나 최소한 결함 수가 감소했는지 확인 및 검증함으로써 품질 향상에 기여합니다. 또한 테스트는 소프트웨어 제품 및 관련 작업 결과물의 품질에 대한 정보를 이해관계자에게 제공하며, 이해관계자는 테스트 결과를 바탕으로 정보에 입각한 결정을 내릴 수 있습니다3.
주어진 네 가지 진술 중 옵션 D만이 테스트가 품질 향상에 기여한 사례로, 테스트를 통해 결함(구성 요소 또는 시스템이 필요한 기능을 수행하지 못할 수 있는 결함4)을 발견하고 해당 결함이 출시(소프트웨어 제품을 고객 또는 최종 사용자에게 전달) 전에 해결(수정 및 확인)되었음을 보여줍니다. 즉, 테스트를 통해 운영 환경에서 잠재적인 장애(구성 요소 또는 시스템이 지정된 한계 내에서 필요한 기능을 수행하지 못하는 이벤트)가 발생하지 않도록 방지하여 소프트웨어 제품의 품질을 향상시켰음을 의미합니다.
옵션 A는 테스트 결과를 요약하고 테스트 목표를 평가하는 보고 활동이지만 소프트웨어 제품 또는 관련 작업 제품의 품질에 직접적인 영향을 미치지 않으므로 품질 향상에 기여하는 테스트의 예는 아닙니다. 테스트 요약 보고서는 테스트 완료 기준, 테스트 결과, 사고 보고서, 테스트 요약 및 평가, 교훈을 포함한 테스트 활동의 결과를 기록하고 전달하는 문서입니다.
옵션 B는 테스트 활동에 필요한 리소스와 시간을 추정하는 계획 활동이지만 소프트웨어 제품 또는 관련 작업 제품의 품질에 직접적인 영향을 미치지 않으므로 품질 향상에 기여하는 테스트의 예는 아닙니다. 테스트 노력 추정치는 테스트 활동을 수행하는 데 필요한 작업량 및/또는 기간의 근사치입니다.
옵션 C는 테스트 환경(테스트 수행에 필요한 하드웨어, 계측기, 시뮬레이터, 소프트웨어 도구 및 기타 지원 요소가 포함된 환경)을 설정하는 준비 활동이지만 소프트웨어 제품 또는 관련 작업 제품의 품질에 직접적인 영향을 미치지 않으므로 품질 향상에 기여하는 테스트의 예는 아닙니다. 테스트 환경 설치는 테스트 환경 사양에 따라 테스트 환경을 설치하고 구성하는 프로세스입니다.
참조:
1: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 10페이지
2: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 11페이지
3: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 12페이지
4: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 13페이지
5: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 13페이지
6: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 77페이지
7: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 78페이지
8: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 79
9: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 80페이지
10: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 81
11: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 82페이지
12: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 83
13: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 84
14: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 85
15: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 86
16: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 87
17: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 88
18: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 89
19: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 90페이지
20: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 91
21: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 92페이지
22: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 93
23: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 94
24: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 95페이지
25: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 96페이지
26: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 97
27: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, 98페이지
28: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 99
29: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 100
30: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 101
31: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 102
32: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 103
33: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 104
34: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 105
35: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 106
36: ISTQB 공인 시험관 기초 레벨 강의 계획서 2018, 버전 4.0, p. 107

* 동등성 분할을 기반으로 x에 대한 올바른 테스트 값을 선택하는 문제입니다.
동등성 분할은 소프트웨어 유닛의 입력 데이터를 테스트 케이스를 도출할 수 있는 동등한 데이터의 파티션으로 나누는 소프트웨어 테스트 설계 기법입니다. 이 경우 주어진 동등성 클래스는 다음과 같습니다:
* (x \leq -100)
* (-100 < x < 100)
* (100 \leq x < 1000)
* (x \geq 1000)
옵션 D는 이러한 각 파티션의 값을 제공합니다:
* (x \leq -100)의 경우 -1000이 됩니다.
* (-100 < x < 100)의 경우 -100과 100이 됩니다.
* (100 \leq x < 1000)의 경우 500이 됩니다.
* (x \geq 1000)의 경우 1500이 됩니다.
따라서 옵션 D는 주어진 네 가지 동등성 클래스를 모두 적절한 값으로 다룹니다.
참조: ISTQB 공인 테스터 기초 레벨(CTFL) v4.0 문서는 ISTQB 및 ASTQB에서 확인할 수 있습니다.
* 1: ISTQB 기초 레벨 강의 계획서 2018, 버전 4.0, 38페이지
* 2: ISTQB 기초 수준 강의 계획서 2018, 버전 4.0, 39페이지
* : ISTQB 기초 레벨 강의 계획서 2018, 버전 4.0, p. 40