테스팅의 기초(Fundamentals of Testing)

테스팅이란?

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

 

소프트웨어 테스팅이란?

결함을 식별하고 소프트웨어 산출물의 품질을 평가하는 일련의 활동

- 이러한 산출물을 테스트 대상(test object)라고 한다.

 

소프트웨어 테스팅은 테스트 실행에 국한되는 것이 아니라 다양한 활동을 포함하며, 소프트웨어 개발수명주기(SDLC)에 따라 달라진다.

 

테스팅은 베이리케이션(Verification) + 밸리데이션(Validation)을 포함한다.

시스템이 주어진 요구사항을 충족함과 동시에 운영 환경에서 사용자 또는 기타 이해 관계자가 필요한 바를 만족해야 한다.

 

테스팅은 정적, 동적으로 수행할 수 있다.

동적 테스트 : 소프트웨어를 실행하며 테스트    -- 테스트 케이스를 도출하기 위해 다양한 테스트 기법과 테스트 접근법을 사용한다.

정적 테스트 : 소프트웨어를 실행하지 않으며 테스트

 

테스팅은 적절한 계획/관리/추정/모니터링/제어가 필요하다.

 

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

 

ISO/IEC/IEEE 29119-1 표준은 소프트웨어 테스팅의 개념을 설명하고 있다

 

 

테스트 목적

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

- 장애 유발 및 결함 식별

- 테스트 대상에 대해 요구된 커버리지 보장

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

- 정의된 요구사항의 충족 여부를 확인하는 베리피케이션

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

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

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

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

 

테스팅 목적은 정황에 따라 달라진다. 정황에는 테스트 대상 작업물 산출물, 테스트 레벨, 리스크, 사용하는 소프트웨어 개발수명주기, 기업 구조, 경쟁사 구도, 시장 출시 시기 등의 비즈니스 정황도 포함된다.

 

 

테스팅과 디버깅

테스팅과 디버깅은 별개의 활동이다.

 

테스팅 : 소프트웨어 결함으로 인한 장애를 유발하거나(동적 테스팅), 테스트 대상에 있는 결함을 직접 찾아낸다(정적테스팅)

디버깅 : 장애의 원인(결함)을 찾고, 원인을 분석하고 제거한다.

 

디버깅 프로세스

장애 재현 - 분석(결함 찾기) - 결함 수정

 

확인 테스팅 : 디버깅 한 이후 문제가 제대로 수정됐는지 확인한다. 처음 테스트를 수행한 사람이 다시 수행하는 것이 바람직함

리그레션 테스팅 : 수정 사항이 테스트 대상의 다른 부분에 장애를 일으키지 않았는지 확인하는 테스팅이다.

 

정적 테스팅으로 결함 식별 시 디버깅은 결함을 제거하는데 중점을 둔다.

장애를 유발하지 않고, 직접 결함을 식별하기 때문에 장애를 재현하고 분석할 필요는 없다.

 

 

 

 

테스팅이 왜 필요한가?

테스팅 : 품질 제어 활동의 일환으로 정해진 범위, 시간, 품질, 예산 내에서 합의된 테스트 목표를 달성하는데 도움을 준다.

테스팅은 테스트팀의 활동으로 국한되지 않는다. 모든 이해관계자들은 자신이 가진 테스트 기술을 활용해 성공에 기여할 수 있다.

컴포넌트, 시스템, 관련 산출물(문서)를 대상으로 한 테스팅은 소프트웨어 결함을 식별하는 데 도움이 된다.

 

 

테스팅이 성공에 기여하는 방법

테스팅 : 결함을 식별하는 비용 효율적인 방법이다. 식별한 결함은 디버깅을 통해 제거할 수 있기에 품질 향상에 간접적으로 기여하게 된다.

 

테스팅은 소프트웨어 개발수명주기의 여러 단계에서 테스트 대상의 품질을 직접 평가할 수 있는 방법을 제공한다.

 

평과 결과 -- 프로젝트 관리 활동에 사용 -- 소프트웨어 개발수명주기 다음 단계로 넘어가는 것을 판단하는 결정 등에 기여하게 된다.

 

테스팅은 개발 프로젝트에서 사용자를 간접적으로 대변한다. 테스터는 개발수명주기 전반에 걸쳐 그들이 이해하고 있는 사용자 요구사항이 반영되게 된다.

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

 

 

테스팅과 품질 보증(QA)

품질 보증(QA, Quality Assurance)과 테스팅이라는 용어를 혼용해서 사용하는 경우가 많지만, 품질 보증과 테스팅은 같지 않다.

 

