เชื่อว่าหลายๆทีมคงจะเคยเจอโมเมนต์ที่กด deploy ขึ้น production
แล้วทุกคนนั่งจ้องหน้าจอ ไม่กล้าลุกไปไหน เอาแต่จ้อง slack รอดูว่าจะมีอะไรระเบิดมั้ย
บางทีเราก็อาจจะต้องรอ deploy ดึกๆ เพราะกลัวจะไปพังตอนลูกค้าใช้อยู่
บางทีก็ต้องมีคนอยู่เวรเฝ้าหลังจากนั้นอีก อยู่ยาวกันจนตีสามตีสี่
หรือบางที เราก็กังวลเวลาที่แก้บั๊กช่วงใกล้ๆ release จนต้องเร่ง retest ทุกอย่างซ้ำจนดึกดื่น เพราะไม่มั่นใจว่าที่แก้ไปจะไปทำอะไรพังบ้าง
ถ้าทีมของคุณเป็นแบบนี้อยู่ อยากบอกว่า มันไม่ใช่เรื่องที่ต้องทนนะคะ และมันแก้ได้ ‼️
🙏 ทำไม deploy ทีไรต้องสวดมนต์ตลอด
ส่วนใหญ่ไม่ได้เกิดจากทีมเราเขียนโค้ดไม่ดีค่ะ และ ไม่ได้เกิดจากเทสไม่ละเอียดพอด้วย
แต่มันมักจะเกิดจากการที่ทีมไม่รู้ว่า “สิ่งที่แก้ไปจะกระทบอะไรบ้าง”
และไม่มั่นใจว่า “ที่เทสไปนั้นครอบคลุมพอหรือยัง”
ลองดูเหตุการณ์นี้นะคะ
- ทีมได้ bug report ว่าปุ่ม Submit ในหน้า checkout ใช้ไม่ได้
- Dev เริ่มแก้ เสร็จแล้วส่งให้ QA เทสต่อ
- QA เทส เปิดหน้า checkout กดปุ่ม Submit ใช้ได้ ให้ผ่าน ✅ ปิด ticket
- Deploy โค้ดที่แก้ขึ้น production
แต่พอ deploy เท่านั้นแหละ 💥 โค้ดที่แก้ดันไปกระทบส่วนที่ตรวจสอบ promo code ได้ยังไงก็ไม่รู้
กลายเป็นลูกค้าใช้ส่วนลดไม่ได้ และเราก็ไม่รู้เรื่องนี้จนลูกค้าไปเจอนั่นแหละ
เพราะไม่มีใครคิดถึง scenario นี้ตั้งแต่แรก
นี่คือตัวอย่างคลาสสิคของการที่ทีม “เทสผ่าน” แต่ก็ไม่ทำให้มั่นใจอยู่ดีค่ะ
เพราะเทสที่ทำไปไม่ได้ครอบคลุม scenario ที่อาจจะกระทบทั้งหมด
🤔 แล้ว QA จะมาช่วยตรงนี้ได้ยังไง???
เรามาลองดูว่า QA แบบที่คอย “จับผิด” กับ QA แบบที่ “สร้างความมั่นใจ” ต่างกันยังไงดีกว่าค่ะ
🕵 QA แบบจับผิด
รอของมา แล้วค่อยเริ่มเทสตามเทสเคส -> เจอบั๊ก ส่งกลับ -> แก้เสร็จส่งมาใหม่ ->
เทสซ้ำ -> เจอบั๊กที่อื่น -> แก้ -> เทสซ้ำอีก วนไปเรื่อยๆ
พอตอน deploy เสร็จ ก็สวดมนต์ อธิษฐานเอา
ทีมที่ทำแบบนี้ มักจะวัดผลกันด้วย “จำนวน bug ticket ที่เปิด” ค่ะ (หวังว่าเดี๋ยวนี้คงจะไม่มีกันแล้วเนอะ แต่เมื่อก่อนคือเพียบ!)
😊 QA แบบสร้างความมั่นใจ
คิด scenario รอไว้เลย -> เอาไปคุยกับ dev ตั้งแต่ก่อนจะเริ่มเเขียนโค้ด -> ดูว่าแก้ตรงไหนไปบ้าง น่าจะกระทบบ้าง ->
ออกแบบ scenario ให้ครอบคลุม user journey ที่กระทบ -> dev ก็จะรู้ว่ามีตรงไหนที่ต้องระวังตอนแก้ ->
เทสเสร็จทุกคนรู้ว่า ตรงไหนเสี่ยงบ้าง แล้วเราเทสไปรึยัง -> กด deploy แบบมั่นใจ
จริงๆ เราวัดผลกันง่ายๆ เลยค่ะ ด้วยการดูว่า ทีมมั่นใจกับคุณภาพของโค้ดมากน้อยแค่ไหน และมั่นใจแค่ไหนตอนกด deploy
💪 แล้วเราจะเริ่มปรับตัวไปทางนั้นได้ยังไง
1. เปลี่ยนจาก “เทสให้ครบทุกอย่าง” เป็น “เทสให้ตรงจุด”
หลายคนติดนิสัยเทสแบบ exhaustive ค่ะ เทสทุกอย่าง ไม่งั้นไม่สบายใจ
ซึ่งอาจจะทำให้เราหมดเวลาไปกับของที่ไม่ค่อย impact จริงๆ และ อาจจะพลาด scenario สำคัญที่ user เจอทุกวันไป
ลองถามตัวเองก่อนเทสค่ะ ว่า “ลูกค้าจะใช้ฟีเจอร์นี้ในเหตุการณ์ไหนบ้าง”
อย่างเช่นหน้า checkout ที่เราคุยกันไป ถ้าเรามัวเทสว่า ใส่ชื่อเกิน 200 ตัวอักษรได้มั้ย ทุกรอบที่ dev แก้โค้ด
ก็อาจจะทำให้เสียเวลา และลืมเทส scenario ที่เกิดขึ้นจริงบ่อยๆ เช่น:
- ลูกค้าที่ checkout และใช้ promo code
- ลูกค้าที่ checkout แล้วกดย้อนกลับมาใหม่
- ของในตะกร้าหมดพอดีตอนที่กำลังจะจ่ายเงิน
- ลูกค้าที่จ่ายเงินไปแล้วเน็ตหลุด
ถ้าเราคิด scenario ที่เกิดขึ้นก่อน แล้วค่อยจัดลำดับว่าอันไหนสำคัญกว่า
การเทสจะครอบคลุมจุดที่มี impact จริงๆได้มากกว่า และเราก็จะใช้เวลาได้ตรงจุดกว่าเดิมมากค่ะ
2. เอา test scenario ไปคุยกับ dev ก่อนจะเริ่มเขียนโค้ด
อันนี้ถ้าทำได้จะช่วยได้เยอะมากๆ เลยค่ะ แทนที่จะรอของมาแล้วค่อยเทส ลองเดินไปหา dev แล้วบอกว่า
“อันนี้คือ scenario ที่จะเทสนะ มีเคสไหนที่คิดว่าน่าเป็นห่วง หรืออาจจะกระทบเพิ่มเติมมั้ย”
เท่านี้ dev ก็จะรู้ล่วงหน้าว่าจะโดนเทสตรงไหนบ้าง และมักจะนึกออกด้วยว่ามีเคสไหนที่ต้องระวังเพิ่ม
และจะได้จัดการไว้ตั้งแต่ตอนเขียนโค้ดเลย ไม่ต้องรอให้เราเทสเจอแล้วค่อยส่งกลับไปแก้
ผลที่ได้คือบั๊กลดลง เวลาที่ใช้เทสก็ลดลง ไม่ต้องคอยเทสซ้ำ และ Dev กับ QA ก็ทำงานเป็นทีมเดียวกันจริงๆ ไม่ใช่ส่งงานไปมา
3. ก่อน deploy ทำ “Confidence Check”
แทนที่จะเทสทุกอย่างซ้ำทั้งหมด ก่อน deploy เราลองชวนทีมนั่งคุยกันสั้นๆ เพื่อตอบ 3 ข้อนี้ดูค่ะ
- เราแก้หรือเพิ่มอะไรไปบ้าง
- สิ่งที่แก้ กระทบส่วนไหนของระบบบ้าง
- สิ่งที่เทสไป ครอบคลุมส่วนที่กระทบแล้วหรือยัง
ถ้าทุกคนตอบได้ชัดเจน และมั่นใจ ก็พร้อม deploy ค่ะ
❓ แต่ถ้าเกิดมีข้อไหนที่ทีมตอบไม่ได้ นั่นเป็นสัญญาณว่า “อาจจะยัง”
🤍 ความรู้สึกที่ทีมควรจะมีตอนกด Deploy
ไม่ใช่ “หวังว่าจะรอด” หรือ “น่าจะโอเคแหละ”
แต่คือ “เราเทสครบตามจุดที่คุยกันไว้แล้ว และแก้ปัญหาที่เจอไปแล้ว พร้อม deploy”
ซึ่งความมั่นใจนี้จะไม่ได้เกิดขึ้นจากการเทสซ้ำหลายรอบค่ะ
แต่มันมาจากการที่ทีมรู้ว่าเทสถูกจุด และ ครอบคลุม scenario ที่สำคัญจริงๆ
นี่คือสิ่งที่ QA ที่ดีจะช่วยทีมได้ค่ะ เราไม่ได้แค่หาบั๊กเยอะๆ
แต่เราช่วยให้ทุกคนมั่นใจในคุณภาพของงาน และ กด deploy ได้อย่างสงบสุขค่ะ