Hotfix งอก ต้องออกให้ได้ภายในวันนี้
แล้วทุกคนก็หันมาถาม QA ว่า จะเทสเสร็จกี่โมง
.
เป็นเรื่องที่เจอกันบ่อยจนกลายเป็นเรื่องปกติไปแล้วค่ะ
ไม่ใช่แค่ hotfix ด้วย
บางทีก็เจอว่างาน delay จนของมาถึง QA ช้าไปหลายวัน
แต่ release date ก็ยังต้องเป็นวันเดิม
เวลาเทสน้อยลง
แต่งานที่ต้องเทสมันก็ยังเท่าเดิม
.
ที่เป็นแบบนี้ ไม่ใช่เพราะทีมทำงานไม่ดี
แต่เพราะงานเทสมันมักจะอยู่ท้ายสุด
พอมีจุดไหนช้า มันก็สะสมมา จนไหลมากองที่ QA ทุกที
และที่เจอบ่อยคือ เราก็จะพยายามเทสทุกอย่าง โดยที่เวลาเหลือน้อยลง
สุดท้ายก็ได้แต่เทสไปแบบไม่มั่นใจ
แล้วก็แบกความเสี่ยงเอาไว้เงียบๆ คนเดียว
.
💡 อย่างนึงที่ช่วยได้คือ risk-based testing
ไม่ใช่เทสน้อยลง แต่เราเลือกว่าควรเทสอะไรก่อน
👉 แก้อะไรไปบ้าง และมันกระทบส่วนไหนบ้าง
👉 ถ้าจุดนั้นพัง กระทบอะไรบ้าง หนักแค่ไหน
สมมติว่า hotfix นี้ แก้การคำนวณคูปองส่วนลด
✅ สิ่งที่เลือกเทส: การคำนวณยอดรวม ส่วนลด และ การจ่ายเงิน
❌ สิ่งที่ไว้ทีหลังได้: หน้าโปรไฟล์ ประวัติออเดอร์ การแสดงสินค้า และส่วนอื่นๆ ที่ไม่ได้ถูกแตะ
.
แล้วทำยังไงถึงจะรู้ว่าควรเลือกตรงไหน
📌 คุยกับเดฟให้เยอะๆ
บางทีเราก็ตอบเองคนเดียวไม่ได้
ลองถามเดฟไปตรงๆ ว่า แก้อะไรไป และน่าจะมีตรงไหนกระทบบ้าง
ไปคุยกับเค้า เพื่อช่วยกันคิด ไม่ใช่โยนปัญหาไปให้เค้าคิดนะคะ
สุดท้ายเราก็จะได้คำตอบที่มาช่วยให้เรา scope การเทสของเราได้มากขึ้น
.
📌 ตกลงกับทีมให้ชัด
👉 จะเทสอะไรบ้าง
👉 อะไรที่ไม่ได้เทสบ้าง
👉 มีความเสี่ยงอะไรบ้าง ที่ทีมต้องยอมรับร่วมกัน
ตกลงกันให้ชัดเจน เพื่อให้ทีมรับรู้ค่ะ
เพราะความเสี่ยงของ release ไม่ใช่สิ่งที่ QA ต้องแบกไว้คนเดียว
.
และถ้าทีมมี automation test ที่ครอบคลุม flow หลักไว้อยู่แล้ว
ก็จะยิ่งเป็น safety net ที่ช่วยให้เรามั่นใจมากขึ้น
เพราะอย่างน้อยเราก็มั่นใจได้ว่า ส่วนที่มันเคยใช้ได้ มันยังใช้ได้อยู่
ยิ่งเวลาน้อย safety net ของเราจะยิ่งมีค่าค่ะ
.
ที่สำคัญคือ เป้าหมายของเรา ไม่ใช่การเทสให้ครบ
แต่คือ ทำยังไงให้ทีมมั่นใจกับการ release ครั้งนี้
และเตรียมรับมือกับความเสี่ยงที่อาจจะเกิดขึ้น
นี่คือสิ่งที่ QA ร่างทอง จะช่วยทีมได้มากที่สุด ในวันที่รีบเร่งแบบนี้ค่ะ