Testing의 정의

What is ‘Testing’

테스팅이란 응용 프로그램 또는 시스템(구성요소를 포함해서)의 동작과 성능, 안정성이 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 메커니즘입니다.
응용 프로그램 또는 시스템이 잘 작동하는지를 확인하는 것이 전통적인 테스팅 개념이었다면 현재의 테스팅은 사용자의 기대 수준과 요구 사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견하고, 최종적으로는 결함 데이터를 근간으로 개발 프로젝트의 리스크(Risk)에 대한 수치적인 판단 근거를 의사결정권자(프로젝트 관리자 등)에게 전달하는 것입니다.

📢 일반적으로 테스팅을 소프트웨어를 실행하면서 테스트를 수행하는 것으로만 인식하는 경우가 많습니다. 그것은 테스팅의 일부분일 뿐이며 테스팅 활동 전부를 나타내는 것은 아닙니다!!

📌 소프트웨어 테스팅

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

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

소프트웨어 결함원인

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

결함, 오류, 장애의 차이점

오류(Error)
- 결함이 되는 요소입니다.
결함(Defects, Bug)
- 에러가 소프트웨어상에 나타나는 것입니다.
- 모든 결함이 장애로 이어지지는 않습니다.
장애(Failure)
- 시스템이 의도된 대로 동작하지 않거나 동작하지 말아야 함에도 동작하는 것입니다.
- 코드에 존재하는 결함은 장애의 원인이 됩니다.

📌 테스팅의 원리

원리 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)

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

📌 테스트의 목적

개발과정에서의 테스팅(컴포넌트, 통합 그리고 시스템 테스팅) ➜ 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애의 원인을 발생시키는 것
인수 테스팅 ➜ 예상된 대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정
소프트웨어의 품질을 평가하기 위한 테스팅 ➜ 특정 시간에 시스템을 출시(Release)하는 것의 리스크를 개발 프로젝트 관련자(Stakeholders)에게 전달하는 것
유지보수 테스팅 ➜ 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인하는 리그레션 테스팅(Regression testing) 과정을 포함
운영 테스팅 ➜ 신뢰성 또는 가용성과 같은 시스템의 특성을 평가

❓ 리그레션 테스팅(회귀테스팅, Regression Testing)
수정으로 인해 변경되지 않은 소프트웨어 영역에 의도하지 않은 새로운 결함이 유입되지 않았는지 또는 기존에 숨어있던 결함이 노출되지 않았는지 확인하기 위해 이전에 테스트한 프로그램을 다시 테스팅하는 것입니다.

📌 테스팅과 디버깅

테스팅

결함을 발견하기 위한 활동입니다.

디버깅

결함의 원인을 밝히고 코드를 수정하는 개발 활동입니다.
이후, 테스터에 의해 확인테스팅(Confirmation testing)을 수행합니다.
- 확인테스팅 : 결함이 제대로 수정되었는지 확인하는 과정, 수정 여부를 확인하기 위해 이전에 실패했던 테스트를 실행

📌 Testing ROI (Return On Investment)

품질비용 (Cost of poor quality)

Quality = Conformance + Non-Conformance
- Conformance costs : 테스팅(결함 발견)과 QA (결함 예방)
- 수동/자동/정적 테스팅 (QA 제외)
- Non-Conformance costs : 결함 수정, 재시험(retesting), 불만족 고객대응, 회사 이미지 손상, 사업 기회 상실 등
- 결함수정 (수치화 하기 어려운 것들 제외)