1. 소프트웨어 테스팅의 기초

 

1. 소프트웨어 테스팅

소프트웨어 시스템 관점에서 테스팅의 필요성

소프트웨어 시스템은 생활의 많은 부분에서 사용되고 있으며 비중은 계속해서 증가하고 있다. 소프트웨어가 올바르게 동작하지 않는 경우 다양한 문제가 발생한다. 이로 인한 피해는 금전적 손실, 시간 낭비, 비즈니스 이미지 손상 등 다양함. 테스팅은 이러한 문제를 최소화하기 위해 반드시 필요하다.

 

소프트웨어 결함원인

결함은 사람이 오류를 범하기 쉽기 때문에 발생하며, 시간적인 압박, 복잡한 코드, 기반 환경의 복잡성, 기술이나 시스템의 변경, 그리고 수많은 시스템 상호 간의 연동 등의 이유로 발생한다. 장애는 이와 같은 결함에 의해서뿐만 아니라 환경적인 조건에 의해서도 발생한다.

[결함 / 오류 / 장애의 차이점]

오류(Error) : 결함이 되는 요소.

결함(Defects, Bug) : 에러가 소프트웨어상에 나타나는 것. 모든 결함이 장애로 이어지지는 않음.

장애(Failure) : 시스템이 의도된 대로 동작하지 않거나 동작하지 말아야 함에도 동작함. 코드에 존재하는 결함은 장애의 원인이 됨

 

소프트웨어의 개발, 유지보수, 운영 시 테스팅의 역할

발견하지 못했던 결함들을 테스팅을 통해 릴리즈 전에 발견하고 수정한다면, 운영 환경 내에서 발생하는 결함들의 리스크를 줄이는데 기여할 수 있으며 소프트웨어 시스템의 품질 향상에도 도움을 준다.

개발 초기의 요구사항 분석 단계부터 리뷰와 정적 분석을 통해 정적으로 시작될 수 있으며 각각의 개발 단계의 대응하는 테스트 레벨에 따른 테스팅이 이루어진다. 컴포넌트 테스팅과 통합 테스팅은 개발 조직이 중심이 되어 수행되고, 시스템이 갖춰진 이후의 테스팅은 개발 조직의 지원을 받아 독립성을 가진 테스트 조직을 중심으로 수행하는 것이 바람직하다. 최종 소프트웨어 사용자가 인수하는 과정에서의 테스팅도 전체 개발 과정에서의 한 가지 테스팅이다. 이와 같은 테스팅은 소프트웨어가 고객에게 전달된 이후 결함이 발생할 가능성을 최소화한다.

 

테스팅과 품질

테스팅을 통해 발견한 결함에 근거하여 대상 소프트웨어의 기능 또는 비기능적 요구사항과 품질특성(기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 등) 관련 품질 측정이 가능하다.

테스트 설계 및 실행이 정상적으로 진행되었다는 전제하에 소프트웨어의 품질에 대한 확신을 가질 수 있다. 올바르게 설계된 테스팅은 시스템의 전반적인 리스트 수준을 감소시킨다. 테스팅이 결함을 찾아내고, 발견된 결함이 수정 때 소프트웨어 시스템의 품질은 향상된다.

 

2. 테스팅이란 무엇인가?

테스팅이란 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘이다. 

테스트 활동은 테스트를 수행하기 전과 후에도 존재하며, 테스트 계획과 제어 같은 활동이나 테스트 조건의 선택, 테스트 케이스의 설계, 테스트 수행 결과 점검, 테스트 완료 및 통과 조건의 평가, 테스트 프로세스와 테스트 대상 시스템에 대한 리포트, 마무리 또는 마감과 같은 일련의 활동들을 포함한다.

 

3. 테스팅의 원리

원리 1 : 테스팅은 결함이 존재함을 밝히는 활동이다.

테스팅은 소프트웨어에 잠재적으로 존재하는 결함을 줄일 수는 있지만, 결함이 전혀 발견되지 않은 경우라도 해당 소프트웨어에 결함이 없다고 증명할 수는 없다. 즉 테스팅은 결함이 존재함을 밝히는 것이다.

