문서요약 - 국제화와 현지화 테스팅 by De Young

제목: 국제화와 현지화 테스팅(Internationalization and Localization Testing)

저자: Clinton De Young

문서유형: 책 “Software Testing and Internationalization”에서 제 6장(총 66페이지), 2003년

 

글로벌 시장을 겨냥한 소프트웨어 생성 시 흔히 직면하는 문제와 이런 국제적인 제품을 더 잘 테스트 할 수 있도록 그 이해를 돕는 내용들을 기술한 자료

---

주요 용어 정의

• 현지화(Localization): 소프트웨어의 번역(translation) 그리고 그것을 최종사용자에게 보이는 것(presentation)과 관련된 개발 및 테스팅 측면. 프로그램을 번역하는 것과 적절한 아이콘, 그래픽, 문화적 고려사항을 선택하는 것을 포함. 또한 프로그램의 헬프 파일과 문서를 번역하는 것도 포함
• 국제화(Internationalization): 프로그램 내에 외국어 텍스트 및 데이터를 다루는 것과 관련된 개발 및 테스팅 측면. 정렬(sorting), 텍스트 및 데이터 가져오기(importing)와 내보내기(exporting), 통화/날짜/시간 형식을 정확히 다루기, 스트링 파싱(string parsing), 대문자와 소문자 다루기 등을 포함. 소스 코드로부터 스트링(또는 사용자 인터페이스 텍스트)을 분리하고, 사용자 인터페이스 상에 외국어 스트링이 올바르게 디스플레이 될 수 있도록 충분한 공간을 확보하는 작업도 포함
• 현지화된(Localized): 외국어로 번역된 프로그램, 문서 등을 지칭
• 국제화된(Internationalized): 국제적인 데이터(international data)를 올바르게 처리할 준비가 코드 단계에서부터 된 프로그램을 가리킴. 국제화된 프로그램은 언어나 무수한 데이터 형식에 상관없이 어디서든 동작하는 프로그램이다.
• I18N과 L10N: 각자 “internationalization”과 “localization”을 지칭하는 약어

글로벌 시장을 겨냥한 소프트웨어 프로그램 계획에 관련된 이슈

1) 프로젝트 계획에서 국제적인 초점 결여

• 제품 주기의 주요 단계 동안 자국어만을 고려하여 계획을 세우고 나중에(종종 자국어 버전 출시일 한 두 달 전에서야) 이 소프트웨어를 외국 환경(타 언어 플랫폼)에서도 실행되도록 변경하기 시작함
• 이런 접근 방법은 국제적인 제품 출시에 지연을 초래할 수 있고 또한 다수의 코드 베이스가 나오게 함(여러 코드 버전은 에러가 생기기 쉽고 유지보수 비용도 높아짐)
• 약간의 적절한 선행 계획만으로도 이러한 실수는 쉽게 피할 수 있음. 예, 자국어 버전 제품을 고쳐서 외국어 버전을 생성하는 대신에 자국어와 지원할 외국어 모두를 핵심 제품에 삽입되어야 할 모듈로 간주하고, 프로그램 기능을 최종사용자가 보는 UI 및 프리젠테이션으로부터 분리한다.

2) 자국어 중심의 프로젝트 계획이 왜 개발에서 이슈가 되는가

• 소프트웨어의 자국어 버전에만 집중한 프로젝트 계획 하에서는 개발자가 국제적인 문자, 데이터 형식, 국제화된 소프트웨어와 관련된 여러 사항들을 고려하는데 종종 실패한다.
• 예를 들면, 개발자가 시간/날짜 형식을 하드코딩 하거나 또는 시간/날짜 오브젝트의 데이터 처리를 특정한(대개 자국의) 형식에 기반함. 이런 코드는 외국 운영체제 상에서 실행될 때 문제가 생기며 이를 수정하는데 시간이 소요됨

프로젝트 초기부터 I18N을 고려하는데 실패한 것이 문제점으로 이어지는 예:

- 날짜 형식으로 미국은 “month/day/year”, 독일은 “day.month.year”, 일본은 “year/month/day”을 사용함

- 사용자의 생일을 추적하는 프로그램을 세계 시장에 판매한다고 가정. 이 프로그램의 데이터베이스가 미국에서 사용되는 형식에 기반하여 날짜를 저장함

