답변.

문제의 배경:

글로벌화 시대에 더 많은 제품이 다국어화되고 있습니다. 로컬라이제이션(번역, 날짜, 숫자, 통화 등의 형식) 테스트는 새로운 시장 출시가 UI와 논리의 변화를 초래할 때 특히 수동 테스터에게 중요한 작업입니다. 로컬라이제이션 검사는 인식 오류, 부정확한 번역 및 사용자 경험 문제를 방지하기 위해 필요합니다.

문제:

이 유형의 테스트를 자동화하는 것은 어렵습니다. 시각적, 의미적 및 문화적 측면이 중요하기 때문입니다. "긴 단어로 인해 레이아웃이 무너진다", "측정 단위의 불일치", 또는 "날짜 형식 변경으로 인한 기능 중단"과 같은 오류가 자주 발생합니다. 테스터는 종종 텍스트에 대해서만 표면적인 검사를 수행합니다.

해결책:

프로세스 조직에는 다음이 포함됩니다:

- 용어집에 따라 모든 번역의 정확성 검사
- 긴 문자열과 짧은 문자열 테스트(독일어, 핀란드어 등에서 중요함)
- 선택된 로케일의 맥락에서 날짜, 숫자, 통화 표시 검사
- UI의 정확성 검사: 잘린 텍스트가 있는지, 줄 바꿈이 있는지, 화면에서 모두 읽을 수 있는지 여부
- "다양한" 언어(예: RTL 표시가 필요한 아랍어)로 모든 변경 사항 테스트

주요 특징:

시각적 아티팩트 및 비표준 시나리오에 대한 수동 검사
로케일의 세부 사항(날짜, 통화, 호칭 형태)에 대한 주의
승인된 번역 용어집을 통한 검증

함정 질문.

로컬리제이션 텍스트를 원본 영어와 비교하는 것만으로 번역 품질을 검사할 수 있나요?

아니요, 의미, 언어의 특수성, 포맷팅의 뉘앙스 및 UI 통합을 고려해야 합니다. 번역이 문자 그대로 "정확"하더라도 원어민에게는 의미상 완전히 잘못될 수 있습니다.

유럽 언어에서 작동하는 제품이라면 RTL 언어 테스트를 생략해도 되나요?

아니요, RTL(아랍어, 히브리어) 지원은 레이아웃의 특별한 변경을 요구하며, 수동 테스트가 없으면 요소 재배치와 기능 손실이 발생할 수 있습니다.

테스터가 편안하고 익숙한 언어에서만 로컬리제이션 테스트를 해야 할까요?

아니요, 원어민을 참여시키거나 언어학자의 서비스를 활용해야 합니다, 특히 다른 문화 및 측정 시스템이 있는 시장에 대해 이야기가 나올 때는 더욱 그렇습니다.

일반적인 오류 및 안티 패턴

용어집과의 비교 없이 "눈으로" 테스트하기
비표준 길이 문자열 테스트 생략
로케일의 특수한 사항(통화, 복수 형태, 날짜 형식)을 무시하기

실생활 사례

부정적인 케이스

테스터가 영어와 러시아어 버전만 검사하고 독일어는 테스트하지 않았습니다. 출시 후 사용자들은 버튼의 잘린 텍스트와 읽기 어려운 메시지에 대해 불평했습니다.

장점:

빠른 검증 통과

단점:

프로덕션에서의 레이아웃 문제
사용자 충성도 감소

긍정적인 케이스

테스터가 모든 지원 로케일의 UI를 검사하고 독일어의 긴 단어 문제를 기록하고 수정 후에 재테스트를 진행했습니다. 모든 수정 사항이 제때에 적절히 수행되었습니다.