누구나 만드는 테스트 자동화

시작하기에 앞서

제가 재직하는 회사에서는 다양한 프로그래밍 언어와 기술이 혼합되어 있으며, 복잡한 시스템 아키텍처로 구성된 서비스를 운영하고 있습니다. 이러한 구조적 특성 때문에 레거시 환경에서 발생하는 코드 오류는 MSA(Microservices Architecture) 환경에서의 부분적 오류보다 훨씬 더 심각하게 고객에게 직접적인 오류 화면으로 노출될 수 있습니다. 이는 곧 서비스 장애로 이어지며, 장애가 발생한 시간만큼 고객사의 매출 손실로 직결됩니다.

따라서 우리는 고객사와 최종 사용자가 문제를 인지하기 전에, 단 1분, 1초라도 더 빠르게 장애 상황을 탐지하고 즉각 대응할 수 있어야 합니다. 이를 가능하게 하는 핵심 수단이 바로 QA 자동화이며, 이를 위해서는 실제 서비스 사용 환경을 충실히 반영한 다양한 테스트 케이스의 작성이 반드시 필요합니다.

그러나 QA 자동화를 위한 테스트 코드 작성은 결코 간단하지 않습니다. 테스트 과정은 웹 브라우저의 DOM 요소를 찾아내고, 이를 조작하며, 사용자의 행동을 코드로 시뮬레이션해야 하기 때문에 개발 지식이 없는 사람에게는 매우 높은 진입 장벽으로 작용합니다.

최근에는 AI 기술의 발전으로 인해 QA 자동화의 진입 장벽이 다소 낮아지고 있습니다. 예를 들어, 화면의 스크린샷을 AI에게 전달하며 “이 버튼을 클릭하는 테스트 케이스를 만들어줘”라고 요청하면, 생각보다 높은 수준의 테스트 코드를 자동으로 생성해 주는 것이 가능해졌습니다. 하지만 여전히 그 결과물은 결국 코드입니다. 코드를 주기적으로 실행하고 관리하며, 문제 발생 시 유지보수하는 과정은 개발자가 아닌 사용자에게는 여전히 큰 부담이 될 수밖에 없습니다.

이러한 한계를 해결하기 위해 노코드 기반 QA 자동화 툴을 개발했습니다. 여기에 AI 기술을 결합하여, 비개발자도 손쉽게 테스트 케이스를 만들고 실행하며 관리할 수 있는 환경을 제공하고자 했습니다.

이 문서는 해당 툴에 포함된 다양한 기능과 활용 방법을 정리하여, 누구나 쉽게 QA 자동화를 이해하고 적용할 수 있도록 돕기 위해 작성되었습니다. 사용 중 오류가 발견되거나 개선이 필요한 부분이 있다면 언제든 제보해 주시기 바랍니다.

크롬 확장 프로그램으로 만든 이유

현실 환경 그대로 캡처: SSR/CSR을 오가는 하이브리드 화면에서 로컬 스토리지·쿠키·세션 상태를 함께 잡아야 했습니다. 크롬 익스텐션이 DOM과 네트워크 이벤트를 직접 수집할 수 있어 가장 자연스러운 선택이었습니다.
레거시·MSA 혼합 서비스 대응: 페이지 리로드와 SPA 라우팅을 모두 감지해 분리된 스텝으로 기록해야 했는데, 확장 프로그램이 이를 안정적으로 추적했습니다.
비개발자 접근성: 사용자는 확장 프로그램을 켜고 “Record”만 누르면 됩니다. 프레임워크 지식 없이도 행동 기반 테스트가 자동 생성됩니다.

Chrome Recorder 기반 커스터마이징

기본 Recorder 엔진 활용: 크롬 기본 Recorder가 click/input/navigation을 단계별로 남겨주기에, 이를 파싱해 우리 DSL로 변환했습니다.
추가 훅: 파일 업로드, iframe/shadow DOM, fetch/XHR 응답 코드, 스크린샷 캡처 등을 추가로 수집해 레거시 화면에서도 깨지는 지점을 보완했습니다.
노이즈 최소화: 불필요한 이동·중복 클릭을 dedupe/merge 하여 짧고 읽기 쉬운 테스트를 남기고, 요소 선택자는 data-testid가 우선되도록 후처리했습니다.
AI 연계: 녹화된 스텝을 요약해 “추가로 검증할 assertion을 제안해줘” 같은 프롬프트를 자동 생성, 필요 시 검증 구문을 추천받습니다.

테스트 코드 작성 방법 (1. 자동 생성)

