실라버스 제 1 장. 테스팅의 기초

1.1 테스팅이란 무엇인가?

 

* 테스팅 활동
　- 테스트 대상 컴포넌트 or 시스템을 실행 O : 동적 테스팅
　- 테스트 대상 컴포넌트 or 시스템을 실행  X :  정적 테스팅
　- 작업 산출물(요구사항, 사용자 스토리, 소스 코드)에 대한 리뷰
　- 베리피케이션(검증 verification) : 시스템이 주어진 명세를 충족하는지 확인
　- 밸리데이션(확인 validation) : 시스템이 운영 환경에서 사용자 or 기타 이해관계자의 요구를 만족시키는지 확인

 

1.1.1 테스팅의 일반적인 목적 (K1)

 

* 일반적인 프로젝트에서 테스팅의 목적
　① 작업 산출물(요구사항, 사용자 스토리, 설계 소스 코드 등등) 평가에 의한 결함 예방
　② 명시된 모든 요구사항이 충족됐는지 검증
　③ 테스트 대상의 완성 여부 + 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
　④ 테스트 대상의 품질 수준에 대한 자신감 획득
　⑤ 부적절한 SW 품질의 리스크 레벨 감소 -> 장애와 결함을 발견
　⑥ 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
　⑦ 계약/법률/규제 요구사항 or 표준의 준수 + 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인

 

* 테스팅의 목적이 정황(현재의 테스트 레벨과 사용하는 SW 개발 수명주기 모델 등등)에 따라 달라지는 예
　① 컴포넌트 테스팅의 목적 中....
　　- 결함을 최대한 조기에 가능한 많이 식별, 수정
　　- 코드 커버리지를 높이는 것
　② 인수 테스팅의 주요 목적 中....
　　- 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공

 

1.1.2 테스팅과 디버깅 (K2)

 

* 디버깅
　- 테스트 실행 -> SW 결함으로 인한 장애 발견 -> 장애의 원인을 찾고 분석해서 수정하는 개발 활동

* 확인 테스팅
　- 디버깅 이후 실행
　- 결함을 제대로 수정했는지 확인
  

* 역할별 담당
　- 테스터 : 초기 테스트, 마지막 확인 테스트 담당
　- 개발자 : 디버깅 관련 컴포넌트, 컴포넌트 통합 테스팅 (지속적 통합)을 수행
　- (애자일 개발 & 기타 SW 수명주기 모델) 테스터 : 디버깅, 컴포넌트 테스팅에 관여하기도 함.

 

1.2 테스팅이 왜 필요한가?

 

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

 

* SW와 시스템이 문제를 안고 배포되는 경우를 줄일 수 있는 예 
(적절한 테스트 기법, 전문성을 가지고 적절한 테스트 레벨, 개발 수명주기 단계에 적용했을 때)
　① 테스터를 요구사항 리뷰 or 사용자 스토리 개선에 참여시키면 해당 작업 산출물에서 결함을 발견할 수 있다.
　　요구사항 결함을 식별하고 제거하면 잘못 or 테스트할 수 없는 기능이 개발되는 리스크를 줄일 수 있음
　② 시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업할 경우,
　　설계와 그것을 어떻게 테스트해야 하는지에 대해 서로 좀 더 깊이 있게 이해하게 됨
　③ 코드를 개발하는 동안 테스터가 개발자와 적극적으로 협업할 경우, 
　　코드와 그것을 어떻게 테스트해야 하는지에 대해 서로 좀 더 깊이 있게 이해하게 된다.
　　-> 코드와 테스트에서의 결함 발생 리스크가 줄어듦
　④  테스터가 릴리스 전에 소프트웨어를 확인하고 검증하면,
　　놓쳤을 수 있는 장애를 발견 + 디버깅(장애의 원인인 결함을 제거)하는 데 도움을 줄 수 있음
　　-> SW가 이해관계자의 필요한 요구사항을 충족시킬 가능성을 높일 수 있음

 

1.2.2 품질 보증과 테스팅 (K2)

 

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

 

