การทดสอบการแปลเป็นภาษาท้องถิ่นคืออะไร? ตัวอย่างกรณีทดสอบและรายการตรวจสอบ

การทดสอบการแปล

การทดสอบการแปล เป็นเทคนิคการทดสอบซอฟต์แวร์ซึ่งมีการทดสอบพฤติกรรมของซอฟต์แวร์สำหรับภูมิภาค สถานที่ หรือวัฒนธรรมเฉพาะ วัตถุประสงค์ของการทดสอบการแปลเป็นภาษาท้องถิ่นสำหรับซอฟต์แวร์คือการทดสอบด้านภาษาและวัฒนธรรมที่เหมาะสมสำหรับสถานที่นั้นๆ เป็นกระบวนการปรับแต่งซอฟต์แวร์ตามภาษาและประเทศเป้าหมาย

พื้นที่หลักที่ได้รับผลกระทบจากการทดสอบการแปล ได้แก่ เนื้อหาและ UI

เป็นกระบวนการทดสอบแอปพลิเคชันระดับโลกที่มี UI, ภาษาเริ่มต้น, สกุลเงิน, วันที่, รูปแบบเวลา และเอกสารได้รับการออกแบบตามประเทศหรือภูมิภาคเป้าหมาย ช่วยให้มั่นใจได้ว่าแอปพลิเคชันมีความสามารถเพียงพอสำหรับการใช้งานในประเทศนั้น ๆ

ตัวอย่าง:

1. หากโครงการได้รับการออกแบบสำหรับรัฐทมิฬนาฑูในอินเดีย โครงการที่ออกแบบควรเป็นภาษาทมิฬ ควรมีแป้นพิมพ์เสมือนทมิฬ ฯลฯ

2. หากโครงการได้รับการออกแบบสำหรับสหรัฐอเมริกา ควรเปลี่ยนรูปแบบเวลาตามเวลามาตรฐานของสหรัฐอเมริกา นอกจากนี้รูปแบบภาษาและเงินควรเป็นไปตามมาตรฐานของสหรัฐอเมริกา

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

เหตุใดจึงต้องทดสอบการแปลเป็นภาษาท้องถิ่น?

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

ในการทดสอบประเภทนี้ ผู้ทดสอบหลายรายจะทำซ้ำฟังก์ชันเดียวกัน พวกเขาตรวจสอบสิ่งต่าง ๆ เช่นข้อผิดพลาดในการพิมพ์ ความเหมาะสมทางวัฒนธรรมของ UI ข้อผิดพลาดทางภาษา ฯลฯ

เรียกอีกอย่างว่า “L10N” เพราะมีตัวอักษร 10 ตัวอยู่ระหว่าง L และ N ในคำว่า localization

เบื้องหลังความพยายามนี้ยังมีเหตุผลเชิงพาณิชย์อยู่ด้วยเช่นกัน ฉลากที่แปลผิด หรือวันที่ที่อ่านว่า 03/04 เป็นเดือนมีนาคมแทนที่จะเป็นเดือนเมษายน จะบั่นทอนความเชื่อมั่นในตลาดที่ทีมงานได้ลงทุนไปแล้ว และข้อบกพร่องเหล่านั้นมักถูกพบโดยผู้ทดสอบในพื้นที่เป้าหมาย แทนที่จะเป็นโดยทีมงานภายนอก การทดสอบ GUI แสดงเป็นภาษาอังกฤษ

การทดสอบการแปลภาษาเทียบกับการทดสอบการรองรับหลายภาษา

กิจกรรมทั้งสองอย่างนี้ดำเนินการตามลำดับ ไม่ใช่แข่งขันกัน การทดสอบความเป็นสากล (I18N) ยืนยันว่าโค้ดสามารถรองรับภาษาท้องถิ่นใดก็ได้ จากนั้นการทดสอบการแปลภาษา (L10N) จะยืนยันว่าภาษาท้องถิ่นใดถูกต้อง

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

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

