Severity vs Priority เรื่องเส้นผมบังภูเขาที่ QA หลายคนยังสับสน
เคยเถียงกับ Dev หรือ PO เรื่อง Severity หรือ Priority กันมั้ยคะ
อันนี้คนนั้นบอก Critical คนนี้บอกไม่ใช่ Medium ก็พอ
อีกคนบอก ไว้แก้รอบหน้าก็ได้ ตรงนี้คนไม่ได้ใช้เยอะขนาดนั้น
แล้วสรุปใครถูก… ในฐานะที่เป็นคนที่ต้องใส่ Severity ลงไปใน Bug Ticket ของเราเนี่ย เราจะเชื่อใครดี
แล้วเราจะรู้ได้ยังไงว่าทีมควรจะแก้เรื่องนี้ “เดี๋ยวนี้” เลย หรือ”รอก่อน” ก็ได้
จริงๆแล้วปัญหานี้แก้ได้ง่ายมาก ถ้าเราแยกคำว่า Severity และ Priority ให้ขาดค่ะ
🔥 1. Severity = ความรุนแรง ผลกระทบที่มีต่อระบบว่ารุนแรงแค่ไหน
เราต้องลองถามตัวเอง หรือถามทีมดูว่า บั๊กนี้มีพลังทำลายล้างมากแค่ไหน
ระบบพังแค่ไหน กระทบฟีเจอร์อื่นมั้ย หรือไปขวางการทำงานของระบบอื่นหรือเปล่า
ตัวอย่างเช่น: กด Save แล้วแอพระเบิดตัวเอง crash ทันที อันนี้ Severity = Critical แน่นอน
ซึ่งระดับ Severity โดยส่วนใหญ่ก็อาจจะแบ่งเป็น 4 ระดับ Critical, Major, Medium, Minor
- 🔴 Critical = พังงงงงงงง แบบแตกระเบิดไม่สามารถใช้อะไรได้เลย เช่นแอพ Crash, Login ไม่ได้ เป็นต้น
- 🟠 Major = รุนแรง แต่ไม่ถึงกับพังทั้งแอพ และส่วนใหญ่จะไม่มี workaround (วิธีอื่นที่ทำให้ใช้งานระบบต่อได้) หรือกระทบกับฟีเจอร์หลักของระบบ เช่น คิดเงินผิด เพิ่มของลงตะกร้าไม่ได้
- 🟡 Medium = ไม่รุนแรงมากมี workaround ในการให้ผู้ใช้งานไปต่อได้ เช่น ที่อยู่ลูกค้าไม่ขึ้นในหน้าสั่งของ แต่ลูกค้ายังสามารถไปดูได้ในหน้ารายการสั่งซื้อ
- 🟢 Minor = เล็กน้อย เช่น สีผิด, ฟ้อนท์ไม่ตรง หรือ Layout ปุ่มไม่ถูก
🚀 2. Priority = ความสำคัญ กระทบกับ Business หรือ ผู้ใช้งานมากแค่ไหน
ตรงนี้เราจะต้องถามว่า สำคัญแค่ไหน ต้องแก้ด่วนแค่ไหน รอได้มั้ย หรือต้อง Hotfix ตอนนี้เลย
Priority ก็จะแบ่งเป็นหลักๆ เป็น High, Medium, Low ตามความเร่งด่วนของงานนั้นๆ
ซึ่งต้องบอกไว้ก่อนว่าชื่อเรียกระดับความรุนแรงของ Severity และ Priority อาจจะแตกต่างกันไปตามแต่ละทีมหรือบริษัทนะคะ
แต่ละที่อาจจะมีระดับมากน้อยไม่เท่ากัน เช่นบางที่อาจจะมี Priority = Lowest สำหรับบั๊กที่เล็กน้อยแบบสุดๆก็ได้
แต่เราสามารถใช้การแบ่งแบบนี้เป็นไกด์ไลน์เบื้องต้นได้
⚡️ ที่นี้… ความงงจะบังเกิด เมื่อสองอย่างนี้สวนทางกัน!
ลองมาดูตัวอย่างกันจะได้เห็นภาพชัดๆ
Bug: สะกดชื่อแบรนด์ผิด จาก “With Natsiree” เป็น “With Natsiroo”
Severity: Low – เพราะทุกอย่างยังทำงานได้ปกติ ลูกค้าเข้ามากดดูเนื้อหา กดซื้อของได้ ไม่มีอะไรพัง
Priority: High – ต้องแก้ด่วน! เพราะเป็นจุดที่ผิดไม่ได้เลย ทำให้ภาพลักษณ์บริษัทเสีย
ลองมาดูอีกเคสกัน
Bug: ปุ่มพิมพ์ใบเสร็จกดแล้ว Error ถ้าเลือกใบเสร็จย้อนหลังมากกว่า 5 ปีขึ้นไป
Severity: Major – ฟังก์ชั่นพิมพ์ใบเสร็จพัง ใช้งานไม่ได้เลย และไม่มีวิธีอื่นในการพิมพ์ได้
Priority: Low – ลองเช็คข้อมูลการใช้งานจริงของลูกค้าแล้ว พบกว่าส่วนใหญ่จะพิมพ์ย้อนหลังไม่เกิน 1 ปี และไม่เคยมีใครพิมพ์ย้อนหลังเกิน 5 ปีเลย
แบบนี้แปลว่าแก้ทีหลังได้ ทีมเอาเวลาไปทำอย่างอื่นที่สำคัญกว่าก่อนได้
💡 เห็นมั้ยคะว่า… บั๊กที่ “รุนแรงมาก” อาจจะไม่ได้ต้อง “รีบแก้ด่วน” เสมอไป
กลับกัน บั๊กที่ดูไม่มีอะไร อาจจะต้องรีบแก้ทันทีก็ได้ เพราะอาจจะกระทบกับภาพลักษณ์หรือรายได้ของบริษัท
Mindset ของ QA ร่างทอง
โดยส่วนใหญ่แล้วในการเป็น QA เรามักจะเป็นคนเคาะ Severity ของบั๊กนั้น เพราะเราคือคนที่รู้ดีที่สุดว่าปัญหานั้นรุนแรงแค่ไหน มีผลกระทบเยอะแค่ไหน
ส่วน Priority เราอาจจะกำหนดไปให้ในเบื้องต้นก่อน แต่ส่วนมากมักจะต้องไปคุยกับทีม และ ฝั่ง Business เพื่อดูบริบทอีกทีว่าบั๊กตัวนี้จะต้องแก้ด่วนแค่ไหน
บางอย่างที่เราเห็นว่ารุนแรงมาก แต่พอไปเช็คกับ Business จริงๆ อาจจะพบว่าลูกค้าไม่ได้ใช้เลยก็ได้
การเป็น QA ที่ดี ไม่ใช่แค่หาบั๊กเจอ แล้วเร่งให้ทีมแก้ทุกตัว แต่เราควรจะต้องเข้าใจบริบทของ Business ด้วย
บางครั้งอาจจะรวมไปถึงการเข้าไปดูพฤติกรรมการใช้งานของลูกค้า หรือดู Data ที่เกิดขึ้นจริง
เพื่อช่วยให้ทีมจัดลำดับความสำคัญได้ถูกต้อง นี่คืออีก Mindset ที่สำคัญของ QA ที่จะช่วยให้ทำงานกับทีมได้อย่างราบรื่นค่ะ
และที่สำคัญ!! เรื่องการจัดการ Defect และไกด์ไลน์วิธีคิดแบบนี้ เป็นหนึ่งในหัวข้อสำคัญที่อยู่ในคอร์ส “Testing the Right Way” ที่กำลังจะเปิดตัวเร็วๆนี้ด้วย
ใครอยากปูพื้นฐานให้แน่น เข้าใจแก่นของการเทสจริงๆ สามารถเข้าไปดูรายละเอียดและลงชื่อใน waitlist ไว้ก่อนได้เลยนะคะ