소프트웨어 테스트에는 다양한 유형이 있으며, 각 테스트는 특정한 목표와 전략을 갖고 있습니다.

• 승인 테스트: 전체 시스템이 의도한 대로 작동하는지 확인합니다.
• 코드 검토: 새 소프트웨어와 수정된 소프트웨어가 조직의 코딩 표준을 따르고 모범 사례를 준수하는지 확인합니다.
• 통합 테스트: 소프트웨어 구성 요소 또는 기능이 함께 작동하는지 확인합니다.
• 단위 테스트: 각 소프트웨어 단위가 예상대로 실행되는지 확인합니다. 단위는 애플리케이션에서 테스트할 수 있는 가장 작은 구성 요소입니다.
• 기능 테스트: 기능 요구 사항을 기반으로 비즈니스 시나리오를 에뮬레이션하여 기능을 확인합니다. 블랙박스 테스트는 기능을 검증하는 일반적인 방법입니다.
• 성능 테스트: 다양한 워크로드에서 소프트웨어가 어떻게 실행되는지 테스트합니다. 예를 들어, 부하 테스트는 실제 부하 조건에서 성능을 평가하는 데 사용됩니다.
• 회귀 테스트: 새로운 기능이 중단되거나 기능이 저하되는지 확인합니다. 전체 회귀 테스트를 수행할 시간이 없는 경우 온전성 테스트를 사용해 메뉴, 기능 및 명령을 표면 수준에서 검증할 수 있습니다.
• 보안 테스트: 소프트웨어가 해커나 기타 악의적인 유형의 취약점에 노출되어 있지 않은지 확인하여 서비스에 대한 액세스를 거부하거나 잘못된 성능을 유발하는 데 악용될 수 있는 취약점이 없는지 확인합니다.
• 스트레스 테스트: 시스템이 장애를 일으키기 전까지 어느 정도의 부담을 견딜 수 있는지 테스트합니다. 스트레스 테스트는 비기능 테스트의 일종으로 간주됩니다.
• 사용성 테스트: 고객이 작업을 완료하기 위해 시스템 또는 웹 애플리케이션을 얼마나 잘 사용할 수 있는지 확인합니다.

각각의 경우에 기본 요구 사항을 검증하는 것은 중요한 평가입니다. 마찬가지로 중요한 것은 예비 테스트는 테스터 또는 테스트 팀이 소프트웨어 오류로 이어질 수 있는 예측하기 어려운 시나리오와 상황을 발견하는 데 도움이 된다는 점입니다.

간단한 애플리케이션이라도 수많은 테스트를 거쳐야 할 수 있습니다. 테스트 관리 계획은 사용 가능한 시간과 리소스를 고려할 때 어떤 유형의 테스트가 가장 가치가 있는지 우선순위를 정하는 데 도움이 됩니다. 가장 적은 수의 테스트를 실행하여 가장 많은 결함을 찾아내어 테스트 효과를 최적화합니다.

소프트웨어 테스트는 제2차 세계대전 직후에 시작된 소프트웨어의 개발과 함께 등장했습니다. 컴퓨터 과학자 톰 킬번(Tom Kilburn)은 1948년 6월 21일 영국 맨체스터 대학교에서 첫 선을 보인 최초의 소프트웨어를 개발한 것으로 알려져 있습니다. 이 소프트웨어는 기계 코드 명령을 사용하여 수학적 계산을 수행했습니다.

당시의 주요 테스트 방법은 디버깅이었고 그 이후 20년 동안 계속 사용되었습니다. 1980년대에 들어서면서 개발팀은 소프트웨어 버그를 격리하고 수정하는 것을 넘어 실제 환경에서 애플리케이션을 테스트하는 것으로 눈을 돌렸습니다. 이 덕분에 테스트를 더 넓은 관점에서 생각하고 소프트웨어 개발 수명 주기의 일부였던 품질 보증 프로세스를 테스트에 포함하게 되었습니다.

소프트웨어를 개발할 때 품질 관리의 필요성에 대해 이의를 제기할 사람은 거의 없습니다. 배송이 늦어지거나 소프트웨어에 결함이 있으면 브랜드의 평판이 손상되어 고객이 만족하지 못하고 이탈할 수 있습니다. 극단적인 경우에는 버그나 결함으로 인해 상호 연결된 시스템의 성능이 저하되거나 심각한 오작동이 발생할 수 있습니다.

에어백 센서 감지기의 소프트웨어 결함으로 인해 100만 대 이상의 차량을 리콜해야 했던 닛산의 사례나, 12억 달러 규모의 군용 위성 발사에 실패를 초래한 소프트웨어 버그를 생각해 보세요.¹ 수치만 봐도 알 수 있습니다. 2016년 미국에서는 소프트웨어 장애로 인해 1조 1,000억 달러의 자산 손실이 발생했고 44억 명의 고객에게 영향을 미쳤습니다.²