- 독일 고객이 이 프로그램을 설치하고 독일에서 사용되는 날짜 형식으로 자신의 생일 1969년 2월 10일을 입력하면(즉, 10.2.1969) 프로그램은 이 사람이 1969년 10월 2일에 태어난 걸로 여김. 고객이 1969년 2월 23일 태어난 경우(즉, 23.2.1969)는 1969년 23월 2일을 생일로 간주(물론 유효하지 않은 데이터이므로 프로그램에 의해 거부됨)

3) 자국어 중심의 프로젝트 계획이 왜 테스팅에서 이슈가 되는가

• 현지화된 빌드가 생성될 때까지는 자국어로 된 제품만을 테스트하기로 테스팅 팀이 계획한 경우, 외국어로도 프로그램이 정확하게 동작하는지 제대로 확인할 충분한 시간이 없음(제품의 해외 버전 출시가 자국어 제품 출시 후 90일 정도까지 지연되는 이유)
• 테스팅 팀이 프로젝트 초부터 I18N 이슈를 테스트하고자 하여도 효과적인 I18N 계획이 생성되고 프로젝트 관리자와 구성원들의 지원이 없으면 할 수가 없음. 결국 현지화 이슈에 집중해야 할 시기인 제품 주기 막판에서야 I18N 테스팅을 하게 됨
• 이렇게 늦어진 테스팅의 부정적 영향으로 다수의 코드 베이스를 들 수 있음. 자국어(영어) 제품이 출시된 후에 테스팅 부서가 해외 빌드에서 결함을 찾게 되고 이를 수정하기 위해 개발자가 종종 코드를 분기하는 것을 선택함(즉, 다수의 코드 베이스가 나오게 되고 유지보수 비용이 증가)

글로벌 시장을 겨냥한 소프트웨어 프로그램 개발에 관련된 이슈

1) 스트링 관련 문제

하드코딩된 스트링(hard coded strings)

• 아래 예처럼 프로그램 변수에 스트링을 하드코딩한 경우 이 코드를 컴파일 할 때마다 스트링이 실행파일의 한 부분이 됨
• 이 경우 소프트웨어를 타 언어로 번역하기가 어려움. 번역자가 스트링을 찾아 소스 코드를 뒤져야 하므로 뭔가를 빠트릴 가능성이 높고, 코드의 일부를 번역하는 중에 실수를 하여 컴파일 에러를 야기할 위험도 높음
• 더 큰 문제는 지원하는 각 언어마다 별도의 코드 버전을 낳게 됨. 예를 들어, 영어, 가장 흔한 서유럽 언어(독일어, 프랑스어, 스페인어, 포르투갈어, 이탈리아어), 그리고 아시아 언어(중국어 번체와 간체, 일본어, 한국어)를 지원하는 경우 10개의 다른 코드 베이스를 관리할 필요가 생김

스트링을 코드로부터 분리(Separate strings from code)

• 프로그램의 스트링을 코드의 나머지 부분으로부터 분리하면 단일 코드베이스로 10개의 다른 언어를 생성할 수 있음. 즉, 모든 스트링을 코드 베이스로부터 분리된 하나(또는 하나 이상)의 파일에 넣음
• 이 파일은 사용된 스트링 분리 방법과 프로그래밍 언어에 따라 ‘스트링 테이블(string tables)’, ‘메시지 파일(message files)’, ‘속성 파일(properties files)’ 등의 이름으로 불림
• 업체가 종종 범하는 실수로 스트링을 별도의 C나 C++ 헤더 파일에 넣은 후 이를 프로그램 실행 파일로 컴파일 함. 이 방법은 스트링을 하드코딩하는 것보다는 낫지만 매 언어마다 프로그램을 재컴파일 해야 하는 필요성을 제거하지는 못함(따라서 비권장)

키-값 쌍(Key-value pairs) 또는 해시 테이블(hash tables)

• 스트링을 담은 별도 파일은 아래 예처럼 각 스트링 엔트리가 두 개 값으로 구성됨(하나는 스트링 자체이고 다른 하나는 해당 스트링에 접근을 위한 키). 이런 조합을 키-값 쌍(key-value pairs) 또는 해시 테이블(hash tables)이라고 지칭
• 개발자는 스트링을 프로그램에 하드코딩하는 대신 키를 사용해 원격 파일(또는 라이브러리)의 스트링에 접근함. 즉, PromptForName = Prompt 같은 코드를 작성
• 프로그램 실행 시 올바른 언어 스트링 파일로부터 스트링이 동적으로 로드되고, 따라서 스트링의 올바른 언어 버전이 사용자에게 디스플레이 된다(모든 언어 파일에서 스트링 키 값은 동일하고 실제 스트링 값만 각기 다른 언어로 번역됨).

