เช็กลิสต์ทดสอบฟอร์มชำระเงิน ก่อนปล่อยใช้งานจริง

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

ทำไมฟอร์มชำระเงินต้องมีเช็กลิสต์ของตัวเอง?

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

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

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

รายการที่ต้องทดสอบก่อนปล่อย

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

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

ทดสอบเส้นทางที่ถูกปฏิเสธและแรงกดดันของผู้ใช้

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

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

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

กดปุ่มจ่ายเงินซ้ำแล้วจะถูกหักสองครั้งไหม?

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

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

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

ทดสอบการคืนเงินและการยกเลิกรายการ

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

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

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

สำหรับนักพัฒนา: ตารางสถานะและคุณสมบัติไม่ทำซ้ำ

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

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

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

เตรียมข้อมูลทดสอบให้ครบในเครื่องมือเดียว

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

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

ก้าวต่อไป

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