1장 테스팅의 기초

1.1 테스팅이란 무엇인가?

 

소프트 웨어 테스팅은 소프트웨어 품질을 평가하고, 소프트웨어 사용 시 나타나는 장애의 위험을 줄여줄 수 있다.

 

소프트웨어 테스팅은 결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동이다.

테스트의 대상이 되는 산출물을 테스트 대상(Test object)라고 한다.
테스팅은 소프트 웨어를 실행하고 결과를 확인하는 테스트 수행(Test execution)에 국한되지 않는다.

테스팅의 활동은 소프트웨어 개발 수명주기(SDLC)에 따라서 달라진다.

테스팅은 베리피케이션(verification 검증. 테스팅 시스템 관점)과 밸리 데이션(validation 검정. 즉 확인. 시스템 운영 환경 관점)  모두 포함한다.

 

테스팅은 동적 테스팅과 정적 테스팅이 있다.

 

동적 테스팅(4장 참고) : 소프트웨어를 실행함

정적 테스팅(3장 참고) : 소프트웨어를 실행하지 않음. 리뷰와 정적 분석을 포함

 

테스팅은 기술적인 활동에 국한되지 않으며, 적절한 계획/관리/추정/모니터링/제어도 필요(5장 참고)

테스터는 도구를 사용하지만, 테스팅은 주로 테스터가 전문 지식을 갖추고 분석 기술을 사용해 비판적 사고와 시스템적 사고를 적용하는 지적 활동이다.

 

1.1.1. 테스트 목적

(k1) 일반적인 테스트 목적을 식별할 수 있다 -> 암기

 

• 요구사항, 사용자 스토리, 설계, 소스 코드 등 작업 산출물 평가

• 장애 유발 및 결함 식별

• 테스트 대상에 필요한 커버리지 보장

• 소프트웨어 품질 부족으로 인한 리스크 수준 완화

• 정의된 요구사항의 충족 여부를 확인하는 베리피케이션(검증)

• 테스트 대상의 계약, 법률, 규제 요구사항 준수 여부를 확인하는 베리피케이션(검증)

• 이해관계자가 정보에 입각한 결정을 내리는데 필요한 정보 제공

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

• 테스트 대상의 완성 여부와 이해관계자의 기대 충족 여부를 확인하는 밸리데이션(검정)

 

 

1.1.2. 테스팅과 디버깅

(k2) 테스팅과 디버깅을 구분할 수 있다. -> 이해

디버깅은 개발자의 영역이며 테스팅은 테스터와 개발자 모두의 영역이다.

개발 당시 IDE를 이용한 디버깅 포인트와 테스트 코드를 생각해보자.

정적 테스팅	동적 테스팅
소프트웨어를 실행하지 않음	소프트웨어를 실행함
초기 단계에서 결함을 발견하고 수정 비용 절감	소프트웨어가 요구사항을 충족하고, 예상대로 동작하는지 확인
문서 리뷰, 코드 리뷰, 정적 분석	유닛 테스트, 통합 테스트, 시스템 테스트, 사용자 수용 테스트
비용 효율적, 조기 결함 발견	실제 동작 평가, 사용자 경험 개선
실행 중에 발생하는 결함을 찾기 어려움	후기 단계에서 결함을 발견하면 수정 비용이 높아질 수 있음

 

테스팅	소프트웨어의 결함을 발견하는 과정. 테스터는 예상 결과와 실제 결과를 비교하여, 소프트웨어의 결함이나 오류를 식별합니다.
디버깅	발견된 결함의 근본 원인을 분석하고 수정하는 과정. 개발자가 코드를 분석

 

동적 테스팅 이후 디버깅 프로세스
• 장애 재현 -> 분석(근본 원인 식별) -> 원인 해결

 

정적 테스팅으로 결함을 식별한 경우 디버깅은 결함을 제거하는 데 중점을 둔다.
정적 테스팅에서는 장애를 유발하지 않고 직접 결함을 식별하기 때문에 장애를 재현하고 분석할 필요가 없다.

 

이후 확인 테스팅(confirmation testing)으로 문제가 제대로 수정됐는지 확인

확인 테스팅은 처음 테 스트를 수행한 사람이 다시 수행하는 것이 바람직하다.

