테스트 전략

Test strategy
테스트 계획과 비교

테스트 전략은 소프트웨어 개발 주기의 테스트 접근법을 설명하는 개요다.테스트 전략의 목적은 조직적이고 수준 높은 목표에서 실제 테스트 활동까지 합리적으로 차감하여 품질보증 관점에서 이러한 목표를 충족시키는 것이다.시험 전략의 작성과 문서화는 모든 목표를 모든 이해관계자가 완전히 다루고 이해하도록 체계적으로 수행되어야 한다.또한 조직과 제품이 시간이 지남에 따라 진화함에 따라 자주 검토되고, 도전하고, 업데이트되어야 한다.또한 시험 전략은 용어, 시험 및 통합 수준, 역할과 책임, 추적성, 자원 계획 등의 측면에서 품질 보증의 다른 이해당사자들을 일치시키는 것을 목표로 해야 한다.

시험 전략은 이해관계자의 제품 위험을 시험 수준에서 어떻게 완화하는지, 어떤 종류의 시험을 수행해야 하는지, 그리고 어떤 진입 및 출구 기준을 적용하는지 설명한다.그것들은 개발 설계 문서에 기초하여 만들어졌다.시스템 설계 문서가 주로 사용되며, 때때로 개념 설계 문서를 참조할 수 있다.설계 문서는 곧 출시될 소프트웨어에서 사용할 수 있는 기능을 설명한다.개발 설계의 모든 단계에 대해, 새로운 기능 세트를 테스트하기 위한 해당 테스트 전략이 생성되어야 한다.

검정 수준

시험 전략은 수행할 시험 수준을 설명한다.주로 단위 시험, 통합 시험, 시스템 시험의 세 가지 레벨이 있다.대부분의 소프트웨어 개발 조직에서 개발자는 단위 테스트를 담당한다.개별 테스터 또는 테스트 팀은 통합 및 시스템 테스트를 책임진다.

역할 및 책임

테스트 리더, 개별 테스터 및 프로젝트 관리자의 역할과 책임은 본 섹션의 프로젝트 수준에서 명확하게 정의되어야 한다.여기에는 이름이 연관되어 있지 않을 수 있지만 역할이 매우 명확하게 정의되어야 한다.

시험 전략은 개발자들에 의해 검토되어야 한다.또한 커버리지가 완전하지만 중복되지 않는지 확인하기 위해 모든 레벨의 테스트에 대해 리드(lead)에 의해 검토해야 한다.시험 관리자와 개발 관리자 모두 시험을 시작하기 전에 시험 전략을 승인해야 한다.

환경 요구사항

환경 요건은 시험 전략의 중요한 부분이다.시험에 사용되는 운영체제를 기술한다.필요한 OS 패치 수준과 필요한 보안 업데이트도 명확하게 알려준다.예를 들어, 특정 테스트 계획에서는 테스트를 위한 전제조건으로 윈도우즈 8.1을 설치해야 할 수 있다.

테스트 도구

테스트 사례의 실행에는 수동과 자동의 두 가지 방법이 사용된다.시험의 성격에 따라 수동시험과 자동시험의 조합이 최선의 시험방법인 경우가 대부분이다.

위험 및 완화

시험 프로세스에 영향을 미칠 위험은 반드시 완화 사항과 함께 열거해야 한다.리스크를 문서화함으로써, 그 발생을 미리 충분히 예상할 수 있다.발생을 방지하거나 피해를 완화하기 위해 선제적인 조치를 취할 수 있다.표본 위험은 하청계약자가 수행하는 코딩 완료의 의존성 또는 시험 도구의 능력이다.

테스트 일정

시험 계획서는 시험 단계를 완료하는 데 걸리는 시간을 추정해야 한다.시험 단계를 완료하기 위한 많은 요건이 있다.첫째, 시험관은 모든 시험 케이스를 한 번 이상 실시해야 한다.게다가 결함이 발견되면 개발자들이 문제를 해결해야 할 것이다.그런 다음 테스터는 고장난 테스트 케이스를 올바르게 작동할 때까지 다시 테스트해야 한다.마지막으로, 검사자는 개발자가 다른 부품을 수리하는 동안 우연히 소프트웨어의 일부를 파손하지 않았는지 확인하기 위해 사이클이 끝날 무렵에 회귀 테스트를 수행해야 한다.이것은 이전에 적절하게 기능했던 시험 사례에서 발생할 수 있다.

또한 시험일정에는 시험에 사용할 수 있는 시험자의 수가 기록되어야 한다.가능하면 각 테스터에 테스트 케이스를 할당하십시오.

시험 단계는 많은 불확실성을 수반하기 때문에 시험 일정을 정확하게 추정하기 어려운 경우가 많다.계획자들은 우발적인 문제를 수용하는 데 필요한 추가 시간을 고려해야 한다.이 근사치를 만드는 한 가지 방법은 소프트웨어의 이전 릴리스에 필요한 시간을 살펴보는 것이다.소프트웨어가 새로운 경우, 초기 시험 일정 근사치에 2를 곱하는 것이 좋은 방법이다.

회귀 테스트 접근법

특정한 문제가 확인되면 프로그램은 디버깅되고 수정은 프로그램에 적용된다.수정 사항이 제대로 작동하는지 확인하기 위해 해당 기준에 대해 프로그램을 다시 테스트할 것이다.회귀 테스트는 한 수정체가 해당 프로그램이나 다른 인터페이스에서 다른 문제를 일으킬 가능성을 감소시킬 것이다.따라서, 관련된 일련의 테스트 사례를 다시 반복하여 특정 수정에 의해 다른 것이 영향을 받는지 여부를 테스트해야 할 수 있다.이것이 어떻게 수행될 것인가에 대해서는 이 절에서 자세히 설명해야 한다.