2) 다이얼로그 관련 문제 – 스트링 확장

• 단어나 문장이 타 언어로 번역될 때 대개 스트링 길이에 변화가 생김(원래 언어 버전의 길이보다 길어지거나 짧아진다). 아래 좌측의 아무 이상이 없던 영어 버전 다이얼로그도 우측 그림처럼 독일어로 번역되면 스트링 길이가 늘어나면서 일부가 잘려나가게 됨
• 해결책으로 1) 스트링 확장에 필요한 공간을 고려하여 다이얼로그 레이아웃을 적절히 조정하거나, 2) 다이얼로그 리소스를 별도의 동적 라이브러리로 분리(동적 라이브러리를 사용하는 경우 다이얼로그 크기 정보를 스트링 리소스와 같은 파일에 넣을 수도 있음)

레이아웃을 통해 스트링 확장을 고려

• IBM이 사용자 인터페이스 생성 시 스트링 확장에 필요한 공간을 추정하는 단순한 표준을 마련함(아래 표 참고). 영어를 기준 언어로 타 언어들의 공간 요구사항을 계산
• 위 다이얼로그 예에서 영어 스트링(“Authorized User List:”)은 콜론과 스페이스 포함해서 길이가 21자이고 독일어 버전은(“Liste der berechtigten Benutzer:”) 32자임. 아래 표를 참고해 21 * 2.2를 계산하고 결과를 반올림하면 46개 문자가 나옴
• 이런 계산의 목적은 매 언어마다 다이얼로그 크기를 조정하고 프로그램을 재컴파일 하는 수고 없이 모든 언어를 넉넉히 수용할 수 있는 단일 다이얼로그를 생성하기 위함

별도 리소스를 통해 스트링 확장을 고려

• 다이얼로그 정보를 별도의 동적 라이브러리(런타임 시에 프로그램으로 로드됨)에 넣는 것이 가능함. 이 경우 각 언어를 위한 별도의 라이브러리를 생성함. 즉, 각 언어의 UI 크기가 제각각 다르게 커스토마이징 될 수 있다.
• Windows 애플리케이션 작성에서는 Microsoft의 개발 도구가 쉽게 다이얼로그 리소스를 별개 동적 라이브러리로 분리하도록 해줌. 타 언어/도구/환경도 인터페이스를 이런 식으로 생성하는 것을 지원함

3) 빌드와 인스톨러

• 단일 버전의 코드와 다수 버전의 언어 파일(동적 라이브러리 또는 표준 텍스트 파일)을 지원하는 빌드 환경과 인스톨러를 생성하는 것이 필수적임. 즉, 신규 빌드가 생성될 때마다 모든 언어 파일을 수반한 코드 베이스가 생성되어야 함
• 또한 이 파일들을 지원하는 셋업 프로그램이 설계되어야 함. 셋업 프로그램은 사용자 운영체제의 언어 설정에 기반하여 어떤 언어 파일이 설치되어야 할지를 자동으로 찾음. 또는 인스톨러가 하나의 언어만 설치하는 대신 모든 언어 파일을 설치하고 어떤 리소스를 로드할지는 프로그램이 실행 시 결정함(대개 서버 프로그램에서 사용되는 방법)
• 테스터는 지원하기로 계획된 모든 언어 플랫폼에서 제품을 테스트 하고 동적 리소스가 정확하게 로드되는지 확인해야 함

I18N 테스팅

1) 첫 날부터 테스팅을 시작

• 테스터는 작업할 실질적인 빌드가 나오기 전까지는 제품 주기 단계에서 종종 소외됨. 하지만 국제적인 소프트웨어 구축 시 테스터가 초기부터 관여해야 할 일이 많이 있음
• 제품 주기의 계획 단계에서는 국제화 관련 이슈를 이해하고 있는 테스터가 계획 자체를 테스트함. 즉, 프로젝트 계획이 국제화를 제대로 지원하는지 확인함
• 테스터는 회사가 지원을 계획한 언어들이 무엇인지 파악하고, 지원하려는 모든 언어를 빌드가 생성할 수 있도록 보장해야 한다. 그러기 위해 빌드 마스터와 협업하고, 빌드 환경이 적절하지 못한 경우 결함으로 지적한다.
• 제품 주기의 아키텍쳐 단계에서는 계획된 아키텍쳐 중 국제적 환경에서 정확하게 동작하지 않는 것을 결함으로 지적함. 예) 회사의 제품이 유니코드 지원을 계획함. 설계 문서에서 네트워크로 데이터 전송 시 유니코드를 코드페이지로 전환하고 데이터가 목적지에 도착하면 다시 유니코드로 전환하는 방안이 제안됨. 테스터는 이런 전환이 아시아 언어에서 문제를 야기할 수 있으므로 대신 UTF-8로 전환할 것을 제안함

