책 발췌 – 로칼라이제이션 테스팅 이슈 by Ron Patton

출처: 책 Software Testing by Ron Patton, 2001년
10장 Foreign-Language Testing, 159~165페이지

 

언어, 방언, 현지 관습 및 문화를 고려하여 소프트웨어를 특정 로컬에 적용하는 프로세스를 현지화(localization)라고 하고, 이를 테스트하는 것을 현지화 테스팅(localization testing)이라고 한다. 다음은 현지화 테스팅에서 텍스트 번역과 관련된 일부 이슈들이다.

 

텍스트 확장(Text Expansion)

영어가 다른 언어로 번역되면 같은 내용을 말하기 위해 일반적으로 더 많은 문자가 필요하다는 것이 밝혀졌다. 그림 10.1은 두 가지 컴퓨터 단어의 번역된 텍스트를 담기 위해 버튼의 크기가 확장되는 것을 보여준다.

그림 10.1 다른 언어로 번역하면 최소화(Minimize) 및 최대화(Maximize)라는 단어의 크기가 달라질 수 있으므로 이를 수용하기 위해 UI를 다시 디자인해야 하는 경우가 있다.

 

이러한 확장으로 인해 긴 텍스트의 영향을 받을 수 있는 소프트웨어 영역을 신중하게 테스트해야 한다. 올바르게 줄 바꿈되지 않거나, 잘리거나, 하이픈이 잘못 연결된 텍스트를 찾아라. 이것이 화면, 윈도우창, 박스, 버튼 등 어디에서나 발생할 수 있다. 또한 텍스트를 확장할 수 있는 충분한 공간이 있지만 그로 인해 뭔가 다른 것이 제자리에서 밀려나는 경우도 찾아보라.

 

또 다른 가능성은 이렇게 길어진 텍스트가 주요 프로그램 실패나 심지어 시스템 크래시를 일으킬 수 있다는 것이다. 프로그래머가 영어 텍스트 메시지에 충분한 내부 메모리를 할당했지만 번역된 문자열에는 충분하지 않았을 수 있다. 영어 버전의 소프트웨어는 제대로 작동하지만 독일어 버전은 메시지가 표시될 때 크래시가 발생하는 것이다.

 

 

ASCII, DBCS 및 Unicode

ASCII는 256개의 문자만 표현할 수 있고 이는 모든 언어에서 가능한 모든 문자를 표현하기에는 충분하지 않다. 소프트웨어가 다양한 언어로 개발되기 시작했을 때 이러한 한계를 극복할 수 있는 솔루션을 찾아야 했다. MS-DOS 시절의 일반 솔루션이자 오늘날에도 여전히 사용되는 방식은 코드 페이지(code pages)라는 기술을 사용하는 것이다. 코드 페이지는 각 언어마다 다른 코드 페이지가 있는 대체 ASCII 테이블이다. 소프트웨어가 퀘벡의 프랑스어 PC에서 실행되는 경우 프랑스어 문자를 지원하는 코드 페이지를 로드하고 사용할 수 있다. 러시아어는 키릴 문자를 위한 다른 코드 페이지를 사용한다. 이 솔루션은 256자 미만의 언어에는 문제가 없지만 일본어, 중국어 및 수천 개의 심볼이 있는 기타 언어에서는 문제가 발생한다. 일부 소프트웨어는 DBCS(Double-Byte Character Set)라는 시스템을 사용하여 256개 이상의 문자를 제공한다. 1바이트 대신 2바이트를 사용하면 최대 65,536개의 문자가 가능하다.

 

많은 상황에서 코드 페이지와 DBCS로 충분하지만 몇 가지 문제를 가지고 있다. 가장 중요한 것이 호환성(compatibility) 이슈이다. 히브리어 문서가 영국 워드프로세서를 실행하는 독일 컴퓨터에 로드되면 횡설수설하는 결과가 나올 수 있다. 적절한 코드 페이지나 코드 페이지 간의 적절한 변환이 없으면 문자를 올바르게 해석할 수 없다.

 

이러한 혼란에 대한 솔루션이 유니코드 표준이다. 유니코드는 플랫폼, 프로그램, 언어에 관계없이 모든 문자에 고유한 번호를 제공한다. 유니코드는 주요 소프트웨어 회사, 하드웨어 제조업체 및 기타 표준 그룹에서 지원하는 세계적인 표준이기 때문에 점점 더 보편화되고 있다. 대부분의 주요 소프트웨어 애플리케이션이 이를 지원한다. 그림 10.2은 지원되는 다양한 문자를 보여준다. 소프트웨어가 현지화될 가능성이 조금이라도 있다면 프로젝트의 프로그래머는 “오래된” ASCII와의 관계를 끊고 유니코드로 전환하여 시간을 아끼고 버그 발생을 방지해야 한다.

 

그림 10.2 이 Microsoft Word 2000 대화 상자는 유니코드 표준에 대한 지원을 보여준다.

 

 

핫키(Hot Keys) 및 단축키(Shortcuts)

검색이라는 단어가 영어로는 Search이고 프랑스어로는 Rechercher이다. 소프트웨어의 영어 버전에서 검색을 선택하는 핫키가 Alt+S인 경우 프랑스어 버전에서는 이를 변경해야 한다. 소프트웨어의 현지화된 버전에서는 모든 핫키와 단축키가 제대로 작동하는지, 사용하기가 너무 어렵지 않은지(예: 세 개의 키누르기를 요구) 테스트해야 한다. 그리고 영어 핫키와 단축키가 비활성화되어 있는지 확인하는 것을 잊지 마라.

 

 

확장 문자(Extended Characters)

현지화된 소프트웨어는 물론 현지화되지 않은 소프트웨어에서도 흔히 발생하는 문제가 확장 문자를 처리하는 데 있다. ASCII 테이블을 다시 참조하면 확장 문자는 A~Z 및 a~z의 일반 영어 알파벳 밖에 있는 문자이다. 이에 대한 예로는 José의 é 또는 El Niño의 ñ와 같은 악센트 문자가 있다. 소프트웨어가 유니코드를 사용하도록 작성되었거나 코드 페이지나 DBCS를 올바르게 관리하는 경우라면 이는 문제가 되지 않지만, 테스터는 아무 것도 가정해서는 안되므로 확인해 볼 가치가 있다.

 

이를 테스트하는 방법은 소프트웨어가 문자 입력을 받거나 출력으로 내보내는 모든 위치를 찾는 것이다. 각 위치에서 확장 문자를 사용해보고 일반 문자처럼 작동하는지 확인하라. 대화 상자(Dialog boxes), 로그인 및 모든 텍스트 필드가 좋은 대상이다. 모뎀을 통해 확장 문자를 보내고 받을 수 있는가? 확장 문자로 파일 이름을 지정하거나 파일에 그 문자를 포함할 수 있는가? 제대로 인쇄되는가? 우리 프로그램과 다른 프로그램 간에 잘라내기, 복사하기, 붙여넣기를 하면 어떻게 되는가?

 

 

문자에 대한 계산(Computations on Characters)

확장 문자에 계산을 수행하는 소프트웨어가 확장 문자를 해석하는 방식도 문제가 될 수 있다. 이에 대한 두 가지 예는 단어 정렬과 대문자 및 소문자 변환이다.

 

여러분의 소프트웨어가 단어 목록을 정렬하거나 알파벳순으로 배열하는가? 파일명이나 웹 사이트 주소와 같은 선택 가능한 항목들이 리스트 박스에 있는가? 그렇다면 아래 단어를 어떻게 정렬하겠는가?

 

아시아권 문화에 판매할 소프트웨어를 테스트하는 경우 정렬 순서가 문자를 칠하는 데 사용된 브러시 획의 순서에 따라 결정된다는 사실을 알고 있는가? 위 목록이 중국어로 작성된 경우 완전히 다른 정렬 순서를 가질 수 있다. 내가 테스트하는 언어에 대한 정렬 규칙이 무엇인지 알아보고 적절한 정렬 순서가 발생하는지 구체적으로 확인하는 테스트를 개발하라.

 

확장 문자에 대한 계산이 실패하는 또 다른 영역은 대문자 및 소문자 변환이다. 많은 프로그래머가 학교에서 배우는 "트릭" 솔루션이 단순히 문자의 ASCII 값에 32를 더하거나 빼서 대소문자를 변환하는 것이기 때문에 문제가 된다. A의 ASCII 값에 32를 더하면 a의 ASCII 값을 얻는다. 그러나 확장 문자에는 이것이 작동하지 않는다. Apple Mac 확장 문자 세트에 이 기술을 사용한다면 Ñ(ASCII 132)을 ñ(ASCII 150) 대신에 §(ASCII 164)로 잘못 변환하게 될 것이다.

 

 