수정 사항이 테스트 대상의 다른 부분에 장애를 일으키지 않았는지 확인하기 위해 리그레션 테스팅(regression testing)을 추가로 수행할 수 있다.

 

 

1.2. 테스팅이 왜 필요한가?

품질 제어 활동의 일환으로 테스팅은 정해진 범위, 시간, 품질, 예산 내에서 합의된 목표를 달성하는 데 도움을 준다.
성공에 기여하는 테스팅이 테스트팀의 활동으로 국한된 것은 아니다. 모든 이해관계자는 자신이 가진 테스트 기술을 사용해 프로젝트 성공에 기여할 수 있다. 컴포넌트, 시스템, 관련 문서를 대 상으로 한 테스팅은 소프트웨어 결함을 식별하는 데 도움이 된다.

 

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

(k2) 테스팅이 필요한 이유를 예를 들어 설명할 수 있다 ->이해

 

1. 테스팅은 결함을 식별하는 비용 효율적인 방법

 

2. 식별한 결함은(테스팅 활동이 아닌 디버깅을 통해) 제거할 수 있기 때문에 테스팅은 테스트 대상의 품질 향상에 간접적으로 기여

 

3. 테스팅은 소프트웨어 개발수명주기(SDLC)의 여러 단계에서 테스트 대상의 품질을 직접 평가하는 방법을 제공한다. 이런 평가결과는 대규모 프로젝트 관리 활동에서 릴리스 여부의 판단과 같은, 소프트웨어 개 발수명주기(SDLC) 다음 단계로의 이동여부 결정에 기여

 

4. 테스팅은 개발 프로젝트에서 사용자를 간접적으로 대변.
테스터는 개발수명주기 전반에 걸쳐 그들 이 이해하고 있는 사용자 요구사항을 고려한다. 사용자 대표 집단이 개발 프로젝트에 참여하게 할 수도 있지만, 높은 비용과 적합한 사용자의 가용성 부족으로 쉽지 않은 경우가 많다.

5. 계약 또는 법적 요구사항을 충족하거나 규제 표준 준수를 위해 테스팅이 필요할 수 있다.

 

1.2.2. 테스팅과 품질 보증(QA)

(k1) 테스팅과 품질 보증의 관계를 상기할 수 있다. -> 암기

 

품질 보증(QA, Quality Assurance)	테스팅은 품질 제어(QC, Quality Control)
품질 보증은 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법 좋은 프로세스 를 올바르게 준수하면 좋은 제품이 만들어진다는 가정을 기반	적합한 수준의 품질 달성을 지원하는 활동에 초점을 맞춘 제품 중심의 교정 접근법
개발 및 테스팅 프로세스 모두에 적용되며, 프로젝트에 참여하는 모두의 책임	테스팅은 품질 제어의 주요 활동 정형 기법(모델 확인 및 정확성의 증명), 시뮬레이션, 프로토타이 핑도 품질 제어에 속한다.

 

테스트 결과는 품질 보증(QA)과 품질 제어(QC) 모두에 사용된다. 품질 제어는 결함을 수정하는 데 사용하며, 품질 보증은 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용한다.

 

1.2.3. 오류, 결함, 장애, 근본 원인

(k2) 근본 원인, 오류,결함,장애를 구별할 수 있다 -> 이해

근본적 원인은 사람 및 환경적 요소등으로 결정된다.

 

1. 사람은 오류(실수)를 저지르며 이에 따라 결함(결점, 버그)이 발생하고, 이는 결국 장애로 이어질 수 있다. 사람은 시간적인 압박, 작업 산출물의 복잡성, 프로세스, 인프라, 상호작용 등 다양한 이유로, 또 단순히 피로하거나 충분한 훈련이 부족해서 오류를 범할 수 있다.

 

2. 결함은 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 빌드 파일과 같은 지원 산출물 (supporting artifact)에서 나올 수 있다. 소프트웨어 개발수명주기(SDLC) 초기에 만든 산출물의 결함을 발 견하지 못했을 때 이후 결함이 있는 산출물로 이어지는 경우가 많다. 소스 코드에 있는 결함이 실행되 면 시스템이 수행해야 할 작업을 수행하지 못하거나, 수행하지 않아야 할 작업을 수행해 장애를 일으킬 수 있다. 실행될 경우 항상 장애를 일으키는 결함도 있지만, 특정 상황에서만 장애를 일으키거나 장애로 이어지지 않는 결함도 있다.

 

