페이퍼요약 – 테스팅 지뢰밭 통과하기 by O’Neill

페이퍼요약 – 테스팅 지뢰밭 통과하기 by O’Neill

제목: 테스팅 지뢰밭 통과하기(Clearing the Testing Minefield)

저자: Donna O’Neill, 호주

문서유형: 컨퍼런스 페이퍼(총 4페이지), 2001년

 

테스터가 프로젝트에서 자신의 업무를 수행하는데 있어 종종 직면하게 되는 장애에 효과적으로 대응할 수 있는 몇몇 전략을 제시한 자료

à 프로젝트의 테스트를 하는데 있어 마주칠 수 있는 잠재 리스크(이 문서에서는 ‘지뢰’라는 용어를 사용)에 대해 테스트 계획을 수립하고 관리하는 사람이 많이 알면 알수록 더 좋은 계획을 세울 수 있으며, 해당 리스크가 실제 발생했을 때 효과적으로 대처할 수 있음(즉, 테스팅 활동에 전념해야 할 시간을 다른 문제 때문에 낭비하는걸 막을 수 있음). 이 문서에 담긴 정보가 테스트 계획 수립 시 유용함

---

테스팅 지뢰밭이란(What is the testing minefield)?

종종 소프트웨어 테스터가 대부분의 작업 시간을 개발 주기 말의 중요 단계에서(개발된 소프트웨어 출시로부터 최종 고객 인도로 이어지는 단계) 보내게 되는데, 이 때가 프로젝트가 가장 많은 일정 압박을 받는 시기임. 제대로 관리가 안 되는 경우 이 단계가 마치 사방에 위험이 숨어있는 지뢰밭과 같지만, 적절한 관리가 이루어진다면 이 지뢰밭을 안전하게 건널 수 있다.

테스팅 지뢰밭에 어떤 위험들이 있는가?

테스팅 지뢰밭에는 테스터의 일을 어렵게 만드는 여러 장애물이 산재되어 있음. 우선 적합한 테스팅을 수행하기에 충분한 시간을 프로젝트 계획자가 할당해 주는 경우가 드물며, 이런 상황이 불가피하게 개발 지연이 발생할 때 더 악화된다(즉, 테스팅을 위해 할당된 고정된 시간량이 축나게 됨). 급조된 부적절한 테스트 커버리지, 낮은 품질의 소프트웨어 출시, 테스터 피로(에너지 소진)에 기여하는 요인으로 아래와 같은 것들이 있음 

• 빅뱅 테스팅·방법(The big bang approach to testing)
• 설화에 기반한 요구사항 정의(The folklore syndrome of requirements definition)
• 불확실한 비기능 요구사항(Fuzzy non-functional requirements)
• 컴포넌트 품질에 대한 당연한 가정(Assumed quality of components)
• 개발자로부터 예기치 못한 소프트웨어 수령(The software surprise from developers)
• 갑작스런 테스트 환경 셋업(The test environment set-up rush)
• ·불안정 소프트웨어로 인한 흔들리는 토대(The shaky foundation of unstable software)
• 쉬운 일을 먼저 하고 까다로운 일은 뒤로 미룸(The path of least resistance)

테스팅 지뢰밭을 어떻게 무사히 통과할 수 있는가?

효율적이고 효과적인 테스팅의 열쇠는 리스크 기반 테스팅 전략을 사용하는 것이다. 즉, 잠재적인 문제를 사전에 최대한 많이 식별하고, 할당된 시간에 무엇을 달성할 수 있고 무엇은 불가능한지에 대해 테스터가 스스로와 관리자에게 정직히 공개하며, 이것에 맞게 테스트 전략을 계획한다.

전형적인 테스팅 해저드를 이해함으로써 우리가 지뢰밭에 다다르기 전에 이것(지뢰)들을 예견하고 관리할 수 있다(이것들의 발생이 불가피하다면 적어도 그 영향을 줄일 수 있다).

 

테스팅에 빅뱅 접근방법을 피한다

• 현실에서는 모든 테스팅이 프로젝트 끝의 제품 출시 직전이 될 때까지 미뤄진 경우를 종종 볼 수 있음. 늦어진 테스팅은 테스터의 초과 근무(과로)를 요구하고, 막판에 주요 결함이 발견되는 경우 일정 혼란이 생기며, 품질 낮은 소프트웨어가 출시될 수도 있다.
• 마지막 순간의 일정 혼란을 피하는 열쇠는 점증적 엔드-투-엔드 테스팅 방법을 사용해 최대한 많은 작업을 지뢰밭 단계 전에 수행하는 것:
  - 테스터를 프로젝트 초기에 관여시키고(요구사항 검토 프로세스 동안), 이후 즉시 테스트 계획을 시작한다.
  - 짧은 빌드를 가진 점진적 개발 전략을 사용한다. 동작하는 기능 쓰레드를 초반에 그리고 자주 테스터에게 릴리즈한다.
  - 개발 작업을 집중시키는데 테스터 피드백을 사용한다. 테스터가 수집할 효과적인 메트릭으로 기능 영역 당(또는 테스트 당) 발견된 결함의 수/성격/심각도, 제기된 결함 누적 수 vs 종료된 결함 누적 수, 재테스팅에서 퇴짜 맞은 수정된 결함 수 등이 있다.

