From Benz engineer to programmer 2차 전직

공부 기간 : 6/1~ 6/23 

공부 방법 : 오직 실라버스..

우선 실라버스가 너무나도 졸립고... 재미없어서 첫 주는 실라버스만 대충 1장부터 6장까지 스윽 봤습니다..

그 다음주부터 일주일간 실라버스를 블로그에 정리하면서 필사를 했습니다.. 너무나도 고독의 시간..

그리고 그 주 주말에 문제 A를 풀고 좌절을 맛보고 오답을 하면서 제가 몰랐던 이론을 정리했습니다.

그 다음에는 B를 풀고 이제 문제의 감을 잡았습니다.

어떤 식으로 나올지 감을 잡고 이번 부터는 26점 맞더군요... 

이때 다시 오답을하고, A를 다시 풀었습니다. 

A를 다시 오답하고 C를 풀어보고 28점을 맞았습니다..

연속으로 A 와 B를 풀고 다시 틀린거 오답했습니다. 

1. 실라버스 스윽 흐름 파악하기

2. 문제풀면서 좌절감 맛보고 오답노트하는데 오답을 거의 필사 느낌처럼 문제에 필요한 이론 다시 공부하고 적는 방법으로..

3. 문제 A B C 를 동일하게 했습니다...

후기 - 

저는 회사를 다니고 끝나고 헬스장을 꼭 꼭 가기때문에 부족한 시간은 일찍자고 일어난 새벽에 똘망 똘망한 눈망울로 공부를 했습니다. 

항상 저는 무언가를 할때 그때 이룰 성취감을 상상합니다.! 흐흐...

하기 싫을 때는 떨어졌을때의 그 기분을 상상합니다.. 흑흑흑 ....

비전공인 저는 처음 보는 이론이 많았지만.. 역시.. 하면 되네요 ..! 

제가 하면 모두가 할수 있습니다.! 저는 머리가 안좋아서 계속 봐야하거든요..ㅎㅎ 어쨋든 올해 목표중 하나를 이뤘네요 히히히 

모두들 화이팅 하세요!

1.2.2 품질 보증과 테스팅

품질이란 컴포넌트, 시스템, 또는 프로세스가 명시된 요구사항이나 사용자/고객의 필요와 기대를 만족하는 정도이다.

품질 관리는 품질 보증과 품질제어를 포함한 여러가지 활동을 포함하는 용어이다.

품질 보증은 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 초점을 두고있다. 품질 제어는 테스팅 활동이 포함.

1.2.3 오류, 결함,장애

사람 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)을 발생시키는 오류(실수)를 범할 수 있다.

특정 작업 산출물 내 결함의 원인이 되는 오류는 연관된 다른 작업 산출물의 결함의 원인이 되는 또 다른 오류의 계기가 될 수 있다.

결함의 근본 원인이란 해당 결함을 생성하는데 기여한 최초의 해동이나 조건을 지칭한다. 결함을 분석함으로써 근본 원인을 찾을 수 있으며, 차후 유사한 결함의 발생 가능성을 낮출수 있다.

예를 들어, 단 한줄의 잘못된 코드로 인한 이자 지급 오류는 소비자 불만을 초래한다. 제품 소유자가 이자 계산법을 잘못 이해해서 작성한 애매모호한 사용자 스토리를 기반으로 코드가 잘못 작성 되었다.

이 예제에서 결과는 소비자 불만이며 장애는 잘못된 이자 지급이다. 결함은 코드에 포함된 잘못된 계산식이며, 그것의 원인이 되는 최초의 결함은 사용자 스토리의 모호성이다. 최초 결함의 근본 원인은 제품 소유자의 지식 부족이였으며, 그 결과로 제품 소유자가 사용자 스토리를 작성할 때 오류를 범했다고 볼 수 있다. 

Ex) C-Q3

A. 시스템 개발자가 잘라 붙이기 후 변경된 부분에 대한 이름 수정을 잊어 버렸다. (오류,실수)

B. 후진 시 경고음을 울리는 불필요한 코드가 시스템에 들어갔다. (결함)

C. 라디오 볼륨을 키우거나 줄일 때 시스템이 설정 속도를 유지하지 못한다. (장애)

D. 시스템의 설계 명세에 Km/h 속도 단위가 잘못 표기되었다. (결함) 

1.4 테스트 프로세스

모두가 사용하는 일반적인 테스트 프로시저는 없지만, 설정한 목적의 달성 가능성을 높여주는 공통적인 테스트 활동 세트는 존재한다. 이런 테스트 활동 세트를 테스트 프로세스라 한다.  

테스트 프로세스에 속하는 테스트 활동과 이런 활동을 어떻게 구현할지, 또 이런 활동을 언제 수행할지에 대한 내용은 조직의 테스트 전략에서 다룰수 있다.

1.4.2 테스트 활동과 작업 

• 테스트 계획 - 계획 ( 일정, 테스팅 접근법,..)
• 테스트 모니터링과 제어 ( 상황진행보고서, 요약보고서등)
• 테스트 분석 - 베이시스 평가, 테스트 컨디션 우선순위
• 테스트 설계 - 테스트 데이터 식별, 인프라와 도구 식별 , 테스트 환경 설계 , 테스트 케이스와 테스트 세트
• 테스트 구현 - 테스트 데이터 생성 , 테스트 프로시저
• 테스트 실행 - 결함 보고서
• 테스트 완료 - 보고서, 

 - 테스트 계획 : 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동을 포함한다. 예를 들어, 적합한 테스트 기법과 작업 명시, 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립 등이 여기에 포함된다.

5.2 테스트 계획과 추정

5.2.1 테스트 계획의 목적과 내용 

 - 계획에 영향을 주는 요소

• 조직의 테스트 정책
• 테스트 전략
• 사용하는 개발 수명주기 및 방법
• 테스팅의 범위
• 목적
• 리스크
• 제약
• 심각도
• 테스트 용이성
• 자원의 가용성

 - 테스트 계획서 기록 내용

• 테스팅의 범위 정의, 목적, 리스크 결정
• 전반적인 테스팅 접근법 정의
• 테스트 활동을 소프트웨어 수명주기 활동에 통합하고 조정
• 테스트 대상 다양한 테스트 활동에 필요한 인력과 기타 자원, 테스트 활동 수행 방법 결정
• 테스트 분석, 설계, 구현, 실행, 평가 활동의 일정 조정. 일정은 특정 날짜나 반복주기 단위로 편성할 수 있다.
• 테스트 모니터링과 제어에 사용할 메트릭 선정
• 테스트 활동 예산 결정
• 테스트 문서의 구조와 상세화 정도 정의

------------------------------------------------------------

• 작업 산출물 : 테스트 계획(베이시스에 대한 정보)

- 테스트 모니터링과 제어 : 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척상황과 지속적으로 비교하는 활동을 말한다.

테스트 제어는 테스트 계획에 따른 목적 달성을 위해 필요한 행동을 취하는 활동을 포함한다. 

테스트 모니터링의 목적은 정보 수집 및 테스트 활동에 대한 피드백과 가시성 제공이다. 모니터링 대상 정보는 수동 혹은 자동으로 수집할 수 있고, 테스트 진행상황을 평가하는 데 활용한다. 그리고 테스트 종료 조건(예: 제품 리스크 커버리지, 요구사항 커버리지, 인수 기준)을 만족하는지 또는 애자일 프로젝트에서 완료의 정의와 관련된 테스팅 작업을 만족하는지 측정하는 데 이용한다.

테스트 제어 활동의 예는 

• 식별한 리스크(예: 소프트웨어 인도 지연) 발생 시 테스트 우선순위의 변경
• 테스트 환경이나 기타 자원의 가용 여부에 따라 테스트 일정 변경
• 재작업으로 인해 테스트 항목이 시작 조건이나 종료 조건 만족하는지 재 평가 
• 작업 산출물 : 테스트 요약 보고서와 같은 여러 형태의 테스트 보고서

5.3.1 테스팅에서 사용하는 메트릭

테스팅 활동 중이나 종료 시점에 아래와 같은 사항을 평가하기 위해 메트릭을 수집할 수 있다. 

• 계획한 일정과 예산 대비 진행 상황
• 테스트 대상의 현재 품질
• 테스트 접근법의 타당성
• 목적 대비 테스트 활동의 효과 

일반적인 테스트 메트릭은 다음과 같다.

• 계획 대비 테스트 케이스 준비 작업 완료율(또는 계획 대비 테스트 케이스 작성률)
• 계획 대비 테스트 환경 준비 작업 완료율
• 테스트 케이스 실행률(예: 수행한/수행하지 않은 테스트 케이스 수 , 테스트 케이스 합격/불합격 수, 테스트 컨디션 합격/불합격 수)
• 결함 정보( 예: 결함 밀도, 발견한 결함, 수정한 결함, 실패율, 확인 테스트 결과)
• 요구사항 커버리지, 사용자 스토리 커버리지, 인수 기준 커버리지, 리스크 커버리지, 코드 커버리지
• 작업 완료, 자원 할당과 사용, 노력
• 다음 결함을 발견하면 얻는 이익 대비 비용이나 테스트를 계속 실행해 얻게 되는 이익 대비 비용 등을 포함하는 테스팅 비용

5.3.2 테스트 보고의 목적, 내용, 독자

테스트 보고의 목적은 테스트활동(예: 테스트 레벨) 중이나 마무리 시점의 테스트 활동 정보 요약과 공유이다.

