การทดสอบฟอร์มใบแจ้งหนี้สำหรับลูกค้าองค์กร ต้องครอบคลุมอะไร

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

ฟอร์มใบแจ้งหนี้ของลูกค้าองค์กรมีฟิลด์อะไรบ้าง?

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

ความท้าทายไม่ได้อยู่ที่จำนวนฟิลด์ แต่อยู่ที่ว่าแต่ละฟิลด์บังคับหรือไม่บังคับต่างกันในแต่ละประเทศและแต่ละประเภทลูกค้า ระบบที่บังคับทุกฟิลด์กับทุกคนจะทำให้ลูกค้าบางกลุ่มกรอกไม่ได้ ส่วนระบบที่ปล่อยว่างทุกฟิลด์ก็จะได้ข้อมูลที่ออกเอกสารไม่ได้จริง

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

ทำไมต้องแยกเส้นทางบุคคลกับองค์กร?

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

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

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

สี่เส้นทางที่มักถูกลืมทดสอบ

ตารางต่อไปนี้สรุปสี่เส้นทางที่ทีมมักลืม ซึ่งเป็นสาเหตุอันดับต้น ๆ ของข้อผิดพลาดที่พบหลังเปิดใช้งานจริง

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

ลูกค้าต่างประเทศเพิ่มความซับซ้อนตรงไหน?

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

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

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

ปัญหาที่เจอบ่อยเมื่อรันทดสอบจริง

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

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

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

ปัญหาข้อที่สี่คือการทดสอบด้วยข้อมูลที่ดูเหมือนจริงเกินไป ทั้งชื่อบริษัทและที่อยู่ที่มีลักษณะเหมือนของจริงทำให้คนทดสอบสับสนและอาจหลุดออกไปในเอกสารที่ส่งหาลูกค้าได้ เรื่องนี้เชื่อมกับแนวปฏิบัติที่อธิบายไว้ในวิธีสร้างข้อมูลสำหรับการทดสอบ

สำหรับนักพัฒนา: เมทริกซ์กรณีทดสอบและความซ้ำซ้อน

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

ในแต่ละช่องของเมทริกซ์ควรระบุสามอย่าง คือ ผลลัพธ์ที่คาดหวัง ข้อความที่ควรแสดงเมื่อไม่ผ่าน และสถานะของรายการหลังส่งฟอร์ม การระบุข้อความที่ควรแสดงไว้ล่วงหน้าช่วยให้ตรวจได้ว่าข้อความที่ระบบตอบกลับตรงกับความตั้งใจจริง ไม่ใช่แค่ผ่านหรือไม่ผ่าน

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

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

เริ่มจากชุดข้อมูลทดสอบชุดเดียว

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

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

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