ISTQB CTFL 용어 정리

제 1장 테스팅의 기초

 

커버리지

• 특정한 커버리지 항목이 테스트 스위트에 의해 이행되는 백분율 정도

 

디버깅

• 소프트웨어에서 장애의 원인을 발견하고, 분석하여 제거하는 절차

 

결함

• 필요한 기능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점. 결함의 예는 부정확한 구문이나 부정확한 데이터 정의 등이다. 실행 중에 결함이 발생할 경우, 컴포넌트나 시스템의 장애를 야기시킬 수 있다.

 

오류

• 부정확한 결과를 초래하는 인간의 활동

 

장애

• 컴포넌트나 시스템이 예상된 인도나 서비스 또는 예상 결과와 실제적인 편차를 보이는 것.

 

품질

• 컴포넌트, 시스템 또는 프로세스가 명시된 요구사항과 사용자/고객의 필요와 기대를 충족시키는 정도.

 

품질 보증

• 품질 요구사항이 충족될 것이라는 신뢰감을 제공하는 데에 집중하는 품질 관리의 한 부분.

 

근본 원인

• 불일치를 유발하는 근원적인 요소. 이것은 프로게스 개선을 통해 영구적으로 제거할 수 있다.

 

테스트 베이시스

• 요구사항을 내포하고 있는 모든 문서. 테스트 케이스는 테스트 베이시스를 토대로 만들어 진다. 문서가 오직 공식적 수정절차의 방법에 의해 수정될 수 있다면, 해당 테스트 베이시스를 동결 테스트 베이시스라 부른다.

 

테스트 케이스

• 특별한 목표 또는 테스트 상황을 테스팅하기 위해 개발된 입력값, 실행 사전조건, 예상 결과, 실행 사후조건 들의 집합. 특별한 목표와 테스트 상황은 특정 프로그램 경로를 실행하거나 지정된 요구사항을 준수하는지 검증하는 것을 의미한다.

 

테스트 제어

• 테스트 프로젝트에 계획 대비 차이가 나타나면 계획대로 진행되도록 정정 행동을 전개하고 적용하는 테스트 관리 업무.

 

테스트 데이터

• 테스트가 실행되기 이전에 데이터베이스와 같은 곳에 존재하며 테스트 대상 컴포넌트나 시스템에 영향을 주거나 영향을 받는 데이터

 

테스트 설계

• 테스트 아이템의 테스트 상황(커버리지 항목)과 상세한 테스트 접근법을 명세화하고 이와 연계된 상위 수준 테스트 케이스를 식별하는 활동

 

테스트 모니터링

• 테스트 프로젝트의 상태를 정기적으로 점검하는 것과 관련된 활동을 다루는 테스트 관리 업무. 리포트는 실제(결과)를 계획한 것과 비교하여 준비된다.

 

테스트 대상

• 테스트되는 컴포넌트나 시스템.

 

테스트 목적

• 테스트를 설계하고 실행하기 위한 근거 또는 목적

 

테스트 오라클

• 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거. 테스트 오라클은 (벤치마크를 위한) 기존 시스템, 사용자 메뉴얼, 또는 개인의 전문 지식일 수 있으나 코드가 될 수는 없다.

 

테스트 계획

• 의도된 테스트 활동의 범위, 접근법, 자원 그리고 일정을 기술하는 문서. 테스트 계획은 다른 테스트 항목, 테스트 대상의 기능 및 특성, 테스팅 업무, 업무 담당 배정, 테스터의 독립성 정도, 테스트 환경, 사용할 테스트 설계 기법과 테스트 측정 기법, 선택의 근거, 그리고 긴급 대책을 요하는 모든 리스크를 식별한다. 테스트 계획은 테스트 기획 프로세스를 기록한 것이다.

 

테스트 절차

• 테스트를 수행할 때 따라야 할 순서.

 

테스트 프로세스

• 기본적인 테스트 프로세스는 테스트 기획, 명세, 실행, 기록 그리고 완료 여부의 점검으로 구성된다.

 

테스트 스위트

• 테스트 대상 컴포넌트나 시스템에 사용되는 여러 테스트 케이스의 집합. 테스트 스위트는 테스트 사후조건이 주로 다음 테스트를 위한 사전조건이 되는 테스트 케이스로 구성된다.

 

테스팅

• 소프트웨어 제품과 관련 작업 산출물이 특정 요구명세를 만족하는지 결정하고, 목적에 부합하는지 입증하고 결함을 찾아내기 위해 해당 산출물을 계획, 준비, 평가하는 정적/동적인 모든 수명주기 활동으로 구성된 프로세스

 

테스트웨어

