หลายๆทีมคงเป็นแบบนี้กันอยู่ใช่มั้ยคะ ไม่ว่าจะ Dashboard ที่โชว์ ranking ตามจำนวนบั๊กที่หาได้ หรือ KPI ที่วัดจากจำนวน Ticket ที่เปิด 😅กลายเป็นเราวัดผลงานของ QA กันด้วยจำนวนบั๊กที่หาเจอ แต่ลองมาคิดดูอีกทีนะคะ ถ้าทีมส่งมอบ product ออกไปโดยที่ไม่มีบั๊กเลยQA ในทีมนั้นหาบั๊กได้ 0 ตัว แปลว่าเขาทำงานได้ดีที่สุด หรือ แย่ที่สุด บั๊กน้อย อาจไม่ได้แปลว่า QA ทำงานน้อยนะคะแต่อาจจะแปลว่า QA เข้าไปช่วยทำให้งานมีคุณภาพมากขึ้น และป้องกันได้ดีตั้งแต่ต้น ลองเปรียบเทียบสองทีมนี้ดูนะคะ ทีม A 👉 QA รอของมา -> เข้าไปเทส -> เจอบั๊ก 20 ตัว👉 แล้วก็ส่งกลับไปให้ Dev แก้ 👉 แก้เสร็จเรียบร้อย -> ส่งกลับมาให้เทส -> QA เจอบั๊กอีก 5 ตัว ->

ไหน ใครเป็นมือใหม่บ้างคะ บางทีตอนที่เราเป็น QA แรกๆ เนี่ย เราไม่รู้หรอกว่าสิ่งที่เราทำไปมันดีหรือไม่ดียังไงวันนี้เลยอยากจะมาแชร์ 5 ข้อ ที่มักจะเห็นคนพลาดกันบ่อยๆ (และตัวพี่กิ่งเองก็เคยผ่านมาทุกข้อเลย 😅) ลองมาดูกันนะคะ ว่ามีตรงไหนที่เราสามารถทำให้ดีขึ้นได้บ้าง ❌ เทสทุกอย่างให้ครบก่อน✅ เทสให้ตรงจุดก่อน เทสครบก็ควรจะเป็นเรื่องดีไม่ใช่เหรอ แต่จริงๆ การที่เราจัดลำดับไม่ถูก แล้วพุ่งไปเทสเคสยิบย่อยก่อน เพราะอยากเทสให้ครบทุกอย่าง ก็อาจจะทำให้เราเจอบั๊กที่สำคัญจริงๆ ช้ากว่าที่ควรจะเป็นนะคะ ลองถามตัวเองว่า “ตรงไหนที่สำคัญสำหรับ User” แล้วเริ่มจากตรงนั้นก่อนถ้ามีบั๊ก เราจะได้แก้จุดที่สำคัญก่อนค่ะ ❌ รอ dev ส่งงานแล้วค่อยเทส ✅ คุย requirement ก่อน dev เริ่มโค้ด บั๊กที่เจอหลังจากเขียนโค้ดเสร็จแล้ว กับบั๊กที่เจอตั้งแต่ก่อนเริ่มโค้ด ราคาต่างกันมหาศาลค่ะแค่นัดคุย scenario กับ dev ก่อนจะเริ่มงานนั้นๆ ก็ช่วยให้ประหยัดเวลาได้เยอะ และคุณภาพของงานก็ดีขึ้นตามไปด้วย ❌ เขียน test case เยอะ = QA ที่ดี ✅

เชื่อว่าหลายๆทีมคงจะเคยเจอโมเมนต์ที่กด deploy ขึ้น productionแล้วทุกคนนั่งจ้องหน้าจอ ไม่กล้าลุกไปไหน เอาแต่จ้อง slack รอดูว่าจะมีอะไรระเบิดมั้ย บางทีเราก็อาจจะต้องรอ deploy ดึกๆ เพราะกลัวจะไปพังตอนลูกค้าใช้อยู่บางทีก็ต้องมีคนอยู่เวรเฝ้าหลังจากนั้นอีก อยู่ยาวกันจนตีสามตีสี่หรือบางที เราก็กังวลเวลาที่แก้บั๊กช่วงใกล้ๆ release จนต้องเร่ง retest ทุกอย่างซ้ำจนดึกดื่น เพราะไม่มั่นใจว่าที่แก้ไปจะไปทำอะไรพังบ้าง ถ้าทีมของคุณเป็นแบบนี้อยู่ อยากบอกว่า มันไม่ใช่เรื่องที่ต้องทนนะคะ และมันแก้ได้ ‼️ 🙏 ทำไม deploy ทีไรต้องสวดมนต์ตลอด ส่วนใหญ่ไม่ได้เกิดจากทีมเราเขียนโค้ดไม่ดีค่ะ และ ไม่ได้เกิดจากเทสไม่ละเอียดพอด้วยแต่มันมักจะเกิดจากการที่ทีมไม่รู้ว่า “สิ่งที่แก้ไปจะกระทบอะไรบ้าง”และไม่มั่นใจว่า “ที่เทสไปนั้นครอบคลุมพอหรือยัง” ลองดูเหตุการณ์นี้นะคะ แต่พอ deploy เท่านั้นแหละ 💥 โค้ดที่แก้ดันไปกระทบส่วนที่ตรวจสอบ promo code ได้ยังไงก็ไม่รู้ กลายเป็นลูกค้าใช้ส่วนลดไม่ได้ และเราก็ไม่รู้เรื่องนี้จนลูกค้าไปเจอนั่นแหละ เพราะไม่มีใครคิดถึง scenario นี้ตั้งแต่แรก นี่คือตัวอย่างคลาสสิคของการที่ทีม “เทสผ่าน” แต่ก็ไม่ทำให้มั่นใจอยู่ดีค่ะ เพราะเทสที่ทำไปไม่ได้ครอบคลุม scenario ที่อาจจะกระทบทั้งหมด 🤔 แล้ว QA จะมาช่วยตรงนี้ได้ยังไง??? เรามาลองดูว่า

