현대의 테스트 자동화 스택은 더 이상 Playwright 대 Selenium의 문제가 아닙니다

테스트 자동화 스택을 선택한다는 것이 주로 Selenium과 그해 사람들이 열광하는 새로운 도구 사이에서 무엇을 고를지를 의미하던 시절이 있었습니다.

이제 그런 논의는 너무 작게 느껴집니다.

현대의 테스트 자동화는 단순히 브라우저가 버튼을 클릭할 수 있는지에 관한 것이 아닙니다.

그것은 제품이 변경된 후에도 팀이 테스트를 계속 유지할 수 있는지, CI (지속적 통합) 실패가 신뢰할 수 있는지, 도구가 로그인, 이메일, SMS, API, 테스트 데이터, 역할 (roles), 세션, 프리뷰 환경 (preview environments), 모바일 레이아웃, 그리고 멋진 데모를 유지보수 작업으로 바꿔버리는 모든 지루한 요소들을 처리할 수 있는지에 관한 것입니다.

이것이 제가 테스트 자동화를 '소유권 (ownership)'의 관점에서 생각하는 것을 좋아하는 이유입니다.

단순히 다음과 같은 질문이 아니라:

이 도구가 테스트를 생성할 수 있는가?

다음과 같은 질문입니다:

이 팀이 6개월 후에도 이 테스트 스위트 (suite)를 여전히 신뢰하고, 디버깅하고, 유지보수할 수 있는가?

저는 Test Automation Tools의 가이드들을 살펴보고 이를 더 실용적인 독서 경로로 그룹화했습니다.

비즈니스 케이스(business case)부터 시작하세요

도구를 비교하기 전에, 자동화가 무엇을 절약하기 위한 것인지 이해하는 것이 도움이 됩니다.

많은 팀이 ROI (투자 대비 수익)를 모호한 용어로 이야기합니다. "회귀 테스트 (regression)를 자동화하고 싶습니다"라는 말은 좋게 들리지만, 리더십은 보통 더 구체적인 답변을 필요로 합니다:

수동 테스트 시간이 얼마나 절약되는가?
릴리스 지연을 얼마나 방지하고 있는가?
결함 (defects)을 얼마나 더 일찍 발견하고 있는가?
자동화 자체를 유지보수하는 데 얼마나 많은 시간이 낭비되고 있는가?

시작하기 좋은 곳은 Test Automation ROI Calculator입니다.

ROI 관점의 유용한 점은 숨겨진 비용을 계산하도록 강제한다는 것입니다. 시니어 엔지니어가 매달 일주일 동안 셀렉터 (selectors), 테스트 데이터, CI 설정, 보고서, 그리고 플래키 테스트 (flaky failures)를 수정하는 데 시간을 쓴다면, 무료 오픈 소스 프레임워크는 공짜가 아닙니다.

이는 Flaky Test Cost Calculator와 직접적으로 연결됩니다. 왜냐하면 플래키 테스트 (flaky tests)는 과소평가하기 가장 쉬운 자동화 비용 중 하나이기 때문입니다.

플래키 테스트 (flaky test)는 단순히 재실행에 필요한 시간을 낭비하는 것에 그치지 않습니다. CI (지속적 통합)가 실패(red)할 때마다 다음과 같은 결정 사항을 만들어냅니다:

이것이 실제 버그인가?
배포를 차단해야 하는가?
누가 이를 디버깅할 수 있는 충분한 컨텍스트 (context)를 가지고 있는가?
이번에는 무시해도 되는가?
격리 (quarantine)해야 하는가?

이런 일이 충분히 자주 발생하면, 사람들은 파이프라인 (pipeline)을 신뢰하지 않게 됩니다.

그리고 사람들이 파이프라인을 신뢰하지 않게 되면, 자동화는 보여주기식 연극 (theater)이 되어버립니다.

도구 선택은 사실 유지보수 선택입니다

많은 도구 비교 글들은 기능 (features)에 집중합니다.

그것도 괜찮지만, 더 나은 질문은 보통 유지보수 (maintenance)에 관한 것입니다.

The Real Cost of Maintaining Locator-Heavy UI Tests라는 기사는 UI 자동화에서 가장 큰 장기적 문제 중 하나인 로케이터 (locators)에 대해 다룹니다.

테스트 스위트 (suite)가 새로 구축되었을 때는 셀렉터 (selectors)가 사소한 디테일처럼 보입니다. 그러다 프론트엔드 (frontend)가 변경됩니다. 버튼이 이동합니다. 레이블 (label)이 바뀝니다. CSS 클래스 (class)가 재생성됩니다. 컴포넌트 라이브러리 (component library) 업데이트로 인해 DOM이 변경됩니다. 갑자기 테스트 스위트는 지속적인 관리가 필요한 두 번째 제품이 되어버립니다.

