처음부터 끝까지, 종단 간 테스트(E2E)

고객이라는 대상이 있는 모든 제품은 출시전에 사전 테스트 과정을 거칩니다. 테스트는 보다 완벽한 상품으로 거듭나기 위함이고 이는 소비자에게 좋은 경험을 선사합니다. 그리고 소프트웨어 또한 타겟이 있는 제품이기에 SDLC에 필수적으로 테스트 단계가 포함됩니다.

소프트웨어의 테스트 방법은 크게 '단위 테스트', '통합 테스트', '인수 테스트'로 총 3단계로 구분되며, 이번 포스팅에서는 통합 테스트중 E2E 테스트를 다뤄보려고 합니다.

 

E2E 테스트 진행 과정 묘사 (https://mattermost.com)

종단 간 테스트(End To End Testing)

UI 테스트라고도 하며, 사용자의 입장에서 애플리케이션의 workflow를 처음부터 끝까지를 테스트하여 비즈니스 목표에 대한 시나리오 달성 여부를 확인합니다. 종단 간 테스트는 일반적으로 시스템 테스트가 완료된 이후에 진행되고, 이전 단계에서 확인하지 못했던 사용자 관점의 테스트를 진행합니다. 예를 들어, 전자상거래라고 가정하면 E2E 테스트에서는 계정 생성 > 로그인 > 장바구니에 상품 추가 > 장바구니 상품 결제 > 결제 완료에 대해 테스트를 진행합니다. 

 

Google Test Automation Conference에서 제안된 테스트 피라미드

구글의 테스트 자동화 문서(2014년 기준)에 따르면 E2E에 대해서는 테스트 비중을 낮게 잡고있습니다. 이유는 피라미드의 위에 위치하는 테스트일수록 비용이 증가하고 피드백 반영 과정이 다소 길며 실행 시간이 오래 걸리기 때문입니다. 하지만, 최근 사용자의 환경이 다양해지고 애플리케이션의 복잡성과 종속성이 다양해지는 만큼 E2E 테스트가 중요한 것은 분명합니다.

종단 간 테스트의 범위 정의

가장 먼저, 테스트 커버리지를 설정합니다. 완벽한 애플리케이션을 만들기위해 100%로 설정할 수도 있지만, 테스트의 범위가 넓어질 수록  비용 초과, 배포의 지연, 테스트 코드의 복잡성 증가이 상대적으로 증가하기 때문에 비효율적인 테스트로 변질될 수 있습니다. 따라서, 모든 workflow를 커버하는 것이 꼭 좋은 테스트 방법이라고는 할 수 없습니다. 

합리적인 테스트 범위를 설정하기 위해서는 애플리케이션이 제공하는 경험 중에서 비즈니스에 가장 큰 가치를 제공하는 것, 경험의 빈도가 많고 적은 것을 분류 해야합니다. 비교적 접근 비중이 낮고 애플리케이션을 통해 제공하려는 핵심 가치와는 거리가 먼 것에 대해서는 테스트 범위에서 제외하는 것이 좋습니다.그러면 테스트 적용 범위와 유지 관리 가능성 사이에서 좋은 균형을 유지할 수 있습니다.

일반적으로 아래의 워크 플로가 포함될 수 있습니다.
- 계정 생성 및 로그인
- 장바구니 항목 추가 및 결제
- 추천 상품 목록
- 배송 조회 및 취소/반품/교환 신청
...

의미있는 테스트 설정

의미있는 테스트를 정의하는 것은 팀원들이 테스트 코드를 쉽게 이해할 수 있게 해주며, 도구의 효율성을 높여 결과적으로 팀의 평균 수리시간(MTTR)을 줄여줄 수 있습니다. 이에 대해 Datadog는 아래와 같은 모범사례들을 제시하고 있습니다.

 

- 집중 테스트를 위한 워크 플로를 세분화

워크 플로를 더 작은 범위로 분리하여 유지 관리 지점을 줄이며, 문제를 빠르게 해결할 수 있도록 합니다. 이는 우리가 일반적으로 프로그래밍 하듯 각각의 워크 플로는 하나의 작은 기능들로 분류해야함을 의미합니다. 예를 들어, 계정 생성이라는 워크 플로에 전혀 무관한 결제에 대한 내용이 있으면 추후 테스트 실패시, 에러의 원인을 찾는데 더 많은 시간이 소요됩니다. 따라서, 테스트 케이스의 모든 단일 단계는 워크 플로를 밀접하게 따르도록 하고, 관련 없는 단계의 수를 최적화하고하는 것은 애플리케이션 테스트에 더 많은 가치를 제공할 수 있습니다.

워크 플로의 범위 내에서 단계 중복을 최소화하기 위해 새로운 테스트를 생성할 때, DRY(Don't Repeat Yourself)원칙을 준수해야합니다. 이는 재사용 가능한 하위 테스트를 만듦으로써, 다양한 워크 플로에 포함시킬 수 있고, 단일 테스트는 다양한 하위 테스트로 구성될 수 있습니다.

 

- 예상되는 동작을 확인하기 위해 의미있는 어설션 생성

테스트중 진행될 각각의 워크 플로에 대한 명확한 설명을 추가합니다. 이는 적절한 DOM 요소와 워크 플로를 실행하기 위한 명령, 그에 대한 애플리케이션의 예상 동작을 어설션으로 정의해야함을 뜻합니다. 테스트를 진행하는 워크 플로에 대한 명확한 설명이 없으면 테스트가 수 많은 불필요한 단계, 종속성 및 어설션으로 인해 쉽게 복잡해질 수 있습니다. 이는 결국 테스트 취약성과 실행 시간을 증가시켜 문제를 적시에 해결하고 대응하기 어렵게 만듭니다.

 

- 통제할 수 없는 요인에 자동으로 적응하는 테스트 구축

애플리케이션의 로드 시간이 지연되면 종종 타임 아웃으로 실패하곤 합니다. 로드 시간은 예상치 못한 네트워크 장애 또는 애플리케이션 서버에 과부하를 일으키는 비정상적인 트래픽 급증과 같은 요인의 영향을 받을 수 있습니다. 이러한 불일치로 인해 테스트에서 잘못된 결과로 인해 문제를 판별하고 알리는 능력이 저하될 수 있습니다. 그리고 이러한 유형의 실패를 해결하기 위한 일반적인 방법인 테스트 대기 단계를 하드 코딩하면 테스트를 더욱 신뢰할 수 없게 만들 수 있습니다.

테스트를 실행하기 전에 애플리케이션이 상호 작용할 준비가 되도록 합니다. 이렇게 하면 테스트는 애플리케이션이 로드된 이후에 테스트를 실행하거나 재시도합니다. 예를 들면, 테스트를 완료하기 전에 애플리케이션이 상호 작용할 준비가 되었는지 확인하기 위해 정기적으로 DOM 요소 검색하거나 버튼 요소를 클릭합니다. 테스트에 이러한 유형의 단계를 추가하면 네트워크 오류로 인해 자주 발생하는 실패를 최소화하는데 도움이 될 수 있습니다.

 

- 멱등성 테스트로 애플리케이션 상태 유지

테스트가 테스트 실행 전후의 애플리케이션 및 테스트 환경 상태를 동일하게 유지해야합니다. 즉, 장바구니에 여러 항목을 추가하는데 중점을 둔 테스트는 나중에 장바구니에서 해당 항목을 삭제하는 매커니즘이 있어야합니다.