"과연 사용자의 모든 여정이 순탄할까?" End-to-End(E2E) 테스트의 모든 것

통합 테스트:
- 초점: ‘모듈과 모듈 사이’의 데이터 통신.
- 비유: 자동차의 ‘엔진과 변속기’가 잘 맞물려 돌아가는지 확인하는 것.
시스템 테스트:
- 초점: ‘하나의 완성된 시스템’이 요구사항 명세를 모두 만족하는지.
- 비유: ‘자동차 한 대’가 모든 기능(전조등, 와이퍼, 에어컨)을 갖추었는지 확인하는 것.
E2E 테스트:
- 초점: ‘여러 시스템을 넘나드는’ 실제 사용자의 전체 여정.
- 비유: ‘운전자가 내비게이션(외부 시스템)을 켜고, 차를 운전하여, 주유소(외부 시스템)에서 주유하고, 목적지에 도착하기까지’의 전 과정을 확인하는 것.

개별 시스템은 각자 완벽하게 동작하더라도, 이들이 함께 연결되었을 때 예상치 못한 문제가 발생할 수 있기 때문입니다.

실제 환경에 대한 자신감:
- ‘E2E 테스트’는 실제 운영 환경과 가장 유사한 조건에서 수행됩니다.
- 이 테스트를 통과했다는 것은, 실제 사용자가 겪게 될 문제의 상당수를 예방했다는 강력한 증거가 됩니다.
복잡한 상호작용 검증:
- 현대 서비스는 우리 회사 서버뿐만 아니라, 외부 결제 시스템, 소셜 로그인 API, 지도 서비스 등 수많은 외부 시스템과 실시간으로 연동됩니다.
- ‘E2E 테스트’는 이러한 복잡한 데이터 흐름 속에서 발생할 수 있는 문제를 발견하는 거의 유일한 방법입니다.

‘느리고, 비싸고, 불안정하다’는 점입니다.

이는 ‘테스트 피라미드’에서 E2E 테스트가 왜 맨 꼭대기에 위치해야 하는지에 대한 이유이기도 합니다.

느린 실행 속도:
- 실제 UI를 통해 모든 과정을 시뮬레이션하므로, 단위 테스트나 API 테스트에 비해 실행 속도가 수백, 수천 배 느립니다.
높은 유지보수 비용:
- UI 디자인이 조금만 바뀌거나, 연동된 외부 시스템 중 하나라도 문제가 생기면 ‘E2E 테스트’는 쉽게 실패합니다.
불안정성(Flaky):
- 네트워크 지연, 예기치 않은 팝업 등 테스트 환경의 미세한 변화에도 영향을 받아, 어떨 땐 성공하고 어떨 땐 실패하는 ‘플레이키 테스트’가 되기 쉽습니다.

‘최소한으로, 하지만 가장 중요하게’가 핵심 전략입니다.

1. 핵심 시나리오에 집중:
- 모든 기능을 ‘E2E 테스트’로 만들려는 욕심을 버려야 합니다.
- ‘회원가입 후 첫 상품 구매’, ‘가장 많이 팔리는 상품의 결제 과정’과 같이, 실패했을 때 비즈니스에 가장 치명적인 핵심 사용자 여정(Critical User Journeys)에 대해서만 ‘E2E 테스트’를 작성합니다.
2. UI보다 API를 우선 활용:
- 테스트의 모든 단계를 UI로 조작할 필요는 없습니다.
- 예를 들어, ‘상품 구매’를 테스트하기 위한 사전 조건인 ‘로그인’은, UI를 거치지 않고 로그인 API를 직접 호출하여 처리하면 테스트 시간을 크게 단축하고 안정성을 높일 수 있습니다.
3. 독립적인 테스트 환경과 데이터:
- ‘E2E 테스트’는 여러 시스템에 걸쳐 데이터를 생성하고 변경하므로, 다른 테스트에 영향을 받지 않는 완전히 독립된 환경과 데이터로 수행되어야 합니다.

‘E2E 테스트’는 비용이 많이 들고 관리하기 어려운, 양날의 검과 같습니다.

하지만 사용자의 관점에서 서비스의 전체 흐름을 완벽하게 보장하는 가장 확실한 방법이기도 합니다.

현명한 QA는 ‘E2E 테스트’를 남용하지 않습니다.

대신, 테스트 피라미드 전략에 따라 가장 중요하고 위험한 시나리오를 선별하고, API 테스트 등 다른 기법과 현명하게 조합하여 효율적으로 운영합니다.

Playwright – End-to-end testing: https://playwright.dev/docs/intro
Microsoft – What is end-to-end testing?: https://learn.microsoft.com/en-us/azure/devops/test/what-is-end-to-end-testing

“과연 사용자의 모든 여정이 순탄할까?” End-to-End(E2E) 테스트의 모든 것