테스팅 : 제품 지향적, 품질 달성을 지원하는 활동에 초점을 맞춘 교정 접근법이다. 품질 제어의 주요 활동이다

    ex) 정형 기법(모델 확인 및 정확성의 증명), 시뮬레이션, 프로토타이핑

 

품질 보증 : 프로세스의 구현과 개선에 초점을 맞춘 프로세스 중심의 예방 접근법이다. 좋은 프로세스를 올바르게 준수하면 좋은 제                   품이 만들어진다는 가정을 기반으로 한다. 개발 및 테스팅 프로세스에 모두 적용. 프로젝트에 참여하는 모두의 책임

 

테스트 결과 : 품질 보증과 테스팅에 모두 사용.

  - 테스팅 측면 : 결함을 수정하는데 사용

  - 품질 보증 측면 : 개발 및 테스트 프로세스가 잘 동작하고 있는지 확인하기 위한 피드백으로 사용

 

 

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

사람은 오류(실수)를 저지르며 이에 따라 결함(결점, 버그)이 발생하고, 이는 결국 장애로 이어질 수 있다.

사람은 시간적인 압박, 작업 산출물의 복잡성, 프로세스, 인프라, 상호작용 등의 다양한 이유로 or 단순히 피로하거나 훈련이 부족하여 오류를 범할 수 있다.

 

결함 : 요구사항 명세서나 테스트 스크립트와 같은 문서, 소스 코드, 필드 파일 등의 지원 산출물에서도 나올 수 있다.

 

SDLC 초기에 만든 산출물의 결함을 발견하지 못할 경우 종종 수명주기 후반 산출물의 결함을 이어지는 경우가 많다.

소스코드에 있는 결함이 수행되면 수행해야 할 작업을 수행하지 못하거나, 수행하지 않아야 할 작업을 수행해 장애를 일으킬 수 있다. 특정 상황에서만 장애를 일으키거나 장애로 이어지지 않는 결함도 있다.

 

환경 조건(방사선, 전자기장)등이 펌웨어에 문제가 생기게 하는 경우처럼 환경 조건으로 발생하는 장애도 있다.

 

 

테스팅의 원리

테스팅에 적용할 수 있는 포괄적 지침 테스팅 원리 7가지는 다음과 같다.

 

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

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

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

4. 결함은 집중된다.

5. 같은 테스트를 반복하면 신규 결함 식별 효과는 줄어들게 된다. but 자동리그레션 테스팅처럼 반복하는 것이 유익한 경우도 있다.

6. 테스팅은 정황에 의존적이다. 모든 상황에 적용할 수 있는 하나의 접근법은 없다.

7. 결함-부재는 궤변이다. 요구사항을 철저히 테스트하고 결함을 수정했더라도 사용자의 요구나 기대에 못미치면 안된다. 밸리데이션도 수행되어야 한다.

 

 

 

 

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

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

but 그에 관계 없이 목적을 달성하기 위해 필요한 보편적인 테스트 활동들이 있다. 이런 활동이 테스트 프로세스(Test process)를 구성하게 된다.

 

테스트 프로세스는 여러 요인을 기반으로 주어진 상황에 맞게 조정될 수 있다. 테스트 프로세스에 포함될 테스트 활동과 그러한 활동의 구체적인 수행 방법과 시기는 해당 상황에 필요한 테스트 계획을 짤 떄 결정한다.

 

ISO/IEC/IEEE 29119-2 표준은 테스트 프로세스에 대한 상세 정보를 제공한다.

 

 

테스트 활동과 업무

테스트 프로세스를 구성하는 주요 활동은 다음과 같다.

 

- 테스트 계획(Test planning) : 테스트 목적을 정의한 다음 전반적인 상황에 따른 제약 조건 내에 목적을 가장 잘 달성할 수 있는 접근법을 선택하는 과정

- 테스트 모니터링(Test monitoring) : 지속적으로 모든 테스트 활동을 점검하고, 실제 상황을 계획과 비교하는 활동

- 테스트 제어(Test control)  : 테스트 목적을 달성하는데 필요한 조치를 하는 활동

- 테스트 분석(Test analysis) : 테스트 베이시스를 분석해 테스트 가능한 기능을 식별, 리스크 수준을 고려해 정의 및 우선순위를 매김, 테스트 분석을 지원하기 위해 테스트 기법을 사용하는 경우가 많음, "무엇을 테스트 할 것인가?"라는 질문에 측정 가능한 커버리지 조건으로 답을 제공, 테스트 베이시스와 테스트 대상 또한 그 안에 있을 수 있는 결함을 식별하고 평가하기 위해 함께 분석 됨

