Mindset

เจอ Bug ทีไร สงครามบังเกิดทุกที!ทีมไหนเป็นแบบนี้ยกมือค่ะ เดี๋ยวเรามาดูกันว่าจะทำยังไงได้บ้าง เรื่องนี้เป็นอีกเรื่องที่พี่กิ่งพูดกับทีมบ่อยมากๆนะคะในฐานะ QA หนึ่งในหน้าที่ของเราคือการหาข้อผิดพลาดให้เจอ การเดินไปบอกทื่อๆ ว่า “โค้ดเธอพังนะ” ถ้าสื่อสารไม่ดี จากที่จะช่วยกันแก้ Bug อาจจะกลายเป็นสร้างกำแพงใส่กันแทนก็เป็นได้ จริงๆ แล้ว หนึ่งในทักษะที่สำคัญไม่แพ้การเขียน Test Script ก็คือ Soft Skill นี่แหละค่ะและเป็นอีกหนึ่งเรื่องที่สามารถแยกได้เลยนะคะ ว่า QA คนนี้ร่างทอง ตัวเทพ จริงมั้ย ถ้าใครยังไม่รู้จะเริ่มยังไง วันนี้มาลองดูวิธีการแจ้ง Bug ให้ทีมฟังแล้วไม่เกิดสงครามกันค่ะและวิธีนี้ยังช่วยทำให้ความสัมพันธ์ในทีมดีขึ้น คุยกันง่ายขึ้น งานก็เดินมากขึ้นตามไปด้วย Bug ในระบบแก้ได้ด้วยโค้ด แต่ถ้าเกิด Bug ที่การสื่อสารระหว่างทีม ก็ต้องแก้ด้วยการสื่อสารและการทำความเข้าใจนะคะลองทำไปเรื่อยๆ เดี๋ยวก็จะติดเป็นนิสัยไปเอง ใครมีเทคนิคลับอื่นๆ เวลาคุยเรื่อง Bug หรือคุยปัญหากับทีม Dev สามารถแชร์กันได้นะคะ หรือส่งต่อให้เพื่อนในทีมมาร่วมวงกันได้เลยค่ะ

เคยมั้ยคะ รอ Dev ทำฟีเจอร์ให้เสร็จพร้อมเทสมาเป็นอาทิตย์ พอได้มาเทสจริงๆ ปุ๊บ… แค่กดปุ่มแรกไป หน้าจอก็หมุนไม่หยุด หรือ Error แดงเถือก! แล้วเราก็จะรู้สึกว่า “ให้ฉันรอแล้วได้อะไร” ในเมื่อของก็ยังพังอยู่แบบนี้แล้วชั้นจะเทสยังไงไหวพอไปบอก Dev ก็อาจจะได้คำตอบว่า เดี๋ยวต้องไปแก้ Logic หลังบ้านก่อน แล้วต้องแก้ UI ให้รับค่าใหม่ด้วย สรุป… ต้องรอต่อไปอีก 2 วันเพื่อให้ระบบพร้อมเทส (อีกรอบ) นี่แหละค่ะคือความเจ็บปวดของการทำ UI-Heavy Testing หรือที่บางคนอาจจะเคยเห็นชื่อ “Ice Cream Cone Testing” 🍦 คือการทำเทสผ่านหน้าจอ (Layer บน) เยอะๆ แต่ฐานข้างล่างอย่าง API หรือ Unit Test กลับกลวงโบ๋ กลายเป็นสามเหลี่ยมกลับหัวที่ฐานไม่แน่น พร้อมล้มตลอดเวลา วันนี้พี่กิ่งจะมาแชร์ให้เห็นภาพชัดๆ ค่ะว่าการมี API First Mindset จะช่วยให้เราเป็น “QA ร่างทอง” ที่เจอบั๊กไวกว่า

เปิดโพย 3 คำถามกันตายตอน Refinement เคยมั้ย ที่เรานั่งอยู่ในประชุม Refinement (หรือ Grooming) เพื่อพูดคุยเกี่ยวกับ Requirement กัน Dev ก็คุยกันเรื่อง Logic วุ่นวาย PO ก็อธิบาย Flow งานมารัวๆ ส่วนเราที่เป็น QA ก็ได้แต่นั่งฟัง แล้วก็จด Requirement ตามเงียบๆ “เดี๋ยว Dev โค้ดเสร็จส่งของมาให้แล้วค่อยเอามาเทสแล้วกัน” ตัดภาพมาที่อีก 1 อาทิตย์… Dev ส่งของมาให้และเราก็กำลังจะเริ่มเทส “อ้าว ถ้า User กดปุ่ม Back ตอนจะจ่ายเงินล่ะ” “แล้วถ้ากรอกตัวเลขติดลบตรงนี้ จะพังมั้ย” “ทำไมตรงนี้ไม่ได้ทำ ไม่มี Requirement บอกไว้เหรอ” แล้วยังไงต่อล่ะทีนี้… สุดท้ายเราก็จะเดินไปบอกทีมว่า “ยัง Deploy ไม่ได้นะคะ ยังมีบั๊กที่ต้องแก้เต็มเลย” 🛑แต่มาลองคิดดู จริงๆเราสามารถช่วยทีมได้ตั้งแต่ก่อนจะเริ่มเขียนโค้ดอีกนะ! ถ้าเราอยากจะเป็น

เจาะลึกบทบาทของ Quality Advocate ในยุค Agile สวัสดีค่ะทุกคน หลังจากโพสต์ที่แล้วเราคุยกันไปเรื่อง “อวสาน QA” หลายคนน่าจะสงสัยว่า แล้วเราจะเป็น “QA ร่างทอง” ที่อยู่รอดและทรงคุณค่าในยุค 2026 ได้ยังไง วันนี้เราจะมาชวนเจาะลึกบทบาทหนึ่งที่เป็นหัวใจสำคัญ นั่นคือการเปลี่ยนแปลงตัวเองจาก Gatekeeper มาเป็น Quality Advocate ที่ทำหน้าที่เหมือนเป็น Navigator ให้กับทีมนั่นเองค่ะ ทำไมการเป็น Gatekeeper ถึง “เจ็บทั้งทีม”?? ในโลกการทำงานยุคก่อน QA มักจะถูกวางไว้ที่ปลายน้ำ อยู่ท้ายสุดของ processหน้าที่ของเราคือรอตรวจของเป็นด่านสุดท้ายก่อนออกสู่ตลาด ถ้าเจอบั๊กเมื่อไหร่เราก็สั่งให้ “หยุด” หรือ ส่งของชิ้นนั้นกลับไป ไม่ให้ไปต่อ แต่ในยุคที่ทุกอย่างต้องเร็วแบบนี้ การทำตัวเป็น Gatekeeper กลับสร้างผลเสียให้ทีมแบบไม่น่าเชื่อฃ 3 ขั้นตอนง่ายๆ เพื่อเริ่มเป็น Quality Advocate ถ้าอยากอัพเกรดตัวเองเป็น Navigator แทนที่จะเป็น Gatekeeper ลองปรับ 3 อย่างนี้ดูก่อนค่ะ