Test​ ​Case​ ​คือ​อะไร​ ​และ​เขียน​อย่างไร​ให้​ตรวจ​ ​Requirement​ ​ได้​จริง

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

ส่วนประกอบขั้นต่ำ

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

ภาพที่ 1: ผลคาดต้องมาจากข้อกำหนดที่ตกลง ไม่กำหนดหลังเห็นผลของระบบแล้ว

ตัวอย่างสมมติ: ส่งคำขอ

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

ความผิดพลาดที่พบบ่อย

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

สำหรับรายงาน

แสดง Requirement → Acceptance Criteria → Test Case → ผลจริง อย่างน้อยหนึ่งเส้นทาง หากยังไม่ได้รันทดสอบ ให้ช่องผลจริงเป็น “ยังไม่ทดสอบ” แทนการใส่ผ่านจากผลคาด รายงานควรสรุปข้อบกพร่องที่เหลือและผลกระทบต่อผู้ใช้ด้วย

อ่าน Acceptance Criteria และ Software Testing หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ Test Case ที่ระบุข้อมูลตั้งต้น ขั้นตอน ผลที่คาด และผลจริง ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• The Practical Test Pyramid — ความสัมพันธ์ของกรณีทดสอบกับระดับที่เหมาะสม
• ISTQB: Standard Glossary — คำศัพท์ด้านการทดสอบ