테스트의 주요 목적 중 하나인 결함 식별을 위해 잘 확립된 결함 관리 프로세스가 필요하다.보고된 이상 현상은 실제 결함일 수도, 아닐 수도 있다(긍정 오류, 변경 요청)결함 보고서를 처리하는 과정에서 이를 해결한다.결함 관리 프로세스 구성결함 관리 프로세스는 소프트웨어 개발수명주기(SDLC) 모든 단계에서 보고될 수 있다.보고 양식은 SDLC 단계에 따라 다르며, 모든 관련 이해관계자가 이 프로세스를 따라야 한다.결함 관리 프로세스에는 개별 이상 현상을 발견부터 종료까지 처리하는 작업 흐름(workflow)과 분류 규칙이 포함된다.작업 흐름: 보고된 이상 현상 기록 → 분석 및 분류 → 적절한 대응책 결정(수정/유지) → 결함 보고 종료.결함 보고서의 목적결함을 처리 및 해결하는 책임을 진 사람에게 문제..

테스팅에서 형상 관리는 테스트와 관련된 모든 작업 산출물을 식별, 제어, 추적하는 지침을 제공하는 활동이다.형상 관리 대상테스트 계획서테스트 전략서테스트 컨디션테스트 케이스테스트 스크립트테스트 결과테스트 로그테스트 보고서복잡한 형상 항목 관리형상 항목의 구성, 항목 간 관계, 버전 등을 기록형상 항목이 승인되면 베이스라인으로 설정되고, 공식적인 변경 제어 프로세스를 통해서만 수정 가능새로운 베이스라인을 만들 때 변경된 형상 항목에 대한 기록 유지이전 베이스라인으로 되돌릴 경우 이전 테스트 결과를 재현 가능형상 관리의 보장 사항고유 식별자 부여모든 형상 항목(테스트 대상 포함)에 고유한 식별자를 부여.버전 관리, 변경사항 추적, 형상 항목 간 연관성 식별로 테스트 프로세스 전체의 추적성 유지.명확한 참조식..

테스트 모니터링테스팅에 대한 정보 수집과 관련된 활동수집된 정보는 테스트 진행 상황 판단 및 테스트 완료조건 충족 여부를 측정하는데 사용됨테스트 제어테스트 모니터링에서 얻은 정보로 가장 효과적이고 효율적인 테스팅을 위한 제어 지침을 제공한다.식별된 리스크가 발현될 경우 테스트 우선순위 재지정재작업 이후 테스트 항목이 시작 조건 및 완료 조건을 충족하는지 재평가테스트 환경 인도 지연에 대응하기 위한 테스트 일정 조정필요한 지점과 시기에 신규 자원 추가테스트 완료완료된 테스트 활동에서 데이터를 수집하고, 경험, 테스트웨어, 기타 관련 정보를 모으는 단계입니다.테스트 완료 활동은 프로젝트 마일스톤 도달 시점, 테스트 레벨 또는 애자일 반복 주기 끝, 테스트 프로젝트 완료(또는 취소) 시점, 소프트웨어 배포 또..

리스크 관리의 목적조직이 목표를 달성할 가능성과 제품의 품질을 높이고, 이해관계자의 신뢰를 얻을 수 있게 한다.주요 활동: 리스크 분석(리스크 식별과 평가)과 리스크 제어(리스크 완화와 모니터링)5.2.1 리스크의 정의와 리스크의 속성리스크: 발생 시 부정적인 영향을 미칠 수 있는 잠재적 사건, 위험, 위협 또는 상황리스크의 두 가지 요소:발생 가능성: 리스크 발생 확률(0보다 크고 1보다 작음)영향: 발생 시 생길 피해리스크 수준: 발생 가능성과 영향을 곱한 값5.2.2. 프로젝트 리스크와 제품 리스크프로젝트 리스크: 프로젝트 관리 및 제어와 관련된 리스크조직 문제, 인력 문제, 기술적 문제, 공급업체 문제프로젝트 일정, 예산, 범위에 영향을 미쳐 목표 달성에 영향을 미침제품 리스크: 제품 품질 특성과..

5.1.1. 테스트 계획서의 목적과 내용테스트 계획서는 테스트 프로젝트의 목적, 자원, 프로세스를 설명한다.테스트 목적 달성을 위한 방법과 일정을 문서화한다.수행한 테스트 활동이 정해진 기준을 충족하는 데 도움을 준다.팀원과 기타 이해관계자의 의사소통 수단으로 사용된다.테스팅이 수립한 테스트 정책 및 전략을 준수함을 보여준다.테스트 계획서는 다음과 같은 내용을 포함한다.테스팅 정황테스트 프로젝트의 가정 및 제약 사항이해관계자의사소통리스트 목록테스트 접근법예산 및 일정5.1.2. 반복 주기와 릴리스 계획에 대한 테스터의 기여일반적으로 반복적 소프트웨어 개발수명주기(SDLC)에서 두 가지의 계획, 즉 릴리스 계획과 반복 주기 계획이 이루어진다.릴리스 계획제품 릴리스를 계획하는 단계로 제품 백로그를 (재)정의..

