문서요약 - 소프트웨어 테스팅과 관련된 리스크 by MSQAA

제목: 소프트웨어 테스팅과 관련된 리스크(Risks Associated with Software Testing)

저자: Monterrey Software Quality Assurance Association(MSQAA)

문서유형: 웹문서 http://msqaa.org/

 

프로젝트에서 흔히 접할 수 있는 테스팅 관련 리스크를 나열한 자료

---

리스크 분석과 테스팅

• 테스팅은 본질적으로 리스크 기반 활동. 대부분의 애플리케이션에서 완전 테스팅(exhaustive testing)이 비현실적. 프로젝트팀은 리스크를 최소화하기 위해 시스템의 대표적 샘플을 커버하도록 테스팅 기법들을 균형 있게 활용하는 테스트 전략을 설계
• 테스트 관리자는 애플리케이션과 관련된 리스크에 기반해 적절한 테스팅 양을 결정. 즉, 수행되어야 할 테스팅 양이 연루된 리스크의 양과 직접적으로 관련 있음
• 테스팅의 리스크 기반 본질을 이해 하는 것이 부적합한 테스트 리소스라는 만성적 문제를 다루는 열쇠이다. 리스크가 가용한 테스팅 시간을 할당하는 기초로, 그리고 무엇을 테스트하고 어떻게 리소스를 할당할지 선택을 돕는 기초로 사용됨. 테스트 계획서를 개발하는데 있어 리스크 분석에서 식별된 리스크들을 고려함

주요 테스팅 리스크

테스트 관리자는 테스팅에 영향을 미칠 수도 있는 잠재적 리스크를 식별할 책임이 있으며, 주요 테스팅 리스크로 아래와 같은 것들이 있다.

 

• 충분하지 않은 훈련/테스트 능력 부족: IT 인력 대다수가 테스팅에 대해 제대로 훈련을 받지 못했고 상근 독립 테스팅 인력의 절반 정도만 테스팅 기법에 대해 훈련되어 있다면 테스팅 기법에 대한 많은 오해와 요용이 있을 수 있음
• “우리” 대 “그들”이라는 사고 방식: 개발자와 테스터가 테스팅 이슈의 반대 편에 있을 때 흔히 발생하는 문제. 양측 모두 상대방이 고의로 내게 문제를 안겨준다고 느낌. 정치적 내분이 에너지를 소모하면서 프로젝트가 곁길로 새게 되고 부정적 영향의 관계 외에는 별로 달성하는 것이 없게 됨
• 테스트 도구 결여: IT 관리자가 테스트 도구가 사치라는 태도를 가질 수 있음. 하지만 수동 테스팅이 버거운 작업이 될 수도 있다. 도구만 있다고 모든게 다 되는건 아니지만 도구 없이 효과적으로 테스트를 하려는건 숟가락으로 참호를 파려는 것과 비슷
• 테스팅에 대한 경영진의 이해 및 지원 결여: 테스팅을 위한 지원이 반드시 최고경영진으로부터 나와야 함. 그렇지 않으면 직원들이 이 일을 심각하게 받아들이지 않으며 테스터의 사기도 꺽임. 경영진의 지원이 재정적인 제공에만 그치지 않고 결함이 있어도 정해진 시간에 소프트웨어를 인도할지 아니면 시간을 연장해서라도 일을 제대로 할지에 대한 어려운 의사 결정을 내려야 함
• 고객 및 사용자 참여의 결여: 사용자와 고객이 테스팅 프로세스에서 의도적으로 배제되거나 또는 이들 스스로 관여를 원치 않을 수도 있음. 사용자와 고객은 테스팅에서 가장 핵심적 역할 중 하나를 한다(즉, 소프트웨어가 비즈니스 측면에서 돌아가는지 보장).
• 테스팅을 위한 일정/예산이 충분하지 않음: 이게 흔히 있는 불만이며, 어려운 점은 주어진 시간에 올바른걸 테스트하도록 계획에 우선순위를 정하는 것이다.
• 독립 테스터에게 지나치게 의존: 개발자가 독립 테스터가 자신의 일을 체크할 것을 알고 있어서 코딩에만 집중하고 테스팅은 전적으로 테스터에게 맡겨 버림. 유감스럽게도 이는 더 높은 결함 수준과 더 긴 테스팅 시간을 낳게 됨
• 급속한 변경: RAD(Rapid Application Development) 같은 일부 기술에서 소프트웨어가 테스터가 그걸 테스트 할 수 있는 것보다 더 빠르게 생성되고 수정됨. 이게 자동화와 버전 및 릴리즈 관리의 필요성을 강조함
• 항상 얻을게 없는 상황에 놓인 테스터: 테스터가 너무 많은 결함을 보고하면 프로젝트 지연에 대한 비난을 받고, 거꾸로 테스터가 중요 결함을 발견하지 않으면 낮은 품질에 대한 비난을 받음
• “아니요”라고 말해야만 하는 입장: “아니요, 소프트웨어가 생산에 나갈 준비 안되었어요”라고 말해야만 하는 것이 테스터에게 가장 어려운 딜레마. 프로젝트의 어느 누구도 이 소리를 듣는걸 좋아하지 않으며, 종종 테스터가 일정/비용 압박에 굴복하게 됨
• 테스트 환경: 작업 환경이 효과적이고 효율적인 테스팅에 도움이 되지 않음
• 신기술: 클라이언트/서버, 인트라넷, 인터넷 애플리케이션의 등장으로 테스트 프로세스에 더 많은 리스크가 도입됨. 이 멀티 티어 시스템들이 전통적인 메인프레임 시스템보다 더 복잡하고, 따라서 테스팅 및 구현과 관련된 더 놓은 수준의 리스크를 가짐. 이런 신규 리스크 요인의 예로 보안, 성능, 가용성, 복잡한 컴포넌트 통합, 해당 기술을 처음 접한 팀 등이 있다.
• 새로운 개발 프로세스: 새로운 플랫폼들과 함께 새로운 소프트웨어 개발 방법론이 등장함. 프로젝트팀이 전통적인 폭포수 방법으로부터 더 반복적인 개발 및 인도 방법으로 옮겨감. 이 반복적 방법에서는 테스팅 활동이 이전 보다 더 개발 사이클을 가로질러 통합되어 있음. 전통적 시스템 테스팅이 개발 마지막에서만 수행되는게 아니라 주요 컴포넌트를 위한 프로젝트 내내 여러 차례 수행될 수 있음