테스트에는 비용이 들지만, 좋은 테스트 기술과 QA 프로세스를 갖추고 있으면 기업은 연간 수백만 달러의 개발 및 지원 비용을 절감할 수 있습니다. 초기 소프트웨어 테스트는 제품이 시장에 출시되기 전에 문제를 발견합니다. 개발팀이 테스트 피드백을 빨리 받을수록 다음과 같은 문제를 더 신속하게 해결할 수 있습니다:

• 아키텍처 결함
• 잘못된 설계 결정
• 유효하지 않거나 잘못된 기능
• 보안 취약점
• 확장성 문제

개발 시 충분한 테스트 공간을 확보하면 소프트웨어 안정성이 향상되고 오류 없이 고품질 애플리케이션을 제공할 수 있습니다. 고객의 기대치를 충족하거나 뛰어넘는 시스템은 잠재적으로 더 많은 매출과 더 큰 시장 점유율로 이어집니다.

소프트웨어 테스트는 일반적인 프로세스를 따릅니다. 태스크 또는 단계에는 테스트 환경 정의, 테스트 케이스 개발, 스크립트 작성, 테스트 결과 분석 및 결함 보고서 제출 등이 포함됩니다.

테스트는 시간이 많이 걸릴 수 있습니다. 소규모 시스템에서는 수동 테스트 또는 임시 테스트로 충분할 수 있습니다. 그러나 대규모 시스템의 경우 작업을 자동화하기 위해 도구를 사용하는 경우가 많습니다. 자동화된 테스트를 통해 팀은 다양한 시나리오를 구현하고, 차별화 요소(예: 구성 요소를 클라우드 환경으로 이동)를 테스트하고, 효과적인 요소와 그렇지 않은 요소에 대한 피드백을 신속하게 얻을 수 있습니다.

좋은 테스트 접근 방식에는 API(애플리케이션 프로그래밍 인터페이스), 사용자 인터페이스 및 시스템 수준이 포함됩니다. 자동화되고 조기에 실행되는 테스트는 많을수록 좋습니다. 자체적으로 테스트 자동화 도구를 구축하는 팀도 있습니다. 그러나 제공업체의 솔루션은 다음과 같은 주요 테스트 관리 작업을 간소화할 수 있는 기능을 제공합니다.

연속적인 테스트

프로젝트 팀은 각 빌드를 사용할 수 있게 되면 테스트합니다. 이러한 유형의 소프트웨어 테스트는 배포 프로세스와 통합된 테스트 자동화에 의존합니다. 이를 통해 프로세스 초기에 실제 테스트 환경에서 소프트웨어를 검증할 수 있으므로 설계를 개선하고 위험을 줄일 수 있습니다.

구성 관리

조직은 테스트 자산을 중앙에서 관리하고 어떤 소프트웨어 빌드를 테스트할지 추적합니다. 팀은 코드, 요구 사항, 디자인 문서, 모델, 테스트 스크립트 및 테스트 결과와 같은 자산에 액세스할 수 있습니다. 좋은 시스템에는 관리 상의 번거로움을 최소화하면서 규정 준수 요구 사항을 충족하는 데 도움이 되는 사용자 인증 및 감사 추적이 포함되어 있습니다.

서비스 가상화

코드 개발 초기에는 테스트 환경을 사용하지 못할 수도 있습니다. 서비스 가상화는 누락되었거나 아직 완료되지 않은 서비스 및 시스템을 시뮬레이션하여 팀이 종속성을 줄이고 더 빨리 테스트할 수 있도록 지원합니다. 원래 환경을 수정할 필요 없이 구성을 재사용, 배포 및 변경하여 다양한 시나리오를 테스트할 수 있습니다.

결함 또는 버그 추적

결함을 모니터링하는 것은 품질을 측정하고 개선하기 위해 테스트 팀과 개발 팀 모두에게 중요합니다. 팀은 자동화된 도구를 사용해 결함을 추적하고, 범위와 영향을 측정하며, 관련 문제를 발견할 수 있습니다.

메트릭 및 보고

팀원들은 보고 및 분석을 통해 상태, 목표, 테스트 결과를 공유할 수 있습니다. 고급 도구는 프로젝트 메트릭을 통합하고 대시보드에 결과를 표시합니다. 팀은 프로젝트의 전반적인 상태를 빠르게 확인하고 테스트, 개발 및 기타 프로젝트 요소 간의 관계를 모니터링할 수 있습니다.