• 테스트를 계획, 설계, 실행하는 테스트 프로세스 동안 생성된 산출물. 테스트웨어는 테스팅에 사용되는 문서, 스크립트, 입력값, 예상 결과, 시작과 마무리 절차, 파일, 데이터베이스, 환경, 그리고 모든 추가적인 소프트웨어 또는 유틸리티를 포함한다.

 

추적성

• 요구사항과 이와 연관된 테스트에서와 같이 문서나 소프트웨어에서 연관된 항목을 식별하는 능력

 

밸리데이션

• 요구사항이 컴포넌트나 시스템을 특정하게 의도적으로 사용 또는 활용하는 것을 충족시키는지 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.

 

베리피케이션

• 명세된 요구사항이 충족되었는지를 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.

 

제 2장 소프트웨어 개발 수명주기와 테스팅

 

인수 테스팅

• 시스템이 인수조건을 만족시키는지, 사용자, 고객 또는 다른 인가된 개체가 시스템을 인수할지 결정할 수 있도록 사용자의 필요, 요구, 그리고 비즈니스 프로세스를 고려하여 수행하는 공식적인 테스팅. 즉, 계약상의 요구 사항이 만족되었는지 확인하기 위해, 설치 후 구입자 운영 환경에서 납품자도 참가하여 구입자에 의해 실시되는 시스템 또는 기능 단위의 공식적인 테스팅이다. 이 결과를 기초로 고객(구입자)이 개발된 시스템을 인수할 것인지 결정한다.

 

알파 테스팅

• 개발조직 외부에 위치한 개발 환경 또는 개발자 사이트에서 잠재적 사용자, 고객 또는 독립된 테스트 팀에 의해 수행되는 가상 혹은 실제 운영상의 테스팅. 알파 테스팅은 내부 인수 테스팅의 한 형태로, 상용 소프트웨어 테스팅에 주로 적용된다.

 

베타 테스팅

• 컴포넌트나 시스템이 사용자/고객의 요구를 충족하는지, 비즈니스 프로세스에 적합한지 등을 결정하기 위해 개발자를 참여시키지 않고, 잠재/기존 고객(사용자)이 외부사이트에서 직접 수행하는 운용상의 테스팅. 베타 테스팅은 주로 상용 소프트웨어가 시장의 피드백을 얻기 위한 목적으로, 외부 인수 테스트의 한 형태로 수행된다.

 

상용 소프트웨어

• 일반적인 시장, 즉 대규모의 고객을 대상으로 개발되어 동일한 형식으로 많은 고객들에게 전달되는 소프트웨어 제품

 

컴포넌트 통합 테스팅

• 통합된 컴포넌트 간의 인터페이스와 상호작용에서 결함을 찾아내기 위해 수행하는 테스트

 

확인 테스팅

• 결함에 대한 수정이 이루어 졌는지에 대해 확인하는 테스팅. 수정을 확인하기 위해 이전에 실패한 테스트를 실행한다.

 

기능 테스팅

• 컴포넌트나 시스템의 기능 명세 분석에 정의된 요구 기능이 잘 작동하는지를 확인하는 테스팅.

 

영향도 분석

• 명식된 요구사항에 대한 변경을 구현하기 위해, 각 단계별 개발문서, 테스트 문서, 컴포넌트에 대한 변경을 평가하는 것.

 

통합 테스팅

• 통합된 컴포넌트나 시스템 간의 인터페이스와 상호작용에서의 결함을 중점적으로 찾는 테스팅.

 

유지보수 테스팅

• 운영 중인 시스템의 변경 또는 변경된 환경이 운영 중인 시스템에 미치는 영향력에 대한 테스팅.

 

비기능 테스팅

• 기능성과 연관시키지 않고 신뢰성, 효율성, 유지보수성 그리고 이식성 등과 같은 컴포넌트나 시스템의 품질 특성이나 속성을 테스팅.

 

리그레션 테스팅

• 수정으로 인해 변경되지 않은 소프트웨어 영역에 새로운 결함이 유입되지 않았는지, 또는 기존에 숨어있던 결함이 노출되지 않았는지 확인하기 위해 이전에 테스트된 프로그램을 (다시) 테스팅 하는 것. 이 기법은 소프트웨어 혹은 실행 환경이 변경되었을 때 수행한다.

 

시스템 통합 테스팅

• 시스템과 패키지의 통합 테스팅. 외부 조직 또는 시스템(예, 전자 데이터 교환 시스템, 인터넷 등)과의 인터페이스를 테스팅 하는 것.

 

시스템 테스팅

• 명시된 요구사항을 만족하는지 확인하기 위해 통합된 시스템을 테스트 하는 절차. 컴포넌트나 부분 시스템이 하나의 시스템으로 동작하게 되면서 시스템 기능 및 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 모든 시스템 구성요소를 통합한 후 평가하는 테스팅이다.

 

테스트 환경