2) 프로그램의 설치를 테스팅

• 외국어로된 설치를 테스팅 시 디폴트 설치 디렉토리를 체크해야 함. 예를 들면, 영어나 일본어에서는 Windows 95의 디렉토리 구조가 “Program Files” 디렉토리를 포함하고 대부분의 Windows 프로그램이 디폴트로 여기에 설치되지만, 스페인어에서는 동일한 디렉토리가 “Archivos de programa” 라고 불림. 따라서 개발자가 설치 스크립트에 “Program Files”를 하드코딩 하는 대신 Program Files 디렉토리를 가리키는 Windows 별칭(alias)을 사용하는지 확인해야 함
• 외국어 머신 상에서 설치 해제 프로그램이 실패하는 경우도 있으므로 언인스톨러(uninstaller)도 체크해야 함

3) 현지화 대상 스트링(Localizable Strings)을 테스팅

• 스트링을 테스트하기 위해서 수동으로 또는 툴을 통해 자동으로 의사 빌드(pseudo build)를 생성함
• 의사 빌드를 수동 생성하려면 스트링 테이블의 복사본을 만들고 모든 스트링이 최소한 몇몇의 외국 문자를 포함하도록 이를 편집함. 시간이 많이 걸리는 작업이므로 개발자가 간단한 유틸리티(스트링 테이블이나 언어 텍스트 파일로부터 스트링을 추출하고 이것을 테스터가 읽고 이해가 가능한 외국 문자로 전환함)를 작성하는 것이 좋음
• 의사 빌드(즉, 스트링 테이블/파일이 의사 언어 스트링으로 수정된 버전)가 가용하면 테스트스위트(테스트케이스)를 사용하여 코드에 테스트를 수행함. 의사 언어에 나타나지 않는 스트링이 있으면 결함으로 기록(스트링이 의사 언어에 있지 않는 것은 그것이 리소스 파일에 포함되지 않았다는 것이고 따라서 프로그램에 하드코딩 되었음을 의미)
• 주기적으로 이런 의사 언어 빌드를 생성하고 이를 테스트 함으로써 모든 프로그램 스트링이 리소스 파일로 분리되었음을 보장할 수 있게 됨(즉, 현지화가 간편해짐)

4) 외국 문자(Foreign Characters) 테스팅

• 다양한 문자 집합(character sets)을 테스트하기 위해서 프로그램을 지원할 각 로컬(locale)의 현지화된 플랫폼 상에서 테스트한다. 즉, 이 플랫폼들 상에서 텍스트 데이터를 받아들이는 프로그램의 모든 부분에 외국 문자를 입력하고 프로그램이 데이터를 제대로 처리하는지 확인한다.
• Windows 상에서 유럽 또는 라틴 문자를 입력하기 위해서 Windows의 Character Map 도구 또는 확장 비트열(escape sequences)을 사용할 수 있다.
• 데이터 입력 필드에 입력된 데이터가 화면 상에 정확하게 디스플레이 되는 것뿐만 아니라 데이터베이스(또는 다른 저장 장치)로 정확하게 전달되는 것도 확인해야 함. 이를 위해 데이터베이스를 직접 확인하거나 또는 데이터베이스로부터 데이터를 꺼내 화면상에 디스플레이 하는 프로그램의 뷰/보고서 기능을 이용함

5) 2바이트 중복 문자(Double-Byte Overlapping Characters)

• 2바이트 언어 사용시 중복 문자의 테스트가 필요함. 중복 문자는 사용되는 컨텍스트(1바이트 또는 2바이트)에 따라 하나 이상의 문자로 매핑될 수 있는 값들을 의미함. 예, 백슬래시 문자의 ASCII 값이 0x5C인데 이 16진수 값을 2바이트 문자의 꼬리 바이트로 사용하는 여러 일본어 문자가 존재함
• 0x5C가 2바이트 문자의 일부로 사용된 경우에 프로그램이 이를 백슬래시로 인식하면 문제가 야기됨. 예를 들어, 사용자가 파일을 하드 드라이브에 저장하도록 하는 커스톰 다이얼로그를 가진 Windows 프로그램에서 일본어 사용자가 0x5C 문자를 포함하는 스트링을 커스톰 파일 다이얼로그에 입력. 이 다이얼로그가 문자의 마지막 바이트를 백슬래시로 해석한 경우 Windows 파일명에서 백슬래시 문자 사용이 지원되지 않으므로 파일 저장이 실패하게 됨
• 0x5C가 유일한 중복 값은 아니지만 Windows 시스템에서는 이것이 주로 문제를 야기함(백슬래시로 잘못 해석될 때 디스플레이 문제뿐만 아니라 기능 문제도 야기). Linux, *BSD, UNIX 같은 플랫폼에서는 코멘트를 나타내는데 사용되는 “#” (0x23) 문자가 문제를 야기할 수 있음