왼쪽에서 오른쪽으로, 오른쪽에서 왼쪽으로 읽기

히브리어와 아랍어와 같은 일부 언어가 왼쪽에서 오른쪽이 아닌 오른쪽에서 왼쪽으로 읽는다는 것도 큰 이슈이다. 전체 사용자 인터페이스를 거울 이미지로 홱 뒤집는 것을 상상해보라.

 

다행히도 대부분의 주요 운영 체제는 이러한 언어 처리를 위한 빌트인 지원을 제공한다. 이것이 없으면 거의 불가능한 작업이 될 것이다. 그럼에도 불구하고 이런 텍스트를 번역하는 것은 여전히 간단한 문제가 아니다. 이 작업을 위해 OS의 기능을 활용하려면 많은 프로그래밍이 필요하다. 테스팅 관점에서는 이것을 단순한 현지화 제품이 아닌 완전히 새로운 제품이라고 생각하는 것이 안전할 것이다.

 

 

그래픽에서의 텍스트(Text in Graphics)

그래픽에 텍스트가 사용될 때 또 다른 번역 이슈가 발생한다. 예를 들어 그림 10.3의 아이콘은 Bold, Italic, Underline 및 Font Color를 선택하는 표준 아이콘이다. 영문자 B, I, U, A를 사용하기 때문에 영어를 읽지 못하는 일본 사람에게는 이것이 아무런 의미가 없다. B는 약간 어둡고, I는 기울어져 있고, U는 그 아래에 선이 있는 모양에 따라 의미를 파악할 수도 있지만, 소프트웨어는 퍼즐이 되어서는 안 된다.

 

이로 인해 소프트웨어가 현지화되면 각 아이콘이 새로운 언어를 반영하도록 변경되어야 한다. 이러한 아이콘이 많으면 프로그램을 현지화하는 데 엄청나게 많은 비용이 들 수 있다. 이러한 텍스트-인-그래픽(text-in-graphic) 버그를 개발 사이클 초기에 찾아서 끝까지 가지 도록 하라.

 

그림 10.3 Word 2000에는 번역하기 어려운 비트맵 텍스트의 예가 있다.

 

 

소스 코드에서 텍스트 제외

이것이 의미하는 바는 모든 텍스트 문자열(strings), 에러 메시지 및 번역될 수 있는 모든 것이 소스 코드와 별개로 별도의 파일에 저장되어야 한다는 것이다. 절대 Print “Hello World”와 같은 코드 라인을 보는 경우가 없어야 한다.

 

대부분의 로컬라이저는 프로그래머가 아니며 프로그래머일 필요도 없다. 한 언어에서 다른 언어로 번역하기 위해 소스 코드를 수정하도록 하는 것은 위험하고 비효율적이다. 그들이 수정할 것은 소프트웨어가 표시할 수 있는 모든 메시지가 담겨있는 리소스 파일(resource file)이라 불리는 단순 텍스트 파일이다. 실행 소프트웨어는 이를 통해 메시지를 참조하며 해당 메시지가 영어이든 또는 네덜란드어이든 신경 쓰지 않고 똑같이 표시한다.

 

이런 이유로 화이트박스 테스터가 코드를 검색하여 외부 파일에 배치되지 않은 내장 문자열(embedded strings)이 없는지 확인하는 것이 중요하다. 스페인어 프로그램에서 중요한 에러 메시지가 영어로 나타나는 것은 꽤 당혹스러울 것이다.

 

이 문제의 또 다른 변형은 코드가 텍스트 메시지를 동적으로 생성하는 경우이다. 예를 들어 프로그램이 사용자로부터 입력 받은 정보 및 여러 텍스트 조각을 모아서 하나의 더 큰 메시지를 만들 수 있다. 문제는 모든 언어에서 단어 순서가 동일하지 않다는 것이다. 영어에서는 잘 어울리지만 각 구문이 별도로 번역되어 있기 때문에 표준 중국어나 독일어에서 함께 붙어 있으면 횡설수설이 될 수 있다. 문자열이 코드에서 일부 잘리지 않도록 하고 코드에 의해 더 큰 문자열로 쌓이지 않도록 하라.