• 테스트를 수행하기 위해 필요한 하드웨어, 계측기, 시뮬레이터, 소프트웨어 툴, 그 밖의 지원 요소를 포함하는 환경

 

테스트 레벨

• 함께 편성되고 관리되는 테스트 활동의 그룹. 테스트 레벨은 프로젝트에서 책임과 연관 되어있다. 테스트 레벨의 예로는 컴포넌트 테스트, 통합 테스트, 시스템 테스트, 그리고 인수 테스트가 있다.

 

테스트 유형

• 하나 이상의 상호 연관된 품질속성에 대해 컴포넌트나 시스템을 테스팅 하고자 목표하는 테스트 활동 묶음. 테스트 유형은 신뢰성 테스트, 사용성 테스트, 회귀 테스트 등과 같은 특정 테스트 목표에 집중한다. 그리고 테스트 유형은 하나 이상의 테스트 레벨 또는 테스트 단계에서 발생할 수 있다.

 

제 3장 정적 테스팅

 

비공식 리뷰

• 공식적인(문서화된) 절차를 따르지 않는 리뷰.

 

동적 테스팅

• 컴포넌트나 시스템 소프트웨어를 실행하면서 수행하는 테스팅.

 

공식 리뷰

• 인스펙션과 같이 문서화된 절차와 검토를 위한 요구사항을 갖는 리뷰.

 

인스펙션

• 개발 표준 위반과 상위 레벨 개발 문서와의 불일치 등과 같은 결함을 발견하기 위해 문서를 눈으로 검사하는 리뷰의 한 종류. 가장 공식적인 리뷰 기법이며 항상 문서화된 절차에 기반하여 수행한다.

 

리뷰

• 계획되어 있는 결과와 불일치하는 것을 확인하고 개선을 조언하기 위해 제품이나 프로젝트의 상태를 평가하는 것.

 

정적 분석

• 요구사항이나 코드와 같은 소프트웨어 산출물을 실행하지 않고 분석하는 것.

 

정적 테스팅

• 리뷰 또는 정적 코드 분석과 같이 소프트웨어의 실행 없이 명세 또는 구현, 개발 단계에서 컴포넌트나 시스템을 테스팅 하는 것.

 

기술적 리뷰

• 선택하고자 하는 기술적 접근법에 대한 합의에 초점을 맞춘 동료 그룹 토의 활동. 기술적 리뷰는 동료 검토로도 알려져 있다.

 

제 4장 테스트 기법

 

경계값 분석

• 경계값에 기반하여 테스트 케이스를 설계하는 블랙박스 테스트 설계 기법. 즉, 경계값 분석은 등가 분할된 경계의 유효한 값과 경계에서 가장 가까운 유효하지 않는 값을 테스트 데이터로 선택하여 컴포넌트나 시스템을 테스트하는 기법이다. 개발자가 분할된 경계값을 처리하면서 개발상의 실수 가능성이 높다는 것에 착안하여 테스트 데이터를 선정한다. 결국 경계값 분석은 등가 분할 기법을 확장하여 등가 분할 내에 있는 임의의 값이 아닌 분할된 영역의 경계에 있는 값을 테스트 데이터로 이용하여 보다 많은 결함을 발견하는 테스트 케이스를 작성하는 기법이다.

 

결정 커버리지

• 테스트 스위트에 의해 이행된 결정 결과값의 백분율. 100% 결정 커버리지는 100% 분기 커버리지와 100% 구문 커버리지를 모두 포함한다.

 

결정 테이블 테스팅

• 테스트 케이스가 결정 테이블에 표시된 입력값과 자극(원인)의 조합을 테스트 하도록 설계하는 블랙박스 설계 기법.

 

오류 추정

• 테스트 중인 컴포넌트나 시스템에서 유입된 오류의 결과로 어떤 결함이 발생할 것인지를 테스터의 경험을 사용하여 예측하고, 해당 결함만을 중점적으로 검출하는 테스트를 설계하는 테스트 설계 기법.

 

경험 기반 테스트 설계 기법

• 테스터의 경험, 지식과 직관에 기반하여 테스트 케이스를 도출하고 선정하는 절차.

 

탐색적 테스팅

• 테스터가 테스트를 수행하면서 테스트 설계를 능동적으로 제어하고, 새롭고 보다 나은 테스트를 설계하기 위해, 테스트를 수행하는 동안 얻은 정보를 활용하는 비공식적인 테스트 설계 기법.

 

상태 전이 테스팅

• 유효하고 비유효한 상태 전이를 수행하도록 테스트 케이스를 설계하는 블랙박스 테스트 설계 기법.

 

구문 커버리지

• 테스트 스위트에 의해 이행되는 실행문의 백분율.

 

제 5장 테스트 관리

 

형상 관리

