หลายๆทีมคงเป็นแบบนี้กันอยู่ใช่มั้ยคะ ไม่ว่าจะ Dashboard ที่โชว์ ranking ตามจำนวนบั๊กที่หาได้ หรือ KPI ที่วัดจากจำนวน Ticket ที่เปิด 😅
กลายเป็นเราวัดผลงานของ QA กันด้วยจำนวนบั๊กที่หาเจอ
แต่ลองมาคิดดูอีกทีนะคะ
ถ้าทีมส่งมอบ product ออกไปโดยที่ไม่มีบั๊กเลย
QA ในทีมนั้นหาบั๊กได้ 0 ตัว
แปลว่าเขาทำงานได้ดีที่สุด หรือ แย่ที่สุด
บั๊กน้อย อาจไม่ได้แปลว่า QA ทำงานน้อยนะคะ
แต่อาจจะแปลว่า QA เข้าไปช่วยทำให้งานมีคุณภาพมากขึ้น และป้องกันได้ดีตั้งแต่ต้น
ลองเปรียบเทียบสองทีมนี้ดูนะคะ
ทีม A
👉 QA รอของมา -> เข้าไปเทส -> เจอบั๊ก 20 ตัว
👉 แล้วก็ส่งกลับไปให้ Dev แก้
👉 แก้เสร็จเรียบร้อย -> ส่งกลับมาให้เทส -> QA เจอบั๊กอีก 5 ตัว -> ส่งกลับไปอีก -> วนไป 3 รอบ
👉 สุดท้าย Release ช้ากว่าที่แพลนไว้ 1 สัปดาห์
ทีม B
👉 QA เอา scenario ไปคุยกับ Dev ก่อนเริ่มโค้ด -> Dev เข้าใจเคสที่จะเกิดขึ้น -> ป้องกัน Edge Case ไว้ตั้งแต่ต้น
👉 Dev โค้ดเสร็จ -> ส่งมาให้ QA เทส -> เจอบั๊กเล็กๆ 5 ตัว
👉 Dev และ QA เข้าไปช่วยกัน -> แก้และเทสจบได้เลย -> Release ตรงเวลา
สังเกตเห็นอะไรมั้ยคะ
ทีม A หาบั๊กได้ 20 + 5 ตัว
ทีม B หาบั๊กได้ 5 ตัว
ทีมที่หาบั๊กได้น้อยกว่า กลับ Release ได้ตรงเวลากว่า
แล้วทีมไหนทำงานดีกว่ากัน
QA ที่เก่งจริงๆ ไม่ได้วัดกันที่จำนวนบั๊กที่เจอค่ะ
แต่วัดกันที่ 3 อย่างนี้
📌 จำนวนรอบที่ส่งงานไปมาระหว่าง Dev กับ QA
ยิ่งน้อยยิ่งดี แปลว่าเราสื่อสารกันได้ดี ทุกคนเข้าใจตรงกันตั้งแต่ต้น
📌 จำนวน Bug ที่เจอบน Production
เจอน้อย แปลว่า Product ของเราคุณภาพดี ไม่ใช่ QA ไม่ทำงาน
📌 ความมั่นใจของทีมที่มีต่อคุณภาพของ Product
ไม่ใช่ “น่าจะโอเคแหละ” แต่คือ “เราเทสครอบคลุมแล้ว พร้อม Deploy”
ถ้าใครยังวัดผลด้วยจำนวนบั๊ก หรือแข่งกันหาบั๊กอยู่ ก็ลองปรับมุมมองดูนะคะ
เริ่มเข้าไปป้องกันปัญหาตั้งแต่ต้น แทนที่จะรอเจอตอนปลายทางอย่างเดียว
➡️ คิดเรื่องการเทส ตั้งแต่ตอนคุย Requirement
➡️ เอา Scenario ไปคุยกับ Dev ตั้งแต่ก่อนเริ่มโค้ด เพื่อให้เข้าใจตรงกันตั้งแต่ต้น
➡️ สื่อสารปัญหาให้ชัดเวลาเจอบั๊ก ลดการส่งงานกันไปมา
พี่กิ่งมีแจก Bug Report Template ฟรี เพื่อช่วยให้สื่อสารกันง่ายขึ้น มี field ที่ควรใส่ครบ พร้อมตัวอย่างจริงให้เอาไปปรับใช้ได้เลย
แอด LINE OA แล้ว พิมพ์ TEMPLATE เพื่อรับฟรีได้เลยนะคะ 👇
https://lin.ee/PI9jnYm