Intro
프로덕트를 안정적으로 운영하기 위해서는 테스트 방법을 잘 설계하는 것이 필수이다. 사내에는 Browser Stack을 활용한 E2E 테스트가 존재하였고 master 브랜치의 CD Flow에 해당 테스트가 포함되어 있었다.
그러나 운영했던 E2E 테스트는 실제 우리 프로덕트에서 발생하는 에러를 사전에 방지하는 경우가 거의 없었으며, 때때로 실제 기능들이 정상동작하는 경우에도 에러를 발생하여 개발자를 혼란에 빠뜨렸다.
이 문제를 해결하기 위해서 찾던 중 구글 테스팅 블로그에 올라온 글이 있어 참고하였고, 이 글의 내용을 참고하여 팀 내 테스트 방법을 어떻게 개선했는지 공유하고자 한다.
테스트 방법
테스트 방법에는 크게 3가지로 나눌 수 있다.
- E2E 테스트 : 프로덕트를 사용자 관점에서 테스트하는 방법이다. DB 및 여러 인프라가 갖추어진 상태로 사용자 관점에서 테스트한다.
- Integration 테스트 : 여러 모듈이 합쳐진 하나의 기능을 테스트하는 절차이다.
- Unit 테스트 : 소스코드의 특정 모듈(ex. 함수) 단위가 의도된 대로 동작하는지 검증하는 절차이다.
E2E 테스트의 문제
이 중 E2E 테스트는 시스템의 모든 동작을 검증할 수 있고, 유닛 테스트로 검증이 불가능한 사용자 관점의 테스트까지 가능하지만, 다음과 같은 심각한 문제점이 있다.
- 제품이 빌드되고 배포되고 최종적으로 테스트가 실행되기까지의 과정을 기다려야 한다. (프로젝트의 규모가 크다면 테스트 실행 시간은 기하급수적으로 늘어난다. )
- 네트워크 딜레이와 같은 랜덤 변수로 생기는 실패 때문에 테스트 신뢰도가 Unit Test, Integration Test에 비해 낮다.
- 실패 격리성이 떨어진다.
작은 규모의 스타트업의 경우 QA 엔지니어와 같은 검증 및 테스트 인력이 부족한 경우가 많기 때문에 E2E 테스트를 작성 및 유지보수하는 것이 현실적으로 어렵다.
테스트 피라미드
이와 관련되어 구글 테스트 자동화 컨퍼런스에서 나온 테스트 피라미드는 우리가 어떻게 테스트 비용을 줄이고 테스트를 안정적으로 구축할 수 있을지 기준을 제시한다.
테스트 피라미드에 따르면 테스트의 대부분은 Unit 테스트로 구축되어야 하며, 이 피라미드 위로 올라 갈수록 테스트 범위는 넓어지되, 테스트 개수는 작아져야 한다. 올바른 가정으로 구글은 70/20/10 분할을 제안하였다.
점검 및 개선 결정
테스트 피라미드를 참고하여 우리 상황을 점검하였다.
-
개발팀 규모가 크지 않고 QA를 전담할 인력이 없다.
-
백엔드 및 ML의 코드 coverage는 85% 이상이며, 모델의 도메인 로직의 Unit 테스트부터 API 단 Integration 테스트가 잘 구축되어 있다.
-
프론트엔드 코드 coverage는 50% 이상이며, 아직 통합 테스트 부분이 미진하다.
-
현재 개발된 E2E 테스트는 배포 전 버그나 에러를 탐지하는 데 도움을 주지 못하고 있다.
-
개발팀이 E2E 테스트를 유지 보수하는 데 시간을 쓰는 것보다 다른 feature 혹은 코드를 근본적으로 리팩토링 하는 데 시간을 쓰는 것이 더 중요하다.
두 가지 선택지가 나왔는데 E2E 테스트를 획기적으로 개선하는 방향과 E2E 테스트를 없애는 방향이 나왔다. 우리는 여러 상황을 고려하여, E2E 테스트를 제거하기로 결정하였다.
그 결정의 주요 근거는 다음과 같다.
- E2E가 우리 프로덕트의 버그를 잡는데 도움이 되고 있지 않다. E2E를 유지보수할 시간에 FE 리팩토링 수행, Unit 및 Integration 테스트 코드를 작성하는 것이 더 중요하다.
- E2E의 랜덤 실패를 매번 확인하는 것에 대한 Cost가 발생하고 있다.
다만 E2E 테스트를 무작정 제거하는 것이 아니고 E2E에서 중요하게 검증하고 있는 Flow를 Integration 테스트를 작성하여 대체하였다.
그리고 향후 정말 중요하게 검증해야 할 유저 플로우가 생기고, 팀 규모가 더 커지면 E2E 테스트를 도입하기로 결정하였다.
결과
이 결정 이후 개발자들이 주요한 기술 부채들에 집중하게 되었고, 리팩토링된 코드에 Unit 테스트 및 Integration 테스트를 더 많이 작성하게 되어서 버그를 예방하는 효과를 보게 되었다. 그리고 실제 프로덕션에서 발생하는 버그도 30% 이상 감소하였다.
또 내부적으로 테스트에 대한 자신감이 생겨서 배포 주기도 더 짧게 가져갈 수 있었다
복잡도가 높은 시스템이거나 팀 내 QA 엔지니어를 운영할 만큼 규모가 커진다면 E2E 테스트를 작성하는 것을 고려해야겠지만, 아직 우리 팀은 E2E를 도입하고 운영하기보다는 기술 부채를 해결하고 테스트 피라미드의 밑바닥을 다지는 것이 더 올바르다는 판단을 하였다.
앞으로 팀이 더 커지고, 시스템의 복잡도가 높아져서 E2E 테스트 도입을 고민할 날을 기대한다.
