หลายๆทีมคงเป็นแบบนี้กันอยู่ใช่มั้ยคะ ไม่ว่าจะ 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

ตลาดหาแต่ Automation… แล้ว Manual แบบเราล่ะเอาไงดี ใครเป็น Manual QA บ้าง เปิดเว็บหางานทีไร เจอแต่คำว่า “Must have Cypress/Playwright experience”, “Experience in Selenium or Automated Testing Frameworks”… อ่านแล้วก็อดใจสั่นไม่ได้ใช่มั้ยคะ เชื่อว่าหลายคนคงจะเกิดอาการ Imposter Syndrome กำเริบจนแทบจะหมดสิ้นแพชชั่น และแอบตั้งคำถามกับตัวเองว่า “แล้วถ้าเรายังเขียนสคริปต์ไม่คล่อง เราจะรอดมั้ย” แต่ความจริงที่หลายๆคนมักไม่ได้พูดถึงคือ “ก่อนที่เราจะเขียน Automation ได้ระดับเซียน เราก็ต้องมี เซนส์ของการเป็น QA ที่ดี ให้ได้ก่อนค่ะ” เครื่องมือ Automation มันฉลาด และทำงานไวก็จริง แต่มันไม่สามารถแยกให้เราได้ค่ะว่า Test Case ที่สำคัญ หรือ Test Case ที่มีคุณค่าต่อ Business นั้นอยู่ตรงไหนบ้าง มันแค่รันตามสิ่งที่เราเขียนสคริปต์สั่งไว้ ถ้าเรากระโดดไปเขียน