3. 장애의 원인이 오류와 결함만 있는 것은 아니다. 방사선이나 전자기장으로 인한 펌웨어 결함 때문에 발 생하는 장애처럼 환경 조건으로 발생하는 것도 있다.

 

4. 근본 원인은 문제 발생의 근본적인 이유(예: 오류로 이어지는 상황)를 말한다. 근본 원인은 근본 원인 분석(root cause analysis)을 통해 식별한다. 근본 원인 분석은 보통 장애가 발생하거나 결함을 식별한 경우 수행한다. 근본 원인을 처리(예를 들어 제거)하면 유사한 장애나 결함을 예방하거나 그 빈도를 줄일 수 있다.

 

1.3. 테스팅의 원리

(k2) 테스팅의 7가지 원리를 설명할 수 있다. -> 이해

 

아래는 실러버스에서 소개하는 7가지 테스트 원리이다.

 

1. 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지는 않는다.

즉 결함이 없다는 것을 증명할 수는 없다. 테스팅으로 테스트 대상에 결함이 잔존해 있을 확률을 줄일 수 있지만, 결함이 전혀 발견되지 않았다 하더라도 그 소프트웨어가 완벽하다는 뜻은 아니다.

 

2. 완벽한 테스팅은 불가능하다.

모든 것을 테스팅한다는 것은 매우 간단한 소프트웨어를 제외하고 는 불가능하다(Manna 1978). 따라서 완벽하게 테스트하려고 하기보다 테스트 기법(4장 참조), 테 스트 케이스 우선순위 지정(5.1.5 참조), 리스크 기반 테스팅(5.2 참조)을 사용해 테스트 노력을 집중해야 한다.

 

3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.

프로세스 초기에 발견해 제거한 결함은 연관된 다른 산출물의 후속 결함으로 이어지지 않는다. 소프트웨어 개발수명주기(SDLC) 후반에 발생하 는 장애가 줄기 때문에 품질 비용이 절감된다(Boehm 1981). 결함을 조기에 식별하기 위해 정적 테스팅(3장 참조)과 동적 테스팅(4장 참조) 모두 최대한 이른 시점에 시작해야 한다.

 

4. 결함은 집중된다.

보통 대부분의 결함은 소수의 시스템 컴포넌트에 집중되어 발생하는 경향을 보이며, 운영 장애의 대부분 역시 소수의 컴포넌트에서 발생한다(Enders 1975). 이런 현상은 파 레토 원리(Pareto principle)의 예이다. 예상 결함 집중 영역과, 실제로 테스트나 운영 중 관측한 결함 집중 영역은 리스크 기반 테스팅의 주요 입력으로 사용된다(5.2 참조).

 

5. 테스트 효과는 줄어든다.

만일 같은 테스트를 계속해서 반복하면, 결국 해당 테스트의 신규 결함 식별 효과는 점점 줄어들게 된다(Beizer 1990). 이런 현상을 극복하기 위해 기존 테스트와 테스트 데이터의 수정 및 새로운 테스트 작성이 필요할 수 있다. 그러나 자동 리그레션 테스팅처럼 같은 테스트를 반복하는 것이 유익한 결과로 이어지는 경우도 있다(2.2.3 참조).

 

6. 테스팅은 정황에 의존적이다.

모든 상황에 적용할 수 있는 하나의 테스팅 접근법은 없다. 테스팅 은 정황에 따라 다르게 진행한다(Kaner 2011).

 

7. 결함-부재는 궤변이다.

소프트웨어 베리피케이션이 시스템의 성공을 보장할 것이라고 기대하는 것은 잘못된 생각이다. 정의한 모든 요구사항을 철저히 테스트하고, 발견한 모든 결함을 수정하 더라도 사용자의 요구나 기대에 못 미치거나, 고객의 비즈니스 목표 달성에 도움이 되지 않고 경쟁 시스템에 비해 부족한 시스템이 만들어질 수도 있다.
따라서 베리피케이션과 함께 벨리데이션도 수행해야 한다(Boehm 1981).

 

1.4. 테스트 활동, 테스트웨어, 테스트 역할

