개발자도 알아야할 소프트웨어 테스팅 실무 요약1

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

 

1.1 소프트웨어 테스팅이 왜 필요한가?

오류 error, 결함 defect, 결점 fault, 장애 failure 와 같은 용어들의 차이점을 구분하고 이해하고 실수 mistake와 버그 bug와 관련 지어설명할 수 있다. 

 

- 시스템의 문제를 최소화하기 위해 반드시 필요하다.

- 개발자는 코드를 쓰거나 문서를 작성할 때 결함(defects and bugs)를 만드는 오류 error를 범할 수 있다.

- 코드에 존재하는 결함은 장애 failure의 원인이 된다.

- 환경적인 조건에서도 발생한다. ex. 방사, 자기, 전자기장, 물리적 오염 또한 sw 결함을 유발시킬 수 있다.

 

1.1.3 sw 개발 유지보수 운영 시 테스터의 역할

- 결함들을 체계적인 테스팅을 통해 릴리즈 전에 발견하고 수정한다면 운영 환경 내에서 발생하는 결함들의 리스크(위험)들을 줄이는 데 기여할 수 있고, sw 품질 향상에 도움이 된다.

- sw 테스팅은 계약상(법적) 요구조건들 또는 산업에 특화된 표준들을 만족시키기 위해서도 필요하다.

 

1.1.4 테스팅과 품질

개발 표준, 교육 훈련 그리고 결함 분석 등과 함께 테스팅이 품질 보증의 활동의 하나로 통합되어야 sw 시스템의 품질 향상을 확보할 수 있다.

 

1.1.5 테스팅 얼마나 해야 충분한가?

적당한 테스팅의 정도를 파악하기 위해서는 리스크 수준을 고려해야 하며, 기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간, 비용과 같은 프로젝트의 제약사항을 고려해야 한다.

 

1.2 테스팅이란?

사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견하고 최종적으로는 결함 데이터를 근간으로 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달하는 것이다. 

 

테스트 활동은 테스트 수행 전과 후에도 존재, 동적&정적 테스팅 모두 결함 발견이라는 유사한 목적 달성을 위한 방법으로 사용된다.

 

가장 일반적인 목적은 1. 남아있는 결함 발견 2. 명세 충족 확인 3. 사용자 및 비즈니스의 요구 충족 확인 4. 결함 예방

이 있다. 

 

테스팅은 관점에 따라서 달라진다. 개발 관점에서 테스팅의 주요 목적은 sw의 결함을 찾아내고 수정하기 위해서 많은 장애 failure 상황을 만들어 내는 것이다. 인수 테스팅에서 주요 목적은 예상한대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정이다. 

 

유지보수 테스팅은 개발 과정에서 변경 작업이 일어나는 경우 새로운 결함이 유입되었는지 확인하는 리그레션 테스팅 과정을 포함한다. 운영 테스팅 기간의 주요 목적은 신뢰성 또는 가용성과 같은 시스템의 특성을 평가하는 것이다. 

 

테스팅 vs 디버깅

테스팅은 결함을 발견하기 위한 활동, 디버깅은 결함의 원인을 밝히고 코드를 수정하는 개발 활동이다. 이후 테스터에 의해 확인 테스팅이 수행 되어야 하며, 이 과정에서 결함이 제대로 수정되었는지 확인할 수 있다. 

 

1.3 테스팅의 일반적인 원리

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

원리2 - 완벽한 테스팅(exhaustive testing)은 불가능하다. (무한 경로, 무한 입력값, 무한 타이밍: GUI 이벤트 발생 순서에 대한 조합도 무수히 많음)

 

우주항공, 의료 등 안전이 최우선(Safety critical) sw를 개발하고 테스팅할 때는 더 많은 노력, 리소슬르 투입하여 강도 높게 수행하는 것이지 완벽한 테스트가 수행되는 것은 아니다.

 

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

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

 

=> 테스트 전문가를 개발 초기에 투입하여 절차에 따라 체계적으로 테스팅을 수행할 경우, 동일하거나 더 높은 수준의 품질을 확보하면서 개발 프로젝트 기간을 전체적으로 단축시킬 수 있는 효과를 기대할 수 있다.

 

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

자체적으로 복잡한 구조를 가지고 있는 모듈, sw나 시스템의 다른 부분 또는 다른 모듈과 다량의 복잡한 상호 작용을 하는 모듈(복잡한 인터페이스), 개발 난이도가 높거나 최신 기술을 사용한 모듈, 기존에 개발된 것을 사용하지 않고 새롭게 개발한 모듈, 크기가 큰 모듈에서 일반적으로 결함이 집중된다.

 

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

동일한 tc로 동일한 테스트를 반복적으로 수행한다면 나중에는 더 이상 새로운 결함을 찾아내지 못한다.