이것이 바로 이러한 비교 글들이 유용한 이유입니다:

이것은 단순히 어떤 방식이 항상 더 낫다고 선언하려는 것이 아닙니다.

Playwright, Cypress, Selenium과 같은 코드 우선 (Code-first) 도구들은 팀이 스택을 유지 관리할 수 있는 기술과 규율을 갖추고 있을 때 매우 훌륭할 수 있습니다. 하지만 이는 또한 팀이 프레임워크 주변의 모든 것, 즉 피스처 (fixtures), 헬퍼 (helpers), 셀렉터 (selectors), 리포트 (reports), 환경 (environments), 재시도 (retries), 데이터 설정 (data setup), CI 동작 (CI behavior), 그리고 디버깅 워크플로우 (debugging workflow)를 직접 책임져야 함을 의미합니다.

관리형 플랫폼이나 로우코드 (low-code) 플랫폼은 더 넓은 범위의 테스트 소유권 (test ownership)을 목표로 할 때 더 타당할 수 있습니다. 특히 QA, 제품 (product), 또는 지원 (support) 팀이 모든 변경 사항을 개발자 티켓으로 전환하지 않고도 흐름을 검토하고 업데이트해야 하는 경우 더욱 그렇습니다.

노코드 (No-code) 및 로우코드 (low-code) 테스트는 주로 누가 테스트를 소유하느냐의 문제입니다

노코드 (No-code) 테스트는 때때로 너무 성급하게 무시되곤 합니다.

노코드의 취약한 버전은 아무도 신뢰하지 않는 취약한 (brittle) 테스트를 생성하는 레코드 앤 플레이백 (record-and-playback) 방식입니다.

하지만 유용한 버전은 다릅니다. 이는 팀에게 수정 가능한 테스트 모델 (test model)을 제공하고, 테스트 생성의 장벽을 낮추며, 비즈니스 흐름 (business flows)을 커버하는 데 필요한 커스텀 프레임워크 (custom framework) 작업량을 줄여줍니다.

다음 가이드들은 해당 평가 부분에 도움이 됩니다:

실질적인 질문은 "비기술 인력이 테스트를 생성할 수 있는가?"가 아닙니다.

더 나은 질문은 다음과 같습니다:

회귀 위험 (regression risk)에 가장 가까이 있는 사람들이 테스트 스위트 (suite)를 악화시키지 않으면서 자동화에 기여할 수 있는가?

이 차이가 중요합니다.

제품을 깊이 이해하고 있는 수동 QA 담당자는 구현 사항만 보는 개발자보다 중요한 회귀 흐름 (regression flow)을 정의하는 데 더 적합한 위치에 있을 수 있습니다. 하지만 도구에는 여전히 가드레일 (guardrails)이 필요합니다. 그렇지 않으면 테스트 스위트는 중복되고, 취약하며, 불분명한 흐름들의 더미가 될 수 있습니다.

훌륭한 로우코드 (low-code) 도구는 디버깅 (debugging)을 불가능하게 만들 정도로 복잡성을 숨겨서는 안 됩니다. 테스트가 이해 가능하고, 검토 가능하며, 유지보수 가능하도록 충분한 구조를 노출해야 합니다.

브라우저 커버리지 (Browser coverage)는 여전히 실제적인 문제입니다

브라우저 테스트는 사람들이 대부분 해결된 주제라고 가정하는 것 중 하나입니다.

그렇지 않습니다.

개발자의 노트북에 있는 Chrome은 macOS의 Safari, 기업 환경의 Edge, CI에서의 Firefox, 또는 렌더링 동작이 다른 모바일 뷰포트 (mobile viewport)와 동일한 것이 아닙니다.

브라우저 커버리지를 위해 다음 가이드들이 유용합니다:

핵심은 브라우저 커버리지(browser coverage)를 거대한 체크박스 항목처럼 취급하지 않는 것입니다.

모든 테스트를 모든 브라우저에서 실행할 필요는 아마 없을 것입니다. 대신 리스크(risk)를 기반으로 한 스마트한 브라우저 매트릭스(browser matrix)가 필요합니다:

주요 브라우저 전반에 걸친 핵심 플로우 (critical flows)
반응형 중단점 (responsive breakpoints) 전반에 걸친 레이아웃 민감 플로우 (layout-sensitive flows)
실제 환경에서의 결제, 로그인 및 온보딩 플로우
빠른 CI 피드백을 위한 소규모 스모크 테스트 스위트 (smoke suite)
비용 정당성이 확보되는 지점에서의 심층적인 회귀 테스트 (regression runs)