테스팅은 정황에 의존적이지만, 상위 수준에서 봤을 때 만약 없다면 테스팅이 테스트 목적을 달성하기 어렵게 되는 보편적인 테스트 활동이 있다. 이런 테스트 활동이 테스트 프로세스(test process)를 구성하 게 된다. 테스트 프로세스는 여러 요인을 기반으로 주어진 상황에 맞게 조정될 수 있다. 테스트 프로세스에 포함할 테스트 활동과 그러한 활동의 구현 방법과 수행 시기는 보통 해당하는 상황의 테스트 계획 을 할 때 결정한다(5.1 참조). 이어지는 몇 개의 절은 테스트 활동 및 업무, 정황이 미치는 영향, 테스트웨어, 테스트 베이시스와 테스 트웨어 간의 추적성, 테스팅 역할의 측면에서 일반적인 테스트 프로세스를 설명한다. ISO/IEC/IEEE 29119-2 표준은 테스트 프로세스에 대한 추가 정보를 제공한다.

 

1.4.1. 테스트 활동과 업무

(K2) 다양한 테스트 활동과 업무를 요악할 수있다. -> 이해

기본적인 용어들의 암기 필요

 

순차적으로 수행되 는 것처럼 보일 수 있으나, 실제로는 반복적 또는 병렬로 구현되는 경우가 많다. 테스팅 활동은 일반적 으로 시스템과 프로젝트에 맞게 조정한다.

 

테스트 계획(Test planning)	테스트 목적을 정의한 다음 전반적인 상황에 따른 제약 조건 내에서 목적을 가장 잘 달성할 수 있는 접근법 선택.
테스트 모니터링과 제어 (Test monitoring and control)	모니터링 : 지속적으로 모든 테스트 활동을 점검하고 실제 진행 상황을 계획과 비교하는 활동 테스트 제어 : 지속적으로 모든 테스트 활동을 점검하고 실제 진행 상황을 계획하고 비교. 테스트 목적을 달성하는데 필요한 조치를 하는 활동
테스트 분석(Test analysis)	테스트 베이시스를 분석해 테스트 가능한 기능을 식별,관련 테스트 컨디션 정의, 우선순위 정하는 활동 포함되며 이와 관련된 리스크와 리스크 수준도 같이 고려. 테스트 베이시스와 테스트 대상을 평가해 결함을 식별하고, 테스트 용이성을 평 가한다. 테스트 분석을 지원하기 위해 테스트 기법을 사용하는 경우가 많다. 테스트 분석은 측 정할 수 있는 커버리지 조건으로 “무엇을 테스트할 것인가?”라는 질문에 대한 답을 제공한다.
테스트 설계(Test design)	테스트 컨디션을 테스트 케이스와 기타 테스트웨어로 구체화 하는 작업 테스트 케이스 입력값을 구체화하는 데 도움이 되는 커버리지 항목 의 식별을 포함하는 경우가 많다. 활동을 지원하기 위해 테스트 기법(4장 참조)을 활용할 수 있다. 테 스트 설계는 테스트 데이터 요구사항 정의, 테스트 환경 설계, 기타 필요 인프라와 도구 식별도 포함한 다. 테스트 설계는 “어떻게 테스트할 것인가?”라는 질문에 답을 제공
테스트 구현(Test implementation)	테스트 실행에 필요한 테스트웨어를 만들거나 획득하는 작업을 포함한다. 테스트 케이스는 테스트 절차(test procedure)로 묶을 수 있으며, 테스트 스위 트(test suite)로 조합하는 경우도 많다. 수동 및 자동 테스트 스크립트를 만들게 된다. 효율적인 테스트 실행을 위해 우선순위를 반영한 테스트 실행 일정으로 테스트 절차를 정리한다. 테스트 환경 을 구축하고 올바르게 설정되었는지 확인한다.
테스트 실행(Test execution)	일정에 따라 테스트를 수행하는 것(테스트 런)을 포함한다. 테스트는 수동/자동으로 실행할 수 있다. 테스트 실행은 지속적 테스팅(continuous testing), 페어 테 스팅 세션(pair testing sessions) 등 다양한 형태로 이루어질 수 있다. 실제 테스트 결과를 기대 결과와 비교한다. 테스트 결과는 기록된다. 이상 현상을 분석해 가능한 원인을 파악한다. 이런 분석을 통해 관찰 한 장애를 기반으로 이상 현상을 보고할 수 있다
테스트 완료(Test completion)	일반적인 프로젝트 마일스톤에서 수행하며, 해결되지 않는 결함에 대해서 변경 요청서 또는 제품 백로그 항목을 만든다. 향후 유용할 수 있는 테스트 웨어를 식별해서 보관하거나 적절한 팀에 인계한다. 테스트 환경은 합의된 상태로 종료하게 된다. 테스트 활동을 분석해 향후 반복 주기, 릴리스, 프로젝트를 위한 교훈과 개선 사 항을 파악한다. 테스트 완료 보고서를 작성해 이해관계자에게 전달한다.

 

1.4.2. 정황에 따른 테스트 프로세스

(K2) 정황이 테스트 프로세스에 미치는 영향을 설명할 수 있다. ->이해

 

테스팅은 단독으로 수행되지 않는다. 테스트 활동은 조직에서 수행하는 개발 프로세스의 필수적인 부분 이다. 테스팅 비용은 이해관계자가 부담하게 되며, 테스팅의 최종 목표는 이해관계자의 비즈니스 목표 달성을 지원하는 것이다. 따라서 테스팅 수행 방식은 다음과 같은 여러 정황 요소에 따라 달라진다.

 

• 이해관계자(필요, 기대, 요구사항, 협력 의지 등)

• 팀원(기술, 지식, 경험 수준, 가용성, 훈련 필요성 등)

• 비즈니스 도메인(테스트 대상의 중요도, 식별된 리스크, 시장 요구사항, 구체적인 법적 규제 등)

• 기술적 요인(소프트웨어 유형, 제품 아키텍처, 사용된 기술 등)

• 프로젝트 제약 조건(범위, 시간, 예산, 자원 등)

• 조직적 요인(조직 구조, 기존 정책, 적용한 실천법 등)

• 소프트웨어 개발수명주기(SDLC)(공학적 실천법, 개발 방법론 등)

• 도구(가용성, 사용성, 규정 준수 등)

 

테스트 전략, 적용된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트 문서 상세화 수준, 보고 등 많은 테스트 관련 문제에 영향

 

1.4.3. 테스트웨어

(K2) 테스트 활동을 지원하는 테스트웨어를 구분할 수 있다. -> 이해

1.4.1을 암기 한다면 충분히 연관되어 생각할 수 있다.

 

테스트 활동의 결과물로 만들어진다. 조직마다 테스트웨어를 생성/구체 화/명명/구성/관리하는 방식에 상당한 차이가 있다. 적절한 형상관리(5.4 참조)는 작업 산출물의 일관성 과 무결성을 보장한다.

 

테스트 계획 작업 산출물	테스트 계획, 테스트 일정, 리스크 관리 대장(risk register), 시작 및 완료 조건. 리스크 관리 대장은 리스크 발생 가능성, 리스크 영향, 리스크 완화 정보가 들어있는 리스크 목록이다. 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건은 종종 테스트 계획서에 들어간다
테스트 모니터링과 제어 작업 산출물	테스트 진행 상황 보고서 제어 지침 문서 리스크 정보
테스트 분석 작업 산출물	(우선순위가 지정된) 테스트 컨디션, (바로 수정하지 않았다면) 테스트 베이시스의 결함에 관한 결함 보고서
테스트 설계 작업 산출물	(우선순위가 지정된) 테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항
테스트 실행 작업 산출물	테스트 로그, 결함 보고서
테스트 완료 작업 산출물	테스트 완료 보고서 향후 프로젝트 또 는 반복 주기 때 개선할 실천 항목 문서로 기록한 교훈 변경 요청서

 

1.4.4. 테스트 베이시스와 테스트웨어 간의 추적성

(K2) 추적성을 유지하는 것의 가치를 설명할 수 있다. -> 이해

좋은 추적성은 직관적인 이해에 도움이 된다.

 

효과적인 테스트 모니터링과 제어를 구현하려면 테스트 프로세스 전반에 걸쳐 테스트 베이시스의 개별 요소, 개별 요소와 관련된 테스트웨어(예: 테스트 컨디션, 리스크, 테스트 케이스), 테스트 결과, 식별한 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.

