มือไม้สั่น หน้าชา ใจหล่นไปอยู่ที่ตาตุ่ม… 😱
ความรู้สึกที่อาจจะเกิดขึ้นหลังจากเราเห็นแจ้งเตือนใน Slack ว่า “ลูกค้าเจอ Bug บน Production!”
ปฏิกิริยาแรกของ QA ส่วนใหญ่คือการโทษตัวเองค่ะ
“เราพลาดได้ยังไง”
“ทำไมถึงเทสไม่เจอ”
“เราไม่เก่งหรือเปล่า”
“ทีมจะมองว่าเราเทสไม่ดีมั้ย”
หรือบางคนก็อาจจะโดนถามเลยด้วยซ้ำว่า เทสยังไง เทสตรงนี้หรือเปล่า ทำไมถึงไม่เจอบั๊กตัวนี้
พอโดนบ่อยๆเข้าก็อาจจะเริ่มกลัวการกดปุ่ม Release หรือการเปลี่ยน Ticket status เป็น Passed
และอาจจะกลายเป็นความเครียดสะสม นอนไม่หลับกระสับกระส่าย รู้สึกแย่กับตัวเองไปซะอย่างนั้น
วันนี้เลยอยากชวนทุกคนมาลองจัดการ “ใจ” ก่อนที่จะจัดการ “งาน” ของเราค่ะ
1. จัดการใจ: แยก “ตัวตน” ออกจาก “บั๊ก”
ก้าวแรกของการเป็น QA ที่ใจไม่พัง คือต้องแยก คุณค่าในตัวเอง (Self-worth) ออกจากผลของงานให้ได้ก่อนค่ะ
บั๊กไม่ใช่ “ความผิดพลาดส่วนบุคคล” แต่คือ “ช่องว่างของกระบวนการ”:
Software สร้างขึ้นโดยมนุษย์ และมนุษย์พลาดได้เสมอ การที่บั๊กหลุดไม่ได้แปลว่าคุณไม่เก่ง
“ตัวคุณ” กับ “ผลของงาน” คือคนละส่วนกันค่ะ Software ที่คุณภาพไม่ได้ ไม่ได้แปลว่าตัวคุณไม่ดี
แต่มันแปลว่า Process ของเรายังมีช่องว่างอยู่
ส่วนใหญ่แล้วการที่บั๊กหลุดไปถึง Production ได้ มักจะเกิดจากปัญหาเล็กๆน้อยๆหลายๆอย่างที่บังเอิญเกิดขึ้นพร้อมกันพอดี
หน้าที่ของเราคือหาให้เจอ แล้วไปอุดมันร่วมกับทีม
หยุดเสียงวิจารณ์ในหัว (Inner Critic):
เมื่อเกิดปัญหาแบบนี้ขึ้น เสียงในหัวเราจะเริ่มทำงานหนักกว่าปกติ
“ทำไมแค่นี้มองไม่เห็น”
“พลาดเรื่องนี้ไปได้ยังไง”
“Dev จะรำคาญเรามั้ย”
เราอยากให้ลองเปลี่ยนบทสนทนากับตัวเองค่ะ ลองเปลี่ยนมาถามตัวเองด้วยความอ่อนโยน (Self-Compassion) ว่า
“ในสถานการณ์ที่เกิดขึ้น เราทำดีที่สุดแล้วหรือยัง”
เพราะบางที เราอาจจะอยู่ในสถานการณ์ที่มีข้อมูลจำกัด
หรือ เวลากระชั้นชิด ต้องรีบเทสเพื่อ release ให้ทันเวลา
ถ้าคำตอบคือใช่ ก็ไม่มีเหตุผลที่เราจะใจร้ายกับตัวเองค่ะ
บั๊กคือ “Feedback” ไม่ใช่ “คำพิพากษา”:
ลองเปลี่ยนมุมมองดูหน่อย บั๊กที่หลุดไปคือข้อมูล (Data) ชุดหนึ่งที่มาบอกเราว่า “เฮ้ย ตรงนี้ระบบยังไม่แข็งแรงนะ”
มันคือโอกาสที่เราจะได้เรียนรู้พฤติกรรมของ User หรือ Logic ที่เราอาจจะมองข้ามไป
ยิ่งเรายอมรับได้เร็วเท่าไหร่ เราก็จะยิ่งมีพลังงานเหลือไปใช้ในการแก้ปัญหาได้เร็วเท่านั้น
ใช้กฏ 3-Breath Rule:
เมื่อเห็น Bug Report บน Production อย่าเพิ่งรีบพิมพ์ขอโทษรัวๆ หรือรีบวิ่งไปคุยกับคนอื่นด้วยความลนลาน
ให้ลองหยุดนิ่งๆ หายใจเข้า-ออก ลึกๆ 3 ครั้ง เพื่อดึงสติจากความแพนิคที่อาจจะเกิดขึ้น กลับมาสู่การแก้ปัญหา
เมื่อใจนิ่งขึ้น เราจะถามคำถามที่ฉลาดขึ้น สโคปปัญหาได้แม่นยำขึ้น และจัดการเหตุการณ์ตรงหน้าได้ดีขึ้นมากค่ะ
2. จัดการงาน: เมื่อสติมา งานก็ต้องเดินต่อ
เมื่อใจนิ่งแล้ว ให้รีบเปลี่ยนโหมดมาเป็นผู้แก้ไขสถานการณ์ เพื่อให้ “เจ็บแล้วจบ” และไม่เกิดขึ้นซ้ำอีก
🔍 Root Cause Analysis (RCA):
หาให้เจอว่าทำไมบั๊กนี้ถึงหลุดออกไปได้
- Requirement ไม่เคลียร์
- Test environment ไม่เหมือนจริง
- ลืมเทส Scenario นี้จริงๆ
- ไม่ได้เทสด้วย Data แบบนี้ ซึ่งมีแค่บน Production
📝 Update Test Cases:
ที่สำคัญ อย่าลืมกลับไปเพิ่มเทสเคส หรืออัพเดตเทสเคสเดิม ให้ครอบคลุม Scenario ที่เกิดขึ้น
เพื่อไม่ให้บั๊กนี้หลุดไปซ้ำอีก
🤖 Add Test Automation & Unit Test:
ถ้าเป็นไปได้ เราควรเพิ่ม Automation Test เพื่อดักไว้ได้เลยค่ะ จะเป็น E2E หรือ จะคุยกับ Dev ให้เพิ่ม Unit Test ก็ได้หมด
โดยเฉพาะจุดที่เป็น Critital Path เพื่อให้มั่นใจว่าบั๊กตัวเดิมจะไม่มีวันฟื้นคืนชีพกลับมาอีก (No Regression!)
🤖 Process Improvement:
กลับมาดูภาพรวมของทีม และ process การทำงาน ว่ามีตรงไหนต้องปรับปรุงเพิ่มมั้ย
เช่น การทำ Peer Review หรือ ปรับปรุงการทำ Regression Test ให้ครอบคลุมมากขึ้น
หรือปรับวิธีการ Deploy บน Test environment ให้ใกล้เคียงกับ Production มากี่สุด
QA ที่ดี จะไม่ไล่จับบั๊กอย่างเดียวนะคะ เราจะต้องหาวิธีป้องกันให้บั๊กเกิดขึ้นน้อยที่สุดด้วย
3. บทเรียนสำคัญ: ความผิดพลาดนี้แหละ ที่จะทำให้เราพัฒนา
ในฐานะที่เคยสัมภาษณ์ QA มาเยอะประมาณนึง หนึ่งในคำถามที่เราชอบถามคือ “เคยทำบั๊กหลุดไป Production มั้ย”
🚩 ถ้าใครตอบว่า “ไม่เคยเลยค่ะ/ครับ” ต้องกลับมาทบทวนกันใหม่หน่อย!
เชื่อมั้ยคะว่ามีคนตอบว่าไม่เคยเยอะมาก แต่ถามว่าเราเชื่อมั้ย ก็อาจจะยัง…
และคำถามที่แท้จริงที่เราอยากถามคือ “บั๊กหลุดแล้วทำยังไงต่อ” เพราะเราอยากรู้วิธีที่คุณจัดการกับปัญหานั้น
ในโลกของการสร้าง Software ที่ซับซ้อน… การเจอบั๊กบน Production เป็นเรื่องปกติธรรมดาที่ QA ทุกคนต้องเคยเจอ ไม่ว่าคุณจะเก่งหรือรอบคอบแค่ไหนก็ตาม
คนที่เราอยากได้เข้าทีม ไม่ใช่คนที่ “ไม่เคยพลาด” แต่คือคนที่ยอมรับความจริง
และสามารถอธิบายได้ว่า บั๊กนั้นเกิดขึ้นเพราะอะไร คุณได้เรียนรู้อะไร และจัดการป้องกันมันยังไง เพื่อไม่ให้เกิดซ้ำอีก
(ผิดพลาดได้ไม่เป็นไร แต่ถ้าผิดซ้ำที่เดิมก็ไม่ควร)
การยอมรับความผิดพลาด เรียนรู้จากมัน และเปลี่ยนให้เป็นบทเรียนของกระบวนการที่แข็งแกร่งกว่าเดิม
นี่แหละ คือคุณสมบัติของ “QA ร่างทอง” ที่ทุกบริษัทต้องการตัว
🤍 “You are the Human behind the Software.
It’s okay to make mistakes, as long as you make it a lesson.”
ใครเคยเจอประสบการณ์ บั๊กหลุดจนโดนด่าเละบ้าง จัดการใจกันยังไง
หรือได้บทเรียนอะไรที่ทำให้เราเก่งขึ้นมาจนถึงทุกวันนี้ มาแชร์กันได้นะคะ