* 품질 보증(QA, Quality Assurance)
　- 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 초점
　- 높은 작업 산출물 품질은 결함 예방에 도움이 됨
　- 근본 원인 분석(root cause analysis)(결함의 원인을 찾아서 제거)의 활용
　 　 　 　 +
　 회고 회의( retrospective meetings)의 결과를 적절하게 적용
　 -> 프로세스를 개선 -> 효과적인 품질 보증에 매우 중요

 

* 품질 제어(QC, Quality Control)
　- 테스트 활동이 포함

 

1.2.3 오류, 결함, 장애 (K1)

 

* 오류(실수)
　- 사람이 프로그램 코드 or 기타 작업 산출물을 작성하면서 결함(결점, 버그)을 발생시킴
　- 요구사항을 도출하면서 범해진 오류 (요구사항 결함) -> 프로그램 작성 시 오류를 일으켜 결국 (코드 결함)의 원인이 됨

 

* 코드의 결함이 실행되면 장애를 일으킬 수 있지만 반드시 그런 것은 아님!

 

* 결함 中 일부는 발생 가능성이 없거나 매우 낮아서 특수한 입력 or 사전조건이 충족돼야 장애를 일으킬 수 있음

 

* 오류 발생 원인
　① 시간적인 압박 
　② 사람의 실수
　③ 경험이 적거나 기술이 부족한 프로젝트 참여자
　④ 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제
　⑤ 코드, 설계, 아키텍처의 복잡성 / 해결해야 하는 근본 문제 / 사용하는 기술의 복잡도
　⑥ 시스템 내/외부 인터페이스에 대한 이해 부족 (특히 내/외부 인터페이스 수가 많은 경우)
　⑦ 새롭고 익숙하지 않은 기술

 

* 장애
　- 코드 결함 + 환경 조건
　- 방사능, 전자기장, 환경 오염 등 -> 펌웨어 결함의 원인 or HW 상태를 변화 -> SW 실행에 영향을 줄 수 있음
　- 테스트 결과가 기대한 것과 다르다고 해서 무조건 장애가 있다고 볼 수 없는 경우
　　· 테스트 실행 방식의 오류 or 테스트 데이터, 환경, 기타 테스트웨어에 결함이 있는 경우
　　· 거짓양성(false positive) : 결함으로 보고됐지만 실제 결함이 아닌 경우
　　· 거짓음성(false negative) : 테스트가 발견했어야 할 결함을 발견하지 못하는 경우

 

1.2.4 결함, 근본 원인, 결과 (K2)

 

* 결함의 근본 원인
　- 해당 결함을 만들어낸 최초의 행동 or 조건
　- 결함을 분석 -> 근본 원인을 찾을 수 있음

 

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

　- 결과 : 소비자 불만 
　- 장애 : 잘못된 이자 지급
　- 결함 : 코드에 포함된 잘못된 계산식
　- 최초 결함 : 사용자 스토리의 모호성
　- 최초 결함의 근본 원인 : 제품 소유자의 지식 부족
　- 오류 : 근본 원인의 결과로 제품 소유자가 사용자 스토리를 작성할 때 오류를 범함

 

1.3 테스팅의 7가지 원리 (K2)

 

① 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다.
　- 테스팅은 결함이 존재한다는 것을 보여줄 수 있지만, 결함이 없다는 것을 증명할 수 없다.
　- 테스팅은 SW에 발견되지 않은 결함의 존재 가능성을 줄일 수는 있지만,
　결함이 전혀 발견되지 않았다 하더라도 해당 SW가 완벽하다는 뜻은 아니다.

 

② 완벽한(exhaustive) 테스팅은 불가능하다.
　- 완벽하게 테스트하고자 하기보다는 리스크 분석 + 우선순위를 토대로 테스트

 

③ 조기 테스팅(early testing)으로 시간과 비용을 절약할 수 있다.
　- 시프트 레프트(Shift Left) : 초기부터 시작하는 테스팅
　- SW 수명주기 초기부터 테스팅 -> 나중에 큰 비용이 동반되는 수정을 줄이거나 없앨 수 있음 (3.1절)

 

④ 결함은 집중된다.
　- 출시 전 + 운영상 장애의 대부분의 결함은 소수의 모듈에 집중되어 발생하는 경향을 보임
　- 예상 결함 집중 영역 + 테트와 운영 중 실제로 관측한 결함 집중 영역 -> 리스크 분석의 주요 입력값으로 사용됨
　- 리스크 분석은 테스트 노력을 집중시키는 데 필요하다. (원리 2)

 