วิธีการทดสอบการแปลเป็นภาษาท้องถิ่น

สำหรับการทดสอบการแปลเป็นภาษาท้องถิ่นทั่วไป เราได้ตั้งค่าการทดสอบการตรวจสอบการสร้าง การทดสอบสมรรถนะ, การทดสอบการถดถอยและการลงนามครั้งสุดท้าย

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

2. การทดสอบปกติเป็นขั้นตอนในการรันกรณีทดสอบปกติและค้นหาข้อบกพร่องของบันทึกระหว่างการดำเนินการ

3. การทดสอบการถดถอยคือ ข้อบกพร่อง กระบวนการถดถอยเพื่อให้แน่ใจว่าข้อบกพร่องได้รับการแก้ไขในขณะที่ไม่มีผลกระทบของข้อบกพร่องคงที่ต่อพื้นที่โดยรอบ

4. Final Sign-off คือการดำเนินการตรวจสอบขั้นสุดท้ายเกี่ยวกับบิลด์ก่อนส่งมอบให้กับลูกค้า

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

ระบบอัตโนมัติในการทดสอบการแปลภาษา

หากโครงการมีขนาดใหญ่และจำเป็นต้องทดสอบบ่อยครั้ง เราก็ทำ การทดสอบระบบอัตโนมัติ.

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

หมายเหตุ Selenium เป็นหนึ่งในเครื่องมือบุกเบิกในด้านนี้ มีฟีเจอร์มากมาย แต่ต้องใช้ความรู้ด้านเทคนิคเพิ่มเติมจึงจะใช้งานได้

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

เครื่องมือทดสอบการแปลภาษา

งานแปลภาษาต้องใช้เครื่องมือสามประเภทที่แตกต่างกัน และทีมส่วนใหญ่มักใช้เครื่องมือทั้งสามประเภทนี้

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

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

รายการตรวจสอบแนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบการแปลภาษา

• จ้างบริษัทที่ให้บริการด้านการแปลและปรับภาษาให้เหมาะสมกับแต่ละประเทศ (localization firm) ที่มีความเชี่ยวชาญด้านวิศวกรรม i18n
• ตรวจสอบให้แน่ใจว่ากลยุทธ์การทดสอบการแปลของคุณช่วยให้มีเวลาสำหรับภาษาแบบไบต์คู่มากขึ้น
• ตรวจสอบให้แน่ใจว่าคุณได้ทำการปรับโค้ดของคุณให้รองรับ DBCS อย่างถูกต้องก่อนใช้งานtracส่งข้อความใดก็ได้เพื่อส่งไปแปล
• แยกข้อความทุกข้อความออกไปเก็บไว้ในไฟล์ทรัพยากรก่อน เพื่อไม่ให้ข้อความที่ผู้ใช้มองเห็นได้ถูกเขียนไว้ในโค้ดโดยตรง
• ควรทำการทดสอบการแปลแบบคร่าวๆ ก่อน เพราะจะช่วยเปิดเผยข้อผิดพลาดเรื่องการตัดคำและการเขียนข้อความตายตัว ก่อนที่จะมีการลงทุนด้านการแปลจริง
• เว้นพื้นที่จัดวางสำหรับส่วนขยายข้อความ เนื่องจากคำแปลจากภาษาอังกฤษมักมีความยาวมากกว่าฉลากต้นฉบับ
• ทดสอบภาษาที่เขียนจากขวาไปซ้าย เช่น ภาษาอาหรับและภาษาฮิบรู บนหน้าจอจริง ซึ่งเป็นที่ที่รูปแบบการกลับด้านและการเขียนข้อความแบบผสมทิศทางมักจะทำให้เกิดปัญหามากที่สุด
• จัดทำคู่มือรูปแบบการเขียนเฉพาะพื้นที่ โดยครอบคลุมลำดับวันที่ ตัวคั่นทศนิยม รูปแบบที่อยู่ คำนำหน้าชื่อ และน้ำเสียง
• ควรให้เจ้าของภาษาตรวจสอบบทภาพยนตร์ที่เสร็จสมบูรณ์แล้ว เพราะความเหมาะสมทางวัฒนธรรมไม่สามารถยืนยันได้จากบทภาพยนตร์เพียงอย่างเดียว

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

