ทีมที่ดีที่สุดที่พี่กิ่งเคยอยู่
คือทีมที่ QA แทบไม่ได้เปิด bug ticket เลย
.
ไม่ใช่เพราะไม่มีบั๊กนะคะ ก็เจอบั๊กเหมือนปกตินั่นแหละ
แต่เจอปุ๊บ ทัก dev ปั๊บ แล้วก็แก้กันตรงนั้นเลย
คุยกันจบใน Slack ไม่ได้เปิด ticket แล้วไปต่อคิวรอ dev แก้
.
เพราะทีมนั้นทำ shift left กันสำเร็จจริงๆ ค่ะ
dev กับ QA ทำงานเป็นทีมเดียวกัน
ไม่ใช่ “dev ทำเสร็จแล้ว ส่งให้ QA ไปเทสต่อ”
.
พอกลับไปลองแกะดูว่าตอนนั้นเกิดอะไรขึ้น
คิดว่ามี 3 อย่างที่ทำให้มันเป็นไปได้
.
[1] เจอเร็ว ตั้งแต่ของยังอยู่ใน branch
เพราะ QA เทสบน feature branch ได้เลย
มี env ให้เลือก deploy branch ที่อยากเทสได้เอง
ไม่ต้องรอ merge เข้าของกลางก่อน
ของใน sprint ก็ทำ automation คู่ไปด้วยตลอด
แล้วก็รันทุกวัน พอมีอะไรพังก็รู้ตั้งแต่ตอนที่ dev ยังจำได้ว่าเพิ่งแก้อะไรไป
.
[2] คุยเร็ว บั๊กจบตั้งแต่คุยกัน
เวลาเจอบั๊ก ก็ไปบอก dev ให้แก้ได้เลย
ส่วนใหญ่ก็จบตอนที่เดินไปคุย หรือจบใน Slack นั่นแหละ
มี automation อะไรพัง QA เข้าไปเช็ค ถ้าเป็นบั๊กก็บอก dev แก้ แล้วก็จบเลย
เปิด ticket แค่เวลามีบั๊กที่จะเอาไว้แก้ทีหลังก็พอ เพื่อให้เราไม่ลืมกลับไปแก้เฉยๆ
.
[3] process ชัด
มี pipeline ชัดเจน จุดไหนเช็คอะไร แต่ละ environment ใครทำอะไรบ้าง
Cutoff ของแต่ละจุดคือตรงไหน จาก dev env -> integration -> staging -> production
QA จะรู้ตลอดว่าต้องเช็คอะไร พร้อมรึยัง
ก่อนเอาขึ้นแต่ละจุด QA ทุกคนจะบอกว่าของตัวเองพร้อมมั้ย
ทำให้ QA ไม่ได้เป็นแค่คนเช็คของปลายทาง
แต่เป็นหนึ่งในคนที่ร่วมตัดสินใจว่าพร้อมรึยัง
.
ถ้าทีมนี้วัดผลงานด้วยจำนวน bug ticket ที่เปิด
รับรองว่าไม่มีใครผ่าน KPI แน่นอน
แต่ตอนที่ทำงานกับทีมนี้ เป็นช่วงที่รู้สึกว่าสบายมาก
และทุกครั้งที่ release ก็ release กันได้อย่างมั่นใจ
พี่กิ่งเลยคิดว่าจำนวน ticket มันไม่ได้บอกว่า QA คนนั้นเก่งแค่ไหน
แต่มันบอกว่า dev กับ QA ทำงานห่างกันแค่ไหน
ยิ่งเราต้องเปิด ticket ทุกครั้งที่เจอบั๊ก ก็ยิ่งแปลว่า dev กับ QA ทำงานแบบอยู่คนละฝั่ง
เลยต้องส่งของข้ามไปเพื่อไปต่อคิวอีกที
ยิ่งทั้งสองทีมอยู่ห่างกัน ticket ก็ยิ่งเยอะ และก็ยิ่งแก้ช้าตามไปด้วย
.
ถ้าทีมไหนยังทำทั้ง 3 ข้อไม่ได้ ก็ไม่ต้องกังวลไปนะคะ ไม่ใช่เรื่องแปลกเลยค่ะ
เพราะหัวใจสำคัญไม่ได้อยู่ที่เครื่องมือ แต่อยู่ที่เป้าหมายของงาน QA ของเรา
ว่า เราช่วยให้ทีมมี feedback loop ที่เร็วขึ้นได้ตรงไหนบ้าง
และ เราช่วยให้ทีมมั่นใจใน quality ของ product ของเราได้ยังไงบ้าง
.
📌 เริ่มลองง่ายๆ ได้เลย
ครั้งต่อไปที่เจอบั๊ก ก่อนจะเปิด ticket แล้วส่งไปให้ dev ตามปกติ
👉 ลองทักไปคุยกับ dev ก่อนว่าเจอบั๊กตัวนี้ ชี้ให้เค้าเห็นว่าเกิดอะไรขึ้น ทำยังไงถึงเจอ
👉 ถ้าต้องเปิด ticket ไว้ track ก็ค่อยเปิดตามก็ได้
👉 บทสนทนาต้องมาก่อนเสมอ ticket ควรเป็นแค่สิ่งที่เอาไว้ track ไม่ใช่ที่ที่เอาไว้คุยกันค่ะ
แล้วลองสังเกตดูนะคะ ว่ามันจบเร็วขึ้นกว่าเดิมแค่ไหน