정확한 추적성은 커버리지 평가를 지원하며, 측정 가능한 커버리지 기준이 테스트 베이시스에 정의되어 있을 때 매우 유용하다. 커버리지 기준은 테스트 목적 달성 상태를 나타내는 활동을 촉진하는 핵심성 과 지표로 기능할 수 있다.

• 테스트 케이스에서 요구사항으로의 추적성을 통해 테스트 케이스가 요구사항을 커버하고 있는 지 확인할 수 있다.
• 테스트 결과에서 리스크로의 추적성을 통해 테스트 대상의 잔존 리스크 수준을 평가할 수 있다.

 

좋은 추적성은 커버리지 평가 외에도 변경사항의 영향을 파악할 수 있게 하고, 테스트 감사를 용이하게 하며, IT 운영 및 관리(IT governance) 기준을 충족하는 데 도움이 된다. 좋은 추적성은 또한 테스트 진행 상황 및 완료 보고서에 테스트 베이시스 개별 요소의 상태를 명시하여 보고서를 더 쉽게 이해할 수 있 게 한다. 이해관계자에게 테스팅의 기술적 측면을 이해하기 쉬운 방식으로 전달하는 데 도움이 되기도 한다. 추적성은 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.

 

1.4.5. 테스팅에서의 역할

(K2) 테스팅에 참여하는 다양한 역활을 비교할 수 있다. -> 이해

 

두 가지의 주요 테스팅 역할, 즉 테스트 관리 역할과 테스팅 역할을 다룬다. 이 두 역할 에 할당되는 활동과 업무는 프로젝트 및 제품의 정황, 역할 담당자의 기술 수준, 조직 상황 등의 요소에 따라 달라진다.

 

테스트 관리	테스트 역활
테스트 프로세스, 테스트팀 그리고 테스트 활동 리더십에 대한 전반적인 책임을 지 는 것 테스트 관리 역할은 팀 리더, 테스트 관리자, 개발 관리자 등이 수행	테스팅의 공학(기술)적인 측면에 대한 전반적인 책임 한 사람이 테스팅과 테스트 관리 역할을 동시에 수행하는 경우도 있다.
테스트 계획, 테스트 모니터링과 제어, 테스트 완료 활동 협업이 필요한 업무 는 개발팀 외부의 테스트 관리자가 수행	주로 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 활동

 

1.5. 테스팅의 필수 기술 및 모범 사례

기술(skill)이란 어떤 일을 잘 해내는 능력으로, 그 사람이 가진 지식, 경험, 적성에서 비롯된다. 우수한 테스터는 업무를 잘 수행하기 위한 몇 가지 필수적인 기술을 갖추어야 한다. 우수한 테스터는 팀플레이, 즉 협업에 능한 사람이어야 하며, 다양한 수준의 독립성으로 테스팅을 수행할 수 있어야 한다.

 

1.5.1. 테스팅에 보편적으로 필요한 기술

(K2) 테스팅에 필요한 보편적인 기술의 예를 지적할 수 있다.

적절한 배경지식 및 자료들을 기반으로 한 커뮤니케이션으로 합리적으로 정보를 전달해야한다.

 

보편적인 것들이지만, 다음 기술은 테스터에게 특히 요구되는 것들이다:

 

• 테스팅 지식(테스팅 효과를 높이기 위해, 예: 테스트 기법 활용)

• 철저함, 신중함, 호기심, 세부사항에 대한 주의력, 체계적인 접근(결함, 특히 찾기 어려운 결함 식별을 위해)

• 우수한 의사소통 기술, 경청하는 자세, 팀플레이(모든 이해관계자와 효과적으로 상호작용하고, 다른 사람에게 정보를 전달하고, 상대의 이해를 구하고, 결함을 보고하고, 논의하기 위해)

• 분석적 사고, 비판적 사고, 창의성(테스팅 효과를 높이기 위해)

• 기술 지식(테스팅 효과를 높이기 위해, 예: 적절한 테스트 도구 사용)

• 도메인 지식(최종 사용자/비즈니스 대표자를 이해하고 그들과의 소통을 위해)

 

테스터는 좋지 않은 소식을 전해야 하는 경우가 많다. 나쁜 소식일 경우 그것을 전하는 사람을 탓하는 것은 인간이 가지고 있는 기본 성향 중 하나이다. 따라서 테스터에게 의사소통 기술은 매우 중요하다.

 

