แนวคิดการกำหนด Bug Severity: Bugนี้รุนแรงแค่ไหน?
เมื่อเราทดสอบซอฟต์แวร์แล้วพบข้อผิดพลาด (Bug) ปัญหาที่พบบ่อยคือเราไม่แน่ใจว่าจะระบุระดับความรุนแรง หรือ Severity อย่างไรดีเพื่อให้ทีมเข้าใจตรงกัน โดยมีเฟรมเวิร์กหรือคอนเซปต์ง่าย ๆ ที่ประกอบด้วย 2 ปัจจัยหลัก ดังนี้
1. Impact (ผลกระทบ)
เราต้องพิจารณาว่าหากลูกค้าหรือ User มาเจอBugตัวนี้ จะส่งผลเสียมากน้อยแค่ไหน
– ระดับ Critical หรือ High: เช่น เว็บไซต์ Shopping แสดงราคาผิดพลาด ซึ่งส่งผลเสียต่อธุรกิจโดยตรง หรือกรณีการสะกดคำผิดในจุดที่เป็น Branding (เช่น ชื่อแบรนด์ผิด) หรือคำที่มีผลทางกฎหมาย ซึ่งกระทบต่อชื่อเสียง (Reputation) ขององค์กรอย่างมาก
– ระดับ High หรือ Medium: กรณีที่ฟังก์ชันหรือฟีเจอร์บางอย่างใช้งานไม่ได้ แต่ User ยังมีทางอื่น (Workaround) ให้ไปใช้งานฟังก์ชันนั้นจนจบกระบวนการได้
– ระดับ Low (Minor): เช่น การสะกดคำผิดทั่วไปในจุดที่ไม่ใช่ส่วนสำคัญของแบรนด์
2. Probability (โอกาสที่จะเกิดขึ้น)
ปัจจัยนี้เป็นสิ่งที่คนมักลืมคิดถึง คือโอกาสที่ผู้ใช้งานจะไปเจอBugตัวนั้นจริง ๆ มีมากน้อยแค่ไหน
ตัวอย่าง: Bug ที่ทำให้แอปพลิเคชัน Crash (แอปเด้งดับ) ปกติจะมี Impact เป็น Critical แต่ถ้าเงื่อนไขการเกิดคือ “User ต้องกดเปลี่ยนใจที่หน้าชำระเงินซ้ำ ๆ กันถึง 20 รอบ” โอกาสที่ลูกค้าทั่วไปจะเจอเหตุการณ์นี้ก็น้อยมากจริง ๆ
framework สรุป: Severity = Impact × Probability
หาก Bug มี Impact สูง (เช่น App Crash) แต่มี Probability ต่ำมาก (โอกาสเกิดน้อย) ระดับของ Severity อาจจะถูกลดลงมาจาก Critical เหลือเพียง Medium หรือ Low ได้ตามความเหมาะสม
ความแตกต่างระหว่าง Severity และ Priority
อีกหนึ่งคำที่มักมาคู่กันคือ Priority หรือ “Bug ตัวนี้ควรถูกแก้ไขเร็วแค่ไหน” ซึ่งอาจไม่จำเป็นต้องสัมพันธ์กับ Severity เสมอไป
Severity (ความรุนแรง): วัดที่ตัวBugเองว่ามีผลกระทบต่อระบบอย่างไร
Priority (ความสำคัญในการแก้): วัดที่ความจำเป็นเร่งด่วนในเชิงธุรกิจ
กรณีศึกษา: พบBugในหน้าแคมเปญใหม่ที่แสดงข้อมูลผิดพลาด ซึ่งมี Impact รุนแรงระดับ Critical แต่แคมเปญนี้มีกำหนดจะเปิดให้ใช้งานในอีก 3 เดือนข้างหน้า ดังนั้น ณ วันนี้ Priority ในการแก้ไขอาจจะเป็น Low หรือ Medium ก็ได้ เพราะBugนี้ยังไม่มีโอกาสสร้างผลกระทบเชิงลบต่อ User ในปัจจุบันเลย
ดังนั้นการเข้าใจทั้งเรื่อง Impact, Probability และแยกแยะระหว่าง Severity กับ Priority ให้ชัดเจน จะช่วยให้ทีม QA และนักพัฒนาสามารถจัดลำดับความสำคัญของงานได้อย่างมีประสิทธิภาพ และลดความขัดแย้งในการทำงานร่วมกันได้