회귀 검정 사례를 선택할 때는 다른 검정 수준을 고려하십시오.단위, 통합 및 시스템 테스트 사례가 좋은 후보군이다.수정 사항과 직접적인 관련이 있고 기본적인 비즈니스 시나리오가 여전히 작동한다는 것을 증명하는 비즈니스 크리티컬 사례를 거의 포함하지 않는 사례를 선택하십시오.또한 비기능 테스트(보안, 성능, 가용성)는 비즈니스 연속성을 입증하는 데 중요한 역할을 한다는 점을 기억하십시오.

일부 회사에서는 한 단위에 수정 사항이 있을 때마다 해당 단위에 대한 모든 단위 테스트 사례가 반복된다.

테스트 그룹

요구사항 목록에서 기능성이 유사한 관련 영역을 식별할 수 있다.이 영역들은 테스트 그룹이다.예를 들어, 철도 예약 시스템에서, 티켓 예약과 관련된 모든 것은 기능 그룹이고, 보고서 생성과 관련된 것은 기능 그룹이다.같은 방법으로 기능적인 측면에 따라 시험 그룹을 식별해야 한다.

우선순위 테스트

시험사례 중 우선순위를 정해야 한다.소프트웨어 프로젝트를 테스트하는 동안 특정 테스트 케이스가 가장 중요한 것으로 취급되며, 실패하면 제품을 출시할 수 없다.일부 다른 테스트 사례들은 기능상 중요도가 낮거나 심지어 외관상 중요도가 낮을 수 있으며, 만약 그것들이 실패한다면, 우리는 기능을 크게 손상시키지 않고 제품을 출시할 수 있다.이러한 우선순위 수준은 명확하게 명시되어야 한다.이것들은 시험 그룹에도 매핑될 수 있다.

테스트 상태 수집 및 보고

테스트 사례가 실행될 때, 테스트 리더와 프로젝트 관리자는 테스트 활동의 관점에서 프로젝트가 정확히 어디에 있는지 알아야 한다.프로젝트가 어디에 있는지 확인하려면, 개별 테스터의 입력 내용이 테스트 리더에게 전달되어야 한다.여기에는 어떤 테스트 사례를 실행하는지, 실행한 시간, 통과된 테스트 사례의 수, 실패한 사례의 수, 실행 불가능한 경우의 수 등이 포함된다.또한, 그 프로젝트가 얼마나 자주 그 상태를 수집하는지도 분명히 명시되어야 한다.일부 사업은 일별 또는 주별로 현황을 수집하는 관행이 있을 것이다.

시험기록 유지관리

시험사례를 집행할 때는 언제 집행했는지, 누가 했는지, 얼마나 걸렸는지, 어떤 결과가 나왔는지 등 실행내역을 추적하는 것이 중요하다.이 데이터는 모든 팀원과 함께 테스트 리더와 프로젝트 관리자가 중앙 위치에서 이용할 수 있어야 한다.이것은 중앙 서버의 특정 디렉토리에 저장될 수 있으며, 문서에는 위치와 디렉토리에 대해 명확하게 명시되어야 한다.문서와 파일의 명명 규칙도 반드시 언급되어야 한다.

요구사항 추적성 매트릭스

주요 기사:추적성 행렬

이상적으로는 소프트웨어가 일련의 요건을 완전히 충족해야 한다.설계에서 각 요건은 소프트웨어 프로세스의 모든 문서에서 다루어져야 한다.문서에는 HLD, LLD, 소스 코드, 유닛 테스트 케이스, 통합 테스트 케이스 및 시스템 테스트 케이스가 포함된다.요구사항 추적성 매트릭스에서 행에는 요구사항이 있다.열은 각 문서를 나타낸다.교차 셀은 문서가 문서의 요구사항 ID와 관련된 정보와 함께 특정 요구사항을 다룰 때 표시된다.이상적으로, 모든 요건이 모든 문서에서 다루어진다면, 모든 개별 셀은 유효한 섹션 ID 또는 이름을 기입한 후, 우리는 모든 요건이 다루어진다는 것을 안다.셀이 비어 있는 경우 요구사항이 올바르게 설명되지 않았음을 나타낸다.

테스트 요약

고위 경영진은 주간 또는 월간 단위로 시험 요약을 할 수 있다.만약 그 프로젝트가 매우 중요하다면, 그들은 심지어 매일 그것을 필요로 할지도 모른다.이 절에서는 빈도와 함께 고위 경영진을 위해 어떤 종류의 시험 요약 보고서를 작성할지 다루어야 한다.

시험 전략은 시험팀이 전체 기간 동안 전체 프로젝트에 대해 무엇을 할 것인지에 대한 명확한 비전을 제시해야 한다.이 문서는 필요한 경우 고객에게 제시될 수 있다.이 문서를 준비하는 사람은 제품 영역에서 기능적으로 강해야 하며, 매우 좋은 경험을 가지고 있어야 한다. 이것은 시험 활동을 위해 팀 전체를 견인할 문서이기 때문이다.테스트 전략은 프로젝트 시작 시 바로 테스트 팀 구성원에게 명확하게 설명되어야 한다.

참고 항목

참조

  • 암만, 폴과 오프트, 제프소프트웨어 테스트 소개.뉴욕: 케임브리지 대학 출판부, 2008
  • Bach, James (1999). "Test Strategy" (PDF). Retrieved October 31, 2011.
  • 다소, 아리스티드.소프트웨어 엔지니어링의 검증, 검증 및 테스트.허쉬, PA: 아이디어 그룹 펍, 2007