테스트 결과의 전달을 제품이나 작성자에 대한 비판으로 오해할 소지가 있다. 확증 편향(confirmation bias)은 현재 가지고 있는 믿음과 맞지 않는 정보를 받아들이기 어렵게 만든다. 테스팅이 프로젝트 성공 과 제품 품질에 상당히 기여함에도 불구하고, 테스팅을 파괴적인 활동으로 간주하는 사람도 있다. 이런 인식을 개선하려면 결함과 장애관련 정보를 건설적인 방법으로 전달해야 한다.

 

1.5.2. 전체 팀 접근법

(K1) 전체 팀 접근법의 장점을 상기할 수 있다.

 

테스터에게 중요한 기술 중 하나는 팀 환경에서 효과적으로 일하고, 팀 목표에 긍정적으로 기여하는 능력이다.

익스트림 프로그래밍에서 시작된 전체 팀 접근법(Whole Team Approach)은 이런 능력 을 기반으로 한다.

 

전체 팀 접근법에서는 필요 지식과 기술을 갖춘 팀원이라면 누구나 모든 작업을 수행할 수 있고, 모든 팀원이 품질에 대해 책임진다. 같은 공간을 사용하는 것(co-location)은 의사소통과 상호작용을 용이하게 하므로 팀원들은 (물리적 또는 가상의) 작업 공간을 공유한다. 전체 팀 접근법은 팀의 활력을 높이고, 팀 내 의사소통과 협업을 강화하며, 프로젝트의 성공을 위해 팀이 가진 다양한 기술을 활용해 시너지를 창출한다.

 

테스터는 필요한 수준의 품질 달성을 위해 다른 팀원과 긴밀히 협력하게 된다. 여기에는 비즈니스 담당 자와 협력해 적절한 인수 테스트를 작성하고, 개발자와 협력해 테스트 전략을 협의하고, 테스트 자동화 접근법을 결정하는 것도 포함된다. 따라서 테스터는 테스팅 지식을 다른 팀원과 공유하게 되며, 제품 개 발에 영향을 주게 된다.

 

정황에 따라 전체 팀 접근법이 적절하지 않을 수도 있다. 예를 들어, 안전이 치명적인 경우에는 높은 수준의 테스트 독립성이 필요할 수 있다.

 

1.5.3. 테스팅의 독립성

(K2) 독립적 테스팅의 장단점을 구분할 수 있다.

독립적 테스팅은 효과적으로 결함을 식별할 수 있으나, 높은 독립성은 개발팀과의 불화 및 책임 저하로 이어질 수 있다.

적절한 독립성을 구축하여 상호보완적인 테스팅 환경을 구축해야한다.

 

일정 수준의 독립성은 저자와 테스터의 인지 편향(cognitive biases) 차이로 테스터가 결함을 더 효과적으로 식별할 수 있도록 한다(Salman 1995). 그러나 독립성이 친숙함을 대체하는 것은 아니다. 예를 들어, 개발자는 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.

 

독립성 없음	작업 산출물은 저자가 직접 테스트
일정 수준 의 독립성	저자의 같은 팀 동료가 테스트
높은 독립성	저자의 팀 외부에 있지만 조직 내에 있는 테스터가 테스트
매우 높은 독립성	조직 외부의 테스터가 테스트

 

대부분의 프로젝트는 여러 수준의 독립성으로 테스팅을 수행하는 것이 가장 좋다(예: 개발자가 컴포넌트와 컴포넌트 통합 테스팅을 수행하고, 시스템과 시스템 통합 테스팅은 테스트팀이 수행하고, 비즈니스 담당자가 인수 테스팅을 수행)

 

독립적 테스팅의 장점	독립적 테스팅의 단점
배경, 기술적 관점, 편향이 다르기 때문에 독립적인 테스터가 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다	독립적인 테스터는 개발팀과 차단되어 협업과 의사소통이 어려울 수 있으며, 개발 팀과 적대적인 관계로 이어질 수 있다.
독립적인 테스터는 시스템 명세를 작 성하고 구현하는 과정에서 이해관계자의 가정을 검증하고, 그것에 대한 이의를 제기하거나 반증할 수 있다.	개발자가 품질에 대한 책임감을 잃을 수도 있다. 독립적인 테스 터가 병목으로 인식되거나, 출시 지연의 원인으로 비난 받을 수도 있다.