탐색적 테스팅(exploratory testing), JIT 테스팅(just in time testing) 등의 경험 기반 접근법을 통해 새로운 tc를 추가하는 것이 필요하다.

 

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

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

테스트 주요활동에 대한 테스트 프로젝트 계획, 표준적인 기법 적용, 독립적 테스트 환경(environment), 효율적/효과적 테스트 팀 조직, 정식 리포팅 등

 

원리7 - 오류 부재의 궤변(absence of eorrors fallacy)

개발된 시스템이 사용자의 필요와 기대에 부응하지 못하고 사용성이 현저히 낮다면 결함을 찾고 수정하는 과정은 아무 소용 없다.

 

1.4 테스트 프로세스의 기초

기본적인 테스트 프로세스 주요 활동 구성

- 계획과 제어(planning and control)

 

- 분석과 설계

테스트 베이시스 검토, 테스트 상황, 요구사항, 데이터 식별, 테스트 기법 할당, 테스트 용이성(testability)평가, 테스트 환경 구축

- 구현과 실행(implementation and execution)

테스트 케이스 명세화, 우선순위 선정, 데이터 생성, 프로시저 작성, 선행 테스팅, 테스팅 실행, 기대 결과와 비교

 

- 완료 조건의 평가와 리포팅(evaluating exit criteria and reporting)

완료 조건의 달성 여부 확인, 최종 테스트 보고서 작성

 

- 테스트 마감 활동(test closure activities)

산출물 확인, 테스트웨어 보관, 테스트 프로세스 평가(심사)

 

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

- 테스트 계획 수립 관련 주요 작업

테스트 범위(scope)와 테스트를 위한 리스크에 대한 결정, 그리고 테스팅의 목적에 대한 식별

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

 

- 테스트 제어의 주요한 작업

테스트 진척 상황, 테스트 커버리지와 완료 조건의 모니터링과 문서화, 테스트 계획과의 차이를 교정하는 활동

 

1.4.2 분석과 설계

 

1.4.3 테스트 구현과 실행

가장 효율적이고 효과적으로 테스트 실행하기 위하여 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저 또는 테스트 스크립트를 명세화하는 활동이다. 

효율적인 테스트 실행을 위해 테스트 수트 생성(test case 묶음)

불일치를 인시던트(incident)  또는 결함(defects)로 보고

 

수정으로 인해 새로운 버그가 추가 발생하지 않았는지 또는 변경되지 않은 부분에 수정사항과 연관된 버그가 발생하지 않는지 확인하는 테스트 실행(regression testing)

 

결함 심각도(severity level)별로 분류하여 관리해야 한다.

업계 모범 사례(best practice)는 치명적(show stopper), 매우 심각(fatal), 심각(no workaround), 보통(workaround), 경미(cosmetic)

 

치명적 결함 critical defects,

hw sw 장애, 시스템 잠김(접근 불가), 중지, 데이터 손실 또는 변조

주요 결함 major defects

기능 상실, 잘못된 기능, 주요 기능 오작동

일반 결함 average defects

불완전한 기능, 사소한 기능 오작동

사소한 결함 minor defects

타이핑 에러, 사용자 불편, 스크린 표준의 위반, 좋지 않은 인터페이스

개선사항 enhancement 

에러는 아니지만 개선이 필요한 사항

 

결함 우선순위를 표현하는 사례

즉시 해결 resolve immediately, 주의 요망 give high attention, 대기 normal queue, 낮은 순위 low priority

 

1.4.4 테스트 완료 조건과 리포팅

리포팅은 결함 및 테스트 진행 관련 데이터를 가공하여 메트릭(metrics)로 수치화하고 관련 정보를 표현하는 작업이다.

 

1.4.5 테스트 마감 활동

인시던트 리포트(결함 리포트 포함) 종료, 해결되지 않은 추가 및 변경 요구 사항에 대한 처리

테스트웨어를 유지보수 조직에 이관

테스트 프로세스 심사 및 개선사항 제안

 

1.5 테스팅의 심리학

사람을 인스펙션 하지 말고 소프트웨어 제품을 인스펙션하라 는 것은 테스터를 포함한 검토자와 개발자(분석가, 설계자) 간에 발생 가능한 감정 악화를 피해야 함을 강조한 것이다.

 

1.6 소프트웨어 테스팅을 제약하는 요소

테스트를 더 적극적으로 활용하여 개발 결과물의 완성도(stability)와 품질을 높이고 실제적으로 개발 기간을 단축하는 시도가 필요하다.

 

1.7 테스팅 분야의 매력

1.8 테스트 전문가

테스팅을 효과적이고 효율적(effective and efficient) 으로 수행해야 한다.