E2E 테스트 운영 효율 높이기: 자동 세팅과 Notion 리포팅 도입기

E2E 테스트 운영 과정에서 겪은 불편과 개선 실험

E2E 테스트는 처음 도입할 때도 쉽지 않지만, 시간이 지날수록 유지 관리가 더 어려워집니다.
UI가 조금만 변경되어도 테스트가 쉽게 깨지고, 실패한 테스트를 분석하는 데도 적지 않은 시간이 소요됩니다.
특히 실패 원인이 로그, 스크린샷, 실행 환경 등에 흩어져 있으면 테스트 이후의 피로도가 더 커집니다.

이번에는 완벽한 해답을 찾기보다는, 직접 겪었던 불편을 줄여보는 실험에 초점을 맞추었습니다.
E2E 테스트를 운영하면서 반복적으로 느꼈던 불편은 다음과 같았습니다.

• 테스트 실행마다 테스트 세팅 시간이 길었습니다.
• 실패 시 어떤 케이스가, 어떤 이유로 실패했는지 정보가 흩어져 있었습니다.
• 테스트 결과 공유가 결국 수작업에 의존하고 있었습니다
  (스크린샷 캡처, 로그 복사, 문서나 메신저에 공유)

이를 개선하기 위해 다음 두 가지를 시도하였습니다.

• 캠페인을 자동으로 세팅
• 테스트 실행 결과를 Notion 데이터베이스에 자동 기록

한 줄로 정리하면 다음과 같습니다.

테스트 작성 → 실행 → Pass/Fail + 에러 + 스크린샷/트레이스가 Notion에 누적 기록되도록 구성

---

0) 배경: E2E 도입 초기 목표

E2E 테스트를 처음 도입할 당시에는 더 큰 목표를 염두에 두고 있었습니다.
초기 구상은 다음과 같은 흐름이었습니다.

• Notion에 테스트 케이스를 먼저 작성
• 해당 케이스를 MCP가 읽어 테스트 실행
• 실행 결과를 다시 Notion에 자동 기록

그러나 진행 과정에서 몇 가지 고민이 생겼습니다.

• 자연어로 작성된 테스트 케이스를 그대로 실행하는 방식이 실무에 적합한지
• UI, 데이터, 타이밍 변수에 따라 결과가 쉽게 흔들리지 않는지
• 현재 환경에서 안정적으로 운영할 수 있는 수준인지

결과적으로 장기적인 목표는 유지하되,
당장 적용 가능한 범위부터 시도하기로 결정하였습니다.

이번 실험에서는 테스트 코드를 직접 작성하고, 실행 결과를 Notion에 자동 기록하는 방식에 집중하였습니다.

---

1) As-is / To-be

As-is

• 사람이 모든 테스트 케이스를 직접 정리
• 캠페인 생성, 설정, 발송을 수동으로 반복
• 발송 결과를 화면에서 하나씩 확인

To-be

• 생성, 설정, 저장을 테스트 코드로 자동 실행
• 사람은 사전에 정의된 결과 케이스만 확인
• 정상 동작 여부를 빠르게 판단

---

2) 문제 인식: 왜 이 실험을 진행했는가

로직 변경이나 리팩토링이 발생할 때마다
캠페인 전체 발송 테스트를 반복해야 했습니다.

메시지 캠페인의 특성상 테스트 범위가 넓어
QA에 소요되는 시간이 점점 부담으로 작용했습니다.

이에 따라 QA 과정에서 가장 많은 시간이 소요되던 영역부터
E2E 테스트를 적용해보는 것을 목표로 삼았습니다.

---

3) 역할 분리: E2E 구성 요소 나누기

E2E 테스트 규모가 커질수록 스펙 파일이 복잡해졌습니다.
이를 개선하기 위해 역할을 다음과 같이 나누어 구성하였습니다.

• 시나리오(스펙)
  → 어떤 기능을 검증하는지에만 집중
• UI 조작(헬퍼)
  → 클릭, 입력, 업로드, 토글 등의 반복 동작 분리
• 인증(자동 로그인)
  → 테스트 시작 시점에 인증된 상태로 진입
• 리포팅(Notion)
  → 테스트 종료 후 결과 자동 기록

이와 같이 구성하니 UI 변경 시 수정 범위를 파악하기가 비교적 수월해졌습니다.

---

4) 자동 로그인: 테스트 본문부터 시작하기

• 게이트웨이 방식으로 인증을 선행 처리
• 스펙 코드에서는 로그인 로직을 최대한 제거

