วิธีคิด Bug Severity 🐞📲 #doppiotech #QA #tech #softwaretester #regression #testing #De…

Doppio_Toasty-EDlT0R

QA

March 24, 2026

Table of Content

แนวคิดการกำหนด 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 และนักพัฒนาสามารถจัดลำดับความสำคัญของงานได้อย่างมีประสิทธิภาพ และลดความขัดแย้งในการทำงานร่วมกันได้

Related Blog

Other

QA career — Soft Skill กับ Attitude นั้นสำคัญไฉน

จากประสบการณ์การทำงานมา 20 ปีของพี่ (พูดแล้วก็รู้สึกแก่ 😅) ทำงาน QA มาตั้งแต่เรียนจบเป็น Junior ตัวกระจ๊อย จนมาทำงานในบริษัทยักษ์ใหญ่ สร้างทีม QA ร้อยกว่าคน จนสร้างบริษัทที่มี QA ร่วม 200 คน สิ่งที่สังเกตุเห็นมาตลอดและแอบเป็นสิ่งน่าเศร้าคือ ไม่ค่อยมีใครสอน หรือ พูดถึงความสำคัญของ Attitude หรือ Soft skill ที่จำเป็นสำหรับสายงานนี้ (จริงๆคือไม่ค่อยเห็นการพูดถึงเรื่องพวกนี้ในงาน Tech ทั้งหมดด้วยแหล่ะ) ทั้งๆที่มันเป็นสิ่งสำคัญมากนะ เริ่มตั้งแต่ทำให้คนๆนึงได้งาน ถัดมามันเป็น skill ที่ทำให้คนๆนั้นอยู่รอดกับการทำงานในช่วงแรก และในที่สุดมีส่วนสำคัญในการแยกความแตกต่างระหว่าง QA ธรรมดาที่เดินไปถึงจุดตัน (ถึงแม้จะมี technical skill ที่ดีเยี่ยมก็ตาม) กับ QA ที่เติบโตไปเรื่อยๆจนเป็น A player ใน market ทุกวันนี้ส่วนตัวพี่เอง แทบไม่ได้สอน Technical skill ให้น้องๆด้วยตัวเองละนะเพราะมีคนช่วยสอนเยอะหล่ะ แต่จะใช้เวลาส่วนใหญ่ในการค่อยๆสอน Soft Skill…

QA

Dev ส่งงานไม่ทัน ทำยังไงกะ QA ดี#doppiotech #softwaretester #สายเทค #QA #testing #DEV

เมื่อ Dev ส่งงานไม่ทัน... ควรทำอย่างไรกับ QA? ในสถานการณ์ที่ Developer (Dev) เล็งเห็นว่าไม่สามารถส่งงานได้ทันตามกำหนดเวลา สิ่งสำคัญไม่ใช่การปกปิดปัญหา แต่คือการบริหารจัดการร่วมกับทีม โดยเฉพาะฝ่ายประกันคุณภาพ (QA) ซึ่งมีแนวทางที่น่าสนใจดังนี - การสื่อสารที่โปร่งใสและตรงไปตรงมา: ทีมที่มีประสิทธิภาพควรมีการสื่อสารกันอย่างชัดเจน เมื่อรู้ว่างานจะล่าช้า Dev ควรเดินเข้าไปแจ้ง QA พร้อมขอโทษและระบุระยะเวลาที่คาดว่าจะดีเลย์ (เช่น ล่าช้าไป 2 วัน) เพื่อให้ทุกฝ่ายเตรียมตัวรับมือได้ทัน - การทำ Impact Analysis ร่วมกัน: แทนที่จะปล่อยให้ QA ต้องทดสอบตามแผนเดิมทั้งหมด Dev และ QA สามารถนำ Test Case มาพิจารณาร่วมกันเพื่อวิเคราะห์ผลกระทบ เช่น จากเดิมที่มี 500 เคส Dev สามารถช่วยระบุได้ว่าโค้ดส่วนไหนที่แก้ไขแล้วมีความเสี่ยงต่ำ เพื่อพิจารณาคัดเลือก Test Case บางส่วนออก ช่วยลดระยะเวลาในการทดสอบลงได้ - Dev…

Automation Test

เขียน Code เก่ง ใช่ว่าจะทำ Test Automation ได้ดี

บทความนี้เขียนสำหรับน้องๆสาย Automation หรือน้องๆที่กำลังศึกษาเพื่อก้าวเข้ามาในสาย Test Automation นะครับ เท่าที่เห็นส่วนใหญ่ๆเวลาเริ่มศึกษาหรือทำงานไปซักพัก เราจะ focus อยู่แค่ ใช้ framework อะไร ใช้ภาษาอะไรเขียน แล้วก็ไปเรียนการเขียนภาษานั้นๆ พอเรียนพอฝึกไปซักพัก เขียนได้คล่องก็ อุ๊ย เก่งแล้วเรา เขียน Automate ได้หล่ะ ของ web หรือ mobile app ผมได้หมด ส่งงานมาเลยพี่ ผมพร้อม! เอาจริงๆ ถ้ามาได้ถึงขั้นนี้ ก็ควรภูมิใจจริงๆหล่ะนะ แต่ว่า ถ้าหยุดอยู่แค่นี้ เราก็ทำได้เหมือนคนอีกหลายพันหลายหมื่นคน (และคนหลายพันหลายหมื่นคนที่ทำระดับนี้ได้ กำลังเพิ่มขึ้นเรื่อยๆทุกวัน) จากประสบการณ์ที่เห็นมา คนที่ทำ Automate ได้เจ๋งเนี่ย เขียน code/script automate ได้ คือ พื้นฐานที่จำเป็นต้องมี แต่บทความนี้จะพยายามเล่าถึงส่วนอื่นๆที่จะทำให้เราก้าวไปอยู่ในระดับถัดไปได้ให้ฟังละกันนะครับ ยกตัวอย่าง ถ้าเรามี website ซื้อของ online ตัวนึง…