“It’s not a bug, It’s a feature”“ไม่ใช่บั๊กนะ มันเป็นฟีเจ้อ” คลาสสิค!! เป็นประโยคที่ QA ทุกคนเคยได้ยินกันมาแน่ๆ ใช่มั้ยคะ 😅 บางทีเราแน่ใจสุดๆ ว่ามันพังแน่ๆ กด reproduce ซ้ำได้ทุกรอบแต่พอ report ไปปุ๊บ โดนสวนกลับทันที “อันนี้ตั้งใจทำแบบนี้แหละ” แล้วเราจะทำยังไงต่อดีล่ะ!?. ก่อนอื่นเลย อยากให้ทุกคนเข้าใจก่อนนะคะ ว่าเราไม่ได้จะมาหาว่าใครผิดใครถูก ไม่ได้จะบอกว่าใครดีกว่าใครเพราะ “Bug” หรือ “Not a Bug” มันมี grey area อยู่เยอะมาก ลองนึกตามดูค่ะ ใครเคยเจอสถานการณ์เหล่านี้บ้าง ❌ Requirement ไม่ได้เขียนไว้ชัดเจนระบบทำงานตรงตาม spec แต่ user งงมาก แบบนี้เป็นบั๊กมั้ย? ❌ Dev กับ QA ตีความ Requirement ต่างกันบางทีอาจจะมี edge

มีใครคิดว่าซอฟท์แวร์ที่ดีต้อง “Zero Defect” บ้างคะ ระบบที่ดีที่จะเอาขึ้นได้ต้องเพอร์เฟค 100% ถ้าเจอบั๊กแม้แต่นิดเดียว ก็ต้องรีบขวางไว้ทันที ผลคืออะไรรู้มั้ยคะ กลายเป็นเราทำงานเครียด รู้สึกต้องสู้ ต้องไฟท์ตลอดเวลา อยากให้ทุกอย่างออกมาสมบูรณ์แบบที่สุด แต่พอเราเติบโตขึ้น ก็ทำให้รู้ค่ะว่า เราไม่ควรหมกมุ่นกับความสมบูรณ์แบบที่จับต้องไม่ได้ แต่เราจะต้องทำงานแบบมีกลยุทธ์ คิดถึงRisk และ Cost ที่จะเกิดขึ้นเสมอ ลองมาดูสถานการณ์ตัวอย่างกันค่ะ ว่าแบบไหนเราปล่อยได้ แบบไหนปล่อยไม่ได้ แล้วเราจะจัดการกับมันยังไง 🚨 เมื่อ Business Deadline สำคัญกว่า Minor Bug ลองคิดดูว่าถ้าพรุ่งนี้บริษัทจะต้องปล่อยแคมเปญใหญ่ (เช่น 11.11) ที่ใช้งบการตลาดมหาศาล ฟีเจอร์ที่กำลังจะออกมีมูลค่าสูงมากต่อยอดขาย แต่ดันมาเจอบั๊กในนาทีสุดท้าย แล้วเราจะทำยังไงกับบั๊กพวกนั้นดี ถ้าแก้ก็อาจจะต้องมาเร่งเทสฟีเจอร์นั้นใหม่อีกรอบ แล้วอาจจะทำให้ปล่อยฟีเจอร์นี้ไม่ทัน ขั้นแรกเราต้องประเมินก่อนค่ะว่าบั๊กนี้ “ร้ายแรง” แค่ไหน โดยอาจจะคุยกับฝั่ง Business หรือ PO เพื่อตกลงร่วมกันด้วยก็ได้ ถ้าบั๊กที่เจอเป็น Minor Bug เช่น “ปุ่มแชร์ลง Social