기능 테스트란 무엇인가요?

소프트웨어 개발에는 수많은 유형의 소프트웨어 테스트가 있습니다. 각각 조금씩 다른 접근 방식으로 작업을 수행합니다. 기능 테스트는 사용자 경험의 개념과 가장 밀접하게 연관되어 있으며, 소프트웨어 기능이 예상대로 작동하고 명시된 요구 사항에 따라 작동하는지를 확인하는 한 가지 핵심 질문에 초점을 맞춥니다.

소프트웨어 품질은 소프트웨어 개발 수명 주기의 일부로 다양한 각도에서 평가되는 경우가 많습니다. 기능 테스트와 관련해서, 테스터는 기본적인 기능을 검증하고 소프트웨어 기능이 비즈니스 요구 사항을 충분히 지원하는지를 확인해야 합니다. 테스트 실행을 통해 DevOps 팀은 실제 테스트 결과와 예상 결과를 비교할 수 있습니다.

테스트는 개발 프로세스의 필수적인 부분이며, 기능 테스트는 QA 팀이 일종의 사전 품질 보증을 수행할 수 있도록 하여 실제 출시 시 워크플로가 어떻게 작동할지 명확히 파악할 수 있습니다.

전체 테스트 전략의 일부로 어떤 유형의 소프트웨어 테스트를 사용하는지에 따라 다양한 운영 요소가 강조됩니다. 기능 테스트는 다양한 소프트웨어 모듈 간의 전반적인 호환성을 평가하는데, 이는 예상되는 사용자 상호 작용 및 사용자 인터페이스의 실행 가능성과 같은 다른 관련 요소들에도 직접적인 영향을 미칩니다.

기능 테스트에서 제공하는 테스트 환경은 블랙박스 테스트의 한 예로, 테스터는 화이트박스 테스트에서처럼 시스템 내부의 메커니즘을 파악할 수 없고 대신 시스템과 파이프라인이 바람직하게 작동하는지에 대한 '합격/불합격' 보고서만 받게 됩니다.

기능 테스트는 일반적으로 6단계가 필요한 테스트 프로세스를 따릅니다.

1. 소프트웨어가 수행해야 하는 다양한 기능을 식별합니다.
2. 기능 요구 사항에 따라 입력 데이터를 생성합니다.
3. 기능 사양에 따라 예상 아웃풋을 설정합니다.
4. 테스트 케이스를 수행합니다.
5. 실제 아웃풋이 예상 아웃풋과 어떻게 비교되는지 평가합니다.
6. 소프트웨어 애플리케이션이 기대에 맞게 만족스럽게 작동하는지 확인합니다.

다양한 소프트웨어 테스트 모델이 있는 것처럼 기능 테스트에도 다양한 유형이 있습니다. 이는 매우 많으며, 이 목록은 일부에 불과합니다. 기능 테스트 유형은 다양한 뉘앙스를 포함하며 여기에 알파벳순으로 나열되어 있습니다.

소프트웨어 테스트에서 테스터들은 종종 정형화된 테스트 절차를 수행한 후 임시 테스트를 진행합니다. 이 비공식적인 형태의 탐색 테스트는 전적으로 테스터의 기술과 직관에 따라 진행됩니다. 정의된 구조는 없습니다. 대신 테스터의 직관에 따라 사용되는 테스트 기술이 결정됩니다.

예: 개발자와 테스터가 힘을 합쳐 모듈이나 앱을 개선하는 '버디 테스트'가 있습니다. 이러한 형태의 임시 테스트에서는 일반적으로 테스터가 버그나 기타 수정이 필요한 사항을 발견하는 동안 개발자는 이러한 수정에 집중합니다.

애플리케이션 프로그래밍 인터페이스(API)는 소프트웨어 개발을 가능하게 하고 다양한 앱 또는 시스템의 연결을 허용합니다. API 테스트는 API 연결 지점이 필요에 따라 작동하는지 확인합니다. 또한 사용자 권한과 API를 통한 데이터 관리 방식에 대한 감독 기능도 제공합니다.

예: '헤드리스 테스트(Headless testing)'는 사용자 인터페이스 또는 사용자 인터페이스 데이터 입력 필드가 부족할 때 수행됩니다. 이러한 상황에서는 인터페이스 서비스 또는 앱과 공유되는 입력 데이터는 API 테스트를 통해 테스트하는 것이 가장 좋은 경우가 많습니다.

