테스트 자동화 도입을 위한 UI 식별자 적용 제안

배경

신규 제품 개발 초기부터 QA 담당자로 참여했습니다. 반복적인 회귀 테스트를 효율화하기 위해 Playwright 기반의 UI 자동화 테스트를 검토하고, 실제 화면을 자동으로 조작해 테스트 케이스의 Pass/Fail을 판단하는 코드를 작성했습니다.

발견한 문제

UI 자동화에서는 클릭하거나 값을 입력할 화면 요소를 코드에서 정확하게 지정해야 합니다. 하지만 당시 제품에는 요소를 구분할 수 있는 고유 식별자가 충분히 적용되어 있지 않았습니다.

따라서 클래스 이름이나 요소의 순서를 기준으로 대상을 찾는 방식으로 자동화 코드를 작성해야 했습니다.

self.page.locator("span.user-name").inner_text().strip()
self.page.locator("div.label-item-cont.MuiBox-root.css-0").nth(1).inner_text().strip()
self.page.locator("textarea").nth(0).input_value().strip()

특히 한 화면에 ‘수정’, ‘삭제’처럼 이름이 같은 버튼이 여러 개 존재하는 경우에는 nth(0), nth(1)과 같이 요소의 순서에 의존해 특정 버튼을 선택해야 했습니다.

이 방식에는 다음과 같은 위험이 있었습니다.

버튼의 순서가 바뀌면 기존 코드가 다른 버튼을 선택할 수 있음
새로운 요소가 추가되면 기존 요소의 인덱스가 변경될 수 있음
같은 이름을 가진 버튼이 추가되면 의도하지 않은 요소가 클릭될 수 있음
화면 구조나 자동 생성 클래스명이 변경되면 관련 테스트가 함께 실패할 수 있음
기능 문제가 아닌 선택자 변경으로 테스트가 실패해 유지보수 공수가 증가할 수 있음

즉, 자동화 코드는 실행할 수 있었지만 UI 구조 변화에 취약해 안정적인 회귀 테스트로 운영하기 어려운 상태였습니다.

TESTABILITY FLOW 순서에 의존하는 선택자를 의미 기반 식별자로 전환하는 제안

CURRENT 위치·순서 기반 .nth(1) .MuiBox-root.css-0

화면 구조가 바뀌면 다른 요소를 선택할 수 있음

PROPOSAL 의미·데이터 기반 data-testid="edit-{id}" data-action="delete"

요소의 역할과 서버 데이터 ID를 기준으로 선택

APPLY TARGET

데이터 변경 버튼과 반복 목록 등 자동화 핵심 요소부터 단계적으로 적용

수행한 역할

식별자가 필요한 이유를 개발팀이 이해할 수 있도록, 실제 자동화 코드와 화면 사례를 활용한 설명 자료를 작성해 공유했습니다.

단순히 “ID를 추가해 달라”고 요청하는 것이 아니라, 현재 선택자 방식의 문제와 UI 변경 시 발생할 수 있는 오작동 사례를 구체적으로 설명했습니다. 또한 모든 요소에 일괄적으로 ID를 추가하는 것은 개발 부담이 될 수 있으므로, 자동화에 필요한 주요 요소부터 적용하는 방안을 제안했습니다.

제안한 식별자 적용 기준

화면의 모든 요소가 아닌, 사용자 행동이나 데이터 변경과 직접 관련된 요소를 우선 적용 대상으로 제안했습니다.

데이터를 변경하는 버튼
수정 및 삭제 버튼
핀 추가·해제와 같은 상태 변경 버튼
값을 선택하는 드롭다운
체크박스 등 상태 변경 컴포넌트
반복되는 목록의 행과 해당 행에 포함된 액션 버튼
텍스트만으로 용도를 구분하기 어려운 이미지 버튼

반복되는 목록에서는 서버 데이터의 고유 ID와 액션의 종류를 조합해 요소를 찾을 수 있도록 다음과 같은 구조를 예시로 전달했습니다.

<!-- 목록 영역 -->
<div data-testid="policy-list">

<!-- 서버의 고유 ID를 이용한 각 행 구분 -->
<div data-row-id="{{policyId}}">

<!-- 행 내부의 액션 구분 -->
<button data-action="edit">
<button data-action="delete">
<button data-action="pin-toggle">

필요한 경우 다음과 같이 식별자를 템플릿화하는 방식도 함께 제안했습니다.

<button data-testid="edit-{{policyId}}">
<button data-testid="delete-{{policyId}}">

이미지 버튼에는 aria-label이나 title을 부여하고, 드롭다운과 체크박스 같은 상태 변경 요소에는 data-action을 사용하는 방안도 제시했습니다.

또한 레이아웃만으로 영역이 명확히 구분되는 경우에는 개별 요소마다 ID를 추가하는 대신, 상위 컨테이너에 식별자를 부여한 후 해당 영역 안에서 필요한 요소를 찾는 방식도 제안했습니다. 이를 통해 개발 부담을 줄이면서 자동화 안정성을 확보하고자 했습니다.

커뮤니케이션 방식

개발팀과 다음 내용을 협의하기 위한 자료를 작성했습니다.

UI 식별자가 자동화 테스트에 필요한 이유
클래스명과 요소 순서에 의존할 때 발생하는 문제
식별자가 우선적으로 필요한 요소의 범위
서버 데이터 ID를 활용하는 방식
id, data-testid, data-row-id, data-action 등의 사용 기준
실제 서비스의 식별자 적용 참고 사례

개발자가 자동화 테스트 코드를 직접 확인하지 않더라도 필요성을 이해할 수 있도록, 실행 영상과 실제 코드, 화면 사례를 함께 사용해 설명했습니다.

진행 결과 및 제약

당시에는 제품의 기본 설계와 핵심 기능 구현이 안정적으로 진행되지 않고 있었습니다. 개발 리소스가 제품 자체의 구현과 수정에 집중되면서, QA가 제안한 식별자 적용은 실제 제품에 반영되지 못했습니다.

제품의 화면 구조와 기능도 지속적으로 변경되고 있어 안정적인 자동화 시나리오를 확정하기 어려웠습니다. 이에 따라 자동화 코드의 일부 구현과 적용 기준 제안까지 진행했으나, 운영 가능한 자동화 테스트 구축으로 이어지지는 못했습니다.

기여 내용

UI 자동화 코드를 직접 작성하고 실제 화면에서 동작 가능성을 검증
자동화 안정성을 저해하는 위치·순서 기반 선택자의 문제 식별
실제 실패 가능성을 코드와 화면 사례로 구체화
자동화에 필요한 UI 식별자 적용 기준 제안
개발 부담을 고려해 핵심 요소와 상위 컨테이너 중심의 단계적 적용 방안 제시
자동화 요구사항의 필요성과 적용 방법을 문서화해 개발팀에 공유

경험의 의미

최종적으로 운영 가능한 자동화 환경이 구축된 사례는 아닙니다. 다만 개발 초기 단계에서 자동화 가능성을 직접 검증하고, 안정적인 테스트를 위해 제품에 필요한 기술적 선행 조건을 식별했습니다.

또한 추상적인 요구에 그치지 않고 실제 코드, 오작동 가능성, 적용 대상 및 속성 예시까지 구체화해 개발팀이 검토할 수 있는 형태로 전달했습니다. 이를 통해 QA 관점에서 제품의 테스트 가능성(Testability)을 분석하고 기술 요구사항으로 정리한 경험입니다.