6) 키보드

• 소프트웨어가 해외 플랫폼을 지원하도록 하려면 해외 키보드를 사용해서도 테스팅 해야 함. 많은 외국 키보드가 영어 키보드에서는 가용하지 않은 고유 기능들을 가지므로 지원할 각 로컬에 대한 최소 하나의 키보드를 준비하고 이를 사용하여 제품을 테스트할 것을 권장
• 예를 들면, 포르투갈 시스템 상의 외국어 데이터가 영어 키보드를 사용하여 정확하게 입력되는 것을 확인하고 제품이 고객에게 인도되었지만 브라질 현지에서 포르투갈어 키보드를 사용하는 사용자에 의해 설치되었을 때 C Cedilla (Ç) 문자를 입력할 수 없는 프로그램을 저자가 경험한 적이 있음

7) 인쇄와 문서 크기(Printing and Paper Sizes)

• 나라 마다 각기 다른 표준 문서 크기를 가짐. 미국에서 가장 흔히 사용되는 문서 크기는 “Letter(8½ X 11)”이지만 많은 나라에서 ISO 크기인 A4를 표준 문서 크기로 사용함
• 프로그램이 보고서 같은 인쇄 기능을 포함한다면 지원할 로컬에서 흔히 사용되는 문서 크기로 인쇄하여 해당 기능을 테스트해야 한다.
• 프로그래머가 적절한 경계와 레이아웃을 가진 보고서가 생성되도록 하는데 있어 자국에서 흔히 쓰이는 문서 크기만 고려하는 바람에 다른 문서 크기로 인쇄하면 프로그램 보고서가 보기에 좋지 않은 문제가 종종 발생

8) 정렬(Sorting)

• 외국어는 영어와는 다른 정렬 규칙을 사용해서 정렬됨. 예를 들어, 독일어에서 문자 ö가 문자 o와 나란히 나오도록 정렬되지만 스웨덴에서는 ö가 알파벳 맨 끝에서 정렬됨(즉, 문자 z 이후)
• 때때로 같은 언어 내에서 다수의 정렬 규칙이 있기도 함(예, 스페인어와 독일어). 따라서 제품이 지원하기로 결정한 정렬 규칙에 따라 정렬 기능을 테스트할 필요가 있음
• 예를 들면, 스페인어는 ‘전통식 정렬’과 ‘현대식 정렬’의 두 가지 정렬 규칙을 가짐. 이름 Cecil, Charles, Cynthia가 전통식 정렬 규칙을 따르는 경우 {Cecil, Cynthia, Charles} 순서가 되지만 현대식 정렬 규칙을 쓰면 {Cecil, Charles, Cynthia} 순서가 됨
• 나라와 언어 마다 알파벳을 다르게 정렬하므로 프로그램의 데이터베이스(또는 기타 다른 데이터 저장 장치)가 각 로컬에서 사용되는 정렬 규칙에 따라 정렬된 데이터를 현지 고객에게 제시하는지를 테스터가 확인해야 함

9) 필터링과 검색 기능(Filtering and Searching functionality)

• 데이터를 수집하고 조작하는데 사용되는 프로그램은 대개 데이터 검색과 필터링 기능을 제공함. 글로벌 소프트웨어 테스터는 프로그램의 검색 및 필터링 기능이 외국 문자와도 정확하게 동작하는지 확인해야 한다.
• 프로그램의 필터링과 정렬 기능 관련 주로 목격되는 문제는 외국 텍스트에 있는 액센트 기호를 무시하는 것이다. 예를 들어, 사용자가 단어 “Wörd”로 데이터베이스 검색을 하는 경우 검색 기능이 “Wörd” 뿐만 아니라 (아마도 사용자가 의도하지 않았던) “Word”, “Wórd”, “Wõrd” 같은 단어들도 제공함
• 필터링도 검색과 비슷하게 동작되지만 데이터 조작이 좀 더 영구적인 측면을 가짐. 대개 검색은 매번 수동으로 수행되어야 하지만 필터는 그 기준을 프로그램 내에 저장하고 버튼 클릭이나 간단한 태스크 수행을 통해 저장된 필터를 데이터에 적용할 수 있음
• 필터를 지원하는 대부분의 프로그램이 사전 정의된 빌트인 필터들을 가짐. 직접 구축하여 수동으로 저장한 커스톰 필터를 테스트 하는 것도 중요하지만 프로그램 내에 포함된 빌트인 필터를 체크하는 것도 중요(종종 개발자가 사전 정의된 필터에 국제 문자 지원을 포함하는 것을 잊어버리므로 반드시 체크해야 함)