그 결과 스펙 코드에서는 로그인 관련 내용이 사라지고,
캠페인 생성, 저장, 검증과 같은 핵심 로직에 더 집중할 수 있었습니다.

---

5) 스펙은 얇게, 헬퍼는 두껍게

UI 단계가 많은 기능을 스펙에 그대로 작성할 경우 유지보수가 어려워졌습니다.

이에 따라 다음과 같은 UI 조작을 헬퍼 함수로 분리하였습니다.

• 패널 열림 상태 확인 및 제어
• 이미지 업로드 및 크롭 비율 선택
• 제목 및 본문 입력
• 버튼 추가 및 타입 설정
• 더보기 토글 및 URL 입력

스펙에서는 최종적으로 의도만 드러나는 형태를 목표로 하였습니다.

await setCarouselImage(page, 0, { ratio: '1:1' }); 
await setCarouselTitle(page, 0, '캐러셀 제목'); 
await setCarouselContent(page, 0, '캐러셀 본문'); 
await setButtonType(page, { index: 0, type: 'link' }); 
await setSeeMore(page, { enabled: true, url: 'https://example.com' }); 
await saveCampaign(page);

 

이 방식이 완벽하다고 보기는 어렵지만,
UI 변경 시 수정 지점을 빠르게 파악할 수 있다는 점은 체감할 수 있었습니다.

---

6) Notion 리포팅: 테스트 결과를 남기기

테스트를 실행하더라도 결과가 흩어져 있으면
결국 수작업으로 공유해야 하는 상황이 발생합니다.

이를 개선하기 위해 테스트 종료 시
Notion 데이터베이스에 결과를 자동 기록하도록 구성하였습니다.

기대했던 효과는 다음과 같습니다.

• 어떤 케이스가 자주 실패하는지 한눈에 파악
• 실패 시 에러, 스크린샷, 트레이스를 한 곳에서 확인
• 테스트 실행자와 무관하게 기록 유지

기록 흐름은 다음과 같습니다.

1. 데이터베이스를 이름으로 조회
2. 테스트명 기준으로 케이스 페이지 탐색
3. 없으면 생성, 있으면 업데이트
4. 실행 로그는 본문에 누적 기록

Notion에는 두 가지 레벨로 정보를 남겼습니다.

• 속성: 상태(Pass/Fail), 마지막 실행일, 에러 메시지
• 본문: 실행 시간, 결과 로그, 스크린샷/트레이스 정보

이후 테스트 결과 공유에 드는 부담이 줄어드는 효과를 느낄 수 있었습니다.

---

7) 테스트 실행

npx playwright test
npx playwright test --ui

---

8) 운영하며 느낀 점

좋았던 점

• 로그인 준비 단계가 사라져 스펙이 단순해졌습니다.
• 반복 UI 조작을 헬퍼로 분리해 변경 대응이 쉬워졌습니다.
• 결과가 Notion에 누적되어 공유와 회고가 편해졌습니다.
• CRUD 중심 기능 검증에는 적합한 구조였습니다.

아쉬웠던 점 및 주의 사항

• 스크린샷 및 트레이스 첨부는 환경에 따라 제약이 있을 수 있습니다.
• 테스트 케이스 이름(title) 규칙은 초기에 정의해두는 것이 편리합니다.
• 토큰, 시크릿, DB ID 등 민감 정보는 절대 노출되지 않도록 주의해야 합니다.
• 자연어 기반 실행은 매력적이지만, 정형화가 선행되어야 안정적으로 운영할 수 있습니다.

---

9) 공개 글 기준 보안 체크리스트

• 토큰, 시크릿, DB ID는 로그, 이미지, 본문 어디에도 남기지 않습니다.
• 민감 정보는 환경 변수로 주입하고 글에는 방식만 설명합니다.
• Notion Integration은 테스트용 데이터베이스에 최소 권한으로 연결합니다.

---

마무리

이 방식이 정답이라고 말하기는 어렵습니다.
다만 개인적으로는 테스트 실행 이후의 부담을 줄이는 데에는 분명한 효과가 있었습니다.

자동 로그인을 통해 준비 단계를 줄이고,
Notion 자동 기록을 통해 결과 공유 과정을 단순화하면서
“테스트 실행 → 결과 공유” 흐름을 조금 더 가볍게 만들 수 있었습니다.

추후에는 처음 목표였던 것처럼
Notion에 테스트 케이스를 작성해두고 해당 케이스를 기반으로 테스트를 실행하는 방식도 다시 시도해보고자 합니다.
다만 그때는 자연어 그대로가 아닌,
케이스 포맷, 데이터, 검증 기준을 보다 정형화한 이후 접근할 계획입니다.