원리 2 : 완벽한 테스팅(Exhaustive testing)은 불가능하다.

일반적으로 완벽한 테스팅이 불가능한 이유는 다음과 같다.

- 한 프로그램 내의 내부 조건이 무수히 많을 수 있음 (무한 경로)

- 입력이 가질 수 있는 모든 값의 조합이 무수히 많음 (무한 입력값)

-  GUI 이벤트 발생 순서에 대한 조합도 무수히 많음(무한 타이밍)

원리 3 : 테스팅을 개발 초기에 시작한다.

테스트 활동은 소프트웨어나 시스템 개발 수명주기에서 가능한 초기에 시작되어야 하며, 설정한 테스트 목표에 집중해야 한다.

개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근하는 것을 고려하는 것은 물론, 요구사항 분석서와 설계(기준서) 등의 개발 산출물을 분석하여 테스트 케이스를 도출하는 과정을 통해 결함을 발견하는 것을 말한다.

개발 과정에서 조기 테스트 설계(Early test design)를 하면, 코딩이 끝나자마자 개발 초기부터 준비된 테스트 케이스를 테스트 레벨별로 실행하게 되므로 테스팅 결과를 단기간에 알 수 있고 전체 테스팅 기간을 단축할 수 있다. 코딩에서의 재작업을 줄여 개발 기간을 단축할 수 있고 개발 후반부에 발견된 결함을 예방할 수 있다.

원리 4 : 결함 집중(Defect clustering)

대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보이며, 이러한 결함의 집중은 대부분 운영상의 장애를 초래한다.

원리 5 : 살충제 패러독스 (Pesticide paradox)

동일한 테스트 케이스로 동일한 테스트를 반복적으로 수행한다면, 나중에는 새로운 결함을 찾아내지 못한다. 시스템에 잠재된 보다 많은 결함을 발견하기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선할 필요가 있다.

원리 6 : 테스팅은 정황(Context)에 의존적이다.

테스팅은 정황에 따라 다르게 진행된다. 정황과 도메인(분야)에 따라 다르게 테스팅을 진행해야 하지만 아래와 같이 모든 테스팅에서 변하지 않는 사항도 존재한다.

- 테스트 주요 활동에 대한 테스트 프로젝트 계획

- 표준적인 기법 적용(Technique)

- 독립적 테스트 환경(Environment)

- 효율적/효과적 테스트 팀 조직(Organization)

- 정식 리포팅(Formal reporting) 등

원리 7 : 오류-부재의 궤변(Absence-of-errors fallacy)

사용자 또는 비즈니스의 요구를 충족시켜주지 못한다면, 설사 결함을 모두 발견했다고 하더라고 품질이 높다고 볼 수는 없다.

 

4. 테스트 프로세스

테스트 계획과 제어(통제)

테스트 계획 수립은 테스트 목표와 임무를 달성하기 위해 이를 면밀히 확인하고 필요한 활동을 정의하는 것이다. 테스트 계획 수립 관련 주요 작업 내용은 테스트 범위와 테스트를 위한 리스크에 대한 결정, 그리고 테스팅의 목적에 대한 식별을 작업하는 것이다. 또, 테스트 정책의 실현과 테스트 전략의 구현, 테스트 접근 방법에 대한 결정, 리소스 결정, 일정관리, 테스트 완료 조건의 결정이 있다.

- 테스트 범위 : 다른 시스템과의 인터페이스 정고, 관련 품질 특성, 호환성 테스팅 범위, 커버하고자 하는 테스트 레벨 등

- 리스크 기반 테스트 전략 : 각각의 테스트 레벨에 대한 테스트 대상 제품이 충족해야 할 품질 수준 및 특성과 기술적 어려움, 비즈니스 리스크를 고려한 테스트 전략 수립

- 테스팅 목적 : 품질 요구 수준, 테스트 레벨 별 목적(결함 발견, 요구사항 충족 등), 커버하고자 하는 품질 특성(기능성, 효율성, 신뢰성, 유지보수성 등)

테스트 제어는 계획 대비 실제 진행 상황을 지속적으로 비교하는 활동이다. 이는 진행상태를 보고하는 것과, 테스트 프로젝트의 목표 및 임무를 달성하기 위해 계획과의 차이에 대해 조치를 취하는 것을 의미한다. 테스트 제어의 주요 작업은 테스트 결과에 대한 측정과 분석, 테스트 진척 상황, 테스트 커버리지와 완료 조건의 모니터링과 문서화, 테스트 계획과의 차이를 교정하는 활동, 테스팅의 진행과 변경에 대한 의사 결정 활동이 있다.

 

테스트 분석과 설계

테스트 분석과 설계는 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동이다. 주요 작업으로는 테스트 베이시스 리뷰(요구사항 명세서, 아키텍처, 개발 설계 문서, 인터페이스), 테스트 대상 아이템 또는 제품, 명세, 동작과 구조의 분석을 통해 테스트 상황을 식별하고 우선순위 선정, 비공식적인 테스트 기법으로 테스트 케이스 추가 도출 및 보완, 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별, 테스트 환경 구축에 대한 디자인과 요구되는 기반 시설 및 도구의 식별이 있다.

 

테스트 구현과 실행

가장 효율적이고 효과적으로 테스트를 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저 또는 테스트 스크립트를 명세화하는 활동이다. 이때에는 테스트 환경이 구축되어 있어야 한다. 주요 작업으로는 테스트 케이스의 개발, 구현과 우선순위 선정, 자동화 테스트 스크립트 작성, 테스트 하네스 준비, 테스트 케이스 묶음(Test suites) 생성, 예상 결과와 실제 결과 간의 차이에서 오는 불일치를 incidents 또는 결함으로 보고, 각각의 불일치를 조치한 결과 확인을 위한 테스트 활동을 반복하는 것 등이 있다.

 

테스트 완료 조건과 리포팅

"완료 조건 평가"는 초기에 정의된 테스트 목표에 비해 어느 정도 실제 테스트가 수행되었는지를 평가하는 활동이다. 테스트 목표를 달성했다면 테스트가 완료된다. 그렇지 않다면 추가적인 테스트가 필요한지, 목표를 변경할 것인지 결정하여야 한다. 해당 활동은 각 테스트 레벨(컴포넌트, 통합, 시스템, 인수 테스팅)마다 수행되는 것이 원칙이다.

완료 조건의 평가와 관련된 주요 작업은 테스트 실행 결과가 테스트 계획에 명시된 완료 조건을 만족하는지 확인하는 것, 추가적인 테스트가 필요한지 명세된 테스트 완료 조건을 변경해야 하는지 결정하는 것, 이해관계자에게 배포할 테스트 요약 보고서 작성이 있다. 

리포팅은 진행보고와 릴리즈 조언 및 최종 보고 형태로 이루어지며 테스팅을 수행하면서 수집한 결함 및 테스트 진행 관련 데이터를 가공하여 메트릭으로 수치화하고 관련 정보를 표현하는 작업이다. 리포팅에는 발견됨 결함과 미해결 결함의 추이 및 우선순위, 테스트 진척도, 리스크 및 메트릭으로 실증된 조언, 테스트 환경의 가용성, 테스트 커버리지, 결함 발견 효과성/효율성, 품질 평가 결과 등이 표현된다.

 

테스트 마감 활동

테스트 마감은 완료된 테스트 활동에서 데이터를 수집하여, 테스트에서 발견된 사실 및 수치적 데이터와 함께 테스팅 경험과 테스트 웨어를 종합하고 축적하는 활동이다. 테스팅이 얼마나 체계적으로 수행되었는지를 평가하고 향후 테스팅을 개선하기 위해 모범 사례를 모델로 테스트 프로세스를 심사하는 것 또한 테스트 마감 활동의 중요한 부분이다.

테스트 마감 활동은 테스트 결과 마감, 테스트 웨어, 테스트 환경, 테스트 기반 설비를 차후 사용할 것을 대비하여 마감하고 보관하는 것, 테스트 웨어를 유지보수 조직에 이관, 테스트 프로세스 심사 및 개선사항 제안 등을 포함한다.

 

 

 

출처: 개발자도 알아야 할 소프트웨어 테스팅 실무 제3판