10) 단축키(Shortcut Keys)와 연상기호(Mnemonics)

• 단축키는 마우스로 메뉴 항목을 클릭하지 않고도 프로그램 내에서 특정 태스크를 수행하게 하는 기능키나 키조합이다. 예, Microsoft Word에서 ‘맞춤법/문법 검사기’를 불러오는 F7키, 아래 그림의 메뉴 예에서는 Ctrl + N, Ctrl + O, Ctrl + S가 단축키임
• 니모닉은 메뉴 항목, 버튼, 기타 다른 윈도우 콘트롤 상에 등장하는 밑줄 그어진 문자임. 예, 아래의 Microsoft Word File 메뉴에서 “New”의 ‘N’이나 “Close”의 ‘C’가 니모닉임. 활성화를 위해 메뉴 커맨드, 버튼 등에 있는 밑줄 그어진 문자와 ALT 키를 함께 누른다.
• 니모닉은 외양뿐만 아니라 기능 측면에서도 단축키와 약간 다름. 단축키는 메뉴가 열려 있지 않아도 단순히 키 조합을 눌러 프로그램의 어디서든 활성화될 수 있지만, 메뉴 니모닉은 해당 니모닉을 포함하는 메뉴가 열려 있지 않으면 활성화될 수 없음
• 니모닉과 단축키 둘 다 스트링이므로 현지화 대상 리소스 파일에 포함된다. 즉, 번역자가 외국 스트링에 매치되도록 프로그램의 단축키와 니모닉을 변경할 수 있으며 때때로 이게 문제를 야기함. 예, 번역자가 동일한 니모닉을 같은 메뉴의 다른 두 개 메뉴 항목에 할당
• 현지화 업자가 메뉴 스트링의 어떤 문자에 밑줄이 쳐질지 단순히 변경함으로써 니모닉을 변경할 수 있음. 단축키 스트링도 현지화 업자에 의해 변경될 수 있지만 개발자가 해당 단축키와 연관된 ID에 변경을 가해야만 함. 이런 이유로 단축키와 그 ID가 안 맞는(out of sync) 경우가 발생함

11) 날짜(Date)와 시간(Time)

• 아래 예처럼 국가마다 다른 날짜와 시간 형식을 사용하므로 국제적 프로그램의 모든 시간 및 날짜 필드를 테스트할 필요가 있음. 예, 독일 사용자가 날짜 13.05.03를 입력 시 프로그램이 2003년 5월 13일 대신 2003년 13월 5일로 해석하는 일이 없도록 확인
• 프로그램이 달력을 포함하는 경우 달력 형식도 테스트가 필요함. 미국에서는 일요일이 한 주의 첫 번째 날로 달력의 맨 좌측 열에 나오지만 월요일을 첫 번째 날로 여기는 나라에서는 달력의 맨 좌측 열에 월요일이 오고 일요일은 맨 우측 열에 위치함
• 시간 형식에서 일부 나라는 12시간제를 선호하고 반대로 24시간제를 선호하는 나라도 있지만 어떤 형식을 쓰든 컴퓨터에게는 마찬가지임. 시간 형식은 컴퓨터 안정성 이슈라기 보다는 문화적 편의에 관련됨
• 단, 스웨덴의 시간 형식이 시간과 분을 구분하는데 콜론 대신 마침표를 사용하는 것은 주의가 필요. 이 구분 토큰이 프로그램 내에서 문제를 야기할 수도 있으므로 제품을 스웨덴에서 판매할 계획이라면 프로그램이 콜론 말고 타 구분자(delimiters)도 인식할 수 있는지 확인해야 함(대부분의 현대식 운영체제가 이런 구분자를 처리해 주지만 그래도 항상 체크하는 편이 좋음) 

12) 통화(Currency)

• 대부분의 나라가 고유의 통화 심볼을 가지며 이들 대부분이 다루기 쉽지만 비교적 최근 금융 시장에 추가된 유로(€)는 예외임. 세계에서 사용되는 무수한 코드페이지와 인코딩으로의 신규 추가이기 때문에 일부 플랫폼과 프로그램이 유로를 지원하지 않을 수도 있음. 따라서 내 프로그램이 유로를 지원하는지 항상 확인하는 것이 좋다.
• 프로그램에서 통화 단위를 받아들이는 위치 뿐만 아니라 비밀번호의 일부나 기타 다른 입력 데이터에 유로 문자를 사용하는 것도 좋은 생각임(유럽 지역의 사용자가 비밀번호나 서술문 등에 유로 심볼을 사용할 수도 있으므로 프로그램이 모든 곳에서 이를 지원하는지 확인할 필요가 있음)
• 또한 프로그램이 유로를 지원은 하지만 제대로 디스플레이는 못할 수도 있으므로 이 두 가지 측면을 모두 테스트 해야 한다.

13) 숫자(Numbers)

• 통화나 숫자에서 천 단위와 소수 값을 나타내는데 사용되는 심볼도 확인이 필요. 예를 들면, 미국에서는 1백만이 1,000,000.00으로 작성되지만 독일과 프랑스에서는 같은 숫자가 1.000.000,00으로 작성된다(즉, 마침표와 쉼표의 의미가 뒤집어짐)
• 테스팅 동안 숫자 및 통화 값이 검증 대상 언어에 따라 정확하게 작성되었는지 확인하고, 또한 프로그램이 다른 형식으로 작성된 숫자들과 정확하게 동작하는지 확인해야 한다.

14) 주소, 우편번호, 전화번호

• 국제적인 소프트웨어가 주소 관련 기능을 포함한 경우 외국 주소가 입력될 수 있고 데이터베이스로부터 조회될 수 있는지 확인해야 함
• 전화번호도 로컬에 따라 형식이 다름. 종종 프로그래머가 입력 필드에 전화번호 길이를 제한하는 마스크를 씌우고 자동으로 하이픈과 괄호 문자를 제공함. 이게 좋은 기능이지만 국제적으로는 잘 동작되지 않음. 따라서 프로그램을 다양한 전화 번호 형식으로 테스트 할 필요가 있다.

15) 철자(Spelling), 문법(Grammar), 기타 언어적 고려사항(Other Language Considerations)

• 프로그램에서 사용된 번역의 맞춤법과 문법은 대개 언어전문가를 고용(계약 용역)하여 확인하므로 테스터가 크게 걱정하지 않아도 됨
• 특정 문화에 고유한 관용어나 구어 표현을 프로그램이 너무 많이 사용하면 다른 나라의 사람들이(심지어 같은 언어권 사용자라도) 이해하지 못할 수 있으므로 자제해야 함. 특히, 헬프 파일에서 이해가 어려울 수 있는 구어체나 관용구가 쓰였는지 찾아 바로잡는다.
• 이런 관용어 표현 문제는 소프트웨어를 타 언어로 번역하려 할 때 더욱 악화되므로 속어, 관용어, 말장난, 어떤 문화에 특정한 용어들은 피하는 것이 좋다.
• 소프트웨어가 약어(abbreviations)와 두문자어(acronyms)를 사용 시 사람들이(특히 비영어권 사용자) 이를 이해할 수 있도록 설명이 충분히 되는지 확인한다. 예 “Domain Name Server”의 두문자어 DNS

16) 브랜드명(Brand Names)과 전문 용어(Terminology)

• 컴퓨터 분야의 프로그램 혁신이나 기술을 가리키는 영문 용어를 글자 그대로 외국어로 번역하면 이해가 어렵거나 전혀 말이 안 되는 결과를 얻기도 함. 따라서 이런 전문 용어들은 영어 그대로 두고 관련 문서에서 그 의미를 설명하는 편이 좋음
• 번역된 기술 및 사유 용어(technical and proprietary terms)를 테스트에서 발견하면 결함으로 지적하고, 또한 이런 용어집을 만들어 소프트웨어 번역을 시작하기 전에 현지화 업자에게 제공하는 것도 바람직함

17) 프로그램에서 아시아 언어 텍스트

