시스템 테스트란 무엇인가요?

현미경으로 소프트웨어 시스템을 보고 있다고 상상해 보세요. 가장 높은 배율로 확대하면 소프트웨어 시스템의 기본 구성 요소인 단위를 관찰할 수 있습니다. 그다음 시야를 넓혀 배율을 한 단계 낮춰 보면 이러한 개별 단위로 구성된 모듈을 확인할 수 있습니다. 마지막으로 완전히 축소하면 시스템 전체를 볼 수 있는 시스템 레벨에 도달합니다. 이 수준에서는 시스템 내 모든 구성 요소와 각 모듈이 만들어낸 모든 구성 요소들이 어떻게 함께 작동하는지 한눈에 볼 수 있습니다.

어떤 면에서 시스템 테스트는 이처럼 현미경을 보는 것과 비슷하지만 중요한 차이점이 있습니다. 시스템 테스트는 블랙박스 테스트의 한 형태로, 테스터는 시스템을 구성하는 개별 요소의 모습보다는 시스템 전체 기능에 더 관심을 둡니다. 이러한 종류의 '합격/불합격' 관점에서 볼 때 시스템 동작은 오직 시스템 성능과 관련된 맥락에서만 주목할 만합니다. (화이트박스 테스트는 시스템 내 구성 요소의 특성을 더 잘 들여다볼 수 있게 해 줍니다.)

시스템 테스트에는 특정 소프트웨어 시스템 내에서 함께 작동하거나 작동하지 않을 수 있는 여러 개별 소프트웨어 시스템의 분석이 포함되는 경우가 많습니다.

우주 발사 전 카운트다운을 생각해 보세요. 모두가 점화와 이륙 전 극적인 10단계 카운트다운은 기억하지만, 비행 책임자가 각 부서에 확인을 요청하고 '준비 완료' 승인을 받는 수많은 점검 과정까지 기억하는 사람은 많지 않습니다. 일반적인 우주 발사에서는 부서장들에게 계획된 운영, 임무 안전, 우주선 시스템, 예상 기상 조건 등 수많은 사안에 대해 의견을 묻습니다. 각 부서가 차례로 질의를 받고, 각 부서장은 이에 대해 순서대로 답변합니다.

마찬가지로 시스템 테스트는 새로운 소프트웨어 시스템을 출시하기 전의 최종 체크리스트로 간주할 수 있습니다. 알려진 모든 소프트웨어 버그를 마지막으로 정리하는 과정이 완료되었습니다. 초기 우주 개척자들이 만든 역사적인 체크리스트와 마찬가지로, 시스템 테스트에 포함된 각 '부서'에서 최종 승인을 받아야 비로소 모든 과정이 마무리됩니다.

각 질문은 시스템 기능 관점에서 검토됩니다.

• 각 구성 요소가 예상대로 작동하고 있나요?

• 구성 요소가 서로 원활하게 조화를 이루며 작동하고 있나요?

• 소프트웨어가 매끄러운 사용자 인터페이스를 제공하고, 기대하는 사용자 경험(UX)을 충족할 준비가 되어 있나요?

시스템 테스트에 대해 논의할 때 자연스럽게 테스트 케이스 내에 존재하는 관계인 종속성에 대한 주제를 접하게 됩니다. 이러한 상황에서는 한 테스트 케이스의 결과가 다른 테스트 케이스의 결과에 부분적 또는 전체적으로 의존할 수 있습니다. 종속성에는 기능, 테스트 환경, 보안 정책이 포함될 수도 있으며 조직이 유지하는 전체 테스트 프로세스에 영향을 미칠 수도 있습니다.

시스템 테스트 방법론은 내부 작동에 대한 심층적인 조사를 제공하지 않고(이것이 일종의 블랙박스 테스트라는 점에 유의하세요) 대신 특정 애플리케이션이 작동하는지 여부를 알려줍니다. 시스템 테스트의 취지는 소프트웨어 애플리케이션의 전반적인 기능을 평가하는 과정에서, 격차, 오류 또는 누락된 요구 사항을 찾아내는 데 도움을 주는 것입니다.

시스템 테스트는 일반적으로 Integration Testing(통합 테스트) 후, 승인 테스트 전에 수행되며, 이를 통해 모든 구성 요소가 제대로 작동하는지 확인합니다. 나중에 자세히 살펴보겠지만, 시스템 테스트는 기능적 측면과 비기능적 측면을 모두 아우르는 경우가 많습니다. 엄격한 기능적 영역과 광범위한 비기능적 영역을 모두 기반으로 하기 때문에 사용성, 보안, 성능과 같은 광범위한 측면을 다루게 됩니다.

