แนวทางในการ log bug report ที่ดี สำหรับ QA

การ log bug อาจจะดูเป็นเรื่องง่ายๆ สำหรับ QA ตาม Steps ที่เราๆทราบกันดีอยู่แล้วซึ่งมีรูปแบบไม่ตายตัว อย่างเช่น

• Title
• Description
• Expected result
• Actual result
• Severity

อย่างนี้ใช่ไหมคะ ?? ถ้าเราเขียนแบบนี้ โอเค มันก็ไม่ผิด แต่!! แต่ว่าในที่นี้เราจะลงลึกไปอีก จะพูดถึงการเขียน Bug เพื่อที่ให้คนอื่น ซึ่งอาจจะไม่ใช่คน IT อ่านแล้วเข้าใจ ทริคง่ายๆตามนี้เลยค่ะ

เขียน 1 Bug ต่อ 1 Report

ไม่ควรนำ bug หลายๆตัวมายำภายใน report เดียว

เพราะอาจจะทำให้เรา focus ไม่หมดทุกจุดได้ ซึ่งการแยก 1 bug /report นั้นจะทำให้เรา focus ได้ถูกจุดง่ายขึ้น

หัวข้อ (Title) ต้องอ่านแล้วเข้าใจ

ผู้อ่านสามารถเข้าใจและจับใจความได้ โดยอ่านแค่ Title เพียงอย่างเดียว อย่างเช่น เขียนบอกว่าเกิด Bug อะไรขึ้น เมื่อเขียนเสร็จแล้ว ก็ลองทดสอบโดยการอ่านแค่ Title เพียงอย่างเดียว แล้วเทสว่าเราเข้าใจไหม ถ้าเราอ่านแล้วงง คนอื่นๆก็จะเหลือหรอคะ lol

Actual result

ผลลัพธ์ที่เกิดขึ้นหลังจากการ take action (ไม่สนว่าผลจะถูกหรือผิด)

Expected result

ผลลัพธ์จริงๆแล้วเนี่ย มันควรจะเป็นอย่างไร

Steps to reproduce

Action ที่ทำแล้วทำให้ Bug เกิดอีกครั้ง ควรเขียนเป็น step 1 , step 2, step 3 ยิ่งละเอียดยิ่งดี

Severity

ระดับความรุนแรงของ Bug อาจจะมีตั้งแต่ minor/ high / medium / critical / suggestion etc. แล้วแต่เราจะกำหนดเลย

• critical >>> ต้องรีบแก้ทันที ถ้าไม่แก้ user จะไม่สามารถใช้งานได้ เช่น User ไม่สามารถ login เข้าระบบได้ / กดปุ่ม Next แล้ว Page error
• high >>> สามารถใช้การ work around แก้ขัดได้
• medium >>> bug ที่ไม่ได้กระทบกับการทำงานหลักๆ
• minor >>> bug ที่เป็นในรูปแบบของพวก optional ต่างๆ เช่น สี / ขนาดอักษร / การวง layout เป็นต้น

Platform/Device

เราควรระบุไปด้วยว่า Bug เนี้ย เกิดจาก device / OS แบบไหน เพื่อที่จะเป็นประโยชน์ต่อการ reproduce bug ได้ เพราะ ต่าง platform ก็อาจจะมี bug ที่ต่างกันได้

File attached

หลักฐานเป็นสิ่งจำเป็นอย่างมาก อย่างเช่น รูปภาพ / video เป็นต้น