⑤ 살충제 패러독스에 유의하라
　- 살충제를 계속 사용하다 보면 결국 해충을 잡지 못하듯,
　- 테스트도 반복하다 보면 결국 결함을 더이상 찾지 못하게 된다.

 

⑥ 테스팅은 정황(context)에 의존적이다.
　- 안전 최우선 산업에서 사용하는 제어 SW는 이커머스 모바일 애플리케이션과는 다르게 테스트함
　- 애자일 프로젝트에서의 테스팅은 순차적으로 SW 개발 수명주기 프로젝트에서의 테스팅과는 다르제 진행된다. (2.1절)

 

⑦ 오류 부재는 궤변이다.
　- 테스터가 모든 가능한 테스트를 실행 + 존재하는 모든 결함을 발견 X (원리 1, 2)
　- 많은 결함을 발견하고 고쳤다고 해서 시스템의 성공이 보장된다고 생각하는 것은 궤변(잘못된 믿음)

 

1.4 테스트 프로세스

 

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

 

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

* 조직의 테스트 프로세스에 영향을 줄 수 있는 정황 요소 중 일부
　① 사용 중인 SW 개발 수명주기 모델, 프로젝트 방법론
　② 적용하고자 하는 테스트 레벨, 테스트 유형
　③ 제품, 프로젝트 리스크
　④ 비즈니스 도메인
　⑤ 운영상의 제약사항
　　- 예산과 자원 (resource)
　　- 일정
　　- 복잡도
　　- 계약, 규제 요구사항
　⑥ 운영 정책과 프랙티스 (practices) 
　⑦ 준수해야 하는 내, 외부 표준

* 테스트 레벨, 유형에 상관없이, 테스트 베이시스에 대한 측정 가능한 커버리지 조건이 설정되어 있으면 매우 유용함

* 커버리지 조건은 SW 테스트의 목적 달성 여부를 보여주는 활동의 주요 성능 지표(KPI, key performance indicator)로 사용하기 용이함 (1.1.1절)

 

예) 모바일 애플리케이션
　- 테스트 베이시스 : 요구사항 목록, 지원 대상 모바일 기기 목록
　- 커버리지 조건 : 각 테스트 베이시스 요소를 적어도 하나의 TC로 다루어야 한다는 것
　- 실행한 TC의 결과는 이해관계자에게 명시된 요구사항의 충족 여부,
　지원 대상 기기에서 장애가 발생했는지에 대한 정보 제공

 

1.4.2 테스트 활동과 작업 (K2)

 

① 테스트 계획 (Test planning)  (5.2절)
　- 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의함
　　예) 적절한 테스트 기법과 작업 명시, 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립 등
　- 모니터링과 제어 활동에서 나온 피드백을 기반으로 수정할 수 있음

 

② 테스트 모니터링과 제어 (Test monitoring and control)  (5.3절)

　* 테스트 모니터링 (Test monitoring)

　　- 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교하는 활동

 

　* 테스트 제어 (Test control)
　　- 시간이 지나면서 업데이트될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행

　* 종료 조건(exit criteria) 평가
　　① 명시된 커버리지 조건 대비 테스트 결과와 로그 확인
　　② 테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가
　　③ 추가 테스트 필요 여부 결정
　　　(예 : 일정 수준의 제품 리스크 커버리지를 달성하고자 했던 테스트가 그러지 못했을 경우, 
　　　　　추가적인 테스트 작성 및 실행 요구)

 

③ 테스트 분석 (Test analysis)
　- 테스트 가능한 기능과 연관된 테스트 컨디션을 식별하기 위해 테스트 베이시스를 분석
　- 측정 가능한 커버리지 조건의 측면에서 "무엇을 테스트할지"를 결정

　* 주요 활동
　　① 고려 중인 테스트 레벨에 적합한 테스트 베이시스 평가. 예를 들어 :
　　　- 요구사항 명세
　　　　· 비즈니스, 기능, 시스템 요구사항,
　　　　· 사용자 스토리, 에픽(epic), 유스케이스,
　　　　· 요구되는 기능/비기능 컴포넌트나 시스템의 동작이 명시된 유사한 작업 산출물 등
　　　- 설계와 구현 정보
　　　　· 시스템 or SW 아키텍처 다이어그램