요구사항 정의의 설화 증후군을 관리한다

• 개발 노력이 형편없이 정의된(또는 불완전한) 요구사항에 기반할 때 프로젝트가 조직 내 존재하는 설화와 도메인 지식에 크게 의존하게 됨. 이 지식의 소유자는 종종 그것을 문서화하기를 꺼리며, 테스터는 이 정보를 스스로 알아내려 노력함(이게 계획에 없는 일이다 보니 예산이나 이 일을 제대로 하는데 필요한 기술 없이 작업을 하게 됨)
• 명확한 요구사항 없이는 테스트가 비효율적이고 잘못된 방향으로 가는 경향이 있으며, 또한 시스템이 하도록 의도된 일을 검증하는 대신 단순히 시스템이 하는 일을 보여주는데 그치는 경향이 있음. 개발팀과 고객이 제품 구현 및 테스트 결과에 대한 상이한 관점을 가지고 논쟁하느라 시간이 낭비됨
• 이런 설화 증후군의 영향을 최소화하기 위해 요구사항이 잘 이해되고 합의되었는지 그리고 테스터가 지뢰밭 단계에 들어가기에 앞서 모든 테스트 목표가 명확히 정의되었는지 확실히 해야 함
• 요구사항에 대한 테스터의 접근 방법을 개선하기 위해서 1) 개발팀이 체계적인 요구사항 수집 활동을 맡도록 독려하고 2) 명세가 모든 이해관계자(고객, 개발자, 테스터)에 의해 완전성, 명확성, 테스트용이성 등의 측면에서 검토되었는지 확실히 한다·
• 명확한 테스트 목표를 정의하기 위해서 1) 각 테스팅 레벨을 위한 “테스트 근거(test basis)”를 식별하여 모든 테스트가 명확하게 정의된 목표(예, 유스케이스, 비즈니스 규칙, 기능 요구사항)를 가지도록 하며 2) 요구사항 추적 기법을 사용하여 테스팅의 초점을 맞추고 모든 테스트가 체계적으로 그 목표를 달성할 수 있도록 보장한다.

흐릿한 비기능 요구사항을 옭아맨다

• 품질 속성(신뢰성, 가용성, 사용편이성 등)과 성능 목표 같은 비기능 요구사항들이 명세하기에 매우 어려울 수 있는데, 이는 이것들을 테스트하고 객관적으로 검증하기가 어렵다는 의미이기도 함. 하지만 대개 이 특성들이 고객에게는 매우 중요함
• 대부분의 프로젝트에서 사실상 고객 연락 담당자 역할을 하는 테스터가 이 상황이 야기할 수도 있는 충돌(프로젝트 팀과 고객 간 비기능 요구사항에 대한 상이한 의견)을 정면으로 맞서야 하는 사람이다. 이런 다툼이 종종 프로젝트 생명 주기 막판에(즉, 테스팅 지뢰밭 단계에서) 발생하며, 이게 제품 출시(또는 승인)으로의 값비싼 지연을 야기할 수 있다.
• 명백한 답은 명세서 작성자가 정량적이고 테스트 가능한 용어로 이 속성들을 묘사하도록 장려하는 것이다. 그들이 이에 협조하지 않으면(또는 할 수 없으면) 테스터가 이 요구사항들의 승인 기준에 대한 합의를 얻기 위해 고객에게 직접 호소할 수 있다. 또한 기술 지원 인력도 이 정보의 좋은 소스가 될 수 있다.

컴포넌트 품질을 가정하지 않는다

• 기존 시스템의 업그레이드 또는 구매된/재사용된 컴포넌트를 사용해 개발된 시스템을 위한 테스팅 전략은 컴포넌트의 품질 이력을 고려할 필요가 있음(일단 시스템으로 통합되면 프로젝트가 이 외부 컴포넌트들이 가진 문제를 떠안게 되므로)
• 유감스럽게도 재사용된/구매된 컴포넌트의 진짜 상태를 확실히 알기가 매우 어렵지만 문제의 영향은 줄일 수 있다:
  - 지뢰밭 단계에 들어가기 앞서 컴포넌트 품질을 평가함(사전 테스트 결과의 분석, 컴포넌트 매입 프로세스 동안 수집된 평가 데이터의 분석, 소프트웨어 인스펙션, 직접 테스팅, 타 사용자로부터 피드백 등을 통해서)
  - 시스템 테스팅 동안 특정한 리스크 영역을 겨냥함(예, 인터페이스, 통합된 시스템 동작)

개발자가 완성 소프트웨어를 예고 없이 테스터에게 넘기지 않는다