- 테스트 설계(Test design) : 테스트 컨디션을 테스트 케이스와 기타 테스트웨어(ex : 테스트 차터)로 구체화 하는 작업을 포함, 이 활동을 위해 테스트 기법 사용 가능, "어떻게 테스트할 것인가?"라는 질문에 답을 제공

- 테스트 구현(Test implementation) : 테스트 실행에 필요한 테스트웨어를 만들거나 획득하는 작업을 포함. 테스트 케이스는 테스트 절차(test procedure)로 묶을 수 있으며, 테스트 스위트(test suite)로 조합하는 경우도 많다. 수동 및 자동 테스트 스크립트도 만들게 된다.

- 테스트 실행(Test execution) : 테스트 실행 일정에 따라 테스트를 수행하는 것을 포함, 수동 및 자동으로 실행 가능, 지속적 테스팅(continuous testing), 페어 테스팅 세션(pair testing sessions)등 다양한 형태로 이루어질 수 있다.

- 테스트 완료(Test completion) : 프로젝트 마일스톤에서 수행됨, 해결되지 않은 결함에 대해서는 변경서 및 백로그 항목을 만듦, 향후 유용할 수 있는 테스트웨어를 식별해서 보관하거나 적절한 팀에 인계, 테스트 환경은 합의된 상태로 종료하게 됨, 테스트 활동을 분석해 향후 프로젝트를 위한 교훈과 개선 사항을 파악

 

 

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

테스팅은 단독으로 수행되지 않는다.

테스트 활동은 조직에서 수행하는 개발 프로세스의 필수적인 부분이다.

테스팅 비용은 이해관계자가 부담하게 되며, 이해관계자의 비즈니스 목표 달성을 지원하기 위해 테스팅을 진행한다.

 

테스팅 수행 방식은 다음과 같은 요소에 따라 달라진다

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

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

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

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

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

  - 조직적 요인(조직 구조, 기존 정책, 적용한 프랙티스)

  - 소프트웨어 개발수명주기(SDLC)(공학적 프랙티스, 개발 방법론)

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

위와 같은 요소들은 테스트 전략, 적용된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트웨어의 상세화 수준, 테스트 보고 등 많은 테스트 관련 문제에 영향을 미친다.

 

 

테스트웨어

테스트웨어 : 소프트웨어 테스트 과정을 수행하기 위해 필요한 모든 산출물을 통칭한다.

테스트웨어는 테스트 활동의 결과물로 만들어진다. 조직마다 테스트웨어를 생성, 구체화, 명명, 관리하는 방식에는 상당한 차이가 있다.

적절한 형상관리는 작업 산출물의 일관성과 무결성을 보장한다.

    - 테스트 계획 작업 산출물 : 테스트 계획, 테스트 일정, 리스크 관리 대장, 시작 및 완료 조건

    - 테스트 모니터링과 테스트 제어 작업 산출물 : 테스트 진행 상황 보고서, 제어 지침 문서, 리스크 정보

    - 테스트 분석 작업 산출물 : 테스트 컨디션(우선 순위가 지정된), 테스트 베이시스의 결함에 관한 결함 보고서

    - 테스트 설계 작업 산출물 : 테스트 케이스, 테스트 차터, 커버리지 항목, 테스트 데이터 요구사항, 테스트 환경 요구사항

    - 테스트 구현 작업 산출물 : 테스트 절차, 수동 및 자동 테스트 스크립트, 테스트 스위트, 테스트 데이터, 테스트 실행 일정,테스트                                               환경 요소(스텁, 드라이버, 시뮬레이터, 서비스 가상화)

    - 테스트 실행 작업 산출물 : 테스트 로그, 결함 보고서

    - 테스트 완료 작업 산출물 : 테스트 완료 보고서, 향후 프로젝트에서 개선할 실천 항목, 문서로 기록한 교훈, 변경 요청서

 

 

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

테스트 베이시스 : 테스트의 근거가 되는 모든 문서나 정보

효과적인 테스트 모니터링과 제어를 구현하려면 테스트  베이시스의 개별 요소, 개별요소와 관련된 테스트웨어, 테스트 결과, 결함 간의 추적성을 구축하고 유지하는 것이 중요하다.

 

정확한 추적성은 커버리지 평가를 지원하며, 측정 가능한 커버리지 조건이 테스트 베이시스에 정의되어 있다면 매우 유용할 수 있다. 커버리지 조건은 테스트 목적을 어느정도 달성했는지 나타내는 활동들을 촉진하는 핵심 성과 지표로 사용될 수 있다.

    - 테스트 케이스에서 요구사항으로의 추적성을 통해 테스트 케이스가 요구사항을 커버하고 있는지 확인할 수 있다.

    - 테스트 결과에서 리스크로의 추적성을 통해 테스트 대상의 잔존 리스크 수순을 평가할 수 있다.

 