4장에서 언급한 테스트 접근방법은 결함 식별과 관련해 목표를 가지지만협업 기반 접근법은 협업과 커뮤니케이션을 통한 결함 예방에도 초점을 둔다.4.5.1. 협업 기반 사용자 스토리 작성사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.*3C 구성 요소 *카드 (Card): 사용자 스토리를 설명하는 매체 (예: 인덱스 카드, 전자 게시판 항목)대화 (Conversation): 소프트웨어 사용 방법에 대한 설명확인 (Confirmation): 인수 조건*형식 : * "[역할]로서 [목표]를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기를 원한다." 이후 인수 조건이 뒤따른다.*협업 방법 : * 브레인스토밍, 마인드 매핑 등을 사용하여 비즈니스, 개발, 테스팅의 세..

4.4.1 오류 추정테스터의 지식을 기반으로 오류, 결함, 장애 발생을 예측하는 기법이다.테스터의 지식에 포함되는 요소애플리케이션의 과거 동작: 애플리케이션이 과거에 어떻게 작동했는지에 대한 지식개발자가 범하기 쉬운 오류 유형: 개발자가 자주 저지르는 오류 및 그로 인해 발생하는 결함 유형유사 애플리케이션에서 발생한 장애 유형: 다른 비슷한 애플리케이션에서 발견된 장애 유형오류, 결함, 장애와 관련된 요소입력: 올바른 입력을 인식하지 못함, 매개변수 오류 또는 누락출력: 잘못된 형식, 잘못된 결과논리: 사례 누락, 잘못된 연산자계산: 잘못된 피연산자, 잘못된 계산인터페이스: 매개변수 불일치, 호환되지 않는 유형데이터: 잘못된 초기화, 잘못된 유형결함 공격오류 추정을 체계적으로 구현한 접근법이다. 테스터가..

화이트박스 테스트 기법화이트박스 테스트 기법은 소프트웨어의 내부 구조와 처리를 기반으로 하는 테스트 기법으로, 주로 코드의 논리적 흐름을 검증한다.4.3.1 구문 테스팅과 구문 커버리지구문 테스팅: 실행 가능한 모든 코드 구문을 테스트하는 기법커버리지 계산: 테스트 케이스가 실행한 구문 수를 전체 실행 가능한 구문 수로 나눠서 백분율로 표시100% 구문 커버리지: 모든 구문을 적어도 한 번은 실행했다는 것을 의미하지만, 모든 결함을 식별할 수 있다는 것을 보장하지는 않는다.예제function isEven(number) { if (number % 2 === 0) { // 구문 1 return true; // 구문 2 } else { return false..

블랙박스 테스트에서 사용되는 테스트 기법은 다음과 같다.동등 분할 경계값 분석 결정 테이블 테스팅 상태 전이 테스팅 4.2.1 동등 분할 테스팅정의동등 분할 테스팅은 테스트 대상이 동일한 방식으로 처리될 것으로 예상되는 데이터를 분할 단위로 나누는 기법이다. 각 분할 내의 특정 값을 테스트하는 테스트 케이스가 결함을 식별할 수 있다면, 같은 분할의 다른 값도 결함을 식별할 수 있다고 가정한다. 따라서 각 분할에 대해 하나의 테스트만 수행하면 충분하다.적용 대상동등 분할은 입력, 출력, 형상 항목, 내부 값, 시간 관련 값, 인터페이스 매개변수 등 테스트 대상과 관련된 모든 데이터 요소에 대해 식별할 수 있다.특징분할은 연속적이거나 비연속적일 수 있으며, 정렬돼 있거나, 유한 또는 무한일수 있다.분할은 ..

테스트 기법의 목적테스트 분석(무엇을 테스트할지)과 테스트 설계(어떻게 테스트할지) 작업 지원체계적인 방식으로 적은 수의 충분한 테스트 케이스 개발테스트 컨디션 정의, 커버리지 항목 및 테스트 데이터 식별 도움테스트 기법 분류블랙박스 테스트 기법 (명세 기반 기법)내부 구조 참조 없이 명시된 동작에 대한 분석 기반소프트웨어 구현 방식에 의존하지 않음구현이 바뀌더라도 필요한 동작이 동일하면 테스트 케이스 유효화이트박스 테스트 기법 (구조 기반 기법)내부 구조와 처리에 대한 분석 기반소프트웨어 설계 방식에 의존설계나 구현이 끝난 후에 테스트 케이스 생성경험 기반 테스트 기법테스터의 지식과 경험을 활용테스터의 능력에 따라 효과성 달라짐블랙박스 및 화이트박스 테스트 기법을 보완예상문제문제 1: 블랙박스 테스트 ..