시스템 테스트의 주요 목적 중 하나는 소프트웨어의 코딩 언어가 사용 가능한 프로그램으로 변환될 수 있는지 검증하는 것입니다. 그러나 시스템 테스트의 궁극적인 목표는 평가 대상 소프트웨어가 이를 사용할 사용자의 비즈니스 요구 사항을 충분히 지원하는지 확인하는 데 있습니다.

테스트 과정은 변화하는 실제 사용 환경 조건에서도 소프트웨어가 정상적으로 작동하는지 확인할 수 있도록, 실제 운영 환경과 동일하게 설계됩니다. 마찬가지로 테스트 데이터는 실제 데이터와 상황을 모방하도록 만들어집니다. 테스트 케이스가 수행되면 소프트웨어의 결함을 찾아 수정할 수 있습니다.

시스템 테스트는 세 가지 주요 그룹 중 하나에 따라 분류할 수 있습니다. 첫 번째, Functional Testing(기능 테스트)은 시스템 성능과 관련이 있지만 소프트웨어가 약속한 대로 작동하는지 확인하는 것 이상의 깊은 분석은 수행하지 않습니다. 다음은 몇 가지 주요 Functional Testing 유형입니다.

• 승인 테스트: 사용자 승인 테스트는 생산되는 소프트웨어의 의도된 대상 사용자 그룹을 대표하는 사람들이 수행한 성능 테스트를 통합하는 것을 목표로 합니다. 이러한 사용자들은 실제 환경에서 소프트웨어를 테스트함으로써 테스트 과정에 현실감을 더합니다.

• Integration Testing(통합 테스트): Functional Testing의 매우 중요한 영역 중 하나로, 서로 다른 모듈이나 구성 요소가 긴밀하게 함께 작동해야 할 때 서로 얼마나 잘 맞는지 평가합니다. 이를 시스템 통합 테스트라고 합니다. 완전히 통합된 시스템은 테스터가 핵심 상호 작용을 평가할 수 있는 기반을 제공합니다.

• 스모크 테스트: 스모크 테스트는 개발자가 코드를 변경한 후에도 전반적인 기능이 유지되었는지 확인하는 수단을 제공합니다. 코드 변경이 적용된 후, 스모크 테스트를 통해 그 변경으로 인해 부작용이 발생했는지 빠르게 확인할 수 있습니다.

• 단위 테스트: 단위 테스트에서는 격리된 테스트 환경 내에서 제한된 코드 섹션을 검사합니다. 테스트 대상 단위가 실패하면(테스트 데이터와 기능 목표를 비교하여 확인), 일반적으로 시스템 전체 수준에서 개별 구성 요소나 모듈에 대한 추가 테스트가 필요합니다.

Functional Testing(기능 테스트)은 매우 중요한 정보를 제공하지만, 해당 데이터는 기본적으로 시스템이 제대로 작동하는지 여부에 따라 단순 통과/실패 수준으로 제한됩니다. 여기에는 시스템 보안, UX, 성능 측면과 같은 수많은 관련 변수가 누락되어 있습니다.

비기능 시스템 테스트는 시스템 작동 방식을 판단하는 수단을 제공합니다. Functional Testing(기능 테스트)와 비기능 테스트의 근본적인 차이점은 다음과 같은 간단한 비교로 요약할 수 있습니다.

• Functional Testing(기능 테스트): 시스템이 작동하는가?

• 비기능 테스트: 시스템이 얼마나 잘 작동하는가?

이를 바탕으로 비기능 시스템 테스트의 주요 유형은 다음과 같습니다.

• 접근성 테스트: 제공되는 디지털 콘텐츠가 다양한 장애를 가진 사람을 포함한 모든 사람이 접근할 수 있습니까? 접근성 테스트는 이러한 질문을 조사하며, 신체적·정신적 장애를 가진 사람을 포함한 모든 사용자가 콘텐츠를 이용할 수 있도록 보장하고, 미국 장애인법(ADA)에서 정한 포용 기준과 일치하도록 합니다.

• 호환성 테스트: 애플리케이션이 얼마나 널리 배포되어 있으며, 다양한 플랫폼 환경을 거쳐야 하는지를 고려하면, 호환성 테스트의 필요성을 쉽게 이해할 수 있습니다. 호환성 테스트는 앱이 여러 네트워크, 브라우저, 운영 체제, 하드웨어 구성 등 어떤 환경에서도 얼마나 잘 작동하는지를 평가합니다.

• 부하 테스트: 부하 개념이 제시하는 고유한 특성과 이것이 시스템이 요청을 처리하는 능력에 미치는 영향을 다루는 하위 분야에서, 부하 테스트는 시스템이 대규모로 확장될 때 어떤 일이 발생하는지에 중점을 둡니다. 우리는 시스템이 단일 요청을 처리하는 데 문제없다고 가정하지만, 그 요청이 수천 건, 혹은 훨씬 더 많은 건으로 늘어난다면 어떻게 될까요?

