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