모든 것을 모든 곳에서 테스트하는 것이 책임감 있게 들릴 수 있지만, 이는 느리고, 비싸며, 노이즈가 많아질 수 있습니다.

목표는 최대 이론적 커버리지가 아니라 신뢰성(confidence)입니다.

CI 실패에는 단순한 재실행이 아닌 디버깅 워크플로우가 필요합니다

CI는 테스트 자동화가 실제로 구현되는 곳입니다.

로컬에서는 통과하지만 CI에서 실패하는 스위트가 반드시 나쁜 스위트인 것은 아닙니다. 하지만 아무도 왜 실패했는지 빠르게 설명할 수 없다면, 그것은 릴리스(release)의 문제가 됩니다.

다음 두 가이드가 특히 유용합니다:

좋은 CI 테스트 게이트 (test gate)는 몇 가지 질문에 빠르게 답할 수 있어야 합니다:

제품이 고장 났는가?
테스트가 고장 났는가?
환경이 고장 났는가?
실패를 재현할 수 있는가?
이것이 차단(blocking) 요소인가, 아니면 단순 정보(informational) 제공인가?
수정 책임자는 누구인가?

너무 많은 팀이 모든 실패한 빌드(red builds)를 동일하게 취급합니다. 그렇게 되면 릴리스 게이트는 소음이 심해지고 정치적인 문제가 됩니다.

신뢰할 수 있는 게이트에는 계층(tiers)이 필요합니다. 어떤 테스트는 릴리스를 차단해야 하고, 어떤 테스트는 경고를 주어야 합니다. 어떤 테스트는 매일 밤 실행되어야 하며, 어떤 테스트는 일시적으로 격리(quarantined)되어야 합니다. 릴리스 프로세스는 단순히 테스트 개수가 아니라 리스크를 반영해야 합니다.

Why Test Suites Fail Only in Preview Environments: A Debugging Guide for Modern Web Teams 가이드도 읽어볼 가치가 있습니다. 프리뷰 환경 (preview environments)은 그 자체로 독특한 유형의 실패를 만들어내기 때문입니다.

프리뷰 환경은 종종 작지만 중요한 방식으로 프로덕션 (production) 환경과 다릅니다:

시드 데이터 (seeded data)
인증 설정 (auth configuration)
피처 플래그 (feature flags)
CDN 동작
에셋 캐싱 (asset caching)
도메인 및 쿠키 규칙
배포 타이밍
제3자 통합 (third-party integrations)

프리뷰에서의 테스트 실패는 제품 버그일 수도 있지만, 배포 또는 환경 문제일 수도 있습니다. 추측하기 전에 증거가 필요합니다.

불안정한(Flaky) UI 테스트는 대개 지루한 원인에서 발생합니다

플래키니스 (Flakiness)에는 일종의 신화가 따라다니지만, 그 원인은 대개 지루합니다.

불안정한 셀렉터 (selectors). 공유된 테스트 데이터. 잘못된 대기 (waits). 레이스 컨디션 (Race conditions). 네트워크 타이밍. 환경 드리프트 (Environment drift). 중첩된 병렬 테스트. 애니메이션. 제대로 리셋되지 않은 UI 상태.

Flaky UI Tests: Root Causes, Fix Patterns, and Prevention 가이드는 좋은 개요를 제공합니다.

중요한 것은 플래키니스를 무작위적인 것으로 취급하는 것을 멈추는 것입니다.

대부분의 플래키한 테스트는 무언가가 통제되지 않고 있다는 사실을 알려주고 있습니다:

페이지 상태 (page state)
데이터 상태 (data state)
브라우저 상태 (browser state)
환경 (environment)
타이밍 모델 (timing model)
셀렉터 전략 (selector strategy)

무엇이 통제되지 않고 있는지 식별하고 나면, 해결 방법은 덜 미스터리해집니다.

도구를 구매하기 전에 까다로운 UI 표면(Hard UI surfaces)을 평가해야 합니다

깔끔한 로그인 페이지는 도구를 평가하기에 좋은 기준이 아닙니다.

어떤 테스트 자동화 도구라도 단순한 로그인 양식에서는 좋아 보일 수 있습니다.

진정한 평가는 여러분의 애플리케이션에서 짜증을 유발하는 부분들을 포함해야 합니다:

iframe
Shadow DOM
동적 컴포넌트 (dynamic components)
다중 역할 흐름 (multi-role flows)
세션 격리 (session isolation)
API 기반 설정 (API-driven setup)
테스트 데이터 초기화 (test data reset)
모바일 중단점 (mobile breakpoints)
결제 흐름 (checkout flows)
이메일 또는 SMS 인증
제3자 위젯 (third-party widgets)

다음 가이드들은 이러한 더 까다로운 표면들을 다룹니다: