16

ทดสอบซอฟต์แวร์ต่างประเทศ

ผมมีเพื่อนหลายคนที่เป็น STEs (Software Test Engineers วิศวกรทดสอบซอฟต์แวร์) ซึ่งขอไม่ให้ใส่บทนี้ไว้ท้ายสุดสงสัยว่าทำไมผมจึงนำเรื่องนักทดสอบซอฟต์แวร์ไว้ “ท้ายสุด” อย่างที่เป็นอยู่ มีเหตุผลอยู่ 2 ข้อคือ

• เห็นได้ชัดว่าการทดสอบเป็นสิ่งที่มักจะทำหลังจากพัฒนาผลิตภัณฑ์แล้ว มากกว่าจะทำก่อน จึงทำให้การใส่บทนี้ไว้ท้ายสุดเป็นเรื่องสมเหตุสมผล
• งานของนักทดสอบซอฟต์แวร์ จะมีส่วนซ้ำซ้อนกับข้อมูลในบทนี้อยู่มากซึ่งถ้าผมไม่แยกออกมา ก็จะต้องมีการอ้างอิงถึง “เครื่องหมายทดสอบ” เป็นล้านๆแห่งในหนังสือเล่มนี้

ดังนั้นบทนี้จึงเป็นศูนย์รวม สำหรับผู้ที่ทำหน้าที่เป็นนักทดสอบแต่ไม่เคยทำเรื่อง i18N มาก่อนจะได้ไม่ต้องข้ามบทนี้ไป ถ้าคุณเป็นนักพัฒนา คุณก็ควรจะอ่านด้วยเผื่อนักทดสอบซอฟต์แวร์ของคุณตัดสินใจซื้อหนังสือเล่มนี้และคุณต้องการตัดค่าใช้จ่ายจากการนับ bug!

จุดเริ่มต้นที่น่าจะดีที่สุดคือต้องตัดสินใจว่าจะทดสอบอะไร

วางแผนว่าจะทดสอบอะไรบ้าง?

สิ่งที่ผมหยิบยกขึ้นมาข้างต้นเป็นการพูดเพียงเล็กน้อยเท่านั้นเนื่องจากการทดสอบไม่จำเป็นต้องรอจนทำผลิตภัณฑ์เสร็จ แต่เริ่มจากจุดเริ่มต้นเมื่อนักทดสอบซอฟต์แวร์ตรวจสอบข้อกำหนดต่างๆ และกะว่าจะทดสอบเสร็จเมื่อไร ซึ่งเป็นปัจจัยที่สำคัญอย่างยิ่งในการกำหนดว่า จะตัดคุณสมบัติส่วนใดออกบ้าง และอาจจะดีขึ้นสำหรับเวอร์ชั่นใหม่ซึ่งมีเวลาเพิ่มขึ้น บทนี้จึงเป็นประเด็นที่ต้องระลึกถึง

การปรับแต่งคุณสมบัติ (configurations) เพื่อทำการทดสอบทำได้มากมายหลายวิธีผมจะพยายามสรุปวิธีเหล่านี้ไว้ในตารางที่ 16.1

ตารางที่ 16.1 สภาพแวดล้อมที่ใช้ในการทดสอบที่ต้องพิจารณา

เห็นได้ชัดว่าการทดสอบแบบที่ 5ในตารางที่ 16.1 จะพบ bug จำนวนมากที่เกี่ยวข้องกับ i18N แต่ไม่จำเป็นต้องติดตั้งระบบปฏิบัติการเวอร์ชั่นหลายภาษาในการจัดการเรื่องที่คุณต้องระลึกไว้เสมอมี 3 ข้อคือ

1. การทดสอบบน Windows 2000 เป็นวิธีที่ฉลาดและประหยัดที่สุดในการทดสอบพฤติกรรมภายใต้แอปพลิเคชั่นอื่นเนื่องจากคุณสามารถเปลี่ยนตัวเลือกภูมิภาค และภาษาระบบที่เป็นดีฟอล์ทได้ง่ายคุณอาจจะเพิ่มขีดความสามารถในการเปรียบเทียบภาษากับ terminal services ของ Windows 2000
2. เมื่อดูสภาพแวดล้อมแบบอื่นๆอีก 4 แบบในตารางที่ 16.1 จะเห็นว่าจำนวนงานที่ต้องทดสอบมีเพิ่มขึ้นมาก (สิบเท่าหรือมากกว่านั้นกว่าจะถึงแบบที่ 5)
3. จำนวน bug ที่พบ ซึ่งคุณจะหาไม่เจอในการกำหนดค่าแบบอื่น จะลดลงมาก (ปกติจะพบข้อบกพร่องน้อยกว่า 1% ในแบบที่ 5)

เมื่อพูดถึงทั้งหมดแล้วตอนนี้ผมจะมาดูทีละแบบ การตัดสินใจว่าจะต้องทำการทดสอบครอบคลุมมากน้อยแค่ไหน ไม่ได้ขึ้นอยู่กับนักทดสอบซอฟต์แวร์โดยตรงแต่สิ่งสำคัญอยู่ที่งานว่าจะต้องทำมากแค่ไหน จึงจะครอบคลุมผลิตภัณฑ์ทั้งหมดได้ดังนั้นจึงต้องพิจารณาข้อมูลอย่างรอบคอบ และชั่งน้ำหนักกับปัจจัยด้านอื่น เช่นความต้องการของตลาด ให้ดี

แบบที่ 1: การตั้งค่าตามภูมิภาค

Bugs สำคัญที่สุดที่พบสัมพันธ์กับ i18N พื้นฐาน ในส่วนที่ 1 ของหนังสือเล่มนี้ การใส่ข้อมูลถูกต้องไหม และข้อมูลที่ใส่ตามมามีการจัดการและแสดงผลถูกต้องหรือไม่? เรื่องนี้เอาไปใช้กับปัญหาอื่นๆ และเรื่องค่าของวัน/เวลา ค่าตัวเลขและเงินตราได้หรือไม่? จะเกิดอะไรขึ้นเมื่อการตั้งค่าปฏิทินเปลี่ยนไป ?

การทดสอบนี้ควรจะเน้นกับแผงควบคุม (control panel) บ่อยครั้งที่การทดสอบแอปพลิเคชั่นที่ดีที่สุดคือเลือกภาษาเฉเพาะและแปลกในการตั้งค่าภูมิภาค - อาจจะกำหนดรูปแบบขึ้นเองเป็นบางครั้ง เมื่อจะรายงาน bugs จงตรวจสอบให้มั่นใจว่าได้ระบุค่าที่คุณใช้ตั้งไปแล้ว เพราะมันยากที่จะจำได้เมื่อต้องตั้งค่าบ่อยๆไม่มีเรื่องใดที่จะกวนใจนักทดสอบซอฟต์แวร์มากไปกว่า การหา bug พบแล้วและกลับไม่เจอตอนกลับมาหาใหม่อีก!

นอกเหนือจากการทดสอบตั้งค่าที่ต่างกันแล้วการเลือกเน้นค่าซึ่งคุณรู้ว่าจะมีผู้ใช้บางครั้งก็มีประโยชน์แต่อย่าคิดว่าการทดสอบทั่วไปเป็นการเสียเวลา ที่ที่จะพบ bug ได้ดีที่สุดคือในอักขระภาษาถิ่น(locales) ซึ่งไม่มีใครคิดถึงไม่ว่าจะเป็นนักพัฒนาหรือนักทดสอบซอฟต์แวร์นอกจากนั้นยังทำให้คุณมั่นใจมากขึ้นเมื่อพิจารณาตลาดใหม่ๆ

แบบที่ 2: ใส่ค่าท้องถิ่นและเก็บข้อมูล

อาจจะหาบัคทั้งหมดที่พบในแบบที่ 1 ได้นอกจากนั้นคุณยังหาบัคที่สัมพันธ์กับการใส่ตัวอักขระในภาษาถิ่น และการเก็บไว้ตลอดกล่าวโดยทั่วไปแล้วปริมาณงานที่ทำตามแบบที่ 2 ได้ใช้ไปแล้วในแบบที่ 1 ดังนั้นน่าจะพิจารณาให้ครอบคลุมมากขึ้นด้วยค่าใช้จ่ายที่เท่ากันในแง่ของการวางแผน

แน่นอนว่าภาพจำลองสถานการณ์จริงนี้จะเพิ่มขึ้นเป็นทวีคูณ ทันทีที่คุณตกลงจะทดสอบเพิ่มขึ้น คุณจึงต้องแน่ใจว่ามีคนพร้อมและสามารถเปลี่ยน settings ได้สม่ำเสมอ - ในลักษณะงานที่ยุ่งยากกว่าแบบที่ 1

แบบที่ 3: Default System Language

อาจจะหาบัคทั้งหมดที่พบในแบบที่ 1 และ 2 ได้ และอาจจะพบบัคใหม่ๆได้เมื่อหาบัคที่สัมพันธ์กับตัวอักขระในภาษาถิ่นบนหน้ารหัสอื่นๆและเมื่อหาว่าแอปพลิเคชั่นที่ทดสอบนั้น (application under test – AUT) ทำงานอย่างไรกับอักขระในภาษาถิ่นเหล่านี้

การวางแผนทดสอบภาษาในตระกูลเฉพาะดูจะมีเหตุผลดังจะกล่าวต่อไปด้านล่าง(แต่ละเรื่องจะประกอบด้วยประเภทของบัคที่พบในภาษาตระกูลอื่นๆ)

• อย่างน้อยหนึ่งภาษาในหน้ารหัสเดียวกันที่ต้องใช้จำนวนพื้นที่สำหรับข้อความ - แตกต่างกันภาษาเยอรมันและภาษาดัทช์เป็นตัวอย่างที่ดี ถ้าคุณเริ่มจากภาษาอังกฤษของสหรัฐอเมริกา และภาษาอังกฤษของสหรัฐก็จะเป็นตัวอย่างที่ดีถ้าคุณใช้ภาษาเยอรมันหรือดัทช์ และต้องการให้มั่นใจว่า dialog นั้นยอมรับได้เมื่อต้องใช้พื้นที่ลดลง
• อย่างน้อยหนึ่งภาษาบนหน้ารหัสอื่น - กรีก รัสเซียน และเตอร์กี เป็นตัวอย่างที่ดี ถ้าคุณเริ่มจากสหรัฐหรือยุโรปตะวันออก
• อย่างน้อยภาษาในเอเชีย 1 ภาษา - จีน ญี่ปุ่น และเกาหลีเป็นตัวอย่างที่ดีโดยภาษาญี่ปุ่นเป็นภาษาที่มักจะถูกเลือกบ่อยที่สุด
• อย่างน้อยภาษาแบบสองทาง ภาษา - อาราบิกและฮิบรูเป็นตัวอย่างที่ดี แม้ว่าอาราบิกมัจะพบบัคได้บ่อยกว่าเนื่องจากลักษณะของอักขระในภาษาฮิบรูจะมีกฎเรื่องรูปร่างของอักขระน้อยกว่าซึ่งมีผลกระทบต่ออักขระในภาษานั้น
• อย่างน้อยภาษาลายมือเขียนแบบซับซ้อน 1 ภาษา - ไทยและเวียตนามเป็นตัวอย่างที่ดี เพราะมีรูปร่างการเขียนอักขระและกฎในการแบ่งบรรทัดที่ซับซ้อน ซึ่งเหมาะสำหรับทดสอบการทำงานของแอปพลิเคชั่น
• อย่างน้อยภาษารหัสเดี่ยว (Unicode) - ฮินดีเป็นตัวอย่างที่ดี

คุณไม่จำเป็นต้องเลือกทุกแบบ เช่นถ้าคุณไม่ได้วางแผนใช้เวลาไปกับส่วนที่ 2ของหนังสือเล่มนี้ และสนับสนุนแอปพลิเคชั่นมัลติมีเดียมากนักคุณก็ต้องใช้เวลากับภาษาแบบ Unicode ให้มาก (อาจสรุปว่าใช้ไม่ได้ผล!)

แบบที่ 4: ระบบปฏิบัติการแบบ Faux-Localized

การทดสอบแบบนี้จะหาบัคทั้งหมดในแบบที่1 2 และ 3 ได้ (แม้ว่าจำนวนบัคที่หาได้ในแบบที่ 3 จะมากเท่าไรนั้นขึ้นอยู่กับภาษาที่เลือกใช้)โดยทั่วไปแล้วจะเป็นบัคเพิ่มเติมประเภทอื่น ที่คุณพบว่าสัมพันธ์องค์ประกอบ (รวมทั้งdialog ทั่วไป และ localized components เช่น Internet Explorer หรือ Microsoft Office) ที่มีในระบบปฏิบัติการซึ่งจะแตกต่างกันไปแล้วแต่ภาษา

Windows 2000 Multilanguage User Interface (MUI) และ Office 2000 Language Packs คือวิธีที่เหมาะสมที่สุด (และเป็นเพียงวิธีเดียวเท่านั้น) ที่จะใช้ทดสอบแบบนี้ได้แต่ก็ต้องพิจารณาให้ดีว่าต้องใช้องค์ประกอบเหล่านั้นใน AUT ของคุณหรือไม่

แบบที่ 5: ระบบปฏิบัติการแบบปรับเป็นภาษาถิ่นหมด

การทดสอบแบบนี้เป>็นเป็นการทดสอบขั้นสูงสุดซึ่งจะพบบัคในแบบอื่นๆได้ทั้งหมด (แม้ว่าจำนวนบัคที่หาได้ในแบบที่ 2 จะมากเท่าไรนั้นขึ้นอยู่กับภาษาที่เลือกใช้)ทรัพยากรที่จำเป็นต้องใช้ในการทดสอบแบบนี้มักจะใหญ่เกินกว่าจะพิจารณาในแง่ความเป็นจริงได้แม้คุณจะผลิตภัณฑ์ที่มีขนาดใหญ่มากพอและกำลังวางแผนใช้ระบบอัตโนมัติในการทดสอบก็ตาม

คุณจำเป็นต้องเป็นสมาชิกของ MSDN Universal หรือสมาชิกในสมาคมวิชาชีพเนื่องจากวิธีนี้จะทำให้คุณได้ระบบปฏิบัติการเวอร์ชั่นในภาษาถิ่นต่างๆทั้งหมดการใช้เวลาไปกับการเรียนรู้วิธีตั้งค่าแบบอัตโนมัติเป็นความคิดที่ดีสำหรับภาษาที่คุณไม่รู้จัก เพราะไม่ต้องใช้เวลากังวลมากนักกับ error messages ที่คุณไม่เข้าใจระหว่างการติดตั้ง (เป็นสิ่งที่ผมเรียนรู้จากประสบการณ์!)

เลือกใช้แบบใดแบบหนึ่งจากตารางที่ 16.1

การเลือกว่าจะใช้การทดสอบแบบใดนั้นนับเป็นเรื่องที่ซับซ้อนทีเดียวและคุณแทบจะไม่เจอปัญหา ซึ่งต้องวิเคราะห์ต้นทุน/กำไร ที่ซับซ้อนกว่านี้อีกแล้วโดยทั่วไปการทดสอบส่วนใหญ่ตามแบบที่ 2 ควบคู่ไปกับการเช็คบางจุดตามแบบที่ 3 ก็สมดุลดีแล้วเมื่อคุณเริ่มมีประสบการณ์กับนักพัฒนาและนักทดสอบซอฟต์แวร์ในองค์กรของคุณมากขึ้นคุณจะเริ่มทดสอบผลิตภัณฑ์ได้ล้ำลึกยิ่งขึ้น แต่นักพัฒนาจะต้องเข้าใจเรื่องนี้ด้วยและต้องสร้างบัค i18N ให้น้อยลงด้วย

การติดตั้งแอปพลิเคชั่นที่จะทดสอบ (AUT)

แม้ว่าขั้นตอนนี้จะดูเหมือนเป็นเรื่องซ้ำซากแต่ผมรับรองกับคุณได้เลยว่าไม่ใช่การติดตั้งระบบปฏิบัติการในภาษาถิ่นและการจัดการกับสถานการณ์ต่างๆ เช่นไดเรกทอรี่ปกติ (เช่น Program Files) ซึ่งอาจมีชื่อเป็นภาษาถิ่นเป็นเรื่องสำคัญ

• โปรแกรมอาจไม่ยอมติดตั้งให้ในตำแหน่งที่เหมาะสม
• โปรดแกรมอาจมีปัญหาในการติดตั้ง locations ที่มีอักขระเป็นภาษาถิ่นในพาธนั้น

มีเรื่องหลายๆแบบที่คุณทดสอบได้ในการติดตั้งแต่ละครั้ง

สำหรับสภาพแวดล้อมในการทดสอบขณะติดตั้งแอปพลิเคชั่นที่ใช้ SQL Server นั้น Test Server ของคุณควรจะแยกตัวอักษรเล็กใหญ่ได้เพราะจะช่วยให้เจอปัญหา เช่น อักษร ในภาษาเตอร์กี ซึ่งผมพูดไว้ในบทที่ 4 “เรื่อง User Interface” และบทที่ 12 “Jet, SQL Server และฐานข้อมูลอื่นๆ” การเลือกเซิร์ฟเวอร์ต่างกันอาจพบปัญหาได้เช่นกันการติดตั้ง Test SQL Server ให้เหมาะสมอาจทำให้ไม่พบปัญหาหลายอย่างที่ลูกค้าของคุณอาจจะพบได้ การติดตั้ง SQL Server ใหม่ด้วยประเภทต่างๆเป็นวิธีที่จะหาบัคซึ่งอาจไม่พบได้อย่างดี

การใช้กรณีทดสอบจากต่างประเทศ

เรื่องการทำรายการภาพจำลองการทดสอบ (หรือที่เรียกว่า test breakout ซึ่งมีกรณีทดสอบมากมายนั้น) ไม่รวมอยู่ในหนังสือเล่มนี้ แต่ผมจะคิดเรื่องนี้ไว้ในใจตอนที่คุณสร้างกรณีทดสอบสำหรับ AUT

สิ่งที่ต้องระลึกไว้ในเรื่อง i18N

สำหรับแอปพลิเคชั่นที่ทำใช้ทั่วโลกนั้นคุณควรจะพิจารณาตัวอย่างด้านล่างนี้

• ตรวจสอบทุกที่ที่คุณใส่วันที่ เวลา เงินตรา … หรือจำนวน ในทุกๆที่ที่รับค่าเหล่านี้ใน AUT ตรวจสอบให้แน่ใจว่าคุณใส่ตามรูปแบบที่ถูกต้อง(ดูหน้าต่าง Regional Settings เพื่อหารายละเอียดในภาษาถิ่นที่กำหนด)
• ตรวจที่ที่ AUT ทำการเปรียบเทียบ (comparison) ตรวจสอบ (validation) หรือคำนวณ (calculation) วันที่ เวลาเงินตรา หรือตัวเลขการยอมรับค่าตามรูปแบบที่ถูกต้องไม่ได้รับรองว่าการคำนวณค่าเหล่านั้นจะเข้าใจถึงรูปแบบที่ใช้
• ตรวจสอบทุกที่ที่คุณใส่อักขระในภาษาถิ่นลงไปในช่องใส่ข้อความต้องมั่นใจว่าใส่ทั้งอักขระที่ไม่ใช่ภาษาอังกฤษและที่เป็นภาษาอังกฤษลงไป
• ตรวจสอบให้มั่นใจว่าอักขระในภาษาถิ่นสามารถแสดงทางจอภาพได้ถูกต้องหลังจากพิมพ์แล้ว ถ้าต้องใช้ฟอนต์พิเศษ (เช่น ภาษาญี่ปุ่น) แอปพลิเคชั่นของคุณติดตั้งฟอนต์นี้ลงบนเครื่องหรือยัง? (หรือคุณรับรองได้ว่าฟอนต์นี้มีในการติดตั้ง Windows ทุกครั้ง) ถ้าอักขระในภาษาถิ่นต้องใช้ฟอนต์พิเศษเพื่อแสดงบนจอภาพคุณจะต้องตรวจสอบทุกตำแหน่งที่ข้อความนี้แสดงใน GUI ของคุณ (ปกติแล้วคอนโทรลจะมีคุณสมบัติของฟอนต์ที่อาจจะตั้งแยกต่างหากได้)
• ใส่จำนวนอักขระสูงสุด (ใช้อักขระในภาษาถิ่น) ลงในคอนโทรลที่มีขนาดต่างกันใน GUI เนื่องจากอักขระ Unicode และ DBCs ใช้พื้นที่มากเป็นสองเท่าคอนโทรลอาจจะทำงานได้กับสตริงที่มีขนาดเล็กแต่จะไม่จัดสรรพื้นที่มากพอสำหรับสตริงที่มีขนาดใหญ่
• ระวังปัญหาเรื่องการแสดงผล จากการเปลี่ยน Unicode เป็น ANSI ไม่ดี ซึ่งจะแสดงออกมาเป็นเครื่องหมายคำถามแทนที่จะเป็นอักขระในภาษาถิ่น
• ในบรรทัดเดียวกันระวังปัญหาเรื่องการแสดงผลจากการเลือกฟอนต์ไม่ดีซึ่งมักจะเห็นเป็นรูปแท่งหรือสี่เหลี่ยมแทนที่จะเป็นตัวอักษร
• โดยทั่วไปแล้วข้อความขยะเกิดจากการแปลงค่าจาก ANSI เป็น Unicode ไม่ถูก คุณควรจะระวังเรื่องนี้ให้ดี
• ตรวจสอบให้มั่นใจเท่าที่จะทำได้ว่าข้อมูลที่ควรจะเรียงนั้น ได้รับการเรียงเหมาะสมดีแล้ว
• ถ้าแอปพลิเคชั่นของคุณจะต้องเก็บไว้ตลอด (ไฟล์ ฐานข้อมูล ฯลฯ) ดูให้แน่ใจว่าได้ทดสอบแล้วว่าอักขระในภาษาถิ่นนั้น “round-trip” หมายความว่าพิมพ์เข้า เก็บ เรียกดู และแสดงผลได้ถูกต้องใน GUI
• ถ้าเกิดบัคในข้อมูลที่เป็นภาษาอังกฤษทั้งหมดบนระบบปฏิบัติการที่เป็นภาษาอังกฤษแสดงว่าไม่ใช่ปัญหาของ i18N และต้องระบุไว้ว่าไม่ใช่

สิ่งที่ต้องระลึกไว้เกี่ยวกับ L10N

ในแอปพลิเคชั่นที่ทำเป็นภาษาถิ่นจะมีกรณีทดสอบจำนนมากที่ต้องพิจารณา ดังนี้

• ตรวจสอบแต่ละหน้าต่างแต่ละที่ที่ข้อความนั้นปรากฏสำหรับสตริงภาษาอังกฤษ
• ตรวจสอบ Accelerator Key (ตัวอักขระที่มีเครื่องหมาย underscore ซึ่งให้ผู้ใช้กด ALT+<อักขระ> เพื่อเข้าถึงคอนโทรลดังกล่าว) สำหรับแต่ละคอนโทรลและรายการในเมนูบนหน้าต่าง (บ่อยครั้งเมื่อทำการเปลี่ยนเป็นภาษาถิ่นปุ่มควบคุมหลายปุ่มจะถูกกำหนดค่าเป็นอักษรเดียวกัน ซึ่งทำให้ accelerators สำหรับปุ่มควบคุมซ้อนนั้นไม่ทำงาน)
• ตรวจสอบแต่ละที่ที่ข้อความนั้นปรากฏเพื่อให้แน่ใจว่าไม่ถูกตัดออก เช่นคำที่ไม่ใช่ภาษาอังกฤษส่วนใหญ่จะยาวกว่าคำคำเดียวกันที่เป็นภาษาอังกฤษมาก
• ดู error message แต่ละข้อความ เพื่อให้แน่ใจว่าจัดการกับสตริงนั้นถูกต้องถ้าเป็นไปได้ขอให้เจ้าของภาษาอ่านข้อความในหน้าต่าง เพื่อให้ถูกความหมาย error message หลายข้อความที่เป็นการนำสตริงในภาษาอังกฤษมาผสมกัน (ซึ่งบางอันอาจจะแปลไม่ถูก)ทำให้นำเสนอกับผู้ใช้เป็น 1 สตริง (ซึ่งส่วนใหญ่จะทำให้ผิดความหมายในอีกภาษา) ผมจะพูดถึงปัญหานี้โดยละเอียดในส่วนที่III เรื่อง “ Localization”
• ตรวจสอบภาพในแอปพลิเคชั่นที่ใข้แทนคำกับเจ้าของภาษาถ้าเป็นไปได้ รูปภาพปกติจะไม่ localized แต่อาจจะไม่สื่อถึงสิ่งเดียวกัน หรือเหมาะกับภาษาที่กำหนด เรื่องนี้จะพูดถึงในส่วนที่ III

สิ่งที่ต้องระลึกถึงสำหรับคำที่ซับซ้อนทั่วไป

• เมื่อจัดการกับภาษาที่การผสมตัวอักษรบางอย่างทำให้ผิดกฎหมายมองหาวงกลมที่เป็นเส้นประซึ่งเป็นตัวชี้มาตรฐานสำหรับอักษรที่จะต้องมีอักษรอีกตัวอยู่ด้วย
• ถ้าคุณไม่เข้าใจภาษาจงระวังในการตัดสินใจว่าวิธีจัดการกับภาษานั้นในแอปพลิเคชั่นของคุณไม่ถูกต้อง คนที่รู้ภาษานั้นสำคัญมาก
• มองหาส่วนของข้อความทั้งบนและใต้บรรทัด
• เมื่อต้องจัดการกับภาษา เช่น ภาษาไทยต้องมั่นใจว่าคุณมีคนที่ช่วยตัดคำให้
• คำในภาษาอาราบิกจะเป็นประโยคต่อเนื่อง เช่น أرسل كافة الشوائب، والأسئلة، والاقتراحات، والشكاوى،والتعليقات إلى العنوان: (ในภาษาอังกฤษ ข้อความนี้หมายความว่า “ส่งบัค คำถามคำร้องเรียน และความเห็นทั้งหมดไปที่) ไม่มีช่องว่างระหว้างตัวอักษรในคำ (เหมือนตัวเขียนแบบลายมือในข้อความภาษาลาติน) ดังนั้นจึงต้องระวังคำที่ส่วนใหญ่ดูแยกเป็นอักษรหรืออักขระแต่ละตัว)
• ต้องมั่นใจว่าคนที่รู้ภาษานั้นสามารถตรวจสอบการเรียงคำให้คุณได้
• ถ้าคุณใช้ Windows 2000 และต้องการตรวจสอบการทำงานของคีย์บอร์ดว่าใช้กับคีย์บอร์ดภาษาฮินดีและปุ่ม ได้หรือไม่ คุณอาจลองพิมพ์ v+c+m+d+l+s จะกลายเป็น नमस्ते ซึ่งก็คือคำว่า Namaste ในภาษาฮินดี เป็นคำทักทายปกติ สำหรับการทดสอบในภาษาทมิฬจะต้องพิมพ์ว่า b+C+k+d+k+c+d จะกลายเป็นคำ வணக்கம ซึ่งก็คือคำว่า Vanakam ในภาษาทมิฬ เป็นคำทักทายเช่นกัน ถ้าอักษรหรือเส้นเหล่านี้มองดูแปลกไป แสดงว่า complex script support ทำงานผิดพลาด
• คุณสามารถหาคำที่เหมือนๆกันในภาษาต่างๆที่ต้องการใช้สนับสนุนได้จากลูกค้าหรือ localizer ของคุณ

ที่ที่เราอยู่...

บทนี้มีการพูดหลายเรื่องที่เกิดขึ้นในการทดสอบแอปพลิเคชั่นที่ใช้ทั่วโลกประเด็นต่างๆที่จะต้องพิจารณาอย่างรอบคอบถ้าคุณต้องการขยายตลาดไปทั่วโลกเป็นเรื่องสำคัญที่นักทดสอบซอฟต์แวร์จะต้องระลึกไว้ว่าตนเองคิอคนสำคัญที่สุดในบริษัทที่กำลังขยายตลาดของสินค้า นักทดสอบซอฟต์แวร์คือคนที่จะช่วยประเมินตลาดที่จะเข้าไปบนพื้นฐานความเป็นจริงและความสำเร็จหรือล้มเหลวในตลาดโลกส่วนใหญ่จะอยู่ที่นักทดสอบเหล่านี้ว่าทำงานได้ดีแค่ไหนในการช่วยให้นักพัฒนาทำงานได้อย่างดี

เป็นการปิดท้ายเล่มที่ดี - ด้วยผลิตภัณฑ์ที่นักทดสอบซอฟต์แวร์เซ็นปิดงานนักพัฒนาภูมิใจ และเป็นที่ยอมรับจากลูกค้าทั่วโลกแม้ว่าบางครั้งในความเป็นจริงจะไม่เป็นเช่นนั้นในมุมมองระดับโลกนั้นคุณรับรองได้ว่าคุณจะทำสินค้าที่เข้าใกล้เป้าหมายของคุณมากที่สุด