Technical

Severity vs Priority เรื่องเส้นผมบังภูเขาที่ QA หลายคนยังสับสน เคยเถียงกับ Dev หรือ PO เรื่อง Severity หรือ Priority กันมั้ยคะอันนี้คนนั้นบอก Critical คนนี้บอกไม่ใช่ Medium ก็พอ อีกคนบอก ไว้แก้รอบหน้าก็ได้ ตรงนี้คนไม่ได้ใช้เยอะขนาดนั้น แล้วสรุปใครถูก… ในฐานะที่เป็นคนที่ต้องใส่ Severity ลงไปใน Bug Ticket ของเราเนี่ย เราจะเชื่อใครดี แล้วเราจะรู้ได้ยังไงว่าทีมควรจะแก้เรื่องนี้ “เดี๋ยวนี้” เลย หรือ”รอก่อน” ก็ได้ จริงๆแล้วปัญหานี้แก้ได้ง่ายมาก ถ้าเราแยกคำว่า Severity และ Priority ให้ขาดค่ะ 🔥 1. Severity = ความรุนแรง ผลกระทบที่มีต่อระบบว่ารุนแรงแค่ไหน เราต้องลองถามตัวเอง หรือถามทีมดูว่า บั๊กนี้มีพลังทำลายล้างมากแค่ไหนระบบพังแค่ไหน กระทบฟีเจอร์อื่นมั้ย หรือไปขวางการทำงานของระบบอื่นหรือเปล่า ตัวอย่างเช่น: กด Save

คิดว่าทุกคนต้องเคยเป็นแบบนี้ เราเทสงานอยู่ดีๆ หน้าจอก็ขึ้น loading ไม่หยุดหรือไม่ก็มี error ตัวแดงเด้งขึ้นมา แล้วทุกอย่างก็ระเบิด เทสต่อไม่ได้  แล้วสิ่งแรกที่เราทำก็คือ วิ่งไปโวยวายกับ Dev (หรือทัก slack) แล้วก็บอกว่า  “หน้า xxx มันพังค่ะพี่” ทีนี้เราอาจจะได้คำถามกลับมาจาก Dev ว่า  “พังยังไง”“หน้าจอโชว์อะไร”“ใส่ data ไม่ถูกรึเปล่า” แล้วเราก็ได้แต่ทำตาปริบๆ ไม่รู้จะตอบยังไงสุดท้ายก็ต้องรอให้ Dev มาเช็คให้ เสียเวลาทั้งคู่ ตรงนี้แหละ คือเส้นแบ่งระหว่าง QA ทั่วไป กับ QA ที่ดี QA ร่างทองที่เราอยากจะเป็นกันQA ที่ดี จะไม่ทำแค่รายงานว่าของพัง แต่เราต้องช่วย “วินิจฉัยโรค” เบื้องต้นได้ด้วย สิ่งแรกที่จะช่วยเราได้คือ API Response Code นี่แหละค่ะ หรือบางทีเราก็เรียกมันว่า Status Code วิธีที่เราจะดูมันได้เนี่ย อย่างแรกเลย เวลาเทสงาน ให้เราเปิด