
1. 리스크 관리 개요조직은 목표 달성에 영향을 미칠 수 있는 다양한 내부 및 외부 요인에 직면한다. 리스크 관리는 이러한 요인으로 인해 발생할 수 있는 부정적 영향을 줄이고, 목표 달성 가능성을 높이며, 제품 품질을 개선하는 데 필수적이다.주요 리스크 관리 활동리스크 분석리스크 식별: 발생 가능한 리스크를 체계적으로 탐색하고 기록한다.리스크 평가: 리스크의 발생 가능성과 영향을 분석하여 리스크 수준을 결정한다.리스크 통제리스크 완화: 리스크 수준을 줄이기 위한 조치를 취한다.리스크 모니터링: 리스크 완화 조치의 효과를 평가하고, 새로운 리스크를 지속적으로 식별한다.테스트 활동과 결합된 리스크 관리 접근법을 리스크 기반 테스트라 하며, 이는 테스트 노력의 우선순위를 지정하고 자원을 효율적으로 활용하는 데..

1. 테스트 노력 추정 기법테스트 노력 추정은 테스트 프로젝트의 목표를 달성하기 위해 필요한 작업량을 예측하는 과정이다. 테스트 노력 추정은 프로젝트 일정과 자원 관리에 필수적인 역할을 하며, 다양한 추정 기법이 사용된다.1-1. 비율 기반 추정비율 기반 추정은 과거 프로젝트 데이터를 활용하여 표준 비율을 도출한 뒤 이를 새로운 프로젝트에 적용하는 방식이다.공식:테스트 노력 = 개발 노력 × (테스트 노력 비율 / 개발 노력 비율)예시:이전 프로젝트에서 개발 대 테스트 노력 비율이 3:2였고, 현재 프로젝트의 개발 노력이 600 인/일로 예상된다면, 테스트 노력은 다음과 같이 계산된다.테스트 노력 = 600 × (2 / 3) = 400 인/일1-2. 외삽법외삽법은 프로젝트 초기에 수집된 데이터를 기반으로..