크롬 확장 프로그램 설치

크롬 확장 프로그램을 설치해서 필요한 환경을 구성할 수 있습니다. (현재 블로그에는 공개하지 않았습니다)

내부 배포용 CRX 설치 후 Fly QA 탭이 생기며, 여기서 Recorder를 실행합니다.
회사 내부/스테이징 도메인만 접근하도록 권한을 제한해 보안 리스크를 줄였습니다.

자동화 Recoder 열기

개발자 모드 열기

Fly QA 탭으로 이동

Start Recording 버튼 클릭

원하는 테스트 시나리오 생성

브라우저에서 행동을 모두 추적하여 자동으로 기록합니다.

테스트 시나리오 행동이 끝나면 Stop Recording 을 누르고 Save to Fly QA 클릭

정상적으로 Fly QA 로 이동되었다면 Save 누르고 Test Run 을 통해 정상 실행되는지 확인

(아래 step 목록에서 필요하지 않은 스텝은 삭제해도 됩니다)

Chrome Recorder를 쓸 때의 팁

최소 스텝: 불필요한 스크롤·중복 클릭을 줄이면 녹화 후 정리 시간이 단축됩니다.
고유 셀렉터: id나 data-testid가 없는 요소는 class 변경으로 깨지기 쉽습니다. 가능하면 테스트 대상에 data-testid를 심어두세요.
입력 지연: 자동완성/디바운스 입력 필드는 타이핑 후 약간의 대기 시간을 두면 재생 안정성이 높습니다.
파일 업로드·팝업: OS 파일 선택기 취소나 새 창 전환은 한 번 더 재생해보며 확인하세요. 확장 훅이 잡지만 환경별 예외가 있을 수 있습니다.

테스트 코드 작성 방법 (2. 수동 생성)

시나리오 생성 클릭

각 항목에 알맞게 데이터 입력 후 test case 작성

저장 후 테스트 실행 확인

다른 테스트 블럭 불러오기

시나리오, 블럭은 차이가 있습니다.

시나리오는 테스트 케이스 자체를 말하며, 블럭은 다른 시나리오에서 불러다 실행할 수 있습니다.
예를들어 로그인 과 같은 처리는 매우 자주 사용되는 케이스라 block 으로 로그인 과정을 생성해둡니다.

그리고 다른 시나리오에서 테스트케이스가 실행되지 전에 앞단에 먼저 로그인 처리가 될 수 있도록 로그인 블럭을 불러와 추가해줍니다.

테스트 실행 결과 슬랙 알림 받기

메뉴에서 Setting 으로 이동

슬랙 웹훅 경로를 설정하고 저장을 눌러줍니다.
성공/실패에 대한 내용은 고정메세지이므로 추가로 메시지를 넣고싶다면 Custom Message 자리에 넣어줍니다.

해당 테스트의 담당자 태그 등

테스트 배치 실행하기

모두 작성된 테스트 케이스는 일정 주기로 자동으로 실행할 수 있습니다.
조건 - status 가 publish (배포) 상태여야 합니다.

자동 실행 스케줄을 원하는 시간대로 설정합니다.

마무리하며

서비스 장애를 선제적으로 막으려면 테스트 자동화가 필수라는 점을 다시 확인했습니다. 익스텐션 + Chrome Recorder 조합 덕분에 비개발자도 시나리오를 빠르게 만들 수 있다는 환경을 만들었다는것에 의미가 있었어요.
레거시·MSA가 섞인 환경에서 DOM/스토리지/네트워크를 한꺼번에 잡는 것이 관건이었고, 브라우저 안에서 동작하는 모든것을 기록기록하는것이 가장 어려웠어요. recoder를 사용하면 되지만 세세한것에 대해서는 정확히 추적이 안되더라구요.
아쉬운 점이 있다면 재생 엔진이 Playwright 기반이라 체감 속도가 아주 빠르진 않습니다. 물론 배치성으로 동작한다는 점에서 느리다고 말할 수준은 아니겠지만, 누군가는 티켓팅에도 사용할 수 있는 자동화 라는 환경을 생각해보면 속도면에서 살짝 아쉬운건 사실이었습니다.
다음 목표:
- headless-friendly 환경으로 전환하거나, 크로미움 커스텀 빌드로 초기 부팅을 더 가볍게 만드는 실험
- 프런트에 data-testid 일괄 주입 자동화로 셀렉터 안정성 확보
- AI가 제안한 assertion을 바로 삽입하는 one-click 워크플로우 추가해, 작성-검증 사이클을 더 줄이기