많은 조직들은 테스트 프로세스가 실제 사용자의 실제 경험을 제대로 반영하기를 원합니다. 이러한 기업의 경우 복잡한 테스트 시나리오는 원하는 수준의 정확도를 제공하지만, 복잡성이 높을수록 이를 수행하기 위해 사전에 더 많은 작업이 필요하다는 점을 짚고 넘어가야 합니다.

예: 온라인 주문 처리가 원활하게 작동하는 것처럼 보입니다. 하지만 이 이면에는, 쇼핑객의 온라인 장바구니에 상품을 얼마나 쉽게 담을 수 있는지, 할인 적용 같은 기능이 얼마나 신속하게 반영되는지, 그리고 이런 구매가 얼마나 매끄럽게 이루어지는지와 같은 수많은 프로세스를 테스트해야 합니다.

통합 테스트는 조기 문제 감지 및 광범위한 테스트 범위와 같은 이점 때문에 단위 테스트와 동시에 실행되는 경우가 많습니다. 통합 테스트는 데이터 형식을 일치시키는 데 도움이 될 뿐만 아니라 마이크로서비스의 작동 및 성능에 대한 인사이트를 제공합니다.

예: 주문 관리 시스템이 결제 처리를 관리하는 특정 유형의 모듈과 통합되어 있다고 가정해 보겠습니다. 통합 테스트는 두 엔티티 간에 향후 결함이 발생할 수 있는 위치를 보여 주고 개발자에게 통합 문제를 더 일찍, 더 적은 비용으로 해결할 수 있는 청사진을 제공합니다.

완벽한 세상이라면 기능 테스트가 통과되면 항상 통과될 것입니다. 하지만 이는 현실과 맞지 않습니다. 실제로는 개발자들이 새로운 코드를 변경하는 과정에서 자신도 모르게 오류를 유발하는 경우가 자주 발생하기 때문입니다. 회귀 테스트는 안정적인 기준선이 유지되도록 합니다.

예: 코드가 변경될 때마다 한 가지 형태의 회귀 테스트 또는 다른 형태의 회귀 테스트가 사용됩니다. 여기에는 버그 수정, 새로운 기능 도입, 또는 소프트웨어 업데이트 후에 이루어지는 모든 관련 업데이트가 포함됩니다.

상태 확인 테스트(Sanity testing)는 비교적 사소한 변경이나 버그 수정으로 인해 기존 기능이 손상되지 않았는지 빠르고 민첩하게 확인하는 방법입니다. 상태 확인 테스트는 새로운 기능이 시스템의 나머지 기능에 문제를 일으키지 않는지 빠르게 확인하는 방법으로 사용되는 경향이 있습니다.

예: 회귀 테스트와 마찬가지로 상태 확인 테스트를 사용하면 시스템을 이전 기능으로 '되감기'하여 성능 향상을 확인하고 기본 작동을 확인하며 시스템이 예상대로 작동하는지 확인할 수 있습니다. 코드가 변경될 때마다 한 가지 형태의 회귀 테스트 또는 다른 형태의 회귀 테스트가 사용됩니다. 여기에는 버그 수정, 새로운 기능 도입, 또는 소프트웨어 업데이트 후에 이루어지는 모든 관련 업데이트가 포함됩니다.

'연기가 나는 곳에 불이 있다'는 옛 속담이 있는데, 이 속담에서 '스모크 테스트(smoke testing)'라는 이름이 유래된 것으로 보입니다. 스모크 테스트는 개발 프로세스 초기에 수행되며, 수행 시 엔드투엔드 기능을 판단합니다. 기능에 장애가 발생하면 QA 팀이 필요한 수정 작업을 수행합니다.

예: 스모크 테스트는 새로운 소프트웨어 빌드(또는 주요 코드 변경)를 배포하기 전에 최종 점검으로 지속적 통합 및 지속적 파이프라인을 확인하는 데 사용할 수 있습니다.

엔드투엔드 테스트라고도 하는 시스템 테스트는 전체 소프트웨어 시스템의 소프트웨어가 함께 작동하는 방식을 평가하기 위해 수행됩니다. 시스템 테스트에는 특정 소프트웨어 시스템 내에서 함께 작동하거나 작동하지 않을 수 있는 여러 개별 소프트웨어 시스템의 분석이 포함되는 경우가 많습니다.