테스트 보고서(테스트 진행 상황 보고서, 요약보고서(테스트 활동 종료시점에 작성) ( 테스터 관리자 작성)

- 테스트 진행 보고서에 들어가는 정보

• 테스트 계획 대비 테스트 활동과 진행 상황
• 진행을 방해하는 요소
• 다음 보고 기간에 진행하기로 계획한 테스팅
• 테스트 대상의 품질

- 테스트 요약 보고서에 들어가는 정보(종료 조건 만족시)

• 테스트 수행 내용 요약
• 테스트 기간 도중에 발생한 상황 정보
• 계획 대비 편차(예: 일정, 기간, 테스팅 활동 노력)
• 종료 조건 및 완료의 정의에 대한 테스팅 현황과 제품 품질
• 진행을 방해했거나 계속해서 방해하고 있는 요소
• 메트릭(5.3.1에 설명한 결함, 테스트 케이스, 테스트 커버리지, 활동 진행 상황, 소비한 자원)
• 잔존 리스크
• 재사용 가능한 테스트 작업 산출물'

5.4 형상 관리

형상 관리의 목적은 프로젝트와 제품 수명주기 동안 컴포넌트나 시스템, 테스트웨어와 이들 서로간의 관계 통합을 수립하고 유지하는 데 있다. 형상 관리는 테스팅을 적절히 지원하고자 아래 내용을 확인한다.

• 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록한다. 형상 관리에서 테스트 항목은 서로 연관돼 있다.
• 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경사항을 추적하고, 서로 연결해 테스트 항목 버전과도 연결되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할수 있게 한다.
• 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

테스트 계획을 수립하면서 형상관리 절차와 인프라(도구)를 식별하고 구현해야 한다.

----------------------------------------------------------------------------------------------------------------

- 테스트 분석 : 테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석하고 평가한다.

테스트 분석의 주요 활동

• 고려중인 테스트 레벨에 적합한 테스트 베이시스 평가
• 컴포넌트나 시스템의 기능, 비기능, 구조 측면을 고려한 리스크 분석 보고서
• 테스트 베이시와 테스트 항목을 평가해서 다양한 형태의 결함 식별
• 테스트할 기능과 기능세트 식별
• 테스트 베이시스를 평가하고 기능, 비기능, 구조 특성 리스크 수준 등을 고려해서 각 기능에 대한 테스트 컨디션 정의 및 우선순위 선정
• 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착

*작업 산출물

• 우선수위가 선정된 테스트 컨디션

------------------------------------------------------------------------------------------------------------------

- 테스트 설계 - 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트웨어를  생성한다. 

테스트 설계의 주요 활동

• 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정
• 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별 ***************
• 테스트 환경 설계와 필요한 인프라 도구 식별  ****************
• 테스트 베이시스 , 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정

*작업 산출물 

• 테스트 케이스와 테스트 케이스 세트
• 필요한 테스트 데이터의 설계나 식별
• 테스트 환경 설계
• 인프라와 도구의 식별

-------------------------------------------------------------------------------------------------------------------

- 테스트 구현 : 테스트 구현 중 테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치해서 테스트 프로시저를 만드는 것도 여기에 포함된다.

테스트 구현에 주요 활동

• 테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성
• 테스트 프로시저와(있다면) 자동 테스트 스크립트로부터 테스트 스위트 생성
• 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치
• 테스트 환경 구축, 가능하다면 테스트 하네스, 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인
• 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인
• 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로 간의 양바향 추적성 검증과 업데이트

*작업 산출물

• 테스트 프로시저와 이 프로시저의 배열
• 테스트 스위트
• 테스트 실행 일정

--------------------------------------------------------------------------------------------------------------------

- 테스트 실행 : 테스트 스위트를 테스트 실행 일정에 따라 실행한다.

테스트 실행의 주요 활동

• 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
• 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
• 기대 결과와 실제 결과 비교
• 이상 현상을 분석해 원인 파악
• 관찰한 장애를 기반으로 결함 보고
• 테스트 실행 결과 기록
• 이상 현상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복
• 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성과 검증 업데이트

*작업 산출물

• 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서
• 결함 보고서
• 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등에 대한 문서 

---------------------------------------------------------------------------------------------------------------------

- 테스트 완료 : 완료한 테스트 활동에 서 데이터를 수집해서 경험, 테스트웨어 기타 관련 정보를 축적하는 활동이다. 테스트 완료 활동은 소프트웨어 시스템을 릴리스 했을 때 테스트 프로젝트를 완료 했을때 등 일어난다.

테스트 완료의 주요 활동

• 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인
• 이해관계자에게 전달할 테스트 요약 보고서 생성 
• 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관
• 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계
• 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 분석주기, 릴리스, 또는 프로젝트를 위해 수정해야 하는 사항 판단
• 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용

1.4.4 테스트 베이스와 테스트 작업 산출물 간의 추적성

- 좋은 추적성은 테스트 커버리지에 대한 평가를 가능하게 한다.

- 수정으로 인한 영향 평가를 가능하게 한다. ( 리그레션 테스팅)

- 테스팅에 대한 감사(audit)를 가능하게 한다. (테스트 실행의 완전성 평가)

- IT 통제 조건을 충족할 수 있게 한다.

- 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함함으로써 테스트 진행 상황 보고서와 테스트 요약 보고서를 좀     더 쉽게 이해할 수 있게 한다. 

- 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달한다.

- 비지니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.

2.3 테스트 유형

테스트 유형이란 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합을 얘기한다. 대표적인 목적

• 완전성, 정확성, 적합성 등과 같은 기능 품질 특성 평가 -> 기능 테스트
• 신뢰성, 성능 효율성, 보안성, 호환성, 사용성 등과 같은 비기능 품질 특성 평가 -> 비기능 테스트
• 컴포넌트나 시스템의 아키텍처 및 구조가 정확하고 완전하며 명시된 것과 일치하는지 평가
• 수정의 효과 평가. 예를 들어, 결함이 수정됐는지 확인(확인 테스팅)하고, 소프트웨어나 환경의 변화로 인해 동작에 의도하지 않은 변화가 없는지 평가(리그레션 테스팅)

테스트 유형에는 기능 테스트 , 비기능 테스트 , 화이트박스 테스팅 , 변경 관련 테스팅 , 유지보수 테스팅

- 변경 관련 테스팅 - 리그레션 테스팅 , 확인 테스팅

 - 확인 테스팅 - 결함으로 인한 수정후 확인하는 테스트

 - 리그레션 테스팅 - 의도하지 않은 부작용을 발견하기 위해 하는 테스트 

- 영향도 분석 - 유지보수 릴리스에 포함된 변경을 평가해서, 의도한 결과뿐만 아니라 변경으로 인해 발생할 수 있는 예    견된 부작용을 식별하고, 변경의 영향을 받는 시스템 영역을 식별하기 위해 식별한다. 

  영향도 분석은 변경이 기존 테스트에 미치는 영향을 식별하기 위해 사용할 수 있다.( 리그레션 테스팅에 유리하다)

4. 테스트 기법

 테스트 기법의 목적은 테스트 컨디션, 테스트 케이스, 테스트 데이터 식별을 지원하는 것이다. 

테스트 기법의 선택

• 컴포넌트나 시스템의 복잡도
• 규제 기준
• 고객 또는 계약 요구사항
• 리스크 수준과 유형
• 사용 가능한 문서
• 테스터의 지식과 역량
• 사용 가능한 도구
• 시간과 예산
• 소프트웨어 개발 수명주기 모델
• 컴포넌트나 시스템에서 예상되는 결함 유형 

4.1.1 테스트 기법의 종류와 특성

블랙박스, 화이트박스, 경험기반으로 분류

- 블랙박스 테스트 기법 : 적절한 테스트 베이시스(예 : 공식 요구사항 문서, 명세서, 유스 케이스, 사용자 스토리 또는 비    지니스 프로새스)에 대한 분석을 기반으로 한다. 테스트 대상의 내부 구조를 고려하지 않고, 입력과 출력에 집중한다.

* 특징 

• 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 테스트 베이시스로 부터 도출한다.
• 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용환다.
• 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정한다.

- 화이트박스 테스트 기법 : 아키텍처, 세부 설계, 내부 구조, 구조, 테스트 대상의 코드에 대한 분석을 기반으로 한다. 테스트 대상의 내부 구조와 처리에 집중한다.

* 특징

• 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍쳐, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출한다.
• 커버리지는 선택한 구조내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준응로 측정한다.

- 경험 기반 테스트 기법 : 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계, 구현, 실행한다.

* 특징

• 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 이해관계자의 지식과 경험과 같은 테스트 베이이스로 부터 도출한다.
• 지식과 경험은 소프트웨어의 예상 동작과 사용 환경, 발생 가능성이 있는 결함과 분포 등을 포함한다. 

4.4 경험 기반 테스트 기법( 헷깔림..)

경험 기반 테스트 기법을 적용할 경우 테스트 케이스는 테스터의 기술 역량과 직관 그리고 유사한 애플리케이션과 기술에 대한 경험을 기반으로 도출한다.

 - 오류 추정

 테스터의 지식을 기반으로 오류, 결함 및 장애 발생을 예측하는 데 적용하는 기술이며 다음을 포함한다.

• 애플리케이션의 과거 동작
• 발생하기 쉬 오류의 유형
• 다른 애플리케이션에서 발생한 장애 

- 탐색적 테스팅 **************************************

탐색적 테스팅에서는 비공식 테스트를 테스트 실행중에 동적으로 설계, 실행, 기록하고 평가한다.

테스터가 테스트를 수행할 때 테스트 설계를 적극적으로 제어하고 새롭고 더 나은 테스트 설계를 위해 테스트 하는 동안 얻은 정보를 사용하는 비공식적인 테스트 기법.!

- 체크리스트 기반 테스팅 ****************************************

체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있다. 체크리스트는 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수 있다.

구체적인 테스트 케이스가 없는경우, 체크리스트 기반 테스팅은 대략적인 지침과 일관성을 제공할 수 있다.

3.1 정적 테스팅 기초

정적 테스팅은 작업 산출물을 수동으로 검사( 예 : 리뷰) 하거나 코드나 다른 작업 산출물을 도구를 기반으로 평가( 예 : 정적 분석)하는 방법에 의존한다.

3.1.1 정적테스팅으로 검토할 수 있는 작업 산출물

• 비즈니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
• 에픽(epic), 사용자 스토리, 인수 기준
• 아키텍처 및 설계 명세
• 코드
• 테스트 계획, 테스트 케이스(테스트 설계 산출물), 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어 ( 테스트 구현 산출물)
• 사용자 가이드
• 웹 페이지
• 계약, 프로젝트 계획, 일정, 예산 기획 
• 형상(configuration) 및 인프라(infrastructure) 셋업
• 액티비티 다이어그램과 같은 모델 기반 테스팅에 사용되는 모델 

- 정적 테스팅 효과

• 동적 테스트 실행 전에 보다 효율적으로 결함을 발견하고 수정 ( 결함 수정은 디버깅)
• 동적 테스팅으로 발견이 쉽지 않은 결함 식별
• 요구사항 불일치, 애매 모호함, 모순, 누락, 부정확, 중복 등을 식별해서 설계나 코딩의 결함 예방
• 개발 생산성 향상 (예: 설계 개선, 향상된 코드 유지보수성)
• 개발 비용 및 기간 단축 
• 테스팅 비용 및 기간 단축
• 수명주기 후반 또는 출시 후 운영 과정에서 발견되는 장애 감소로 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소
• 리뷰에 참여하는 팀원 간의 의사소통 개선

- 결함 유형

• 요구사항 결함 (예: 불일치, 모호함, 모순, 누락, 부정확, 중복 등)
• 설계 결함 (예: 비효율적인 알고리즘(algorithm)이나 데이터베이스 구조, 높은 결합도(coupling), 낮은 응집도(cohesion)) 등
• 코딩 결함 (예: 정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
  표준과의 차이 (예: 코딩 표준 미준수 등)
• 잘못된 인터페이스 명세 (예를 들어, 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
• 보안 취약점 (예를 들어, 버퍼 오버플로우에 대한 취약성) 
• 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성 (예를 들어, 특정 인수 조건에 대한 테스트 누락)

3.2 리뷰 프로세스

계획

• 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
• 노력과 기간 추정
• 리뷰 유형에 따라 결정되는 역할 , 활동, 체크리스트와 같은 리뷰 특성의 식별
• 리뷰에 참석할 인원을 선정하고 역할 할당
• 인스펙션과 같은 보다 공식적인 리뷰에 경우에는 시작 및 종료 조건정의
• 시작 조건이 충족되는지 확인

리뷰착수

• 작업 산출물과 이슈기록 양식, 체크리스트, 관련된 작업 산출물 등 배포
• 참가자에게 범위, 목적 ,프로세스,역할 작업산출물을 설명
• 참가자가 리뷰에 대해 가질수 있는 여러 질문에 답변

개별 리뷰

• 작업 산출물 전체 혹은 부분 리뷰
• 잠재 결함, 권고사항, 질문기록

이슈 논의 및 분석

• 식별한 잠재 결함 전달
• 잠재 결함 분석 및 담당자 및 상태 할당
• 품질 특성 평가 및 문서화
• 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정

수정 및 보고

• 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
• 리뷰할 작업 산출물에서 발견한 결함 수정(저자가 수정)
• 결함 정보를 적절한 사람이나 팀과 공유
• 메트릭 수집
• 종료 조건의 충족여부 확인
• 종료 조건이 충족되면 해당 작업 산출물 인수

3.2.2 공식 리뷰에서의 역할과 책임

저자 ( 워크쓰루에서 회의를 주도한다) 

 - 리뷰 대상 작업 산출물 작성

 - 리뷰 대상 작업 산출물 결함 수정

관리자

 - 리뷰 계획 담당

 - 리뷰 실행 결정

 - 인력, 예산, 시간 할당

 - 진행 비용 대비 효과 모니터링

 - 결과가 만족스럽지 않은 경우 제어 결정 실행

촉진자 ( 기술리뷰, 인스펙션에서 회의를 주도한다.)

 - 리뷰 회의 진행 시 효과적 진행 보장

 - 필요한 경우 다양한 관점들에 대해 중재

 - 많은 경우 리뷰 성공의 여부에 결정적인 역할을 하는 사람

리뷰 리더

 - 전반적으로 리뷰에 대한 책임을 지는 사람

 - 참여자를 결정하고 언제 어디서 진행할지 결정

검토자 (테스터 포함)

 - 해당 주제에 대한 전문가, 프로젝트 참여인원, 작업 산출물에 관심이 있는 이해관계자나 특정 기술 혹은 비지니스 배     경을 가진 사람등

 - 리뷰 대상 작업 산출물의 잠재적 결함 식별

 - 다양한 관점을 대표할 수 있음

서기 (대부분의 리뷰에 필수 비공식빼고)

 - 개별 리뷰 활동에서 발견한 잠재 결함 수집

 - 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정 사항 기록

6.1 테스트 도구 고려 사항

테스팅 및 테스트웨어 관리 지원 도구

 - 테스트 관리 도구와 애플리케이션 수명주기 관리 도구

 - 요구사항 관리 도구

 - 결함 관리 도구

 - 형상 관리 도구

 - 지속적인 통합 도구

정적 테스팅 지원 도구

 - 정적 분석 도구( 개발자 지원 , 리뷰) 

테스트 설계 및 구현 지원 도구

 - 모델 기반 테스팅 도구

 - 테스트 데이터 준비 도구 

테스트 실행 및 로깅 지원 도구 

 - 테스트 실행 도구 ( 예 : 리그레션 테스트 수행)

 - 커버리지 도구 ( 예 : 요구사항 커버리지 , 코드 커버리지)

 - 테스트 하네스 

성능 측정과 동적 분석 지원 도구

 - 성능 테스팅 도구

 - 동적 분석 도구

6.1 테스트 도구 고려 사항

- 테스트 도구는 하나 이상의 테스팅 활동을 지원하는데 사용할 수 있으며, 다음과 같은 종류가 있다

• 테스팅에 직접 사용하는 도구 (예: 테스트 실행 도구, 테스트 데이터 준비 도구)
• 요구사항, 테스트 케이스, 테스트 프로세스, 자동 테스트 스크립트, 테스트 결과, 테스트 데이터, 결함을 관리하고 , 테스트 실행 보고와 모니터링을 지원하는 도구
• 분석과 평가 에 사용하는 도구
• 테스팅을 지원하는 모든 도구

6.1.1 테스트 도구의 분류

테스트 도구는 정황에 따라 다음과 같은 하나 이상의 목적이 있다.

• 반복적인 작업이나 수동으로 진행했을 때 상당한 리소스를 필요로 하는 작업(예 : 테스트 실행, 리그레션 테스팅)을 자동화해서 테스트 활동의 효율성을 높인다.
• 테스트 프로세스 전반에 걸쳐 수동 테스트 활동을 지원해서 테스트 활동의 효율성을 높인다.
• 테스팅의 일관성과 결함 재현성 향상으로 테스트 활동의 품질을 향상시킨다.
• 수동으로 실행할 수 없는 활동을 자동화( 예 대규모 성능 테스팅) 한다.
• 테스팅의 신뢰성을 향상 한다.( 예 대규모 데이터 비교 자동화나 동작 시뮬레이션)

도구는 목적, 가격, 라이선스 모델, 사용된 기술에 따라 분류할 수 있다. 본 실바러스에서는 테스트 도구가 지원하는 활동에 따라 도구를 분류 한다.

테스팅 및 테스트웨어 관리 지원 도구 , 정적 테스팅 지원 도구 , 테스트 설계 및 구현 지원 도구, 테스트 실행 및 로깅 지원 도구 , 성능 측정과 동적 분석 지원도구, 특수 목적 테스팅 지원 도구

테스팅 및 테스트웨어 관리 지원 도구 - 테스팅 및 테스트웨어 관리를 지원하는 도구는 다음과 같다.

• 테스트 관리 도구와 애플리케이션 수명 주기 관리 도구 
• 요구사항 관리 도구
• 결함 관리 도구
• 형상 관리 도구
• 지속적인 통합 도구(개발자 지원)

정적 테스팅 지원 도구

• 정적 분석 도구

테스트 설계 및 구현 지원 도구 - 테스트 설계와 구현 단계에서 작업 산출물 (예 테스트 케이스, 테스트 프로시저,테스트 데이터)를 유지보수 하는데 도음을 준다.

• 모델 기반 테스팅 도구
• 테스트 데이터 준비 도구

테스트 실행 및 로깅 지원 도구

• 테스트 실행 도구
• 커버리지 도구 커버리지, 코드 커버리지
• 테스트 하네스

성능 측정과 동적 분석 지원 도구 - 성능 측정 및 동적 분석 도구는 성능 및 부하 테스트 활동이 수동으로는 효과적으로 수행할 수 없기 때문에 이를 지원하는 데 필수적이다.

• 성능 테스팅 도구
• 동적 분석 도구

특수 목적 테스팅 지원도구  - 일반적인 테스트 프로세스를 지원하는 도구 외에 비기능적 특징을 커버하기 위한 보다 특정적인 테스팅을 지원하는 도구도 있다.

6.1.2 테스트 자동화의 효과와 리스크

테스트 실행 지원도구 잠재적 가치 ( 샘플 A - Q39)

• 반복적인 수동 업무의 감소로 시간 절약
• 월등한 일관성과 반복성 제공
• 보다 객관적인 평가 기준 제공
• 테스팅 관련 정보에 접근이 쉬움

테스트 지원도구 잠재적 리스크

• 도구에 대한 비현실적인 기대
• 초기 도구 도입에 필요한 시간, 비용, 노력에 대한 과소 평가
• 도구가 생성하는 테스트 작업 산출물을 유지하기 위한 노력의 과소평가
• 도구에 대한 지나친 의존
• 테스트 작업 산출물에 대한 버전의 관리 소홀
• 요구사항 관리도구, 형상 관리 도구, 결함 관리 도구, 다수의 공급 업체에서 제공하는 도구 환경에서 주요 도구 간의 관계와 상호 운용성 이슈를 관리하지 않음
• 도구 공급 업체의 폐업, 해당 도구의 판매 중단, 해당 도구가 다른 공급 업체에 매각될 수 있음.
• 지원, 업그레이드, 결함 수정에 대한 공급 업체의 부적절한 대응
• 오픈소스 프로젝트는 연기되거나 중단될 수 있음.
• 도구가 새로운 플랫폼이나 기술을 지원하지 않음
• 도구가 소유권이 명확하지 않음.

테스트 실행 도구 - 테스트 실행 도구는 자동화 테스트 스크립트를 사용해 테스트를 실행.

• 캡처 기반 테스트 접근법  - 테스터의 수동적인 조작을 녹화해 테스트를 캡처하는 것은 매력적으로 보일 수 있지만 이러한 접근 방식은 테스트 스크립트의 수가 많을경우 적절하지 않다.
• 데이터 주도 테스트 접근법 - 이 접근법은 테스트 입력값과 기대 결과값을 보통 스프레드시트에 저장하고 더 많은 공통 스크립트를 활용해 해당 테스트 데이터를 읽어 들여 동일한 테스트 스크립트를 매번 다른 데이터로 반복적으로 실행한다.
• 키워드 주도 테스트 접근법 - 이 접근법은 해야 할 행동을 설명하는 키워드를 공통 스크립트가 처리해 키워드 스크립트를 호출한다. 키워드 스크립트는 연관된 테스트 데이터를 처리한다.

위에서 언급한 접근법은 스크립트 언어 전문가(테스터, 개발자 또는 테스트 자동화 전문가) 가 필요하다.

테스트 관리 도구 - 아래와 같은 이유로 다른 도구나 스프레드시트와 연동해야 하는 경우가 많다.

• 필요한 정보를 생성하기 위해
• 요구사항 관리 도구에 저장된 요구사항의 추적성을 지속적으로 유지하기 위해
• 형상 관리 도구에 저장된 테스트 대상 버전 정보와 연결하기 위해

6.2 도구의 효과적인 사용

• 조직의 강점, 약점 등 성숙도 수준 평가
• 도구의 지원으로 테스트 프로세스 개선 기회 식별
• 테스트 대상이 이용하는 기술을 이해해 테스트 대상과 호환 가능한 도구 선택
• 호환과 통합이 가능한 도구 확인을 위해, 조직에서 이미 사용하고 있는 빌드와 지속적인 통합 도구 이해
• 명확한 요규사항과 객관적인 기준에 맞는 도구 평가
• 도구를 일정 기간 무료로 시험해 볼 수있는지 여부
• 공급자 평가 또는 비 상업적 도구 지원 평가
• 조직이 요구하는 도구 사용 코칭과 멘토 요구사항 식별
• 도구를 직접 사용할 사람의 테스팅 역량을 고려한 훈련 수요 확인
• 다양한 라이센스 모델의 장단점 고려
• 필요시 구체적인 비즈니스 사례에 근거해 비용 대비 효과 추정

마지막으로 사전검증을 진행 해야 한다. 사전 검증으로 테스트 대상 소프트웨어와 현재 인프라 환경에서 도구가 효과적으로 동작하는지 확인하고 필요한 경우에는 효율적으로 도구를 사용하는데 필요한 요구사항을 식별.

6.2.2 도구 도입을 위한 파일럿 프로젝트 - 도구 선택과 사전 검증이 성공적으로 끝난 다음 선택한 도구를 조직에 도입하는 시점은 주로 파일럿 프로젝트 이다. 파일럿 프로젝트의 목적은 다음과 같다 :

• 깊이 있는 도구 지식의 습득, 장단점 모두 이해
• 도구를 기존 프로세스와 프랙티스에 어떻게 적용할지 평가하고 무엇을 변경할지 결정
• 도구와 테스트 작업 산출물의 사용, 관리, 저장, 유지보수에 대한 기준 결정
• 목표한 가치를 적절한 비용으로 달성할 수 있는지 평가
• 도구에서 수집하고 보고하기를 희망하는 메트릭을 이해하고 그런 메트릭을 도출하고 보고할 수 있도록 도구를 설정

6.2.3 도구 성공 요인

- 조직에 도구의 평가, 구현, 배포, 지속적인 지원을 위한 성공 요인은 다음과 같다.

• 조직의 다른 부서에 도구 사용 전파를 점진적으로 진행
• 도구의 사용법에 맞게 프로세스를 수정하고 개선
• 도구 사용자에게 교육, 코칭, 멘토링 제공
• 도구사용에 필요한 지침을 정의
• 실제 도구 사용에서 얻은 사용법 정보의 수집 방법 구현
• 도구 사용 현황과 성과를 모니터링
• 특정 도구 사용자에게 지원 제공
• 모든 사용자로부터 사용 후 교훈 수집

소프트웨어 개발 수명주기와 도구를 기술적으로, 유기적으로 통합하는게 중요하다. 가령 운영이나 외부 공급업체를 담당하는 조직을 별도로 둔다.

- 용어 - 

비지니스 프로세스 기반 테스팅 : 테스트케이스를 비지니스 프로세스 상세(설명 내용)와 지식에 기반하여 설계하는 테스팅 접근법.

5.1 테스트 조직

5.1.1 독립적인 테스팅 - 테스팅 ㄱ업은 특정 테스팅 역할을 부여 받은 사람이나 다른 역할을 하는 사람도 수행할 수 있다.(예 고객) 저자와 테스터가 가지는 인지편향의 차이 대문에 일정 수준의 독립성은 테스터가 결함을 더 효과적으로 찾게 해 준다. 그러나 독립성이 친숙함을 대체할 수 없으며 개발자도 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.

테스팅의 독립성 수준은 다음과 같다. (낮은 수준에서 높은 수준까지) : 

• 독립적인 테스터 없음 : 유일하게 개발자가 자신의 코드를 직접 테스트하는 형태
• 개발팀이나 프로젝트팀에 속한 독립적인 개발자나 테스터 : 개발자가 동료의 제품을 테스트하는 형태도 포함
• 조직 내 독립적인 테스트티미나 그룹이 프로젝트 관리자나 상위 관리자에게 직접 보고
• 비지니스 조직 또는 사용자 커뮤니티 소속이거나 사용성, 보안성, 성능, 준수성, 이식성 등 특정 테스트 분야를 전문으로 하는 독립적인 테스터
• 현장 또는 현장 외에서 일하는 조직 외부의 독립적인 테스터

테스트 독립성의 잠재적 이점

• 독립적인 테스터는 그들이 가지고 있는 다양한 배경, 기술적인 관점 , 성향이 달라 개발자와는 다른 유형의 장애를 찾아낼수 있다.
• 독립적인 테스터는 이해관계자가 시스템 명세를 정의하고 구현하면서 만든 가정에 대해 확인하고 이의를 제기하고 틀렸음을 입증할 수 있다.
• 벤더의 독립 테스터는 테스트할 시스템을 고용한 회사의 (정치적) 압박 없이 똑바로 그리고 객관적으로 보고할 수 있다.

테스트 독립성의 잠재적 단점

• 개발팀과의 고립으로 협업이 어려울 수 있고, 개발팀에게 피드백 전달이 늦어지고, 개발팀과 적대적인 관계가 형성 될 수 있다. 
• 개발자가 품질에 대한 책임감을 잃을 수 있다.
• 독립적인 테스터가 병목 현상의 장본인으로 비쳐질 수 있다.
• 독립적인 테스터는 중요한정보( 테스트 대상에 대한 정보)를 전달받지 못할 수 있다.

**5.1.2 테스트 관리자 및 테스터의 역할 ** (샘플 A - Q 30)

테스터 관리자의 역할 - 테스트 관리자의 업무는 테스트 프로세스에 대한 전반적인 책임과 테스트 활동을 성공적으로 이끄는 것이다. 테스트 관리자는 전문 테스트 관리자, 프로젝트 관리자, 개발 관리자, 품질 보증 관리자 역할을 맡을 수 있다.

• 조직의 테스트 정책과 테스트 전략을 개발하고 리뷰
• 정황을 고려한 테스트 활동과 테스트 목적과 리스크 이해를 바탕으로 테스트 활동을 계획, 예를들어 테스트 접근법 선택, 테스트 추정( 테스트 시간, 노력, 비용), 리소스 획득, 테스트 레벨과 테스트 주기정의, 결함 관리 등이 계획에 포함될 수 있다.
• 테스트 계획서 작성과 업데이트 
• 프로젝트 관리자, 제품 오너, 기타 관계자와 테스트 계획 관련 협의
• 통합 계획 등과 같은 다른 프로젝트 활동과 테스팅 관점 공유
• 테스트 분석, 설계, 구현, 실행 활동을 개시하고, 테스트 진행과 결과를 모니터링하며 종료 조건(또는 종료 조건 정의) 의 상태를 점검하고 테스트 완료 활동을 촉진
• 수집한 정보를 바탕으로 테스트 진행 상황 보고서나 이미 완료된 다른 테스트 프로젝트의 테스트
• 테스트 결과와 진행상황에 따라 계획을 조정하고 테스트 제어에 필요한 모든 조치를 취함
• 결함 관리 시스템과 테스트웨어에 적합한 형상 관리 체제 구축 지원
• 테스트 진척 상황 측정과 테스팅 및 제품 품질 평가를 위한 적절한 메트릭 도입
• 테스트 프로세스 지원용 도구 선택과 구현 지원. 예를 들자면 도구 선택 예산(경우에 따라 구입하거나 지원 비용까지) 에 대한 권고,  파일럿 프로젝트에 시간과 노력 할당, 도구 사용에 대한 지속적인 지원 제공 등
• 테스트 환경 구축에 관한 결정
• 조직에 테스터, 테스트팀, 테스트 활동을 홍보하고 지지를 요청
• 테스터의 역량과 경력 개발

테스터의 역할과 업무

• 테스트 계획을 리뷰하고 계획 작성에 참여
• 요구사항, 사용자 스토리와 인수조건, 명세, 모델(즉, 테스트 베이시스)의 테스트 용이성을 분석, 리뷰, 평가
• 테스트 컨디션을 식별 및 기록하고, 테스트 케이스, 테스트 컨디션, 테스트 베이시스 간의 추적성 설정
• 테스트 환경을 설계, 구축, 검증하고 필요한 경우 시스템 관리자, 네트워크 관리자와 협업
• 테스트 케이스와 테스트 프로시저를 설계 및 구현
• 테스트 데이터를 준비하고 획득
• 상세 테스트 실행 일정 수립
• 테스트를 실행하고 결과를 평과해, 기대 결과와 차이 기록
• 테스트 프로세스에 적합한 도구 사용
• 필요한 경우 테스트 자동화
• 수행 효율성, 신뢰성, 사용성, 보안성, 호환성, 이식성과 같은 비기능 품질 특성 평가
• 테스트 산출물 리뷰

5.2 테스트 계획과 추정

5.2.1 테스트 계획의 목적과 내용 -테스트 계획 활동은 제품의 수명주기 전반에 걸쳐 이루어지는 지속적인 활동.

• 테스팅의 범위 정의, 목적, 리스크 결정
• 전반적인 테스팅 접근법 정의
• 테스트 활동을 소프트웨어 수명주기 활동에 통합하고 조정
• 테스트 대상 다양한 테스트 활동에 필요한 인력과 기타 자원, 테스트 활동 수행 방법 결정
• 테스트 분석, 설계, 구현, 실행, 평가 활동의 일정 조정. 일정은 특정 날짜나 반복주기로 편성할 수 있다.
• 테스트 모니터링과 제어에 사용할 메트릭 선정
• 테스트 활동 예산 결정
• 테스트 문서의 구조와 상세화 정도 정의

5.2.2 테스트 전략과 테스트 접근법 - 테스트 전략은 테스트 프로세스의 일반적 모습을 반영한다.

• 분석적 : 특정요소에 대한 분석을 기반으로 한 테스트 전략. 리스크 수준에 따라 테스트를 설계하고 우선순위를 결정하는 리스크 기반 테스팅이 분석적 접근법의 예.
• 모델 기반 : 이러한 유형의 테스트 전략에서 테스트는 요구되는 제품의 특정 측면에 대한 모델을 기반으로 만들어 짐. 특정 측면에는 기능, 비지니스 프로세스, 내부 구조, 비기능 특성 등이 있다. 모델에는 비지니스 프로세스 모델, 상태 모델, 신뢰성 성장 모델 등이 있다.
• 방법론적 : 이 테스트 전략은 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용하는데 의존한다
• 프로세스 준수 또는 표준 준수 : 이 테스트 전략은 외부 규정이나 표준을 기반으로 테스트를  분석, 설계, 구현.
• 전문가 조언 또는 자문 : 이 테스트 전략은 주로 이해관계자, 비지니스 도메인 전문가, 기술 전문가 등의 조언, 지도 지시를 바탕으로 이루어진다. 이 사람들은 외부 테스트팀이나 외부 조직 소속일 수 있다.
• 리그레션-기피 : 기존 기능에 대한 리그레션 테스트를 기피를 목표로 한다. 이 테스트 전략에는 기존 테스트웨어( 특히 테스트 케이스와 테스트 데이터)의 재사용, 리그레션 테스트 자동화 확대, 테스트 스위트 표준화가 포함된다.
• 반응적 : 지금까지 소개한 사전 계획에 따라 실행하는 테스트 전략과는 달리 테스트 대상 컴포넌트나 시스템에 따라 대응하고 테스트 실행 중 발생하는 이벤트에 따라반응적으로 수행하는 테스트 접근법. 이전 테스트 결과에서 얻은 지식을 바탕으로 테스트를 설계하고 구현하며 즉각 테스트를 실행할 수 있다. 

5.2.3 시작 조건과 종료 조건( 준비의 정의와 완료의 정의 -애자일에서) - 활동의 시작 시점과 완료 시점에 대한 조건을 정의해 놓는 것이 좋다. 

시작 조건 

• 테스트 가능한 요구사항, 사용자 스토리나 모델의 가용 여부
• 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부
• 테스트 환경 가용 여부
• 필요한 테스트 도구 가용 여부
• 테스트 데이터와 기타 필요한 자원의 가용 여부

종료 조건

• 계획한 테스트 실행 완료
• 정의한 커버리지 수준( 예 : 요구사항, 사용자 스토리, 인수 조건, 리스크, 코드 등의 커버리지)의 도달
• 해결하지 못한 결함 수가 합의된 수보다 적음
• 추정 잔존 결함의 수가 충분히 적음
• 신뢰성, 수행 효율성 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달

5.2.4 테스트 실행 일정

테스트 케이스와 테스트 프로시저를 작성하고 (일부 프로시저는 가능하다면 자동화) 테스트 프로시저와 테스트 케이스를 조합해 테스트 스위트를 생성한 후 테스트 스위트의 순서를 정해 실행 일정을 만들 수 있다. 테스트 실행 일정에서 테스트 스위트를 어떤 순서로 실행할지 정의한다. 테스트 실행 일정을 만들 때는 우선순위, 종속관계, 확인 테스트, 리스레션 테스트, 가장 효율적인 테스트 실행 순서 등을 고려해야 한다.

테스트 케이스가 서로 종속 관계를 가지고 있다면 각자의 우선순위와 상관없이 필요에 따라 배치해야 한다.

상황에 따라테스트를 다양한 순서로 배치할 수 있으며 각 순서 배치에 따라 효율성 수준이 다를 수 있다. 이런 경우 테스트 실행 효율성과 우선순위 준수 간의 절충을 고려한 결정이 필요하다. (테스트 관리자 역할)

5.2.5 테스트 노력에 영향을 미치는 요소 - 테스트 노력 추정은 테스트 관련 작업에 필요한 노력의 양을 예측하는 활동으로 이는 특정 프로젝트, 릴리스, 반복주기에서 테스팅의 목적을 충족하는 데 필요하다.

• 제품 특성
• 제품과 관련된 리스크
• 테스트 베이시스의 품질
• 제품의 크기
• 제품 도메인의 복잡도
• 품질 특성 요구사항
• 요구되는 테스트 문서의 상세화 정도
• 법적, 규제 준수 요구사항

개발 프로세스 특성

• 조직의 안정성과 성숙도
• 사용하는 개발 모델
• 테스트 접근법
• 사용하는 도구
• 테스트 프로세스
• 시간적 압박

인력 특성

• 관련된 인원의 역량과 경험, 특히 유사한 프로젝트나 제품 관련( 도메인 지식)
• 팀 응집력과 리더십

테스트 결과

• 발견한 결함 수와 심각도
• 필요한 재작업 규모

5.2.6 테스트 추정 기법

- 충분한 테스팅을 하는 데 필요한 노력을 추정하는 예측 기법 몇 가지가 있다.

• 메트릭 기반 기법 : 기존 유사한 프로젝트에서 얻은 메트릭에 기반하거나 보편적인 값을 바탕으로 테스트 노력 예측
• 전문가 기반 기법 : 테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측

5.3 테스트 모니터링과 제어

- 테스트 모니터링의 목적은 정보 수집 및 테스트 활동에 대한 피드백과 가시성 제공. 모니터링 대상 정보는 수동 혹은 자동으로 수집할 수 있고, 테스트 진행 상황을 평가하는 데 활용한다. 그리고 테스트 종료 조건을 만족하는지 또는 애자일 프로젝트에서 완료의 정의와 관련된 테스팅 작업을 만족하는지 측정하는 데 이용.

테스트 제어는 수집하고 보고된 정보와 메트릭의 결과로 취해진 수정 조치나 가이드를 의미한다 수정조치는 어떤 테스트 활동을 커버하거나 소프트웨어 수명주기 활동에 영향을 미칠수 있다.

테스팅 제어 활동의 예

• 식별한 리스크 발생 시 테스크 우선순위의 변경
• 테스트 환경이나 기타 자원의 가용 여부에 따라 테스트 일정 변경
• 재작업으로 인해 테스트 항목이 시작 조건이나 종료 조건 만족하는지 재평가

5.3.1 테스팅에 사용하는 메트릭

테스팅 활동 중이나 종료 시점에 아래와 같은 사항을 평가하기 위해 메트릭을 수집할 수 있다.

• 계획한 일정과 예산 대비 진행 상황
• 테스트 대상의 현재 품질
• 테스트 접근법의 타당성
• 목적 대비 테스트 활동의 효과

일반적인 테스트 메트릭

• 계획 대비 테스트 케이스 준비 작업 완료율 ( 또는 계획 대비 테스트 케이스 작성률)
• 계획 대비 테스트 환경 준비 작업 완료율
• 테스트 케이스 실행률(예- 수행한/수행하지 않은 테스트 케이스 수 , 테스트 케이스 합격/불합격 수, 테스트 컨디션 합격/ 불합격 수)
• 결함 정보
• 요구사항 커버리지, 사용자 스토리 커버리지, 인수 기준 커버리지, 리스크 커버리지, 코드 커버리지
• 작업 완료 , 자원 할당과 사용, 노력
• 다음 결함을 발견하면 얻는 이익 대비 비용이나 테스트를 계속 실행해 얻게 되는 이익 대비 비용 등을 포함하는 테스팅 비용

5.3.2 테스트 보고의 목적, 내용 , 독자 

테스트 보고의 목적은 테스트 활동 중이나 마무리 시점의 테스트 활동 정보 요약과 공유이다. 테스트 활동 중 작성하는 테스트 보고서는 테스트 진행 상황 보고사, 테스트 활동 종료 시점에 작성하는 테스트 보고서는 테스트 요약 보고서라고 부르기도 한다.

상황 보고서에 들어가는 정보는 아래와 같다

• 테스트 계획 대비 테스트 활동과 진행 상황
• 진행을 방해하는 요소
• 다음 보고 기간에 진행하기로 계획한 테스팅
• 테스트 대상의 품질

종료 조건을 만족하면 테스트 관리자는 테스트 요약 보고서를 작성한다.

일반적인 테스트 요약 보고서는 다음과 같은 내용을 포함.

• 테스팅 수행 내용 요약
• 테스트 기간 도중에 발생한 상황 정보
• 계획 대비 편차
• 종료 조건 및 완료의 정의에 대한 테스팅 현황과 제품 품질
• 진행을 방해했거나 계속해서 방해하고 있는 요소
• 메트릭
• 잔존 리스크
• 재사용 가능한 테스트 작업 산출물

5.4 형상 관리

- 형상 관리의 목적은 프로젝트와 제품 수명주기 동안 컴포넌트나 시스템, 테스트웨어와 이들 서로간의 관계 통합을 수립하고 유지하는 데 있다. 형상 관리는 테스팅을 적절히 지원하고 아래 내용을 확인한다.

• 모든 테스트 항목에 고유 식별번호를 부여하고, 버전을 관리하고, 변경 이력을 기록한다. 형상 관리에서 테스트 항목은 서로 연관돼 있다.
• 모든 테스트웨어 항목에 고유 식별번호를 부여하고, 버전을 관리하고 , 변경사항을 추적하고, 서로 연결해 테스트 항목 버전과도 연결되도록 해서 테스트 프로세스 전반에 걸쳐 추적성을 유지할 수 있게 한다.
• 식별한 모든 문서와 소프트웨어 아이템은 테스트 문서 내에서 명확하게 상호 참조되도록 한다.

테스트 계획을 수립하면서 형상관리 절차와 인프라(도구)를 식별하고 구현해야 한다.

5.5 리스크와 테스팅 

5.5.1 리스크의 정의

리스크란 미래에 부정적 결과를 가져오는 이벤트의 발생 가능성이다. 리스크 수준은 이벤트 발생 가능성가 이벤트로 인한 영향도(피해)로 결정한다.

5.5.2 제품 및 프로젝트 리스크

제품 리스크는 작업 산출물이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성이다. 제품리스크가 제품의 특정 품질 특성( 예 : 기능 안전성, 신뢰성, 성능 효율성, 사용성, 보안성,호환성, 유지보수성, 이식성)과 연관되는 경우 품질 리스크라고 한다. 

제품리스크의 예

• 소프트웨어가 명세에서 의도한 기능을 수행하지 못함
• 소프트웨어가 사용자, 고객이나 이해관계자가 요구하는 기능을 수행하지 못함
• 시스템 아키텍처가 일부 비기능 요구사항을 충분히 지원하지 못함
• 특정 계산식이 특정 상황에서 올바르게 수행되지 못함
• 루프 제어 구조 코딩이 잘못됨
• 고성능 거래 처리 시스템의 응답 시간이 적절하지 않음
• 사용자 경험 피드백이 제품 기대치에 미치지 못함

프로젝트 리스크는 발생하면 프로젝트 목적 달성 능력에 부정적인 영향을 줄 수 있는 상황이다.

예

• 프로젝트 이슈 :
  • 배포, 작업 완료, 종료조건이나 완료의 정의를 만족하지 못하고 지연된다.
  • 부정확한 추정, 우선순위가 높은 프로젝트에 예산 재배정, 또는 조직 전반에 걸친 예산 삭감으로 예산이 부족할 수 있다.
  • 프로젝트 후반에 발생하는 변경은 상당한 재작업을 불러올 수 있다.
• 조직 이슈 : 
  • 역량 교육 인력이 부족할수 있다.
  • 개인적인 문제로 갈등이나 문제가 생길수 있다.
  • 사용자, 비지니스 인력, 해당 분야 전문가들이 비즈니스 우선순위 마찰로 참여하지 못할 수 있다.
• 정치적 이슈
  • 테스터가 필요한 사항이나 테스트 결과를 제대로 전달하지 못할 수 있다.
  • 개발자나 테스터가 테스팅과 리뷰도중 발견한 사항에 대한 후속 조치를 못할 수 있다.
  • 테스팅에 대한 잘못된 태도나 기대가 있을 수 있다
• 기술적 이슈
  • 요구사항이 충분히 잘 정의되지 않을 수 있다.
  • 기존 제약 사항으로 요구사항을 만족하지 못할 수 있다.
  • 테스트 환경이 필요한 시점에 준비되지 않을 수 있다.
  • 데이터 변환, 마이그레이션 계획 및 도구 지원이 필요한 시점에 제공되지 않을 수 있다.
  • 개발 프로세스의 약점은 프로젝트 작업 산출물의 품질이나 일관성에 영향을 줄 수 있다.
  • 결함 관리가 부실하고 기타 유사한 문제 때문에 축적된 결함이나 기타 기술적 부채를 가져올 수 있다.
• 공급자 이슈
  • 외부 공급자가 필요한 제품이나 서비스를 공급하지 못하거나 파산할 수있다.
  • 계약 관련 이슈로 프로젝트에 문제가 생길 수 있다.

5.5.3 리스크 기반 테스팅과 제품 품질 

리스크는 테스팅 노력을 집중하는 데 사용된다.  리스크 기반 접근법은 제품 리스크 수준을 조기에 낮추는데 기여한다. 리스크 기반 테스팅은 제품 리스크식별과 리스크 발생 가능성과 영향을 평가하는 제품 리스크 분석을 포함한다.

리스크 기반 접근법에서 제품 리스크 분석 결과

• 사용할 테스트 기법 결정
• 수행할 테스트 레벨과 유형 확정
• 테스트 수행 범위 결정
• 가능한 조기에 심각한 결함을 발견하기 위해 테스트 우선순위 결정
• 기존 테스팅 활동 외 리스크 완화를 위한 다른 활동의 식별

리스크 관리 활동 - 리스크 기반 테스팅은 프로젝트 이해관계자의 집단 지식과 통찰력을 기반으로 제품 리스크를 분석한다. 제품 장애 발생 가능성을 최소하하기 위해 리스크 관리 활동은 다음과 같은 절차를 따르게 된다.

• 잘못될 수 있는 것을 분석
• 처리해야 할 중요한 리스크가 무엇인지 판단
• 해당 리스크를 완화하기 위한 행동 구현
• 리스크의 실제 발생을 대비한 대책 수립

5.6 결함 관리 

 - 테스팅의 목적 중 하나가 결함을 찾는 것이기 때문에 테스팅 중 발견한 결함은 반드시 기록해야 한다. 결함을 기록하는 방법은 테스트 대상 컴포넌트나 시스템의 정황, 테스트 레벨, 소프트웨어 개발 수명주기 모델에 따라 달라진다. 찾아낸 모든 결함은 조사하고, 발견에서 결함 분류까지 추적해야 한다. 모든 결함응ㄹ 해결까지 관리하기 위해 조직은 결함 관리 프로세스( 워크플로우와 결함 분류 규칙)를 수립해야 한다. 아키텍처, 설계자, 개발자, 테스터, 제폼오너 등 결함 관리에 참여하는 모든 사람이 프로세스에 동의해야 한다. 일부 조직에서는 결함 로깅과 추적이 매우 비공식적일 수 있다.

효율적이고 효과적인 결함 관리 프로세스를 위해 조직은 결함의 속성, 분류, 워크플로우에 대한 표준을 정의해 놓을 수 있다.

일반적인 결함 보고서의 목적

• 발생한 모든 부정적인 이벤트 정보를 개발자와 기타 관계자에게 제공해 구체적인 영향을 식별하고, 재현 테스트로 문제를 격리하고, 잠재 결함을 수정하고, 필요에 따라서 문제를 해결할 다른 방법을 찾을 수 있도록 한다.
• 테스트 관리자에게 작업 산출물의 품질과 테스팅 영향을 추적할 방법을 제공한다.
• 개발과 테스트 프로세스 개선에 대한 아이디어를 제공한다.

동적 테스팅에서 작성하는 결함 보고서의 내용

• 식별 번호
• 제목, 보고하는 결함에 대한 짧은 요약
• 결함 보고 날짜, 보고 주체 조직 및 작성자
• 테스트 항목 식별자와 환경
• 결함을 발견한 개발 수명주기 단계
• 로그 데이터베이스덤프 , 스크린샷, 녹화기록등의 결함 재현과 해결을 위한 설명
• 기대 및 실제 결과
• 이해관계자의 관점에서의 결함 영향도의 범위와 정도
• 수정 우선수위
• 결함보고서의 상태
• 결혼, 의경 승인 여부
• 글로벌 이슈
• 변경이력
• 참조

- 용어 - 

에픽

테스트 프로시저

액티비티 다이어그램

3.1 정적 테스팅 기초 - 작업 산출믈 수동으로 검사(리뷰)하거나 코드나 다른 작업 산출물을 도구 기반으로 평가(정적분석)하는 방법에 의존한다. 두 가지 유형의 정적테스팅 모두 테스트 중인 코드 또는 작업 산출물을 실제로 실행하지 않고 평가.

3.1.1 정적테스팅으로 검토할 수 있는 작업 산출물

대부분의 작업 산출물은 정적 테스팅(리뷰나 정적분석)으로 검사할 수 있음.

• 비지니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
• 에픽, 사용자 스토리, 인수기준
• 아키텍처 및 설계 명세
• 코드
• 테스트 계획, 테스트 케이스, 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어
• 사용자 가이드
• 웹페이지
• 계약, 프로젝트 계획, 일정, 예산 기획
• 형상 및 인프라 셋업
• 엑티비티 다이어그램과 같은 모델 기반 테스팅에서 사용되는 모델

3.1.2 정적 테스팅의 효과 

• 동적 테스트 실행 전에 보다 효율적으로 결함을 발견하고 수정
• 동적테스팅으로 발견이 쉽지 않은 결함 식별
• 요구사항 불일치, 애매 모호함, 모순, 누락, 부정확, 중복 등을 식별해서 설계나 코딩의 결함 예방
• 개발 생산성 향상(예 설계개선, 향상된 코드 유지보수성)
• 개발 비용 및 기간 단축
• 테스팅 비용 및 기간 단툭
• 수명주기 후반 또는 출시 후 운영과정에서 발견되는 장애 감소로 소프트웨어 수명주기 전반에 걸친 총 품질 비용 감소
• 리뷰에 참여하는 팀원 간의 의사소통 개선

3.1.3 정적 테스팅과 동적 테스팅의 차이 - 공통된 목적은 작업 산출물의 품질을 평가하고 가능한 빨리 결함을 식별하는 것. 정적 테스팅과 동적 테스팅은 발견하는 유형의 결함이 서로 달라 상호 보완적이다.

가장 중요한 차이점 중 하나는 정적 테스팅은 소프트웨어를 심행하지 않고 결함을 직접 발견하는 것. 

정적 테스팅은 작업 산출물의 일관성과 내부 품질을 향상하기 위해 사용 하는 반면, 동적 테스팅은 일반적으로 외부에서 보이는 동작에 초점을 맞춤.

일반적인 정적 테스트에서의 결함

• 요구사항 결함 ( 불일치, 모호함, 모순, 누락, 부정확, 중복 등)
• 설계 결함 ( 비효율적인 알고리즘이나 데이터베이스 구조, 높은 결함도, 낮은 응집도 등)
• 코딩 결함 (정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
• 표준과의 차이 ( 코딩 표준 미준수 등)
• 잘못된 인터페이스 명세 ( 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
• 보안 취약점 ( 오버플로우)
• 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성( 특정 인수 조건에 대한 테스트 누락)
• 유지 보수성 결함 ( 잘못된 모듈화, 낮은 컴포넌트 재사용성 등)

3.2 리뷰 프로세스 - 합의된 리뷰 목적에 따라 결정(결함발견, 이해 향상, 테스터와 신규 팀원 등과 같은 참여자에 대한 교육 또는 토론과 합의에 의한 결정)

3.2.1 작업 산출물 리뷰 프로세스 

• 계획 
• 리뷰 착수
• 개별 리뷰
• 이슈 논의 및 분석
• 수정 및 보고

계획

• 리뷰 목적, 리뷰할 문서가 전체인지 특정 부분인지, 평가할 품질 특성 등을 포함하는 범위의 정의
• 노력과 기간 추정
• 리뷰 유형에 따라 결정되는 역할, 활동, 체크리스트와 같은 리뷰 특성의 식별
• 리뷰에 참석할 인원을 선정하고 역할 할당
• 인스펙션과 같은 보다 공식적인 리뷰의 경우에는 시작 및 종료 조건 정의
• 시작 조건이 충족되는지 확인

리뷰 착수

• 작업 산출물과 이슈 기록 양식, 체크리스트, 관련된 작업산출물과 같은 기타 자료 배포
• 참가자에게 범위, 목적, 프로세스, 역할, 작업 산출물을 설명
• 참가자가 리뷰에 대해 가질 수 있는 여러 질문에 답변

개별 리뷰

• 작업 산출물 전체 혹은 부분 리뷰
• 잠재 결함, 권고사항, 질문 기록

이슈 논의 및 분석

• 식별한 잠재 결함 전달
• 잠재 결함 분석 및 담당자 및 상태 할당
• 품질 특성 평가 및 문서화
• 종료 조건을 기준으로 리뷰 결과를 평가하여 리뷰 결과 결정

수정 및 보고

• 작업 산출물에 대한 수정을 요하는 잠재 결함에 대한 결함 보고서 작성
• 리뷰한 작업 산출물에서 발견한 결함 수정(일반적으로 저자가 수정)
• 결함 정보를 적절한 사람이나 팀과 공유
• 필요한 경우 주석 작성자의 동의를 포함해 업데이트된 결함 상태 기록
• 메트릭 수집
• 종료 조건의 충족여부 확인
• 종료 조건이 충족되면 해당 작업 산출물 인수

3.2.2 공식 리뷰에서의 역할과 책임

 저자, 관리자, 촉진자, 리뷰 리더, 검토자, 서기, (인스펙션에서는 낭독자도 가능)

저자

• 리뷰 대상 작업 산출물 작성
• 리뷰 대상 작업 산출물 결함 수정

관리자

• 리뷰 계획 담당
• 리뷰 실행 결정
• 인력, 예산, 시간 할당
• 진행 비용 대비 효과 모니터링
• 결과가 만족스럽지 않은 경우 제어 결정 실행

촉진자

• 리뷰 회의 진행 시 효과적 회의 진행 보장
• 필요한 경우 다양한 관점들에 대한 중재
• 많은 경우 리뷰의 성공 여부에 결정적인 역할을 하는 사람

리뷰 리더

• 전반적으로 리뷰에 대한 책임을 지는 사람
• 참여를 결정하고 언제 어디서 진행할지 결정

검토자 

• 해당 주제에 대한 전문가, 프로젝트 참여 인원, 작업 산출물에 관심이 있는 이해관계자나 특정 기술 혹은 비지니스 배경을 가진 사람등
• 리뷰 대상 작업 산출물의 잠재적 결함 식별
• 다양한 관점을 대표할 수 있음.

서기

• 개별 리뷰 활동에서 발견한 잠재 결함 수집
• 리뷰 회의가 진행되는 경우 새로운 잠재 결함, 쟁점, 결정, 사항 기록

3.2.3 리뷰 유형 -리뷰를 다양한 목적으로 활용할 수 있지만, 주된 목적 중 하나는 결함 발견.

비공식 리뷰

(ex - 버디 체크, 페어링, 짝 리뷰)

• 주요 목적 : 잠재적 결함 발견
• 기타 목적 : 새로운 아이디어나 해결책 도출, 소소한 문제의 빠른 해결
• 공식 프로세스를 기반으로 하지 않음
• 리뷰 회의를 진행하지 않을 수 있음
• 저자의 동료 (버디 체크) 또는 다른 사람이 수행할 수 있음
• 결과는 문서로 기록할 수 있음
• 검토자에 따라 성과가 달라짐
• 체크리스트 사용 여부는 상황에 맞게 판단
• 에자일 개발에서 매우 일반적으로 사용됨

워크쓰루

• 주요 목적: 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가
• 기타 목적: 다양한 기술이나 스타일에 대한 아이디어 교환, 참여자 교육, 합의 도출
• 리뷰 회의 전 개별 준비는 필요에 따라 수행
• 리뷰 회의는 일반적으로 작업 산출물의 저자가 주도
• 서기 참여 필수
• 체크리스트 사용 여부는 상황에 맞게 판단
• 시나리오, 드라이 런, 시뮬레이션의 형태로 수행할 수 있음
• 잠재 결함 로그와 리뷰 보고서 작성
• 실무에서는 비공식적인 형식에서 매우 공식적인 형식까지 다양할 수 있음

기술 리뷰

• 주요 목적: 합의 도출, 잠재적 결함 발견
• 기타 목적: 작업 산출물의 품질 평가 및 자신감 획득, 새로운 아이디어 도출, 저자가 미래의 작업 산출물을 개선하도록 지원하고 동기를 부여, 다른 구현 방법 고려
• 검토자는 저자의 기술 동료이면서, 동일 분야 또는 다른 분야의 기술 전문가여야 함
• 리뷰 회의 전 개별 준비 필요
• 리뷰 회의는 선택 사항이며, 이상적으로는 훈련된 촉진자(일반적으로 저자가 아닌)가 주도
• 서기는 반드시 있어야 하며, 이상적으로는 저자가 아닌 사람이 수행
• 체크리스트 사용 여부는 상황에 맞게 판단
• 잠재 결함 로그와 리뷰 보고서 작성

인스펙션

• 주요 목적: 잠재적 결함 발견, 작업산출물의 품질 평가 및 자신감 획득, 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방
• 기타 목적: 저자가 앞으로의 작업 산출물과 소프트웨어 개발 프로세스를 개선하고 합의를 이끌어 내도록 동기를 부여
• 규칙 및 체크리스트를 기반으로 공식 문서 산출물을 작성하는 정의된 프로세스를 수행
• 3.2.2절에서 필수로 지정한 바와 같이 명확하게 정의된 역할 참여, 낭독자 (리뷰 회의중 작업 산출물을 종종 자신의 말로 의역하고 소리내어 읽는 사람)의 참여 가능
• 리뷰 회의 전 개별 준비 필요
• 검토자는 저자의 동료 또는 작업 산출물과 연관된 분야의 전문가
• 명시된 시작 및 종료 조건을 사용
• 서기 차여 필수
• 리뷰 회의는 훈련받은 촉진자(저자가 아닌 사람)가 주도
• 저자는 리뷰 리더, 글을 읽는 사람 또는 서기가 될 수 없음
• 잠재적인 결함 로그 및 리뷰 보고서 작성
• 인스펙션 프로세스 포함 전체 소프트웨어 개발 프로세스를 개선하기 위해 메트릭을 수집하고 사용

3.2.4 리뷰 기법 적용

개별 리뷰 활동 중에 결함을 발견하기 위해 사용할 수 있는 리뷰 기법

• 에드혹 - 검토자에게 리뷰 수행 방법에 대한 안내가 거의 또는 전혀 제공되지 않는다. 검토자는 대부분의 경우 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록. 이 기법은 능력에 크게 의존하며, 여러 검토자가 동일한 문제를 보고할 수 있음.
• 체크리스트 기반 - 체계적인 기법으로, 검토자는 리뷰 시작 시점에 배포된 체크리스트(촉진자에 의해) 를 기반으로 이슈를 식별한다. 리뷰 체크리스트는 잠재 결함을 식별하기 위해 경험에서 도출한 일련의 질문으로 구성. 체크리스트는 리뷰 대상 작업 산출물 유형별로 작성해야 하며 이전 리뷰에서 누락된 이슈 유형을 다루기 위해 주기적으로 개선할 필요가 있음. 체크리스트 기반 기법의 주요 장점은 일반적인 결함유형에 대한 체계적인 커버리지를 갖는 점.
• 시나리오 및 드라이 런 - 시나리오 기반 리뷰에서 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공. 시나리오 기반 리뷰는 작업 산출물에 예상되는 용도를 기반으로 작업 산출물(유스케이스와 같이 적절한 형식의로 문서화된 경우) 에 대해 "드라이런"을 수행할 수 있도록 검토자를 지원. 다른 결함 유형을 발견하기 위해 검토자는 기록된 시나리오에만 너무 얽매이지 않아야 함.
• 관점 기반 - 관점 기반 읽기는 역할 기반 리뷰와 마찬가지로 검토자가 개별 리뷰 중 다양한 이해관계자의 관점을 사용하게 됨. 일반적을 ㅗ사용되는 이해관계자 관점에는 최종 사용자, 영업, 설계자, 테스터, 운영자 등이 있다. 서로 다른 이해 관계자 관점을 사용하면, 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행됨. 관점 기반 읽기가 요구사항 및 기술 작업 산출물에 대한 리뷰에 가장 효과적인 기법. 주요 성공 요인은 리스크 기반으로 다양한 이해관게자의 관점을 적절하게 포함시키고 평가하는것.
• 역할 기반 - 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법. 

3.2.5 리뷰의 성공 요소 

• 각 리뷰는 명확한 목적이 있어야 함. 목적은 리뷰 계획 시 정의하며, 측정 가능한 종료 조건으로 사용
• 목적을 달성하기에 적합하고, 소프트웨어 작업 산출물 및 참여자 유형 수준에 맞는 리뷰 유형을 적용
• 체크리스트 기반 및 역할 기반 리뷰와 같이 사용하는 모든 리뷰 기법은 리뷰 대상 작업 산출물의 결함을 효과적으로 식별하기에 적함해야 한다.
• 사용하는 체크리스트는 주요 리스크 식별을 위해 작성해야 하며, 가장 최신의 정보를 반영해야 함.
• 규모가 큰 문서는 작은 단위로 작성하고 리뷰를 수행해 저자에게 결함에 대한 피드백을 조기에 그리고 빈번하게 제공함으로써 관리를 수행
• 참여자는 충분한 준비 시간을 갖는다.
• 리뷰는 기업의 품질 테스트 정책에 통합된다.

- 용어 - 

인수 테스팅 - 시스템이 사용자의 필요 및 요구사항, 비즈니스 프로세스 측면에서 인수 조건을 만족하는지 확인하고 사용자, 고객, 기타 권한을 지닌 사람이 시스템의 인수 여부를 결정하기 위해 수행하는 공식 테스팅 

테스트 인프라 - 테스트 환경, 테스트 도구, 사무환경 및 절차로 구성된 테스트를 수행하는 데 필요한 조직 산출물

2.1 소프트웨어 개발 수명주기 모델

2.1.1 소프트웨어 개발과 소프트웨어 테스팅

 모든 소프트웨어 개발 수명주기 모델에 적용하기 좋은 테스팅의 특성

• 모든 개발 활동은 그에 사응하는 테스트 활동이 있다.
• 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 가진다.
• 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 한다.
• 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물(ex 요구사항, 설계 등)의 초안이 나오는 즉시 리뷰에 참여한다.

어떤 소프트웨어 개발 수명주기 모델을 선택하더라도 테스팅을 초기에 시작하면 시간과 비용을 절약할 수 있다는 테스트 원리에 따라, 테스트 활동은 수명주기 초반에 시작해야 한다.        

이 실라버스에서 대표적인 소프트웨어 개발 수명주기 모델

• 순차적 개발 모델 - 개발 프로세스의 모든 단계는 이전 단계가 완료될 때 시작돼야 함. 폭포수 모델(순차적 - 요구사항 분석 , 설계, 코딩, 테스팅) ,V-모델 - 각 개발 단계에 테스트 레벨을 부여함. 각 테스트 레벨의 테스트 실행이 순차적으로 이루어져 있음.
• 반복적 개발 모델 - 기능 집합을 종종 고정된 기간의 일련의 주기 안에서 같이 명시, 설계, 구축, 테스트할 때 발생. 반복 주기에는 전체 프로젝트 범위에 대한 변경이나 기존 반복주기 동안 개발한 기능에 대한 수정 포함.
• 점진적 개발 모델 - 요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행. 소프트웨어 기능은 점진적으로 늘어남.

반복적 개발 모델 대표적인 예

• 래셔널 통합 프로세스
• 스크럼
• 칸반
• 나선형

*2.2 테스트 레벨 *

 테스트 레벨이란 함께 분류되고 관리되는 테스트 활동의 집합을 지침.

 실라버스에서 다루고 있는 테스트 레벨이며 구체적인 목적/ 테스트 케이스를 도출하기 위해 참고하는 테스트 베이시스/ 테스트 대상/ 일반적인 결함과 장애/ 구체적인 접근법 -> 같은 특성을 기준으로 분류. 

• 컴포넌트 테스팅(유닛)
• 통합 테스팅
• 시스템 테스팅
• 인수 테스팅

2.2.1 컴포넌트 테스팅

컴포넌트 테스팅의 목적 - 개별적으로 테스트할 수 있는 컴포넌트에 초점 

• 리스크 완화
• 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
• 컴포넌트 품질 수준에 대한 자신감 획득
• 컴포넌트에 존재하는 결함 발견
• 다음 단계로의 결함 전이 방지

테스트 베이시스 -컴포넌트 테스팅의 테스트 베이시스로 사용할 수 있는 대표적인 작업 산출물 

• 상세 설계
• 코드
• 데이터 모델
• 컴포넌트 명세

테스트 대상 

• 컴포넌트, 단위, 모듈
• 코드 및 데이터 구조
• 클래스
• 데이터베이스 모듈

* 대표적인 결함과 장애

• 잘못된 기능(설계 명세의 설명과 다름)
• 데이터 흐름 문제
• 잘못된 코드 및 논리

2.2.2 통합 테스팅

통합 테스팅의 목적 - 컴포넌트나 시스템 간의 상호작용에 초점을 맞춰서 진행한다.

• 리스크 완화
• 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단
• 인터페이스 품질 수준에 대한 자신감 획득
• 결함 발견
• 다음 단계로의 결함 전이 방지                                                                                                           

통합 테스팅 - 컴포넌트 통합 테스팅 , 시스템 통합 테스팅

• 컴포넌트 통합 테스팅 - 통합된 컴포넌트 간의 상호운용성과 인터페이스에 초점
• 시스템 통합 테스팅 - 시스템, 패키지, 마이로 서비스 간의 상호운용성과 인터페이스에 초점

테스트 베이시스

• 소프트웨어 및 시스템 설계
• 시퀀스 다이어그램
• 인터페이스 및 통신 프로토콜 명세
• 유스 케이스
• 컴포넌트나 시스템 레벨의 아키텍처
• 워크플로우
• 외부 인터페이스 정의서

테스트 대상

• 서브시스템
• 데이터베이스
• 인프라
• 인터페이스
• APls
• 마이크로 서비스

일반적인 결함과 장애

- 컴포넌트 통합 테스팅

• 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
• 잘못된 인터페이스 콜 순서나 타이밍
• 인터페이스 불일치 
• 컴포넌트 간의 통신 장애
• 컴포넌트 간의 통신 실패 처리 누락 및 오류
• 컴포넌트 간 주고받는 데이터의 의미, 단위, 경계에 대한 잘못된 가정

- 시스템 통합 테스팅

• 시스템 간의 일관적이지 않은 메시지 구조
• 잘못된 데이터, 누락된 데이터, 잘못된 데이터 인코딩
• 인터페이스 불일치
• 시스템 간의 통신 장애
• 시스템 간의 통신  실패 처리 누락 및 오류
• 시스템 간 주고받은 데이터의 의미, 단위, 경계에 대한 잘못된 가정
• 필수 보안 규정 준수 실패

2.2.3 시스템 테스팅

시스템 테스팅 목적 - 전체 시스템 또는 제품 동작이나 능력에 관심을 가지며, 시스템이 수행할 엔드-투-엔드 작업과 그런 작업을 수행할 때 나타나는 비기능 동작을 고려하는 경우가 많음.

• 리스크 완화
• 시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는 검증
• 완성된 시스템이 기대한 대로 동작하는지 확인
• 전체 시스템 품질에 대한 자신감 획득
• 결함 발견
• 결함이 상위 테스트 레벨이나 생산 단계로의 전이 방지

테스트 베이시스

• 시스템 및 소프트웨어 요구사항 명세)(기능/비기능)
• 리스크 분석 보고서
• 유스케이스
• 에픽과 사용자 스토리
• 시스템 동작 모델
• 상태 다이어그램
• 시스템 및 사용자 메뉴얼

테스트 대상

• 애플리케이션
• 하드웨어/소프트웨어 시스템
• 운영 시스템
• 테스트 대상 시스템
• 시스템 설정과 설정 데이터

결함과 장애

• 잘못된 연산
• 시스템의 잘못되거나 예상치 못한 기능/비기능 동작
• 시스템 내 잘못된 제어 및 데이터 흐름
• 엔드-투-엔드 기능 작업 수행 실패
• 시스템 환경에서 시스템의 정상 동작 실패
• 시스템 및 사용자 메뉴얼대로의 시스템 동작 실패

2.2.4 인수 테스팅

인수 테스팅의 목적 - 시스템 테스팅과 마찬가지로 인수 테스팅도 전체 시스템 또는 제품의 동작이나 능력에 초점을 두고 진하는 경우 

• 전체 시스템의 품질에 대한 자신감 획득
• 완성된 시스템이 기대한 대로 동작하는지 확인
• 시스템의 기능/비기능 동작이 명세대로 동작하는지 검증

인수 테스팅 - 사용자 인수 테스팅/ 운영 인수 테스팅/ 계약 및 규제 인수 테스팅/ 알파 및 베타 테스팅

사용자 인수 테스팅 - 일반적으로 실제 또는 시뮬레이션된 운영 환경에서 예정된 사용자가 사용하기에 얼마나 적합한지 확인하는데 관심을 둔다.

운영 인수 테스팅 - 운영자 또는 시스템 관리 직원에 의해 수행되는 시스템 인수 테스팅(시뮬레이션된) 생산 환경에서 이루어지는 경우가 많다. 가장 중요한 목적은 운영자 또는 시스템 관리자가 비록 예외적이고 어려운 조건에서라도 운영 환경에서 사용자를 위해 시스템을 정상적으로 유지할 수 있다는 자신감을 얻는 것이다. 테스트는 운영 측면에 집중돼 있으며, 다음을 포함할 수 있다.

• 백업 및 복원 테스팅
• 설치, 삭제, 업그레이드
• 긴급 복구
• 사용자 관리
• 유지보수 작업
• 데이터 로딩 및 이관 작업
• 보안 취약점 확인
• 성능 테스팅

계약 및 규제 인수 테스팅 - 주문 개발 소프트웨어의 생산을 위한 계약서에 명시된 인수 조건을 가지고 수행. 인수 조건은 모든 계약 당사자가 계약에 동의할 때 정의. 계약 인수 테스팅은 사용자나 독립적인 테스터가 수행하는 경우가 많음.

규제 인수 테스팅은 정보, 법적, 안전 규제 등과 같이 준수해야 하는 모든 규제를 가지고 수행. 규제 인수 테스팅은 사용자나 독립적인 테스터가 수행하는 경우가 많음. 규제 기관이 결과에 대한 실사나 감사를 진행하기도 한다.

계약 및 규제 인수 테스팅의 가장 중요한 목적은 계약이나 규제 준수에 대한 자신감 획득.

알파 및 베타 테스팅 - 소프트웨어 제품을 시장에 출시하기 전에 기존 혹은 신규 사용자, 고객, 운영자 등으로부터 피드백을 받기 원하는 사용 소프트웨어 개발자가 사용하는 경우가 많다. 

알파 테스팅 - 개발 조직의 현장에서 개발팀이 아닌 신규 혹은 기존 고객이나 운영자, 독립적 테스트팀이 수행.

베타 테스팅 - 신규 혹은 기존 고객이나 운영자가 자신의 환경에서 수행.

목적 - 신규 혹은 기존 고객이나 운영자가 시스템을 일반적인 조건과 운영환경에서 사용해 자신의 목적을 최소한의 어려움, 비용, 리스크 등으로 완수할 수 있다는 자신감을 획득. 또 다른 목적은 시스템을 사용할 조건 및 환경과 관련된 결함의 발견일 수 있음.

테스트 베이시스

• 비지니스 프로세스
• 사용자 또는 비즈니스 요구사항
• 규제, 법적 계약, 표준
• 유스케이스 및 사용자 스토리
• 시스템 요구사항
• 시스템 또는 사용자 문서
• 설치 절차
• 리스크 분석 보고서

일반적인 테스트 대상

• 테스트 대상 시스템
• 시스템 설정과 설정 데이터
• 완전히 통합된 시스템의 비지니스 프로세스
• 복원 시스템이나 비즈니스 연속성 및 긴급 복구 테스팅을 위한 핫 사이트
• 운영 및 유지보수 프로세스
• 양식
• 보고서
• 기존 및 전환된 생산 데이터

일반적인 결함과 장애

• 비즈니스나 사용자 요구사항을 충족하지 못하는 시스템 워크플로우
• 잘못 구현된 비즈니스 규칙
• 계약 혹은 규제 요구사항을 충족하지 못하는 시스템
• 보안 취약성, 많은 부하가 걸렸을 떄 성능 효율성 저하, 지원 대상 플랫폼상에서의 잘못된 운영 등과 같은 비기능 장애

2.3 테스트 유형

테스트 유형 - 특정 테스트 목적을 위해 소프트웨어 시스템이나 시스템의 일부 특정 속성을 테스트하는 활동의 집합

• 완전성, 정확성, 적합성 등과 같은 기능 품질 특성 평가
• 신뢰성, 성능 효율성, 보안성, 호환성, 사용성 등과 같은 비기능 품질 특성 평가
• 컴넌트나 시스템의 아키텍처 및 구조가 정확하고 완전하며 명시된 것과 일치하는지 평가
• 수정의 효과 평가. 예를 들어, 결함이 수정됐는지 확인(확인테스팅)하고 소프트웨어나 환경의 변화로 인해 동작에 의도하지 않은 변화가 없는지(리그레션 테스팅) 평가 

2.3.1 기능 테스팅 - 시스템이 수행해야 하는 기능을 평가하기 위한 테스트를 포함. 기능이란 시스템이 해야 하는 그 "무엇"을 애기

기능 테스팅이 얼마나 철저하게 수행 됐는지 기능 커버리지를 통해 측정할  수 있다. 기능 커버리지란 어떤 기능이 테스트에 의해 어느정도 실행됐는지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기.

2,3,2 비기능 테스팅 - 시스템의 비기능 테스팅은 사용성, 성능 효율성 또는 보안성과 같은 시스템 특성을 평가. 비기능 테스팅이란 시스템이 "얼마나 잘" 동장 하는지에 대한 테스팅을 말함. 기능 테스팅 처럼 모든 테스트 레벨에서 수행 가능. 비기능 테스팅은 조기에 할수록 좋음.

2.3.3 화이트박스 테스팅 - 시스템의 내부 구조나 구현을 기반으로 테스트를 도출. 내부 구조로는 코드, 아키텍처, 워크플로우, 시스템 내 데이터 플로우 등이 있음.

화이트박스 테스팅이 얼마나 철저하게 이루어졌는지 구조 커버리지를 통해 측정.

구조 커버리지란 특정 구조 요소가 테스트에 의해 어느 정도 실행됐는지를 말하며, 커버되고 있는 요소 유형에 대한 백분율로 표기.

2.3.4 변경 관련 테스팅 - 결함을 수정하고자 했든 또는 기능을 추가하거나 개선하기 위해서 했든 시스템이 변경되면, 해당 변경이 결함을 제대로 수정했는지, 기능을 올바르게 구현했는지 또 예상하지 못한 부작용이 발생하지 않았는지 확인하기 위한 테스팅을 수행할 필요가 있음.

• 확인 테스팅 : 결함이 수정된 후 이 결함으로 인해 불합격됐던 모든 테스트 케이스를 새로운 소프트웨어 버전에서 재실행할 수 있음. 확인 테스팅의 목적은 원래 제대로 결함을 제대로 수정했는지 확인하는 것이다.
• 리그레션 테스팅 - 코드의 특정 부분에 대한 변경이 무언가를 수정하기 위해서거나 또는 다른 목적이든 관계없이 이런 변경은 의도치 않게 코드의 다른 부분에 영향을 줄 수 있다. 리그레션 테스팅은 이런 의도하지 않은 부작용을 발견하기 위한 테스트를 수행.

확인 테스팅과 리그레션 테스팅은 모든 테스트 레벨에서 수행 가능

2.4 유지보수 테스팅 - 소프트웨어와 시스템이 생산 환경으로 배포되고 나면 유지보수가 필요. 배포된 소프트웨어와 시스템에 대한 다양한 변경은 거의 필연적으로 발생.

2.4.1 유지보수가 필요한 상황 - 유지보수의 계기

• 개선을 위한 변경 , 계획된 확장(릴리스기반), 수정 혹은 긴급 변경, 운영 환경 변경, 상용 소프트웨어 업그레이드, 결함 및 취약성을 위한 패치 등.
• 이관을 위한 변경, 하나의 플랫폼에서 다른 플랫폼으로 이관할때 다른 ㅇ어플의 데이터를 위한 데이터 전환 테스트 등.

-참조 실라버스

- 용어 -

테스트 컨디션 - 특정 테스트 목적 달성과 관련된 테스트 베이시스의 한 측면 - 하나 또는 그 이상의 테스트 케이스로 검증될 수 있는 항목(item)이나 이벤트로서 정의된다. 유의어 : 테스트 요구사항 , 테스트 상황 (리모컨 예로 전원을 킨다 OR 전원을 끈다.)(실라버스 샘플-A-Q1)

테스트 베이시스 - 요구사항을 내포하고 있는 모든 문서. 테스트 케이시스는 테스트 베이시스를 토대로 만들어 진다. 테스트 분석 및 설계의 기초로 사용되는 지식 체계.

리그레션 테스팅 - 개선을 위한 소프트웨어 수정 후 변경 결과로 소프트웨어의 변경되지 않은 영역에서 결함이 발견되거나 유입되지 않았는지 확인하기 위해 이전 테스트 구성 요소 또는 시스템에 대해 진행하는 테스팅 

메트릭 - 측정을 위해 사용되는 측정 척도 및 방법 
명세(서) - 컴포넌트나 시스템의 요구사항, 설계, 동작, 기타 특성을 지정하는 문서. 이상적인 명세는 완전하고 정확하며, 검증 가능한 방식으로 작성되어 있고, 많은 경우 이러한 규정이 충족되었는지를 확인할 수있는 절차가 포함됨.

테스트 차터 - 세션 기반 탐색적 테스팅에서의 테스트 활동에 대한 문서. 테스트 목적과 테스트 방법에 대한 가능한 테스트 아이디어를 적은것(테스트 분석의 결과로 테스트 컨디션 생성되는 경우도 있음) (실라버스 샘플 A-Q8)

테스트 스위트 - 테스트 구현 산출물에는 테스트 스크립트뿐 아니라 테스트 실행 일정의 묶음인 테스트 스위트.

(실라버스 샘플 A-Q8)

테스트케이스 - 테스트 컨디션에 기반하여 개발된 전제 조건, 입력값, 조치, 기대결과 및 사후 조건의 조합.

(실라버스 샘플 A-Q8)

테스트 스크립트 - 테스트 실행을 위한 일련의 지침. (실라버스샘플 A-Q8)

테스트웨어 - 테스팅에 대한 계획, 설계, 살행, 평가, 보고 등에 활용하기위한 목적으로 테스트 프로세스 동안 생성되는 작업 산출물.

테스팅 - 소프트웨어 제품 및 관련 작업산출물이 특정 요구사항을 충족하는지 확인하고, 목적에 부합하는지 여부를 입증하고, 결함을 발견하기 위해 정적/동적의 모든 계획, 준비, 평가와 관련된 수명주기 활동으로 구성된 프로세스

- - - - - - -

1.1 소프트웨어 테스팅이란 - 소프트웨어 테스팅은 소프트웨어의 품질을 평가하고 운영 중 소프트웨어 장애의 발생 가능성을 줄이는 하나의 방법이다. (가능한 많은 장애를 찾아내어 결함을 식별하고 수정한다. 샘플-A-Q2)

1.1.1 테스팅의 일반적인 목적

일반적인 프로젝트에서 테스팅은 다음과 같은 목적을 가질 수 있다.

• 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방

• 명시된 모든 요구사항이 충족됐는지 검증

• 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인

• 테스트 대상의 품질 수준에 대한 자신감 획득

• 장애 및 결함 발견과 이에 따른 부적절한 소프트웨어 품질의 리스크 레벨의 감소

• 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공

• 계약, 법적, 규범적 요구사항이나 표준 준수나 테스트 대상이 그런 요구사항이나 표준을 준수하는지 확인

* 테스팅의 목적은 테스트하고 있는 컴포넌트나 시스템의 정황(현재의 테스트 레벨과 사용하는 소프트웨어 개발 수명주기 모델 등에 따라 달라질 수 있다.)

• 컴퍼넌트 테스팅의 목적 중 하나는 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별하고 수정하는 것일 수 있다. 또 다른 목적은 코드 커버리지를 높이는 것일 수도 있다. ( 결함을 최대한 조기 발견 및 수정 , 코드 커버리지율 증가)
• 인수 테스팅의 목적중 하나는 시스템이 기대한 대로 동작하는지, 또 요구사항을 충족하는지 확인하는 것일 수 있다.또 요구사항을 충족하는지 확인하는 것일 수 있다.또 다른 목적은 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공하는 것일 수 있다.( 시스템이 기대한 대로 동작 확인, 요구사항 충족 확인, 시스템 배포 리스크 정보 전달)

1.1.2 테스팅과 디버깅

테스팅 - 소프트웨어 결함으로 인한 장애를 찾을 수 있다. -> 디버깅에서 수정을 한 후 제대로 수정했는지 확인.

디버깅 - 결함의 장애의 원인을 찾고 분석해서 수정하는 개발 활동.

( 동적 테스팅은 결함으로 발생하는 장애를 보여주고, 디버깅은 소프트웨어에서의 장애의 원인을 찾아 분석하고 제거한다. 실라버스 A-Q3)

1.2 테스팅이 왜 필요한가?

• 컴포넌트 , 시스템 및 관련 문서에 대한 철저한 테스팅은 운영 중 장애 발생 가능성을 줄이는 데 도움.

• 결함을 발견하고 또 발견된 결함을 수정하는 것은 컴포넌트나 시스템의 품질에 기여.

• 계약/법적 요구사항이나 특정 산업 표준을 만족시키기 위해 필요 가능성.

1.2.1 성공을 위한 테스팅의 기여

• 결함으로 장애가 발생하거나 이해관계자의 요구를 충족시키지 못하는 상황을 개선

1.2.2 품질 보증과 테스팅

품질관리 - 품질 측면에서 조직이 나아가야하는 방향을 제시하고 제어하는 모든 활동이 포함. ( 품질보증,품질제어 포괄)

       - 품질 보증 - 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는것에 초점.

       - 품질 제어 - 테스팅 - 품질을 높이는데 다양한 방법으로 기여(시스템의 품질 리스크 수준을 낮춰준다).요구사항이 충분히 상세하다는 것을 보증.
       (실라버스 샘플A-Q6)

1.2.3 오류, 결함, 장애

사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점,버그)을 발생시키는 오류(실수)를 범할 수 있고, 이로인해 프로그램은 장애를 일으킬수 있음. (실라버스 샘픔A-Q4)

- 대표적 오류 발생원인

• 시간적인 압박

• 사람의 실수

• 경험이 적거나 기술이 부족한 프로젝트 참여자

• 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제

• 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도

• 시스템 내/외부 인터페이스에 대한 이해부족, 특히 내/외부 인터페이스 수가 많은 경우

• 새롭고 익숙하지 않은 기술

1.2.4 결함, 근본 원인, 결과

결함의 근본 원인이란 해당 결함을 생성하는 데 기여한 최초의 행동이나 조건을 지칭. 결함을 분석함으로써 근본 원인을 찾을 수 있으며 , 차후 유사한 결함의 발생 가능성을 낮출 수 있다.

*1.3 테스팅의 7 가지 원리 *

1. 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없을 밝히는 활동이 아니다.- 테스팅은 결함이 존재한다는 것을 보여줄 수 있지만, 없다는 것을 증명할 수 없다.
2. 완벽한 테스팅은 불가능하다.- 모든 것(입력과 사전 조건의 모든 조합)을 테스팅 한다는 것은 매우 간단한 소프트웨어를 제외하고는 불가능하다. 완벽하게 테스트하고자 확신보다는 리스크 분석과 우선순위를 토대로한 테스트에 노력을 집중하 것이 좋다. 
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.- 초기에 결함을 찾기 위해서는 정적 및 동적 테스트 활동 모두 소프트웨어 개발 수명주기 중 가능한 이른 시점에 시작해야 한다. 초기부터 시작하는 테스팅을 시프트 레프트라고도 부른다. 소프트웨어 수명주기 초기부터 테스팅을 함으로써 나중에 큰 비용이 동반되는 수정을 줄이거나 없앨 수 있다.
4. 결함은 집중된다.- 출시 전 테스팅에서 발견하는 대부분의 결함은 소수의 모듈에 집중되어 발생하는 경향을 보이며, 운영상 장애의 대부분 역시 소수의 모듈에서 발생한다. 예상 결함 집중 영역과 테스트와 운영 중 실제로 관측한 결함 집중 영역은 리스크 분석의 주요 입력값으 로 사용된다.
5. 살충제 패러독스에 유의하라- 만일 같은 테스트를 계속해서 반복 실행한다면, 결국 해당 테스트로는 결함을 더 이상 발견할 수 없게 된다. 새로운 결함을 발견하기 위해서는 기존 테스트와 테스트 데이터를 바꾸고 새로운 테스트를 작성할 필요가 있다.(살충제를 계속 사용하다 보면 결국 해충을 잡지 못하듯 테스트도 동일) 자동 리그레션 테스팅의 경우 리그레션 결함이 적다는것을 의미할수도 있다.
6. 테스팅은 정황에 의존적이다.- 테스팅은 정황에 따라 다르게 진행된다. 예를 들어 애자일 프로젝트에서의 테스팅은 순차적 소프트웨어 개발 수명주기 프로젝트에서의 테스팅과는 다르게 진행된다.
7. 오류 부재는 궤변이다.- 조직에 따라서는 테스터가 모든 가능한 테스트를 실행하고 존재하는 모든 결함을 발견하기를 기대하는 경우도 있지만, 원리1과2가 말해주듯 이것은 불가능하다. 단순히 많은 결함을 발견하고 고쳤다고 해서 시스템의 성공이 보장된다고 생각하는 것은 궤변(잘못된 믿음)이다.

*1.4 테스트 프로세스*

- 설정한 목적의 달성 가능성을 높여주는 공통적인 테스트 활동 세트(테스트 프로세스) ,주어진 상황에 맞는 구체적은 소프트웨어 프로세스는 다양한 변수에 따라 결정.

테스트 프로세스에 속하는 테스트활동과 이런 활동을 어떻게 구현할지, 또 이런 활동을 언제 수행할지에 대한 내용은 조직의 테스트 전략에서 다룰 수 있다.

1.4.1 정황에 따른 테스트 프로세스

다음은 조직의 테스트 프로세스에 영향을 줄 수 있는 정황 요소 중 일부이다.

• 사용 중인 소프트웨어 개발 수명주기 모델과 프로젝트 방법론
• 적용하고자 하는 테스트 레벨과 테스트 유형
• 제품 및 프로젝트 리스크
• 비즈니스 도메인
• 다음과 같은 운영상의 제약사항:- 예산과 자원 / 일정 / 복잡도 / 계약 및 규제 요구사항
• 운영 정책과 프랙티스
• 준수해야 하는 내부 및 외부 표준

1.4.2 테스트 활동과 작업

테스트 프로세스를 구성하는 주요 7 활동 

• 테스트 계획 - 테스트 계획서의 수립 또는 수정 활동 (계획서 - 테스트 활동 조정에 사용되며 ,달성할 목표와 방법 일정을 설명하는 문서)
• 테스트 모니터링과 제어 - 테스트 활동의 상황을 확인하고, 계획된 또는 예상된 상태와의 편차를 식별하고 상태를 이해관계자에게 보고하는 테스트 관리 활동
• 테스트 분석 - 테스트 베이시스를 분석하여 테스트 컨디션을 식별하는 활동
• 테스트 설계 - 테스트 컨디션으로부터 테스트 케이스를 유도하고 도출하는 활동
• 테스트 구현 - 테스트 분석과 설계를 기반으로 테스트 실행에 필요한 테스트웨어를 준비하는 활동
• 테스트 실행 - 테스트 대상 컴포넌트나 시스템에 대한 테스트를 실행하고 실제 결과를 생성하는 프로세스
• 테스트 완료 - 테스트 자산을 향후 이용 가능하게 하고, 테스트 환경을 만족스러운 상황으로 유지하고, 관련 이해당사자들에게 테스팅 결과를 전달하는 활동.

1.4.3 테스트 작업 산출물

• 테스트 계획 작업 산출물 - 하나이상의 테스트 계획(테스트 베이시스에 대한 정보 포함)
• 테스트 모니터링과 작업 산출물 - 테스트 요약 보고서와 같은 여러 형태의 테스트 보고서(작성일 기준 테스트 진행 상황 관련 필요한 정보를 제공해야함) 산출물은 작업완료, 리소스 할당과 사용, 공수등과 같이 프로젝트 관리에서 관심을 가지는 사항에 대해서도 다뤄야 함.
• 테스트 분석 작업 산출물 - 분석을 통해 식별되고 우선순위가 선정된 테스트 컨디션은 테스트 분석 작업 산출물에 속함. 이상적으로는 각 테스트 컨디션과 그것이 커버하는 테스트 베이시스 요소와의 양방향 추적성이 성립 되어야함. 탐색적 테스팅에서는 테스트 분석 중 테스트 차터를 생성할 수 있음. 테스트 베이시스의 결함을 발견 보고 가능.(샘플 A-Q8)
• 테스트 설계 작업 산출물 - 테스트 컨디션을 실행할 수 있는 테스트 케이스와 테스트 케이스 세트가 만들어짐. 입력 데이터와 기대 결과로 사용할 값이 고정되지 않은 상위 수준 테스트 케이스를 먼저 설계하는 것이 좋은 경우가 많다. 이런 상위 수준 테스트 케이스는 입력 데이터와 기대 결과값을 바꿔가면서 다양한 테스트 주기에서 재활용할 수 있음.동시에 테스트 케이스의 범위를 충분히 기록 이상적으로는 테스트 케이스와 그것이 커버하는 테스트 컨디션 간의 양방향 추적성이 성립 -테스트 설계는 다음과 같은 결과를 가져옴 - 필요한 테스트 데이터의 설계나 식별 , 테스트 환경 설계, 인프라 도구의 식별
• 테스트 구현 작업 산출물 - 테스트 프로시저와 이 프로시저의 배열. 테스트 스위트, 테스트 실행일정 **이상적인 상황에서는 테스트 쿠현이 끝나면, 테스트 케이스와 테스트 컨디션을 통해 테스트 프로시저와 테스트 베이시스 개별 요소 간의 양방향 추적성을 확인함으로써 테스트 계획에서 정의한 커버리지 조건의 달성 여부를 확인할 수 있다. (샘플 A-Q8)
• 테스트 실행 작업 산출물 - 개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서 (실행 준비 완료, 합격 ,불합격, 실행하지 못함, 의도적으로 실행하지 않음 등) ,결함 보고서. 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트 웨어 등에 대한 문서 ** 이상적인 상황에서는, 테스트 실행이 끝나면 연관된 테스트 프로시저와의 양방향 추적성을 활용해서 테스트 베이시스 개별 요소의 상태에 대해 판단하고 보고할 수 있음.
• 테스트 완료 작업 산출물 - 테스트 요약 보고서, 차후 프로젝트나 반복주기의 개선을 위한 액션 아치템, 수정요청서 혹은 제품 백로그 항목, 완성된 테스트웨어 등이 있음.

참고 - ISTQB 실라버스