원칙: 테스트
이 원칙은 제품 품질을 평가하는 방법에 대한 안내를 제공합니다.
관계
기본 설명

테스트 원칙은 여러 측면에서 다른 원칙에 대한 서비스 제공자 기능을 수행합니다. 테스트 내용은 주로 제품 품질에 대한 평가에 중점을 두며 다음과 같은 핵심 사례를 통해 실현됩니다.

  • 소프트웨어 품질의 결함을 찾아 문서화합니다.
  • 인지된 소프트웨어 품질에 대해 조언합니다.
  • 구체적인 시연을 통해 디자인 및 요구사항 스펙과 관련된 가정사항의 유효성을 검증하고 해당 사항을 입증합니다.
  • 소프트웨어 중간 산출물이 디자인된 대로 작동하는지 확인합니다.
  • 요구사항이 올바르게 구현되는지 확인합니다.

RUP의 다른 원칙과 테스트 간에는 주목할 만한 차이점이 있습니다. 즉, 테스트 수행 시 소프트웨어 제품의 약점을 찾아 공개하게 됩니다. 따라서 요구사항, 분석 및 디자인과 구현 원칙에서 사용되는 원리와 다른 일반 원리를 사용해야 테스트를 가장 효과적으로 수행할 수 있습니다. 또한 세 원칙은 완전성에 초점을 맞추는 반면 테스트는 불완전성에 초점을 맞춘다는 점에서도 다소 미묘한 차이가 있습니다.

올바른 테스트 노력은 다음과 같은 질문을 통해 구현됩니다.

  • 이 소프트웨어는 어떤 경우에 중단됩니까?
  • 이 소프트웨어가 예상대로 작동하지 않을 수 있는 상황은 무엇입니까?

테스트는 다른 원칙의 작업에 내재되어 있는 가정, 위험성 및 불확실성과 관련하여 구체적인 시연 및 공정한 평가를 통해 이런 관심사항을 다룹니다. 이 때 다음과 같은 두 가지 극단적인 방법은 피해야 합니다.

  • 소프트웨어를 효과적이고 적절히 테스트하지 못하고 고유한 문제점 또는 약점을 노출시키는 접근 방식
  • 불필요하게 부정적이거나 파괴적인 접근 방식. 부정적인 접근 방식을 사용하는 경우 원하는 품질의 소프트웨어 제품을 얻을 수 없으며 테스트 노력과 다른 원칙이 분리될 수 있습니다.

여러 설문조사 및 기사에서 제공하는 정보에 따르면 소프트웨어 테스트 비용이 전체 소프트웨어 개발 비용의 30 - 50%에 이르는 것으로 알려져 있습니다. 따라서 대부분의 사용자가 소프트웨어가 충분한 테스트를 거치지 않은 상태에서 전달된다고 믿고 있는 점은 놀라운 일입니다. 이러한 모순은 다음과 같은 몇 가지 핵심 문제에서 기인합니다.

  • 소프트웨어 테스트는 매우 어려운 작업입니다. 주어진 프로그램마다 서로 다르게 동작하는 방식을 정량화할 수 없기 때문입니다.
  • 일반적으로 테스트는 정해진 방법론 없이 수행되므로 프로젝트에 따라 또한 조직에 따라 해당 결과가 다릅니다. 주된 성공 요인은 개인의 능력과 스킬입니다.
  • 생산성 도구를 충분히 사용하지 않아 까다로운 테스트 측면을 관리할 수 없습니다. 자동화된 테스트 실행의 부족 이외에도 많은 테스트 노력이 광범위한 테스트 데이터 및 테스트 결과를 효과적으로 관리할 수 있는 도구 없이 수행됩니다. 소프트웨어의 복잡도와 다양한 사용 방법으로 인해 완전한 테스트를 수행하는 것은 불가능한 목표입니다. 널리 사용되는 방법론과 최신 도구를 사용함으로써 소프트웨어 테스트의 생산성과 효과를 모두 향상시킬 수 있습니다.

높은 품질의 소프트웨어는 항공 교통 관제, 미사일 유도 장치 또는 의료 서비스 제공 시스템과 같이 사람의 생명과 직결된 안전 중심 시스템의 성공에 있어 핵심 요소입니다. 일반적인 MIS 시스템의 경우 심각도의 영향이 즉시 명확하게 나타나지 않을 수도 있지만 결함으로 인해 해당 소프트웨어를 사용하는 비즈니스가 수익상의 상당한 손실을 입거나 법적 비용까지 지불해야 하는 경우가 발생할 수 있습니다. 오늘날과 같은 정보 시대에서는 인터넷을 통해 전자적으로 전달되는 서비스 제공에 대한 요구가 증가하므로 많은 MIS 시스템이 업무에 중요한 시스템으로 간주됩니다. 즉, 시스템 장애가 발생하는 경우 회사는 본연의 기능을 올바르게 수행하지 못하여 많은 손실을 입게 됩니다.

소프트웨어 라이프사이클 초기에 시작되는 품질 접근 방식을 지속적으로 유지함으로써 소프트웨어 완성 및 유지보수 비용을 현저히 줄일 수 있습니다. 또한 이를 통해 낮은 품질의 소프트웨어 배치와 연관된 위험성을 크게 줄일 수 있습니다.

기타 원칙과의 관계

테스트 원칙은 다음과 같이 다른 원칙과 연관됩니다.

  • 요구사항 원칙은 수행할 테스트를 식별하기 위한 기본 입력 중 하나인 소프트웨어 제품의 요구사항을 캡처합니다.
  • 분석 및 디자인 원칙은 수행할 테스트를 식별하기 위한 또 다른 중요 입력인 소프트웨어 제품에 대한 올바른 디자인을 결정합니다.
  • 구현 원칙은 테스트 원칙으로 유효성을 검증하는 소프트웨어 제품의 빌드를 생성합니다. 하나의 반복에서 일반적으로 테스트 주기당 하나씩 여러 빌드를 테스트할 수 있습니다.
  • 배치 원칙은 일반 사용자에게 완성된 소프트웨어 제품을 전달합니다. 소프트웨어를 전달하기 전에 테스트 원칙으로 소프트웨어의 유효성을 검증하지만 배치의 일부로 베타 테스트 및 승인 테스트를 자주 수행합니다.
  • 환경 원칙은 테스트 가이드라인 및 테스트 환경과 같이 테스트 중에 사용되는 지원 아티팩트를 개발하고 유지보수합니다.
  • 프로젝트 관리 원칙은 프로젝트와 각 반복의 필수 작업에 대한 계획을 수립합니다. 반복 계획에 설명되어 있는 것처럼 이 아티팩트는 테스트 노력을 위한 올바른 평가 미션을 정의할 때 사용되는 중요한 입력입니다.
  • 형상 및 변경 관리  원칙은 프로젝트 팀 내의 변경을 제어합니다. 테스트 노력은 각 변경사항이 올바르게 완료되었는지 확인합니다.

추가 자료

Kaner, Bach & Pettichord의 Lessons Learned in Software Testing [KAN01]을 읽어보십시오. 이 문서는 테스트 팀의 중요 관심사항에 대한 핵심 정보를 제공합니다.

자세한 정보