ตัวอย่างกรณีทดสอบสำหรับการทดสอบการแปล

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

S.No	กรณีทดสอบ Descriptไอออน
1	อภิธานศัพท์มีไว้เพื่อใช้อ้างอิงและตรวจสอบ
2	เวลาและวันที่ได้รับการจัดรูปแบบอย่างเหมาะสมสำหรับภูมิภาคเป้าหมาย
3	รูปแบบหมายเลขโทรศัพท์เหมาะสมกับภูมิภาคเป้าหมาย
4	สกุลเงินสำหรับภูมิภาคเป้าหมาย
5	ใบอนุญาตและกฎเป็นไปตามเว็บไซต์ปัจจุบัน (ภูมิภาค) หรือไม่
6	เค้าโครงเนื้อหาข้อความในหน้าต่างๆ ปราศจากข้อผิดพลาด ความเป็นอิสระของแบบอักษร และการจัดแนวบรรทัด
7	ฟังก์ชันอักขระพิเศษ ไฮเปอร์ลิงก์ และปุ่มลัด
8	ข้อความตรวจสอบความถูกต้องสำหรับช่องป้อนข้อมูล
9	โครงสร้างที่สร้างขึ้นประกอบด้วยไฟล์ที่จำเป็นทั้งหมด
10	หน้าจอที่แปลแล้วจะมีองค์ประกอบและตัวเลขประเภทเดียวกันกับผลิตภัณฑ์ต้นทาง
11	ทำให้แน่ใจว่าอินเทอร์เฟซผู้ใช้เฉพาะของซอฟต์แวร์หรือแอปพลิเคชันเว็บสามารถเปรียบเทียบกับอินเทอร์เฟซผู้ใช้ต้นทางในระบบปฏิบัติการเป้าหมายและสภาพแวดล้อมผู้ใช้
12	การจัดเรียงและลำดับตามตัวอักษรเป็นไปตามกฎของภาษาเป้าหมาย ไม่ใช่ภาษาต้นฉบับ
13	ภาษาที่เขียนจากขวาไปซ้ายจะแสดงเค้าโครงได้อย่างถูกต้อง รวมถึงการนำทาง ไอคอน และข้อความที่เขียนจากทั้งสองทิศทาง
14	การป้อนข้อมูลผ่านแป้นพิมพ์ การตรวจสอบการสะกดคำ และการค้นหา รองรับอักขระที่มีเครื่องหมายเน้นเสียงและอักขระหลายไบต์

ข้อดีของการทดสอบการแปลเป็นภาษาท้องถิ่น

ต่อไปนี้เป็นประโยชน์ของการทดสอบการแปล

• ลดต้นทุนการทดสอบโดยรวม
• ลดต้นทุนการสนับสนุนโดยรวม
• ช่วยในการลดเวลาในการทดสอบ
• มีความยืดหยุ่นและปรับขยายได้มากขึ้น

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

ข้อเสียของการทดสอบการแปลเป็นภาษาท้องถิ่น

ต่อไปนี้เป็นความท้าทายของการทดสอบการแปล

• ต้องใช้ผู้เชี่ยวชาญโดเมน
• การจ้างนักแปลในพื้นที่มักทำให้กระบวนการนี้มีราคาแพง
• การจัดเก็บอักขระ DBCS แตกต่างกันไปในแต่ละประเทศ
• ผู้ทดสอบอาจเผชิญกับความท้าทายด้านกำหนดการ

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

คำถามที่พบบ่อย