• 로컬라이제이션 테스트: 지금은 그 어느 때보다 많은 국가와 문화가 참여하는 글로벌 경제 시대입니다. 로컬라이제이션 테스트는 전 세계 다양한 지역으로 배포되는 소프트웨어 콘텐츠가 UX에 관한 일반적인 규칙에 따라 해당 지역에 적합한지 확인하는 작업입니다.

• 성능 테스트: 이 유형의 비기능 테스트는 성능 문제에 특히 주의를 기울입니다. 예를 들어, 시스템이 요청에 빠르고 원활하게 응답하는 것은 좋은 성능을 위해 필수적입니다. 성능 테스트의 테스트 계획은 사용자가 요청이 처리될 때까지 얼마나 기다려야 하는지 평가합니다.

• 보안 테스트: 오늘날 데이터 보안이 가장 중요하다는 것은 누구나 알고 있는 사실입니다. 따라서 보안 전용 테스트가 필요한 것은 당연합니다. 보안 테스트 방법은 회사가 직면할 수 있는 잠재적 위협의 유형에 따라 선택됩니다.

• 스트레스 테스트: 의료 스트레스 테스트가 활동에 따른 스트레스 상황에서 사람의 심장이 얼마나 잘 작동하는지 파악하는 것과 마찬가지로, 소프트웨어 스트레스 테스트는 시스템에 평소보다 큰 부하가 가해질 때 병목 현상과 취약점을 확인하며, 시스템이 운영 탄력성을 얼마나 잘 유지하는지 평가합니다.

• 사용성 테스트: 이 유형의 비기능 테스트는 전적으로 사용자 경험(UX)의 품질에 중점을 둡니다. 사용성 테스트는 소규모 환경에서 특히 실용적으로 활용되는 수동 테스트 방식입니다. 그럼에도 불구하고 자주 적용해야 하며, 애플리케이션 현지화와 같은 복잡한 작업을 수행할 때는 특히 그렇습니다.

기능 테스트나 비기능 테스트 범주에 속하지 않더라도 유용한 다른 시스템 테스트 유형도 있습니다. 그중에서도 특히 주목할 만한 몇 가지 방법론을 소개합니다.

• API 테스트: 애플리케이션 프로그래밍 인터페이스(API)는 매우 중요하며, 다양한 앱이나 시스템을 연결하여 소프트웨어 개발을 가능하게 합니다. API 테스트는 API 연결 지점이 의도한 대로 작동하는지 확인합니다. 또한 사용자 권한과 API를 통한 데이터 관리 방식이 올바르게 운영되는지도 점검합니다.

• 자동화된 테스트: 이름에서 알 수 있듯이 자동화된 테스트(테스트 자동화라고도 함)는 소프트웨어 애플리케이션 테스트에 자동화 기술을 적용한 방식입니다. 소프트웨어 앱에서 테스트 케이스를 실행하도록 설계된 테스트 스크립트를 생성하고 활용해, 사람의 개입 없이 대규모로 테스트를 수행합니다. 테스트 프로세스를 자동화하는 데 도움이 되는 구조화된 가이드라인, 도구, 모범 사례 세트를 프레임워크라고 합니다.

• 수동 테스트: 자동화된 테스트와 정반대로, 수동 테스트는 다양한 테스트 시나리오와 테스트 스크립트의 안내에 따라 평가 대상 소프트웨어를 실험하기 위해 사람의 테스트에 의존합니다. 테스터는 수정이 필요한 문제를 식별하기 위해 소프트웨어를 철저히 시험해 보도록 권장됩니다.

• 마이그레이션 테스트: 기업이 디지털 환경을 업데이트하거나 전환하려는 경우 마이그레이션 테스트가 필요합니다. 이러한 전환 과정에서 핵심 데이터와 소프트웨어가 기존 시스템에서 새로운 시스템으로 제대로 이전되고 있는지 검증해야 합니다.

• 회귀 테스트: 코드 변경은 소프트웨어를 개선하거나 기능을 향상시키기 위한 것이지만, 인적 오류가 추가되면 의도치 않게 문제가 발생할 수 있습니다. 회귀 테스트를 통해 테스터는 필요에 따라 테스트를 다시 실행하여 안정적이고 올바르게 작동하는지 확인할 수 있습니다.

시스템 테스트 프로세스는 가장 포괄적인 블랙박스 성능 테스트를 제공하지만, 시스템 테스트 수행에는 잠재적인 문제가 존재할 수 있습니다.