　　　　· 문서, 설계 명세, 콜흐름도(call flow graphs),
　　　　· 모델링 다이어그램(예 : UML 또는 개체-관계 다이어그램),
　　　　· 인터페이스 명세, 컴포넌트나 시스템 구조를 명시하고 있는 기타 유사한 작업 산출물 등
　　　- 구현한 컴포넌트나 시스템
　　　　· 코드, 데이터베이스 메타데이터(database metagdata), 쿼리(queries), 인터페이스 등
　　　- 컴포넌트나 시스템의 기능, 기비능, 구조 측면을 고려한 리스크 분석 보고서
　　② 테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별. 예를 들어 :
　　　- 모호함 (Ambiguities)
　　　- 누락 (Omissions)
　　　- 불일치 (Inconsistencies)
　　　- 부정확 (Inaccuracies)
　　　- 모순 (Contradictions)
　　　- 불필요한 구문 (Superfluous Statements)
　　③ 테스트할 기능과 기능 세트 식별
　　④ 테스트 베이시스를 평가하고
　　　각 기능에 대한 테스트 컨디션의 정의 및 우선순위 선정
　　　(기능, 비기능, 구조 특성, 기타 비즈니스 기술 요소, 리스크 수준 등을 고려)
　　⑤ 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착 (1.4.3절, 1.4.4절)

 

④ 테스트 설계 (Test design)
　- 상위 수준 TC, 상위 수준 TC 세트, 기타 테스트웨어(testware) 생성(테스트 컨디션을 기반으로)
　- "어떻게 테스트할 것인가"를 다루게 됨

　* 주요 활동
　　① TC, TC 세트 설계 및 우선순위 선정
　　② 테스트 컨디션, TC에 필요한 테스트 데이터 식별
　　③ 테스트 환경 설계, 필요한 인프라 및 도구 식별
　　④ 테스트 베이시스, 테스트 컨디션, TC 간의 양방향 추적성 설정 (1.4.4.절)

 

　* 테스트 컨디션을 TC와 TC 세트로 전환할 때 테스트 기법을 사용하는 경우가 많음 (4장)

 

⑤ 테스트 구현 (Test implementation)
　- 테스트 실행에 필요한 테스트웨어를 생성하고 완성
　- TC를 배치해서 테스트 프로시저를 만듦
　- "테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?"
　- 테스트 설계와 테스트 구현 작업은 합쳐지는 경우가 많음
　　· 탐색적 테스팅
　　· 기타 경험 기반 테스트 유형  

　* 주요 활동
　　① 테스트 프로시저의 개발과 우선순위 선정, 자동 테스트 스크립트 생성
　　② 테스트 프로시저와 자동 테스트 스크립트로부터 테스트 스위트(test suite) 생성
　　③ 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치 (5.2.4절)
　　④ 테스트 환경 구축, 테스트 하네스(test harness), 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목, 
　　　필요한 모든 사항을 제대로 구현했는지 확인
　　⑤ 테스트 데이터를 준비, 테스트 환경에 제대로 입력했는지 확인
　　⑥ 테스트 베이시스, 테스트 컨디션, TC, 테스트 프로시저, 테스트 스위트 서로 간의 양방향 추적성 검증과 업데이트
　　　(1.4.4절)

 

⑥ 테스트 실행 (Test execution)
　- 테스트 스위트를 테스트 실행 일정에 따라 실행

　* 주요 활동
　 ① 테스트 항목, 대상, 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
　 ② 테스트를 수동 or 테스트 실행 도구를 활용해서 실행
　 ③ 기대 결과와 실제 결과를 비교
　 ④ 이상 현상(anomalies)을 분석해 원인 파악
　　(예 : 장애가 코드 결함 때문에 발생할 수도 있지만 거짓양성일 수도 있음 (1.2.3절))
　 ⑤ 관찰한 장애를 기반으로 결함 보고 (5.6절)
　 ⑥ 테스트 실행 결과 기록
　　(예 : 합격, 불합격, 실행할 수 없음)
　 ⑦ 이상 현상 때문에 취한 활동의 결과로 인해 or 계획된 테스팅의 일부로 테스트 활동 반복
　　(예 : 수정된 테스트 실행, 확인 테스팅이나 리그레션 테스팅 등)
　 ⑧ 테스트 베이시스, 테스트 컨디션, TC,  테스트 프로시저, 테스트 결과 간의 양방향 추적성 검증과 업데이트  

 