• 테스트 그룹이 조직의 다른 부분에 의존하는 것이 테스팅 혼란에 크게 기여하는 요인 중 하나임. 테스트 개발 일정을 계획할 수 있으려면 테스터가 소프트웨어를 수령하기에 앞서 기능이 개발되는 순서를 알아야 할 필요가 있다. 이런 사전 통고를 받는데 실패하면 테스터가 급히 테스트를 준비하는 동안(테스트 장비를 모으고 적절한 기술을 가진 테스터가 가용하기를 기다림) 테스트 실행이 지연될 수 밖에 없게 됨
• 테스터가 소프트웨어 전달의 시기와 내용에 대한 사전 통보를 받는걸 보장하는 열쇠가 개발자와의 의사소통이다. 테스트를 실행하고 피드백을 제공하는데 쓸 수 있는 시간을 최대화하기 위해서 지뢰밭 단계에 도달하기 전에 자신의 테스트를 설계하는 것이 테스터에게 훨씬 효과적임
• 테스터에게 넘겨진 소프트웨어는 테스팅을 즉시 시작할 수 있도록 테스트 가능한(수직의) 기능 슬라이스를 포함해야 한다. 만약 테스터가 시스템이 완전히 통합되기 전까지는 테스트 될 수 없는 다양한 기능 조각들만 받는다면 빅뱅 테스트 방법을 써야만 하거나 또는 일회용 테스트 하니스(throw-away test harnesses)를 구축하는데 시간 낭비를 할 수 밖에 없게 됨

셋업을 갑작스레 서두르는걸 피한다

• 요구되는 하드웨어, 지원 소프트웨어, 도구, 테스트 데이터를 갖춘 테스트 환경을 수립하는 것은 테스터가 가장 시간을 많이 소비하는 일 중 하나임. 많은 프로젝트에서 테스터가 테스팅을 위한 소프트웨어를 받고 나서야 비로소 이 작업을 시작하는데, 이는 소중한 테스팅 시간이 이 셋업 작업에 의해 침식된다는 의미다.
• 테스팅 시간을 최대화하기 위해 (늦어도) 계획상의 테스트 실행이 시작될 쯤에는 테스트 환경이 수립되어야 함. 이게 테스터가 최대한 빠르게 개발자에게 피드백을 제공하는걸 가능케 한다. 

불안정한 토대 위에 구축하지 않는다

• 개발자가 적절한 단위 테스팅을 수행하지 않았을 때 테스터에게 넘겨지는 시스템이 거의 항상 불안정함. 즉, 시스템이 예상치 않게 크래시되거나 기타 일정치 않은 동작을 보이는 경향이 있는데, 이게 흔히 나쁜 예외 처리나 낮은 수준의 로직 에러 때문이다.
• 일정치 않은 동작은 효과적인 기능 및 시스템 테스팅을 수행하기 매우 어렵게 만들고, 따라서 제품 요구사항이 덜 철저하게 테스트되는 결과를 낳음. 더구나 테스트의 초점이 달라서 다수의 설계 및 코드 수준의 결함이 기능 테스팅에 적용된 추가적 노력에도 불구하고 발견되지 않고 현장으로 나간다.
• 개발자가 테스팅 생명 주기에서 단위 테스팅이 맡는 중요하고 고유한 역할을 반드시 이해해야 하며, 테스터에게 넘기기 전에 체크리스트 등을 활용하여 단위 테스트를 수행해야 함(이상적으로 설계 검토와 코드 검토가 선행된 후에). 이게 독립적인 요구사항 테스팅을 위한 견고한 토대를 보장함

쉬운 경로에 만족하지 않는다

• 빠른 진척 상황을 보이기 위해 개발자가 쉬운 기능 먼저 구현하는 경향이 있고, 테스터도 동일한 이유로 같은 경향을 보임. 이게 더 어려운 요구사항을 뒤로(이것들을 효과적으로 처리하기에 더 적은 시간이 가용한 시기) 남겨지게 함
• 어려운 요구사항들은 더 복잡하고 시스템의 오퍼레이션에도 중요한 것들임. 이런 요구사항들은 구현하는데 더 오래 걸리고 결함도 더 많은 경향이 있으며, 또한 테스트하기도 더 어렵고 시간이 많이 든다.
• 프로젝트 관리자와 테스트 관리자는 높은 우선순위/리스크 이슈들을 관리하는데 자신에게 더 많은 시간을 줄 필요가 있으며, 개발 생명 주기의 최대한 이른 시점에 아래를 수행한다:
  - 기술 및 인터페이스 복잡도, 미션/안전 중요성, 사용 범위에 따라 요구사항의 우선순위를 준다.
  - 높은 우선순위 요구사항을 최대한 초기에 구현하고 테스트 하도록 개발 일정과 테스팅 일정을 계획한다.
  - 이 요구사항들의 테스트를(그리고 상응하는 설계 및 코드 영역을) 더 철저하게 검토하도록 계획한다.
  - 더 높은 우선순위 요구사항에 더 경험 많은 인력을 할당한다.