Keywords결함 관리(defect management), 결함 보고서(defect report), 입력 기준(entry criteria), 출력 기준(exit criteria), 제품 리스크(product risk), 프로젝트 리스크(project risk), 리스크(risk), 리스크 분석(risk analysis), 리스크 평가(risk assessment), 리스크 통제(risk control), 리스크 식별(risk identification), 리스크 수준(risk level), 리스크 관리(risk management), 리스크 완화(risk mitigation), 리스크 모니터링(risk monitoring), 리스크 기반 테스트(risk-based testing), 테스트 접근법(tes..

앞에서 다룬 테스트 기법들은 결함 감지에 중점을 둔다. 반면, 협업 기반 접근법은 결함 감지뿐만 아니라 협업과 의사소통을 통한 결함 회피에도 초점을 맞춘다. 이 접근법은 소프트웨어 개발 초기 단계부터 팀원과 이해관계자가 적극적으로 참여하여 소프트웨어 품질을 향상시키는 데 기여한다.1. 협업 기반 사용자 스토리 작성사용자 스토리는 시스템 또는 소프트웨어의 사용자나 구매자에게 가치 있는 기능을 나타낸다. 사용자 스토리는 다음 세 가지 핵심 요소를 포함한다.카드(Card): 사용자 스토리를 설명하는 매체로, 인덱스 카드나 전자 보드 항목과 같은 형태로 작성된다.대화(Conversation): 사용자 스토리가 소프트웨어에서 어떻게 사용될지를 설명하며, 문서화되거나 구두로 진행될 수 있다.확인(Confirmat..

다음 섹션에서는 널리 사용되는 경험 기반 테스트 기법으로 다음 세 가지를 다룬다.오류 추측(Error Guessing)탐색적 테스트(Exploratory Testing)체크리스트 기반 테스트(Checklist-Based Testing)1. 오류 추측오류 추측(Error Guessing)은 테스터의 지식을 바탕으로 오류, 결함, 실패의 발생 가능성을 예상하는 기법이다. 이 기법은 다음과 같은 요소에 기반한다.애플리케이션이 과거에 작동했던 방식개발자가 흔히 저지르는 오류와 그로 인해 발생하는 결함 유형유사한 애플리케이션에서 발생했던 실패 유형오류, 결함, 실패는 일반적으로 다음과 관련될 수 있다.입력: 올바른 입력이 허용되지 않거나 매개변수가 잘못되거나 누락된 경우출력: 잘못된 형식, 잘못된 결과로직: 누락..

화이트박스 테스트 기법 중에서도 널리 사용되며 간단한 두 가지 코드 관련 기법인 구문 테스트와 분기 테스트에 중점을 둔다.안전이 중요한 환경, 미션 크리티컬 환경 또는 고무결성 환경에서는 더 철저한 코드 커버리지를 달성하기 위해 보다 엄격한 기법이 사용된다. 또한, 상위 테스트 레벨(예: API 테스트)이나 코드와 관련되지 않은 커버리지(예: 신경망 테스트에서의 뉴런 커버리지)에 사용되는 화이트박스 테스트 기법도 있지만 FL 레벨에서는 다루지 않는다.1. 구문 테스트와 구문 커버리지구문 테스트(Statement Testing)에서 커버리지 항목은 실행 가능한 구문이다. 테스트 케이스를 설계하여 코드의 구문을 실행하고, 허용 가능한 커버리지 수준에 도달하는 것이 목표다.커버리지 측정은 테스트 케이스가 실행..

1. 동등 분할동등 분할(Equivalence Partitioning, EP)은 데이터를 분할(동등 분할)하여 각 분할의 모든 요소가 테스트 대상 객체에 의해 동일한 방식으로 처리될 것이라고 가정하는 기법이다.이 기법은 특정 분할에서 값을 테스트했을 때 결함이 발견되면, 동일한 분할 내의 다른 값에서도 동일한 결함이 발견될 것이라는 이론에 기반한다. 따라서 각 분할에 대해 하나의 테스트만 수행해도 충분하다.특징분할은 입력값, 출력값, 구성 요소, 내부 값, 시간 관련 값, 인터페이스 매개변수 등과 관련하여 식별될 수 있다.분할은 연속적 또는 이산적, 순서 있음 또는 없음, 유한 또는 무한할 수 있다.각 분할은 중복되지 않고 비어 있지 않아야 한다.분할의 유형유효 분할: 테스트 대상이 처리해야 할 값들로 ..

Keywords인수 기준(acceptance criteria), 인수 테스트 주도 개발(acceptance test-driven development), 블랙박스 테스트 기법(black-box test technique), 경계값 분석(boundary value analysis), 분기 커버리지(branch coverage), 체크리스트 기반 테스팅(checklist-based testing), 협업 기반 테스트 접근법(collaboration-based test approach), 커버리지(coverage), 커버리지 항목(coverage item), 결정 테이블 테스팅(decision table testing), 동등 분할(equivalence partitioning), 오류 추측(error gues..

1. 조기 및 빈번한 이해관계자 피드백의 이점조기(Early) 및 빈번한(Frequent) 피드백은 잠재적인 품질 문제를 조기에 전달할 수 있도록 한다. SDLC 동안 이해관계자의 참여가 부족하면 개발 중인 제품이 이해관계자의 초기 또는 현재 비전을 충족하지 못할 수 있다.이해관계자가 원하는 것을 전달하지 못하면 비용이 많이 드는 재작업, 기한 초과, 책임 전가 문제를 초래할 수 있으며, 심지어 프로젝트 실패로 이어질 수 있다.SDLC 전반에 걸쳐 빈번한 이해관계자 피드백은 요구사항에 대한 오해를 방지하고, 요구사항 변경을 조기에 이해하고 구현할 수 있도록 한다. 이를 통해 개발 팀은 자신들이 구축하는 것에 대한 이해를 향상시키고, 이해관계자에게 가장 가치 있고 식별된 리스크에 가장 긍정적인 영향을 미치..

Keywords이상현상(anomaly), 동적 테스트(dynamic testing), 공식 리뷰(formal review), 비공식 리뷰(informal review), 검사(inspection), 리뷰(review), 정적 분석(static analysis), 정적 테스트(static testing), 기술 리뷰(technical review), 워크스루(walkthrough) 1. 정적 테스트 기본 개념정적 테스트는 동적 테스트와 달리 테스트 대상 소프트웨어를 실행할 필요가 없다. 코드를 비롯하여 프로세스 명세, 시스템 아키텍처 명세, 기타 작업 산출물을 수동으로 검사(예: 리뷰)하거나 도구(예: 정적 분석)를 사용하여 평가한다.테스트 목표는 품질을 개선하고, 결함을 감지하며, 가독성, 완전성, 정..