• C 프로그래밍 언어는 “string” 데이터 타입이 없고 대신 character array에 스트링 변수를 저장함(즉, 스트링의 개별 문자를 어레이의 각 컴포넌트에 저장). 문제는 이 char 어레이의 각 컴포넌트가 1바이트 만을 담을 수 있는데 아시아어는 문자마다 2바이트를 필요로 함
• 많은 개발자가 이 이슈를 인지하고 있고 많은 프로그래밍 도구가 2바이트 문자로 인한 문제를 피할 수 있는 좋은 방법을 제공함. 하지만 아시아 언어로 제품을 테스트 시 텍스트가 정확하게 디스플레이 되지 않고 무의미한 쓰레기 문자처럼 보인다면 프로그램이 스트링을 저장하기 위해 char array를 사용하는 문제일 수 있다.

18) 데이터베이스

• 프로그래밍 언어의 변수와 데이터 타입처럼 데이터베이스도 데이터 필드 관련 유사한 개념을 가짐. 즉, 한 종류의 데이터만 받아들이도록 데이터 필드를 설정할 수 있음
• 간혹 프로그래머가 데이터베이스로 데이터를 정확하게 전달하지 못하거나 또는 데이터베이스 필드 타입 자체가 외국 데이터를 정확하게 처리하지 못할 수도 있다.
• 테스터가 데이터베이스에 접근이 가능한 경우면 데이터베이스를 열고 외국 데이터의 유효성을 직접적으로 테스트 할 수 있고(물론 테스터가 SQL이나 기타 다른 쿼리 방법에 익숙해야 함), 또는 프로그램 내에 구축된 데이터 조회 기능을 사용하여 데이터의 테스트를 수행할 수 있다.
• 둘 중 어떤 방법을 선택하던 데이터베이스가 외국 날짜 형식, 스트링, 주소 등을 지원하는지 그리고 이것들이 프로그램으로 정확하게 오고 가는지 확인해야 함
• 데이터가 프로그램에 의해서는 정확하게 처리되었지만 데이터베이스가 특정 외국 데이터를 정확하게 처리하도록 올바르게 구성되지(configured) 않아서 데이터가 데이터베이스로 들어간 후 훼손되는 프로젝트를 저자가 경험한 적이 있음

19) 사계(Seasons)

• 사계가 다른 지역에서 다른 시기에 나타나므로 국제적인 소프트웨어의 이슈가 될 수 있다(세계의 많은 지역에서는 12월에도 눈이 내리지 않음).
• 예를 들면, 달력의 달을 계절 아이콘으로 나타내는 소프트웨어 제품은 7월에는 아이들이 햇볕 아래 뛰어 노는 장면을 보여주고 12월은 눈사람과 목도리를 디스플레이 함. 즉, 아이콘과 그래픽이 사용자가 사는 지역의 계절에 종속적임
• 이렇게 기후에 따라 선택되는 그래픽과 아이콘을 소프트웨어가 포함하는 경우 해당 제품을 현지에 인도하기 전에 계절이 정확하게 반영되는지 고려해야 함

20) 측정치(Measurements)

• 테스팅에서 측정치가 외국 시장에서 사용되는 올바른 표준으로 디스플레이 되는지 확인한다. 예를 들어, 온도를 나타내는 경우 머신 로컬에 기반하여 섭씨(Celsius) 또는 화씨(Fahrenheit)로 정확하게 디스플레이 되는지 확인 

21) 표시(Signs), 상징(Symbols), 색(Colors)

• 소프트웨어에서 특정 기능을 나타내기 위해 툴바 버튼, 위자드 이미지, 그래픽 등에 때때로 표시/상징을 아이콘으로 사용함. 소프트웨어 테스팅 시 특정 나라나 문화에 고유한 표시/상징을 조심해야 함(즉, 부적절한 그래픽 사용을 통해 외국 고객을 혼동시키거나 무례를 범하지 않도록 주의)
• 저자가 경험한 어떤 서버 제품에서는 빨간 동그라미 표시를 사용해 에러가 발생했음을 나타내고 녹색 ‘X’ 표시로 모든 것이 정확하게 동작했음을 알림. 교통 신호 색깔에 기반한 이런 표시가 미국에서는 별 문제 없을 수 있지만 빨간색과 녹색이 성공/실패와 연관되지 않는 일본에서는 문제가 됨. 오히려 일본에서는 ‘X’ 모양이 실패를 나타내고 동그라미는 성공이나 정답을 상징하므로 정반대의 의미로 혼동을 유발
• 여러 다른 문화에서 가지는 표시, 상징, 색깔의 다양한 의미를 이해하는 것이 좋지만 개인이 이를 일일이 알기는 어려움. 따라서 현지화 업자와 이런 이슈를 논의하고, 소프트웨어의 그래픽을 검토하여 겨냥한 외국 시장에 맞지 않으면 개선을 제안해 달라고 현지화 업자에게 요청하는 방법을 권장함