좋은 추적성 : 커버리지 평가 외에 변경 사항의 영향을 파악할 수 있게 한다. 테스트 감사를 용이하게 한다. 운영 및 관리 기준을 충족하는데 도움이 된다. 좋은 추적성은 테스트 베이시스 요소들의 상태를 명시함으로써, 테스트 진행 상황 및 테스트 완료 보고서를 더 쉽게 이해할 수 있도록 해준다.

 

 

테스팅에서의 역할

테스팅에서는 두가지 주요 역할이 있다(테스팅 역할, 테스트 관리 역할)

이 두 역할에 할당되는 활동과 업무는 프로젝트 및 제품의 정황, 역할 담당자의 기술 수준, 조직 상황 등 요소에 따라 달라진다.

 

- 테스트 관리 역할 : 테스트 프로세스, 테스트 팀, 테스트 활동 리더십에 대한 전반적인 책임을 진다. 주요 관심 영역은 테스트 계획, 테스트 모니터링, 테스트 제어, 테스트 완료 활동이다. 테스트 관리 역할의 수행 방식은 정황에 따라 달라진다.

- 테스팅 역할 : 테스팅의 공학(기술)적인 측면에 대한 전반적인 책임을 진다. 테스팅 역할은 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 활동에 초점을 준다.

 

상황에 따라 역할을 수행하는 사람이 달라진 수 있다. 또한 한 사람이 테스팅과 테스트 관리 역할을 동시에 수행하는 경우도 있다.

 

 

 

 

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

기술 : 어떤 일을 잘 해내는 능력으로 그 사람이 가진 지식, 경험, 적성에서 비롯된다.

 

우수한 테스터는 업무를 잘 수행하기 위한 몇가지 필수적인 기술을 갖추어야 한다. 우수한 테스터는 팀플레이, 협업에 능한 사람이어야 하며, 다양한 수준의 독립성에서 테스팅을 수행할 수 있어야 한다.

 

 

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

- 테스팅 지식

- 철저함, 신중함, 호기심, 세부사항에 대한 주의력, 체계적인 접근

- 우수한 의사소통 기술, 경청하는 자세, 팀플레이

- 분석적 사고, 비판적 사고, 창의성

- 기술 지식

- 도메인 지식

 

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

테스트 결과의 전달을 제품이나 작성자에 대한 비판으로 오해할 소지가 있다.

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

 

 

전체 팀 접근법

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

 

전체 팀 접근법 : 익스트림 프로그래밍에서 시작, 필요 지식과 기술을 갖춘 팀원이라면 누구나 어떤 작업이던 수행 가능, 모든 팀원이 품질에 대한 책임을 진다. 의사소통과 상호작용을 용이하게 하기 위해 (물리적 또는 가상의)작업 공간을 공유한다.

 

테스터는 필요한 수준의 품질 달성을 위해 팀원과 긴밀히 협력하게 된다.

비즈니스 담당자와 협력해 적절한 인수 테스트를 작성하고, 개발자와 협력해 테스트 전략을 협의하고, 테스트 자동화 접근법을 결정하는 것도 포함된다. 테스터는 테스팅 지식을 다른 팀원과 공유하며 개발에 영향을 준다.

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

 

 

테스팅의 독립성

일정 수준의 독립성은 저자와 테스터의 인지 편향 차이로 테스터가 결함을 더 효과적으로 식별할 수 있도록 한다.

그러나 독립성이 친숙함을 대체하는 것은 아니다. 예를 들어, 개발자는 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.

 

- 저자가 직접 테스트(독립성 없음)

- 같은 팀 동료가 테스트(일정 수준의 독립성)

- 팀 외부에 있지만 같은 조직 내에 있는 테스터가 테스트(높은 독립성)
- 조직 외부의 테스터가 테스트(매우 높은 독립성)

 

대부분의 프로젝트는 여러 수준으로 독립성으로 테스팅을 수행하는 것이 가장 좋다.

 

독립적인 테스팅의 이점 : 독립적인 테스터는 배경, 기술적 관점, 편향이 다르기 때문에 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다. 독립적인 테스터는 시스템 명세를 작성하고 구현하는 과정에서 이해관계자가 한 가정을 검증하고 그것에 대한 이의를 제기하거나 반증할 수 있다.

 

독립적인 테스팅의 단점 : 독립적인 테스터는 개발팀과 차단되어 협업과 의사소통이 어려울 수 있다. 개발팀과 적대적인 관계로 이어질 수 있다. 개발자가 품질에 대한 책임감을 잃울 수도 있다. 독립적인 테스터가 병목으로 인식되거나, 출시 지연의 원인으로 비판받을수도 있다.