ดินแดนเล็กกับรหัสพิเศษเป็นกลุ่มที่ทีมมักมองข้ามเพราะมีผู้ใช้น้อย แต่กลับเป็นกลุ่มที่ให้ผลตอบแทนสูงที่สุดในการทดสอบ เพราะดินแดนเหล่านี้มีลักษณะที่ต่างจากประเทศขนาดใหญ่ในหลายมิติพร้อมกัน และมักมีโครงสร้างข้อมูลของตัวเอง
ดินแดนใดที่ทำให้ข้อมูลผิดบ่อยที่สุด?
กลุ่มแรกคือดินแดนที่มีสถานะกึ่งอิสระ ซึ่งไม่ใช่ประเทศเต็มรูปแบบแต่ก็ไม่ได้เป็นส่วนหนึ่งของประเทศอื่นในทุกด้าน กลุ่มนี้ทำให้เกิดคำถามว่าควรรวมไว้กับประเทศแม่หรือแยกเป็นรายการต่างหาก
กลุ่มที่สองคือดินแดนที่มีระบบของตัวเอง เช่นมีหน่วยเงิน ระบบรหัสไปรษณีย์ หรือระบบหมายเลขโทรศัพท์เป็นของตัวเอง การมีระบบของตัวเองทำให้การรักษาข้อมูลเป็นรายการแยกมีเหตุผลมากกว่าการรวม
กลุ่มที่สามคือดินแดนที่ถูกอ้างถึงด้วยชื่อที่เคยเป็นทางการในอดีต ซึ่งยังคงอยู่ในข้อมูลเก่าและในความเข้าใจของผู้ใช้บางกลุ่ม
กลุ่มที่สี่คือดินแดนที่ระบบส่วนกลางยังไม่รู้จัก แต่ผู้ใช้พยายามกรอกเข้ามา ซึ่งเป็นกรณีที่ทดสอบเส้นทางที่ระบบต้องตอบอย่างสุภาพ การมีดินแดนเหล่านี้ในชุดทดสอบยังบังคับให้ทีมทบทวนหลักเกณฑ์การเลือกพื้นที่ตั้งแต่ต้น ซึ่งมีอธิบายไว้ในบทความวิธีเลือกประเทศ สำหรับข้อมูลทดสอบ
สิ่งที่ทั้งสี่กลุ่มมีร่วมกันคือไม่มีคำตอบสำเร็จรูป และต้องอาศัยการตัดสินใจที่บันทึกไว้เป็นลายลักษณ์อักษร
ทำไมบางแห่งจึงไม่มีรหัสสองตัวอักษรของตัวเอง?
เพราะระบบรหัสถูกออกแบบให้ครอบคลุมหน่วยทางภูมิศาสตร์และการปกครองในระดับหนึ่ง ไม่ได้ออกแบบให้ทุกพื้นที่ย่อยมีรหัสของตัวเอง พื้นที่บางแห่งจึงปรากฏอยู่ในระบบเฉพาะในฐานะส่วนหนึ่งของหน่วยที่ใหญ่กว่า
ความหมายในทางปฏิบัติคือการตรวจว่าเป็นรหัสสองตัวอักษรที่ถูกต้องไม่เพียงพอที่จะบอกว่าข้อมูลนั้นถูก เพราะการไม่มีรหัสไม่ใช่ความผิดพลาดของผู้ใช้
อีกกรณีที่ต้องระวังคือรหัสที่เคยถูกใช้และถูกยกเลิกไปแล้ว ซึ่งยังคงอยู่ในข้อมูลเก่า การปฏิเสธรหัสเหล่านี้ทันทีจะทำให้ข้อมูลที่เคยถูกต้องอ่านไม่ได้
ระบบรหัสยังมีรหัสที่สงวนไว้สำหรับการใช้งานภายในและการอ้างอิงที่ไม่ใช่หน่วยภูมิศาสตร์จริง การนำรหัสเหล่านี้ไปใช้แทนรหัสของพื้นที่จริงเป็นความผิดพลาดที่ทำให้ข้อมูลสับสน
แนวทางที่ปลอดภัยคือแยกความหมายของการไม่มีรหัสออกจากความหมายของรหัสที่ผิด และเก็บข้อมูลเดิมไว้ให้อ่านได้แม้รหัสจะถูกยกเลิกแล้ว
ควรจัดการชื่อเดิมและชื่อที่ผู้ใช้เรียกเองอย่างไร?
ชื่อเดิมและชื่อที่ผู้ใช้เรียกเองเป็นข้อมูลที่ต้องถูกจัดการ ไม่ใช่ถูกปฏิเสธ เพราะผู้ใช้ที่กรอกชื่อเดิมมักไม่ได้กรอกผิด แต่ใช้ชื่อที่ตัวเองรู้จัก
แนวทางที่ได้ผลคือการมีรายการเทียบที่เก็บชื่อเรียกหลายแบบไว้คู่กับรหัสของพื้นที่ แล้วใช้รายการนี้ในการค้นหาและการตีความข้อมูลที่นำเข้า
สิ่งที่ต้องระวังคือการรวมชื่อที่คล้ายกันโดยอัตโนมัติ ซึ่งอาจรวมพื้นที่ที่ต่างกันจริงเป็นรายการเดียว การให้ระบบเสนอตัวเลือกให้ผู้ใช้ยืนยันปลอดภัยกว่าการตัดสินใจแทน
เมื่อไม่สามารถระบุได้อย่างมั่นใจ การตอบอย่างสุภาพพร้อมขอให้ผู้ใช้ยืนยันจะดีกว่าการเดา เพราะการเดาผิดจะสร้างข้อมูลที่ดูถูกต้องแต่ผิด
ประเด็นเรื่องการจับคู่ชื่อและการจัดการชื่อเรียกหลายแบบมีรายละเอียดในบทความการจับคู่ชื่อประเทศกับชื่อเรียกอื่น
ทำไมต้องแยกสถานะไม่เกี่ยวข้องกับยังไม่ทราบ?
เพราะสองสถานะนี้ตอบคำถามต่างกัน สถานะไม่เกี่ยวข้องบอกว่าไม่มีสิ่งที่ต้องหา ส่วนสถานะยังไม่ทราบบอกว่าเรายังไม่ได้หา
เมื่อสองสถานะนี้ถูกเก็บเป็นค่าเดียวกัน รายงานจะแสดงงานค้างที่ไม่มีอยู่จริง และจะไม่มีใครเห็นความบกพร่องจริงที่ซ่อนอยู่
ในทางกลับกัน ถ้าเก็บสถานะไม่เกี่ยวข้องเป็นค่าว่างธรรมดา ระบบจะไม่สามารถแยกได้ว่าผู้ใช้ข้ามช่องนี้ไปหรือพื้นที่นี้ไม่มีช่องนี้ตั้งแต่ต้น ซึ่งทำให้การตรวจความจำเป็นของช่องทำไม่ได้
การแยกสองสถานะนี้ยังมีผลกับการส่งออกข้อมูลด้วย เพราะผู้รับข้อมูลปลายทางต้องรู้ว่าค่าที่หายไปหมายถึงอะไร จึงจะตัดสินใจได้อย่างถูกต้อง
ในทางปฏิบัติ สถานะทั้งสองควรเป็นค่าที่ระบุได้ชัดเจน ไม่ใช่ค่าที่เกิดจากการไม่มีข้อมูล และควรมีชื่อที่ผู้ใช้เข้าใจได้ ไม่ใช่รหัสภายใน
การไม่รองรับต่างจากรูปแบบผิดอย่างไร?
ทั้งสองกรณีทำให้การบันทึกไม่สำเร็จเหมือนกัน แต่สาเหตุและทางแก้ต่างกันคนละทาง
การไม่รองรับเป็นเรื่องของความสามารถของธุรกิจ ซึ่งไม่เกี่ยวกับข้อมูลที่ผู้ใช้กรอก และไม่มีอะไรให้ผู้ใช้แก้
รูปแบบผิดเป็นเรื่องของข้อมูลที่ผู้ใช้กรอก ซึ่งผู้ใช้แก้ได้ และไม่เกี่ยวกับความสามารถของธุรกิจ
เมื่อรวมสองกรณีเป็นข้อความเดียว ผู้ใช้จะพยายามแก้ข้อมูลซ้ำแล้วซ้ำอีกโดยไม่รู้ว่าปัญหาอยู่ที่อื่น และทีมสนับสนุนจะไม่สามารถแยกได้ว่าควรตอบอย่างไร
สิ่งที่ต้องมีคือสถานะที่แยกประเภทในระบบ ข้อความที่แยกกันบนหน้าจอ และการบันทึกเหตุผลของการปฏิเสธไว้เพื่อตรวจสอบย้อนหลัง
การปฏิเสธที่สุภาพและบอกสาเหตุได้ยังช่วยลดจำนวนครั้งที่ผู้ใช้ติดต่อฝ่ายสนับสนุนด้วย เพราะผู้ใช้รู้ว่าต้องทำอะไรต่อ
| สถานะที่ระบบตอบ | สาเหตุที่แท้จริง | ผู้ใช้ต้องทำอะไร |
|---|---|---|
| ไม่รองรับพื้นที่นี้ | ข้อจำกัดของธุรกิจ | เปลี่ยนปลายทางหรือยกเลิก |
| รูปแบบข้อมูลไม่ถูกต้อง | ข้อมูลที่กรอก | แก้ข้อมูลแล้วส่งใหม่ |
| ยังไม่ทราบผล | ระบบยังยืนยันไม่ได้ | รอหรือติดต่อฝ่ายสนับสนุน |
| ต้องยืนยันพื้นที่ | ชื่อที่จับคู่ได้ไม่ชัดเจน | เลือกพื้นที่ที่ถูกต้อง |
และเมื่อจำนวนพื้นที่ลักษณะนี้เพิ่มขึ้นจนต้องดูแลพร้อมกัน วิธีจัดระเบียบข้อมูลจะต่างจากตอนที่มีเพียงไม่กี่แห่ง และต้องอาศัยค่าคงที่ที่ใช้ได้กับทุกพื้นที่
สำหรับนักพัฒนา: เตรียมชุดตัวอย่างคงที่สำหรับดินแดนเล็ก
ข้อแรกคือเลือกดินแดนตัวอย่างจำนวนน้อยที่ครอบคลุมลักษณะต่าง ๆ และใช้ชุดเดิมทุกครั้งในการทดสอบ เพราะการเปลี่ยนชุดไปเรื่อย ๆ ทำให้ผลการทดสอบเทียบกันไม่ได้
ข้อที่สองคือเขียนข้อกำหนดเฉพาะของแต่ละตัวอย่างไว้ เช่นช่องใดไม่เกี่ยวข้องกับดินแดนนั้นและช่องใดบังคับเพื่อให้เห็นชัดว่าอะไรคือพฤติกรรมที่คาดหวัง
ข้อที่สามคือทดสอบรหัสที่ถูกยกเลิกและรหัสที่ระบบไม่รู้จัก โดยคาดหวังว่าระบบจะตอบอย่างสุภาพและไม่ล้มทั้งกระบวนการ
ข้อที่สี่คือเก็บรหัสที่ผู้ใช้เลือกไว้พร้อมชื่อ ณ เวลาที่บันทึก เพื่อให้เอกสารเก่ายังอ่านได้ถูกต้องเมื่อข้อมูลหลักเปลี่ยนไป
ข้อที่ห้าคือหลีกเลี่ยงการใช้ข้อมูลของบุคคลหรือองค์กรจริงเป็นตัวอย่าง แม้ว่าดินแดนนั้นจะมีผู้ใช้จริงอยู่ก็ตาม
ก้าวต่อไป
เริ่มจากการเปิดรายการพื้นที่ทั้งหมดที่ระบบของทีมรองรับ แล้วทำเครื่องหมายว่าพื้นที่ใดมีระบบของตัวเองและพื้นที่ใดไม่มี ถ้าพบพื้นที่ที่สถานะยังไม่ชัด ให้ตัดสินใจและบันทึกเหตุผลไว้ทันที
ถ้าต้องการดูว่าพื้นที่และภูมิภาคถูกจัดเรียงไว้อย่างไร หน้าประเทศและภูมิภาคบนเว็บไซต์นี้จัดกลุ่มรายการตามภูมิภาคและแสดงข้อมูลของแต่ละแห่งในตารางเดียว และกรณีที่ต้องอ้างอิงหลายพื้นที่พร้อมกันในรายการเดียวมีอธิบายไว้ในบทความสถานการณ์ที่อยู่ข้ามพรมแดน
ตัวอย่างดินแดนในบทความนี้เป็นกรณีขอบที่ผู้เขียนประกอบขึ้นเพื่อสาธิตการจัดการข้อมูล ไม่ได้อ้างอิงการกำหนดรหัสหรือสังกัดของพื้นที่ใดที่มีอยู่จริง