예: 테스터는 엔드투엔드 시나리오를 통해 전체 워크플로를 평가할 수 있습니다. 온라인 소매 운영의 경우 이는 최초 구매 주문부터 전체 주문 처리 프로세스에 이르기까지 소비자가 경험하는 전체 소매 경험을 의미할 수 있습니다.

단위 테스트는 아주 작은 범위에서의 테스트 형태입니다. 여기서는 전체 시스템을 테스트하는 것이 아니라 제한된 코드만 테스트합니다. 코드의 한 섹션을 격리된 테스트 환경에서 평가하며, 단위 테스트가 실패할 경우(테스트 데이터와 기능 목표를 비교한 결과), 시스템 전체 수준에서 추가 테스트를 진행할 수 있습니다.

예: 아주 기본적인 계산 요소는 단위 테스트를 통해 잘 테스트됩니다. 섭씨 온도를 화씨 온도로 변환하는 간단한 함수를 생각해 보면 됩니다. 테스트 환경에는 해당 코드와 관련된 테스트 케이스가 포함되어 있습니다.

소프트웨어 테스트의 후반 단계인 사용자 수락 테스트는 개발된 소프트웨어의 목표 사용자 집단을 대표하는 사람들이 수행한 성능 테스트를 통합하고 이를 통해 학습하고자 하는 것입니다. 이러한 최종 사용자는 테스트 프로세스에 현실감을 더합니다.

예: 소프트웨어 요금제 사용자가 다음 서비스 계층으로 업그레이드하면, 완전히 새로운 기능을 사용할 수 있는 권한이 부여됩니다 사용자 수락 테스트는 사용자가 자신의 기능 접근 권한이 예상대로 증가하는지 확인할 수 있도록 검증합니다.

이름에서 알 수 있듯이, 비기능 테스트는 기능 보장에 필수적이지 않은 애플리케이션 동작을 평가합니다. 그럼에도 잘 정리되고 쾌적한 사용자 경험을 제공하는 것은 이제 소프트웨어 개발의 필수 요소로 간주됩니다. 비기능 테스트는 특히 소프트웨어가 더 큰 확장성을 입증하기 위해 최대화될 때 일어날 수 있는 시스템 문제를 드러낼 수 있습니다.

대부분이 서로 다른 플랫폼과 애플리케이션 유형을 지원하기 때문에 다양한 기능 테스트 도구들을 정확히 추적하는 것은 상당한 노력이 필요합니다. 기능 테스트 도구가 수백 개, 어쩌면 수천 개의 생산되는 것으로 추정되기 때문에 급성장하는 마켓플레이스를 따라잡을 방법은 없지만, 입증된 인기와 인정받는 유용성으로 돋보이는 몇 가지를 소개합니다.

• Appium: 기능 테스트 마켓플레이스에는 많은 오픈 소스 도구가 있으며, 그 중 Appium이 선두를 달리고 있습니다. Appium은 여러 프로그래밍 언어를 지원합니다. 또한 Appium을 사용하면 iOS 및 Android 플랫폼 모두에서 네이티브, 모바일 웹 및 하이브리드 애플리케이션을 자동화할 수 있습니다.

• Katalon Studio: 테스트 자동화 플랫폼 Katalon Studio는 회귀 테스트와 엔드투엔드 테스트를 통해 생성된 결과를 설정하고 평가하는 수단을 제공합니다. 기록 및 재생 기능과 플랫폼 간 조정 기능이 특징입니다.

• Micro Focus 통합 기능 테스트(UFT): Micro Focus의 UFT는 또 다른 상용 테스트 도구로, 테스터에게 웹 서비스, 애플리케이션 프로그래밍 인터페이스(API) 및 그래픽 사용자 인터페이스(GUI) 사용에 대한 명확한 다중 플랫폼 창을 제공합니다.

• Playwright: Microsoft는 웹 브라우저 자동화를 위해 이 상용 프레임워크를 개발했습니다. 이는 신뢰성을 강화하는 것으로 유명합니다. Playwright는 최신 웹 기능을 지원하지만, 프로그래밍 언어를 처리할 수 있는 옵션이 적습니다.

• Selenium: 가장 인기 있는 테스트 자동화 도구 중 하나는 오픈 소스 프레임워크인 Selenium입니다. 이 브라우저 기반 도구를 사용하면 테스터는 JavaScript ^TM, NodeJS 및 Python을 비롯한 다양한 인기 프로그래밍 언어로 테스트 스크립트를 작성하고 평가할 수 있습니다.