Report ที่เราใช้เวลาครึ่งวัน นั่งสรุปผลเทส ใส่ตาราง ใส่กราฟ อย่างดี
แล้วก็ส่งออกไปให้ทีม ให้หัวหน้า ให้ผู้บริหาร หรือใครที่เกี่ยวข้อง
แล้วก็จบงานของเรา
ถามหน่อยว่า มีใครเคยกลับมาดูมั้ยคะ ว่ามีคนอ่านจริงกี่คน แล้วมีกี่คนที่ได้ประโยชน์จาก report ตัวนั้น
บางคนอาจจะคิดว่าเพราะคนอื่นไม่สนใจงาน QA ไง งานเรามันลูกเมียน้อยอยู่แล้ว
แต่ลองกลับมามองดู report ที่เราส่งไปมั้ยคะ ว่ามันเป็นข้อมูลอะไร
มันเป็น “บันทึกว่าเราทำอะไรไปบ้าง”
หรือเป็น “ข้อมูลที่ช่วยให้ใครซักคนเอาไปตัดสินใจต่อได้”
.
❌ Sprint นี้ เขียน Test Case ไป 312 เคส เทสไปแล้ว 290 เคส
เหลือ edge case บางข้อที่ยังทำไม่ได้
เจอบั๊ก 45 ตัว ปิดไปแล้ว 43
ถามว่าอ่านจบแล้วยังไงต่อ…
คำตอบคือ “ไม่รู้”
ทั้งๆ ที่ตัวเลขในนั้นก็ถูกหมด ไม่มีอะไรผิดซักนิด
.
✅ Sprint นี้เทสไปแล้ว 80% ของ scope
Flow หลักที่สำคัญ Login, Checkout, Payment ผ่านครบทุกเคสแล้ว
เหลือ edge case ที่ความเสี่ยงต่ำ
บั๊กที่เหลืออยู่ 2 ตัว เป็น minor ทั้งคู่ แก้ตามไปทีหลังได้
ถ้าต้อง release พรุ่งนี้ ก็ออกได้ แต่ต้องโน้ตความเสี่ยง เรื่อง edge case ที่ยังไม่ได้เทสไว้ด้วย ต้องแจ้ง customer support ให้ช่วยเตรียมรับมือ เผื่อเกิดปัญหา
ส่วนที่เหลือน่าจะใช้เวลา 2 วันในการเคลียร์ให้จบ
.
ข้อมูลชุดเดียวกัน แต่เล่าคนละแบบกัน ไม่ต้องให้คนอื่นมาแปลว่าตัวเลขนั้นหมายความว่าอะไรสำหรับเค้า
เพราะคนอื่นที่ไม่ใช่ QA อาจจะไม่ได้เข้าใจตัวเลขนี้เหมือนกันกับเรา
นี่คือความต่างระหว่าง report ที่บอกว่าเราทำอะไรไปบ้าง
กับ report ที่จะช่วยให้คนอื่นตัดสินใจต่อได้
.
ลองมาดูตัวอย่าง metric ที่ใส่แล้วมีคนเอาไปใช้ต่อได้จริงกันดีกว่าค่ะ
เผื่อใครคิดไม่ออกว่าจะใส่อะไรลงไปดี ก็มาหยิบไปใช้ได้เลย
.
🚦 1. Release พร้อมรึยัง แบบที่ไม่ใช่ฟีลลิ่ง
น่าจะเป็นคำถามที่โดนถามกันบ่อยๆ ใช่มั้ยคะ “พร้อม release รึยัง” “ปล่อยได้เลยมั้ย”
แล้วเราก็อาจจะตอบว่า “น่าจะโอเคนะคะ”
แล้วไอ้ “น่าจะโอเค” เนี่ย มันมาจากไหน
วิธีที่ดีกว่าคือ เราตกลงเกณฑ์กันให้ชัดตั้งแต่แรกไปเลยค่ะ ว่าคำว่า “พร้อม” ประกอบไปด้วยอะไรบ้าง
เช่น
📍 ต้องไม่มี Critical Bug เหลืออยู่
📍 Test Case ที่เป็น High Priority ต้องผ่านทั้งหมด
📍 Execution ต้องเกิน 80%
พอจะ Release เราก็มาดูได้เลยว่า พร้อมหรือไม่พร้อม แล้วที่ไม่พร้อมมันเพราะอะไรกันแน่
👉 แบบนี้ทีมก็ไม่ต้องเดา และ เราก็ไม่ต้องแบกการตัดสินใจเอาไว้คนเดียว
.
🔁 2. Reopen Rate งานถูกส่งกลับไปกลับมากี่รอบ
ไม่ใช่แค่การแก้บั๊กอย่างเดียวนะคะ แต่มันคือ งานที่เคยส่งไปแล้ว แต่ต้องวนกลับมาทำใหม่
แล้วมันก็เกิดได้ทุกจุดในงานของเราเลยค่ะ
📍 บั๊กที่เคยปิดไปแล้ว กลับมาเจออีก
📍 Story ที่แก้บั๊กตรงนี้ ไปงอกบั๊กใหม่ ปิดไม่ได้ซักที
📍 งานที่ส่งไปกี่ครั้ง ก็ไม่ผ่าน UAT เพราะไม่ตรง business requirement
ตัวเลขนี้สำคัญมากเลยนะคะ เพราะมันบอกอะไรเราได้เยอะเลย
สมมติว่ามีงาน 45 ตัว แล้วมี 9 ตัวที่ต้องส่งกลับไป นั่นคือ 20% เลยนะคะ
แปลว่า ในงาน 5 ชิ้น จะมี 1 ชิ้น ที่ต้องทำสองรอบ
พอไล่ดู อาจจะไปเจอว่า เพราะเราไม่ได้คุย requirement กันให้เคลียร์ตั้งแต่แรก ทุกคนเลยตีความ acceptance criteria กันไปคนละแบบ
👉 แบบนี้เราก็จะไปคุยกับทีมได้เลยว่าจะไปแก้ปัญหาตรงไหน เพื่อให้ลดงานลงได้ ไม่ใช่ไปบอกว่าทีมทำงานไม่ดีเลยบั๊กเยอะ
.
⏱ 3. Turnaround Time งานไปกองอยู่ตรงไหน
เวลาเฉลี่ยที่งานนั้นอยู่ในแต่ละขั้นตอน
เช่น ตั้งแต่ Ticket ถูกส่งมาที่ QA จนเทสเสร็จ
ตั้งแต่ Bug ถูก report ไปจนถูกปิด
แล้วเราก็จะเอามาดูต่อได้ว่า แล้วมันไปอยู่ตรงไหนนานผิดปกติ
ถ้าบั๊กส่วนใหญ่ใช้เวลาเฉลี่ย 6 วัน กว่าจะปิดได้ แต่พอไปดูจริงๆ กลายเป็นว่า dev แก้ 1 วัน QA เทสอีก 1 วัน อีก 4 วันคืองานกองอยู่เฉยๆ รอให้หยิบไปเทส
👉 ตัวเลขนี้อาจจะไม่ได้แปลว่าเราทำงานช้า แต่อาจจะหมายถึงงานเข้ามาเร็วกว่าที่ทีมรับไหว ซึ่งเป็นข้อมูลที่เอาไปคุยเรื่องจำนวนคน หรือ การจัด priority ต่อได้ ไม่ต้องแบกความรู้สึกผิดเอาไว้คนเดียว
.
🕐 4. Time to Detect เจอบั๊กช้าไปกี่วัน
บั๊กตัวเดียวกัน เจอตั้งแต่ตอน dev เพิ่ง commit โค้ด กับ เจอตอนก่อน release 1 วัน
ราคาในการแก้บั๊กนั้น ต่างกันมหาศาล
สมมติมีบั๊กเกิดขึ้นมาตั้งแต่ตอนโค้ดถูก merge ตอนวันจันทร์ แต่เรามาหาเจอตอน regression วันศุกร์
แปลว่า ทั้งสัปดาห์นั้นทีมเขียนโค้ดทับของที่พังอยู่แล้ว พอมาเจอตอนวันศุกร์ก็อาจจะงงว่ามันเกิดจากโค้ดตรงไหนกันแน่ และอาจจะเสียเวลาเพิ่มขึ้นจนต้องเลื่อน release นั้นทั้งรอบ
แต่ถ้าเจอหลัง merge เลย อาจจะใช้เวลาแก้แค่ 20 นาทีก็ได้
👉 ตรงนี้แหละที่จะเอาไปใช้ได้ ตอนจะขอเวลาทำ automation test หรือ shift left เพราะเราไม่ได้จะไปขอ tool ใหม่อย่างเดียว แต่มีตัวเลขรองรับว่าตอนนี้เรารู้ตัวช้าไปเฉลี่ยกี่วัน แล้วแต่ละวันที่ช้าไป มันแลกมาด้วยอะไรบ้าง
.
🚨 5. Escape Rate บั๊กหลุดไปถึงลูกค้ากี่ %
บั๊กที่เจอบน production เทียบกับ บั๊กทั้งหมดที่เจอ
ตัวนี้เป็นตัวเลขที่แปลงเป็นเงินได้ตรงที่สุด เพราะมันกระทบกับลูกค้าโดยตรง
ถ้า release ที่แล้วมีบั๊กหลุดไป 10 ตัว จากทั้งหมด 100 ตัว คิดเป็น 10% แล้วตัวเลขนี้มันไม่ใช่แค่บั๊กที่หลุดออกไป แต่มันอาจจะหมายถึง ยอด refund + เวลาของทีม support + รีวิว 1 ดาว เพราะลูกค้าไม่พอใจ
👉 ถ้าเราบอกว่า ตอนนี้ ทุก 10 บั๊ก มี 1 ตัวที่ลูกค้าเจอก่อนเรา แล้วก็เล่าต่อว่า จะลดมันยังไง ด้วยวิธีแบบไหนได้บ้าง ถ้าใครจะของบหรือเวลามาทำอะไรซักอย่าง ตัวนี้ก็จะช่วยได้
.
⚠️ แต่! ต้องระวังด้วยนะคะ
อย่าเอา metric พวกนี้ไปผูกกับ objective หรือ KPI ของแต่ละคน
เพราะมันจะกลายเป็นว่าเราจะเริ่มทำทุกทางเพื่อให้ตัวเลขมันดูดี อาจจะไม่ยอมเปิดบั๊ก หรือไม่ยอมอัพเดตสเตตัส ทุกคนจะเริ่มกลัวว่าจะเป็นความผิดของตัวเอง
Metric ที่ดี ต้องมีไว้ใช้ส่องหาจุดที่ระบบพัง
ไม่ใช่เอาไว้หาว่าใครผิด
.
QA ทั่วไป รายงานแค่ทีมทำอะไรไปบ้าง ตัวเลขเป็นเท่าไหร่ แต่ไม่รู้ว่ามีใครเอาไปใช้อะไรต่อได้บ้าง
แต่ QA ร่างทองจะทำ report ที่บอกทีมว่าสถานการณ์ตอนนี้เป็นยังไง ตัวเลือกมีอะไรบ้าง ความเสี่ยงคืออะไร และต้องไปแก้ปัญหาที่จุดไหน
ความต่างมันไม่ได้อยู่ที่ tool หรือ จำนวนตัวเลขที่ดึงมาใช้นะคะ
แต่มันอยู่ที่ว่าเรามองตัวเองแบบไหน และเข้าใจที่มาที่ไปของตัวเลขนั้นรึเปล่า
.
ก่อนจะใส่ตัวเลขไหนลงไป อย่าลืมถามตัวเองก่อน
“ตัวเลขนี้มีความหมายว่าอะไร และช่วยในการตัดสินใจยังไงได้บ้าง”
ถ้าตอบไม่ได้ ก็แปลว่ามันไม่ควรอยู่ใน report ของเราค่ะ
เราไม่ได้ต้องการแค่ตัวเลขเยอะๆ สวยๆ แต่เราต้องการตัวเลขที่ช่วยให้ทีมตัดสินใจได้