답변.

자동화 테스트의 첫 번째 물결은 사실상 로컬라이제이션(i18n) 검사를 다루지 않았습니다. 왜냐하면 주요 시장이 영어 인터페이스에 초점을 맞췄기 때문입니다. 그러나 애플리케이션의 글로벌화가 진행됨에 따라 로컬라이제이션 품질에 대한 요구가 증가했습니다: 인터페이스는 지원되는 모든 언어에서 올바르게 표시되어야 하며, 텍스트 리소스와 형식이 지정된 문자열은 선택된 로케일에 따라 올바르게 로드되어야 합니다.

주요 문제는 수동 검사가 매우 비용이 많이 들고, 자동화 테스트는 형식, 맥락, 언어의 특수성(예: 오른쪽에서 왼쪽으로 쓰기 또는 문법적 특성)에 따른 변동성으로 인해 복잡하다는 것입니다. 특정 부분의 번역이 없거나, 형식 오류, 레이아웃 오류가 발생할 수 있습니다.

해결책에는 각 로케일에 대한 테스트 데이터 작업, 스냅샷 테스트 사용, UI 요소를 기준 모델과 비교하기, 리소스 파일의 "키-값" 원칙에 따라 검사 도구 도입, API 인터페이스를 통한 문자열의 자동 추출 및 비교, 리소스 파일에 대한 린터의 정기적인 실행이 포함됩니다.

주요 특징:

지원되는 모든 언어의 존재 및 올바른 표시 여부 검사.
기준 번역과 인터페이스의 현재 표시 비교.
레이아웃 손상을 피하기 위한 텍스트의 길이 및 형식 검증기.

함정 질문.

하나의 스크립트로 모든 로케일을 검증하는 보편적인 테스트를 만들 수 있나요?

부분적으로 가능합니다. 그러나 언어의 뉘앙스(격, 성, 입력 방향)는 종종 수동 조정이나 추가 조건을 요구합니다. 100% 보편성은 불가능합니다.

번역 파일이 존재하고 성공적으로 로드되었다면, 이는 i18n 테스트가 통과되었다는 것을 의미하나요?

아니요. 파일이 애플리케이션의 측면에서 잘 링크되지 않았을 수 있으며, 키에 오류가 있을 수 있고, 번역의 사용 맥락이 손상될 수 있으며, 고려되지 않은 특수 기호가 있을 수 있습니다.

1% 미만의 사용자가 있는 언어에 대한 로컬라이제이션 테스트 자동화가 의미가 있나요?

네, 비즈니스에서 한 사용자라도 비즈니스에 중요하다면 의미가 있습니다. 예를 들어 계약 의무를 이행하는 경우나 특별한 요구 사항이 있는 시장에서 그렇습니다. 자동화는 수동 검토에 비해 상당한 자원 절약을 가능하게 합니다.

일반적인 오류 및 안티 패턴

파일의 존재뿐만 아니라 UI에서의 실제 표시를 확인하지 않음.
언어의 문법 및 형식 특성을 고려하지 않고 문자열을 엄격하게 비교함.
단일 로케일에서 다른 로케일로 테스트를 맹목적으로 복사함.

사례 연구

부정적인 사례

팀은 .po 파일의 키와 원래 영어 텍스트를 비교하는 자동 테스트를 도입하였고, 이것만으로 충분하다고 생각했습니다. UI 테스트는 작성하지 않았습니다 — 아랍어 버전 릴리스에서 모든 텍스트가 버튼 경계를 넘어섰고, 일부 문자열은 잘못된 키 때문에 전혀 번역되지 않았습니다.

장점:

i18n 자동화의 빠른 도입.

단점:

실제 사용자 시나리오의 낮은 테스트 범위.
중대한 UX 오류가 간과되었습니다.

긍정적인 사례

리소스의 린팅과 모든 언어에서 인터페이스를 돌아다니며 스크린샷을 찍고 기준 레이아웃과 비교하는 자동 테스트의 조합이 구현되었습니다. RTL/LTR 요소의 혼합을 발견한 팀은 그 근본 원인을 발견하고 릴리스 전에 수정했습니다.