• 변경 프로세스에 기술 및 관리 차원의 지시와 감독을 적용하는 원칙. 변경 프로세스는 형상 항목의 기능적, 물리적 특성을 식별하여 문서화하고, 그러한 특성들의 변화를 제어하고, 변경 절차와 구현 상태를 기록 및 보고하고, 명시된 요구사항에 적합한지를 검증하는 것이다.

 

결함 관리

• 결함을 인지하고, 조사하고, 행동을 취해 처리하는 절차. 결함을 기록하고, 분류하고 영향력을 식별하는 것을 수반한다.

 

결함 리포트

• 컴포넌트나 시스템이 요구되는 기능을 수행하는 과정에서 장애를 유발하는 모든 결함을 리포팅하는 문서.

 

시작 조건

• 정의된 (다음 단계) 작업의 진행을 허가하는 일반적이고 특정한 조건의 집합. 시작 조건의 목적은 시작 조건을 만족하지 못한 채 테스트 되어 추후에 더 많은 헛된 노력이 소요되는 테스크를 시작하지 못하도록 하는 것이다.

 

제품 리스크

• 테스트 대상에 직접적으로 관계된 리스크.

 

프로젝트 리스크

• 프로젝트 리스크는 테스트 인력 부족, 변경 불가한 출시시기, 변경이 잦은 요구사항 등 테스트 프로젝트의 관리 및 제어와 관계된 리스크이다.

 

리스크

• 미래에 부정적 결과로 끝날 수 있는 요소. 주로 영향력과 발생가능성으로 표현된다.

 

리스크 기반 테스팅

• 리스크 기반 테스팅은 개발 프로젝트 초기부터 제품 리스크 수준을 낮추고 이해관계자에게 리스크 상태 정보를 제공하는 테스트 접근법이다. 이는 제품 리스크 식별을 필요로 하고 리스크 수준을 사용해 테스트 프로세스를 가이드한다.

 

테스트 접근법

• 특정한 프로젝트를 위해 테스트 전략을 구현하는 것. 테스트 접근법은 일반적으로 프로젝트의 목표와 리스크 평가 수행 결과를 기반으로 여러가지 테스팅 관련 의사결정을 한다. 이 밖에도 테스트 접근법은 테스트 프로세스를 시작하는 지점, 적용할 테스트 설계 기법, 완료 조건과 수행 할 테스트 유형을 결정하는 역할을 한다.

 

테스트 제어

• 테스트 프로젝트에 계획 대비 차이가 나타나면 계획대로 진행되도록 정정 행동을 전개하고 적용하는 테스트 관리 업무.

 

테스트 전략

• 하나의 프로그램에 대해 어떤 테스트 레벨을 수행할 것인지, 해당 테스트 레벨 내에서 어떻게 테스팅 할 것인지를 정의하는 상위 수준 문서.

 

테스트 요약 보고서

• 테스트 활동과 결과를 요약한 문서. 테스트 요약 보고서에는 완료 조건에 대비하여 상응하는 테스트 항목을 평가하는 것도 기술한다.

 

테스터

• 컴포넌트나 시스템의 테스트에 참여하는 테스트 관련 기술 측면에서 숙련된 전문가.

 

제 6장 테스트 지원 도구

 

데이터 주도 테스팅

• 테이블이나 스프레드쉬트에 테스트 입력값과 예상결과를 저장하여 스크립트를 작성하고 테스트하는 기법. 이를 통해 한 개의 제어 스크립트로 해당 테이블 내에서 모든 테스트를 수행할 수 있다. 데이터 주도 테스팅은 주로 기록/재생 툴 같은 테스트 실행 툴을 활용하도록 지원하는데 쓰인다.

 

키워드 주도 테스팅

• 테스트 데이터와 예상 결과뿐만 아니라, 테스트 대상 어플리케이션과 관련된 키워드를 포함한, 데이터 파일을 사용하는 스크립트 기법. 제어 스크립트가 테스트하기 위한 목적으로 호출한 특별 지원 스크립트로 키워드를 해석한다.

 

테스트 자동화

• 테스트 활동을 수행하거나 지원하는 소프트웨어 툴을 사용하여 테스팅 하는 것. 테스트 자동화는 테스트 관리, 테스트 설계, 테스트 실행과 결과 점검과 같은 테스트 활동을 수행하고 지원한다.

 

테스트 실행 툴

• 자동화된 테스트 스크립트를 사용하여 다른 테스트 대상 소프트웨어를 실행할 수 있도록 기록/재생 툴과 같은 테스트 툴의 한 종류.

 

테스트 관리 툴

• 테스트 프로세스의 테스트 관리와 제어 부분을 지원하는 툴. 테스트 관리 툴은 테스트웨어 관리, 테스트 스케줄링, 결과 로깅, 진척도 추적, 인시던트 관리, 그리고 테스트 리포팅을 지원하는 여러가지 기능이 있다.