개념
로케이터가 통하지 않는 세계
모듈 13(레슨 3)에서 배운 역할·라벨 기반 로케이터는, 화면이 접근성 정보(HTML의 역할, 라벨 등)를 갖추고 있다는 전제 위에서 작동한다. 그런데 다음과 같은 화면에는 이런 정보가 아예 없다.
- 20년 전에 만들어진 데스크톱 프로그램(접근성을 고려해 만들어지지 않음)
- 화면 전체를 그림으로 그리는 방식의 임베디드 기기 UI
- 원격 데스크톱이나 가상 머신 화면을 통째로 원격 제어해야 하는 경우
이런 환경에서는 "버튼"이라는 역할도, "구매하기"라는 라벨도 코드 차원에서 아예 존재하지 않는다 — 화면은 그냥 픽셀의 집합일 뿐이다.
좌표 기반 자동화
가장 단순한 접근은 화면의 특정 좌표(x, y)를 클릭하는 것이다.
(120, 340) 위치를 클릭하라이 방식의 명백한 문제는, 화면 해상도나 창 위치가 조금만 달라져도 좌표가 완전히 어긋난다는 것이다 — 모듈 13(레슨 3)에서 배운 "CSS 클래스가 가장 불안정한 로케이터"보다도 훨씬 더 깨지기 쉽다.
이미지 인식 기반 자동화
더 나은 접근은, 찾으려는 요소의 이미지(스크린샷)를 미리 등록해두고, 현재 화면에서 그 이미지와 일치하는 위치를 찾아 클릭하는 것이다.
1. "구매하기" 버튼의 스크린샷을 미리 캡처해 저장
2. 자동화 실행 시, 현재 화면 전체를 스캔해 그 이미지와 일치하는 위치를 찾음
3. 찾은 위치를 클릭이 방식은 화면 위치가 바뀌어도(버튼이 다른 곳으로 옮겨져도) 이미지 자체만 같으면 찾아낼 수 있다는 점에서 순수 좌표 기반보다 낫다. 다만 화면 크기나 배율(DPI)이 다르면 이미지가 살짝 달라 보여 인식에 실패할 수 있다는 한계가 있다.
OCR(광학 문자 인식) 활용
화면의 텍스트를 이미지가 아니라 글자 자체로 인식해서 찾는
방법도 있다. "이 화면 어딘가에 '승인 완료'라는 텍스트가 나타나면
성공"처럼, 정확한 좌표나 이미지 없이도 텍스트 내용으로 검증할 수
있다 — 모듈 13(레슨 2)에서 배운 getByText와 목적은 비슷하지만,
DOM 구조가 아니라 실제 화면 픽셀을 분석해서 글자를 읽어낸다는
점이 다르다.
안정성의 위계 — 레거시 환경에서도 우선순위가 있다
모듈 13(레슨 3)에서 배운 로케이터 안정성 등급을, 접근성 정보가 없는 환경에 맞게 다시 세우면 다음과 같다.
1순위 — OCR(텍스트 인식) — 화면 배율 변화에 비교적 강함
2순위 — 이미지 인식 — 위치 변화에는 강하지만 배율·테마 변화에 약함
3순위 — 고정 좌표 — 가장 불안정, 최후의 수단정보가 부족한 환경에서도, "어떤 방법이 상대적으로 더 안정적인가"를 따지는 태도 자체는 모듈 13에서 배운 원칙과 동일하다.
실무에서 왜 필요한가
금융권의 레거시 단말 프로그램, 제조 현장의 오래된 설비 제어 소프트웨어처럼 API도 없고 접근성 정보도 없는 시스템은 여전히 많이 남아있다. 이런 환경에서 QA가 "여긴 자동화가 원천적으로 불가능하다"고 포기하는 대신, 이미지·OCR 기반 접근으로 최소한의 회귀 안전망을 만들 수 있다는 것을 알면 선택지가 넓어진다. 다만 이 방식이 모듈 13의 표준 로케이터보다 훨씬 불안정하다는 것도 동시에 인지하고 있어야 한다.
실습 과제
과제 1 — 접근 방법 우선순위 정하기 (10분)
"창 크기를 고정할 수 있고 화면 배율도 일정한 사내 전용 레거시 프로그램"을 자동화한다면, 좌표·이미지·OCR 중 어떤 조합을 우선 고려할지 판단하고 이유를 적는다.
과제 2 — 한계 설명하기 (10분)
이미지 기반 자동화로 짠 테스트가, 회사가 모니터 해상도를 바꾸는 정책을 시행한 뒤 갑자기 대량으로 실패하기 시작했다고 하자. 왜 이런 일이 생겼는지, 그리고 이런 리스크를 미리 어떻게 완화할 수 있었을지 설명한다.
자가 체크리스트
- 로케이터가 통하지 않는 환경이 어떤 곳인지 예시를 들 수 있다
- 좌표·이미지·OCR 기반 자동화의 방식과 안정성 차이를 설명할 수 있다
- 화면 해상도나 배율 변화가 이미지 기반 자동화에 미치는 영향을 설명할 수 있다
- 정보가 부족한 환경에서도 상대적 안정성을 따지는 태도가 모듈 13과 연결됨을 설명할 수 있다
흔한 실수
- 접근성 정보가 없는 화면은 자동화가 아예 불가능하다고 단정한다. 이미지·OCR 기반의 대안이 있다.
- 고정 좌표 방식을 첫 번째 선택지로 쓴다. 가장 불안정한 방법이므로 다른 대안이 없을 때 최후 수단으로만 고려해야 한다.
- 이미지 기반 자동화를 도입한 뒤, 화면 해상도·배율 변경 같은 환경 리스크를 아무도 관리하지 않는다. 이런 변경이 있을 때마다 자동화가 대량으로 깨질 수 있다는 점을 팀에 미리 알려야 한다.
참고 자료
- Sikuli 공식 문서 — 이미지 기반 자동화 도구의 대표 사례
- Tesseract OCR 공식 문서 — 오픈소스 OCR 엔진의 공식 문서