⑦ 테스트 완료 (Test completion)
　- 완료환 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동
　- 일어나는 시점 = 프로젝트 마일스톤 시점
　　˙ SW 시스템을 릴리스 했을 때
　　˙ 테스트 프로젝트를 완료(or 취소)했을 때
　　˙ 애자일 반복주기가 끝났을 때
　　˙ 특정 테스트 레벨을 완료했을 때
　　˙ 유지보수 릴리스를 완료했을 때

 

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

 

1.4.3 테스트 작업 산출물 (K2)

 

No	테스트 프로세스	작업 산출물	부가 설명
1	테스트 계획 (5.2.절)	- 하나 이상의 테스트 계획	- 테스트 계획은 테스트 베이시스에 대한 정보를 포함 - 테스트 베이시스는 추적성 정보를 통해 다른 작업 산출물 + 테스트 모니터링과 제어에 사용되는 종료 조건(or 완료 기준)과도 연결 (1.4.4절)
2	테스트 모니터링과 제어	- 테스트 진행 현황 보고서 - 여러 형태의 테스트 보고서 (예 : 테스트 요약 보고서(다양한 테스트 완료 마일스톤에서 생성))
3	테스트 분석	- 테스트 컨디션 - 테스트 차터	- 각 테스트 컨디션과 그것이 커버하는 테스트 베이시스 요소와의 양방향 추적성이 성립되어 있어야 함 - 테스트 베이시스의 결함 발견, 보고
4	테스트 설계	- 테스트 분석에서 정의한 테스트 컨디션을 실행할 수 있는 TC, TC 세트	* 테스트 설계가 가져오는 결과 　- 필요한 테스트 데이터의 설계나 식별  　- 테스트 환경 설계 　- 인프라와 도구의 식별
5	테스트 구현	- 테스트 프로시저와 이 프로시저의 배열 - 테스트 스위트 - 테스트 실행 일정
6	테스트 실행	- 개별 TC or 테스트 프로시저의 상태에 대한 문서 (예 : 실행 준비 완료, 합격, 불합격, 실행하지 못함, 의도적으로 실행하지 않음 등) - 결함 보고서 (5.6절) - 테스팅에 사용한 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등에 대한문서
7	테스트 완료	- 테스트 요약 보고서 - 차후 프로젝트나 반복주기의 개선을 위한 액션 아이템 - 수정 요청서 or 제품 백로그 항목, 완성된 테스트웨어 등

 

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

 

* 효과적인 테스트 모니터링과 제어를 구현하기 위해서는 테스트 프로세스 전반에 걸쳐 테스트 작업 산출물 간의 추적성을 확립하고 유지하는 것이 중요

* 좋은 추적성의 장점
　① 수정으로 인한 영향 평가를 가능하게 함
　② 테스팅에 대한 감사(audit)를 가능하게 함
　③ IT 통제(IT governace) 조건을 충족할 수 있게 함
　④ 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함
　　(예 : 연관된 테스트에 합/불합격한 요구사항, 연관된 테스트를 다 실행하지 못한 요구사항)
　　-> 테스트 진행 상황 보고서, 요약 보고서를 좀 더 쉽게 이해할 수 있게 함
　⑤ 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달함
　⑥ 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공

 

1.5 테스팅의 심리학

 

1.5.1 인간 심리학과 테스팅 (K1)

* 의사소통을 더 잘할 수 있는 방법에 대한 예제
　① 협력으로 시작
　　- 더 나은 품질의 시스템을 개발한다는 공통 목표를 모두에게 인식시킴
　② 테스팅의 이점을 강조
　　- 예) 결함 정보는 저자자 자신의 작업 산출물의 품질과 역량을 향상하는 데 도움
　　- 조직 차원에서 테스팅 도중 발견하고 수정한 결함은 시간과 비용을 아껴주며 제품 품질의 전반적인 리스크를 낮춰줌
　③ 테스트 결과와 기타 발견 사항을 중립적 + 사실에 기반을 둔 방법으로 전달
　　결함이 발생한 항목을 제작한 사람을 비판 X
　④  상대방이 어떤 느낌을 받을지, 또 해당 정보에 대해 부정적으로 반응하는 이유가 뭔지를 이해하려고 해야 함
　⑤ 상대방이 전달받은 내용을 이해했는지, 상대방이 하고자 하는 망ㄹ을 제대로 이해했는지 확인

 

1.5.2 테스터와 개발자의 사고방식 (K2)

 

* 개발자와 테스터는 생각하는 방식이 다른 경우가 많음
　- 목적이 다르기 때문에 필요한 사고방식도 다름
　　-> 이런 사고방식을 적절히 조합해서 사용
　　-> 더 높은 수줌의 제품 품질을 달성할 수 있음
　- 개발의 일차적인 목표 : 제품 설계, 구축
　- 테스팅의 목적 : 제품에 대한 밸리데이션(확인 validation), 베리피케이션(검증 verification), 릴리스 전 결함 발견 등등

* 테스터의 사고방식
　- 호기심, 전문적 비평 능력, 비판적 시각, 세밀한 것에 주목하는 태도, 긍정적인 소통과 관계 수립에 대한 동기 등등
　　-> 테스터가 경험을 쌓아감에 따라 점차 확대되고 성숙해지는 경향을 가지고 있음

* 개발자의 사고방식
　- 테스터의 사고방식과 같은 요소가 일부 있을 수 있음
　-  성공적인 개발자는 해결책을 설계하고 구축하는 데 더 큰 관심을 기울이며 
　　그런 해결책에 무슨 문제가 있는지에 대해 관심을 가지는 경우는 많지 않음
　- 확증 편향(confirmation bias) 때문에 자신이 만든 오류에 대해 인지하기 어려움
　- 올바른 사고방식을 가지고 있다면, 개발자는 자신이 만든 코드를 직접 테스트할 수 있음　

* SW 개발 수명주기 모델에 따라 테스터 구성 및 테스트 활동 방식이 다름

* 독립적인 테스터
　-  테스트 활동의 일부를 수행하면 결함 발견 효과를 높일 수 있음
　- 특히 규모가 크고 복잡하며 안전이 필수적인 시스템일 경우 중요
　- 저자와는 다른 확증 편향을 가지기 때문에
　작업 산출물 작성자(비즈니스 분석가, 제품 책임자, 설계자, 개발자 등)와는 다른 관점을 갖게 됨

 

 

No	용어	설명	유의어	연관 항목
1	커버리지 (coverage)	커버리지 항목이 식별되거나 테스트 스위트(test suite)에 의해 수행된 정도를 백분율로 표시한 것	테스트 커버리지 (test coverage)
2	디버깅 (debugging)	소프트웨어의 장애 원인을 찾아 분석하고 제거하는 프로세스
3	결함 (defect)	요구사항이나 명세를 충족시키지 못하는 작업 산출물의 불완전함 또는 결점	버그(bug), 결점(fault)
4	오류 (error)	부정확한 결과를 만들어내는 인간의 행동	실수(mistake)
5	장애 (failure)	지정된 범위 내에서 요구되는 기능을 컴포넌트나 시스템이 수행하지 못하는 경우
6	품질 (quality)	컴포넌트나 시스템 또는 프로세스가 특정한 요구사항 및 사용자/고객의 요구와 기대를 충족시키는 정도
7	품질 보증 (quality assurance)	품질 관리의 일환으로, 품질 요구사항이 준수될 것이라는 신뢰를 제공하는데 중점을 둠
8	근본 원인 (root cause)	결함의 원인 중 제거되면 해당 결함유형 발생이 감소하거나 제거될 수 있는 원인
9	테스트 분석 (test analysis)	테스트 베이시스(test basis)를 분석하여 테스트 컨디션을 식별하는 활동
10	테스트 베이시스 (test basis)	테스트 분석 및 설계의 기초로 사용되는 지식 체계
11	테스트 케이스 (test case)	테스트 컨디션을 기반으로 개발된 사전조건, 입력값, 행동(해당하는 경우), 기대 결과, 사후조건의 집합
12	테스트 완료 (test completion)	테스트 자산을 향후 이용 가능하게 하고, 테스트 환경을 만족스러운 상황으로 유지하고,  관련 이해당사자들에게 테스팅 결과를 전달하는 활동
13	테스트 컨디션 (test condition)	특정 테스트 목적 달성과 관련있는 테스트 베이시스(test basis)의 한 측면	· 테스트 요구사항 (test requirement),  · 테스트 상황 (test situation)
14	테스트 제어 (test control)	모니터링 결과 테스트 프로젝트가 계획에서 벗어나고 있다고 판단될 때,  다시 정상 궤도로 돌려놓으려는 시정조치의 개발 및 적용과 관련된 테스트 관리 업무		테스트 관리 (test management)
15	테스트 데이터 (test data)	하나 이상의 테스트 케이스를 실행하기 위한 입력값이면서, 실행 사전조건을 만족하도록 생성되거나 선택된 데이터
16	테스트 설계 (test design)	테스트 컨디션으로부터 테스트 케이스를 유도하고 도출하는 활동		테스트 설계 명세 (test design specification)
17	테스트 실행 (test execution)	테스트 대상 컴포넌트나 시스템에 대한 테스트를 실행하고 실제 결과를 생성하는 프로세스
18	테스트 구현 (test implementation)	테스트 분석과 설계를 기반으로 테스트 실행에 필요한 테스트웨어를 준비하는 활동
19	테스트 모니터링 (test monitoring)	테스트 활동의 상황을 확인하고, 계획된 또는 예상된 상태와의 편차를 식별하고 상태를 이해 관계자에게 보고하는 테스트 관리 활동		테스트 관리 (test management)
20	테스트 대상 (test object)	테스트할 컴포넌트나 시스템		테스트 항목 (test item)
21	테스트 목적 (test objective)	테스트를 설계하고 실행하는 근거나 목적
22	테스트 오라클 (test oracle)	테스트중인 시스템의 실제 결과와 비교할 기대 결과를 판단하기 위한 출처	오라클(oracle)
23	테스트 계획 (test planning)	테스트 계획서의 수립 또는 수정 활동
24	테스트 절차 (test procedure)	실행 순서로 나열된 테스트 케이스 순서. 초기 사전조건을 설정하는데 필요한 모든 관련 동 작과 실행 이후의 모든 마무리 활동까지 포함		테스트 스크립트 (test script)
25	테스트 프로세스 (test process)	테스트 계획, 테스트 모니터링 및 제어, 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행, 테스트 완료로  상호 연관되어 구성된 활동들의 집합
26	테스트 스위트 (test suite)	특정 테스트 주기에서 실행해야 하는 테스트 케이스의 집합이나 테스트 절차	· 테스트 케이스 세트 (test case set),  · 테스트 세트 (test set)
27	테스팅 (testing)	소프트웨어 제품 및 관련 작업산출물이 특정 요구사항을 충족하는지 확인하고, 목적에 부합하는지 여부를 입증하고,  결함을 발견하기 위해 정적/동적의 모든 계획, 준비, 평가와 관련된 수 명주기 활동으로 구성된 프로세스
28	테스트웨어 (testware)	테스팅에 대한 계획, 설계, 실행, 평가, 보고 등에 활용하기위한 목적으로 테스트 프로세스 동안 생성되는 작업 산출물
29	추적성 (traceability)	두 가지 이상의 작업 산출물 사이에 관계가 성립될 수 있는 정도		· 수평적 추적성 (horizontal traceability),  · 수직적 추적성 (vertical traceability)
30	밸리데이션 (확인 validation)	의도된  특정 용도  또는  용도에 대한  요구사항이  충족되었음을 보증하기  위해  객관적 증거와 조사를 통해 확인하는 것
31	베리피케이션 (검증 verification)	특정 요구사항이 모두 구현되었는지를 객관적 증거와 조사를 통해 확인하는 것

 

Sample A

---

Sample B

---

Sample C