본문 바로가기

[게임QA 이론]

[ISTQB] 2. 테스팅이란 무엇인가.

1.2 테스팅이란 무엇인가? (What is testing)


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


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


테스트 활동은 테스트를 수행하기 전과 후에도 존재하며, 테스팅 계획과 제어 같은 활동이나 테스트 조건(Test condition)의 선택, 테스트 케이스의 디자인, 테스트 수행 결과 점검, 테스트 완료 및 통과 조건의 평가, 테스트 프로세스와 테스트 중인 시스템에 대한 리포트, 마무리 또는 마감(Finalizing or closure)과 같은 일련의 활동들을 포함한다. 또한 테스팅은 문서(소스 코드 포함)의 리뷰와 정적 분석(Static analysis)에 의한 테스팅을 포함한다.
Test activities exist before and after test execution, activities such as planning and control, choosing test conditions, designing test cases and checking results, evaluating completion criteria, reporting o the testing process and system under test, and finalizing or clsure (e.g. after a test phase has been completed). Testing also includes reviewing of documents (including source code) and static analysis.


동적 테스팅(Dynamic testing)과 정적 테스팅(Static testing) 모두 결함 발견이라는 유사한 목적을 달성하기 위한 방법으로 사용될 수 있으며, 테스트 대상 시스템의 품질을 향상시키고, 개발 프로세스와 테스팅 프로세스를 개선하기 위한 정보를 제공한다.
Both dynmic testing and static testing can be used as a means for achieving similar objectives, and vill provide information in order to improve both the system to be tested, and the development and testing processes.


다양한 테스트 목적이 있을 수 있으며 그중 가장 기본적인 것은 아래와 같다.
 - 남아있는 결함 발견 (finding defects)
 - 명세 충족 확인
 - 사용자 및 비즈니스의 요구 충족 확인
 - 결함 예방 (preventing defects)


그 밖의 소프트웨어 테스팅 목적을 보다 상세하게 살펴보면 아래와 같다.
 - 품질 수준에 대한 자신감(Confidence) 확득과 정보 제공
 - 비즈니스 리스크를 감소시키는 정보에 근거한(Well-informed) 조언 제공(발견된 결함 기반의 수치적 데이터 활용)
 - 개발 프로세스 점검, 이슈 제기
 - 논리적 설계의 구현 검증(Validate)
 - 시스템과 소프트웨어가 적절히 동작함을 확인


테스트 디자인 과정에서 테스트 베이시스(Test basis)를 검토하는 것을 통해 개발 초기에 테스트를 디자인 하는 방식의 테스팅 프로세스는 코드에 유입될 수 있는 결함을 방지하는데 도움이 된다. 요구사항 또는 설계기준서와 같은 문서를 리뷰하는 것 역시 코드에 결함이 발생하는 것을 사전에 방지하게 할 수 있다.


각기 다른 테스팅 관점은 서로 다른 테스팅 목적을 가지게 된다.
 - 개발과정에서 테스팅(예를 들어, 컴포넌트, 통합 그리고 시스템 테스팅)의 주요한 목적은 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애의 원인을 발생시키는 것이다.


 - 인수 테스팅에서의 주요한 목적은 예상된 대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정이다.


 - 소프트웨어의 품질을 평가하기 위한 테스팅은 특정 시간에 시스템을 출시(Release)하는 것의 리스크를 개발 프로젝트 관련자(Stakeholders) 에게 전달하는 것이다.


 - 유지보수 테스팅은 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인하는 리그레션 테스팅(Regression testing) 과정을 포함한다.


 - 운영 테스팅 기간의 주요한 목적은 신뢰성 또는 가용성과 같은 시스템의 특성을 평가하는 것일 수 있다.


테스팅은 디버깅과 근본적으로 구분되는 개념이다. 테스팅은 결함에 의해 발생된 장애를 드러내는 활동이다. 반면, 디버깅은 결함의 원인을 밝히는 개발 활동으로, 코드를 수정하고 올바르게 수정되었는지 확인한다. 이후에 테스터에 의해 확인 테스팅(Confirmation testing)이 발생하며, 이 과정에서 장애가 정말로 수정되었는지 확인한다.
Debugging and testing are different. Testing can show failures that are caused by defects. Debugging is the development activity that identifies the cause of a defect, repairs the code and checks that the defect has been fixed correctly. Subsequent confirmation testing by a tester ensures that the fix does indeel resolve the failure. The responsibility for each activity is very defferent, i.e. testers test and developers debug.




테스팅의 목적
소프트웨어를 개발하는데 있어 실수와 오류를 범할 가능성은 매우 높다. 테스팅은 개발자, 사용자 모두 자신의 불완전함과 실수를 가정하는데서 출발한다. 테스트는 인간의 불완전성을 극복하고 높은 품질의 제품을 만들기 위한 노력이다. 모든 가능한 데이터를 사용하여 모든 경우의 수에 대하여 철저히 시험하는것은 일반적으로 가능하지 않다. 결국 선택된 데이터를 기초로 시험이 이루어지며 높은 확률로 버그를 찾아낼 수 있도록 좋은 테스트 케이스(test case)를 만들어야 한다.

소프트웨어 시험의 목적은 "소프트웨어의 품질을 향상시키기 위하여 결함(defect)을 발견하는 것"이다.


주요 이유
 - 잔존 결함 발견
 - 명세 충족 확인
 - 사용자 및 비지니스의 요구 충족 확인
 - 비지니스 리스크를 감소시키는 Well-informed 조언 제공 (발견된 결함 기반의 수치적 데이터 제공)


기타 이유
 - 개발 시스템/SW에 대한 자신감 부여
 - 개발 프로세스 점검, 이슈제기
 - 논리적 설계의 구현 검증 (Validate)
 - 시스템/SW가 적절히 동작함을 확인


주의사항
 1. 완벽한 테스트는 불가능하다.
 2. 테스트는 오류가 없음을 보여주려는 것이 아니다.
 3. 주어진 시간과 인력 및 리소스로 오류를 발견할 확률이 높은 테스트 케이스를 찾아내고 실행해야 한다.
 4. 한계를 인정해야 한다.
    (모든 입력값을 테스트 할 수 없음, 모든 경로(Path)를 테스트할 수 없음, 모든 타이밍을 테스트할 수 없음)


Testing ROI (Return On Investment)
품질비용  (Cost of poor quality)
 - Quality = Conformance + Non-Conformance


 - Conformance costs : 테스팅(결함 발견)과 QA (결함 예방)
 - 수동/자동/정적 테스팅 (QA 제외)


 - Non-Conformance costs : 결함 수정, 재시험(retesting), 불만족 고객대응, 회사 이미지 손상, 사업 기회 상실 등
  - 결함수정 (수치화 하기 어려운 것들 제외)