Software​ ​Testing​ ​คือ​อะไร​ ​และ​ควร​ทดสอบ​ระบบ​ใน​ระดับ​ใด​บ้าง

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

ทดสอบอะไรบ้าง

เริ่มจากกฎธุรกิจและข้อมูลที่ผิดได้ เช่น การคิดเงิน สิทธิ์ผู้ใช้ และการเปลี่ยนสถานะ จากนั้นตรวจการทำงานร่วมกันของ API ฐานข้อมูล และระบบภายนอก สุดท้ายทดสอบเส้นทางสำคัญจากมุมผู้ใช้ เช่น เปิดหน้า กรอก ส่ง และเห็นผล การตรวจด้วยคนยังมีค่ากับความเข้าใจและการเข้าถึงที่ Test Script อาจไม่ครอบคลุม

ภาพที่ 1: แต่ละระดับตอบความเสี่ยงต่างกัน จึงควรเลือกให้สัมพันธ์กับ Requirement

ตัวอย่างสมมติ: ระบบอนุมัติคำขอ

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

วางแผนจากความเสี่ยง

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

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

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

อ่าน Unit, Integration และ E2E และ Test Case หรือดู บริการ Web Application

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

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

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

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

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

• The Practical Test Pyramid — การเลือกความละเอียดของการทดสอบ
• Playwright: Introduction — ตัวอย่างการทดสอบเว็บแบบ End-to-End