👻❌ เคยเจอผีหลอกตอนรัน Automation Test กันมั้ยคะ รันบนเครื่องตัวเองกี่รอบก็ผ่านหมด ผ่านตลอด ผ่านทุกครั้ง ไม่เคยติดปัญหาอะไรแต่พอเอาขึ้นไปรันรวมกับ Regression Test เท่านั้นแหละพังยับ!!! แล้วเราเอามาลองรันบนเครื่องตัวเองหลังจากเห็นมันพังเอ้า ก็ผ่าน สุดท้ายนั่งกุมหัว ไม่รู้จะทำยังไง 🤦‍♀️ แค่นั้นยังไม่พอ พอเป็นแบบนี้บ่อยๆ กลายเป็น Automation Test ที่ไม่ stable และไม่มีใครเชื่อมันซะงั้นสุดท้ายกลับมานั่งเช็ค manual เหมือนเดิม เพราะผล Automation Test มันเชื่อไม่ได้ อวสาน QA ร่างทอง Test ที่รันอยู่ก็ไม่มีใครเชื่อทีมก็ไม่แบ่งเวลาให้เขียน Automation Test เพราะไม่เห็นประโยชน์สุดท้ายก็รัน Manual เหมือนเดิม … ยังค่ะ ยังไม่จบแค่นี้ เราไม่อวสานกันง่ายๆ แบบนี้หรอกนะคะวันนี้พี่กิ่งจะพามาเจาะลึก “หนึ่งปัญหาสำคัญ” ที่ทำให้เกิดเหตุการณ์แบบนี้ได้ค่ะบางทีมันไม่ได้เกิดจากเขียนโค้ดไม่ดี หรือระบบมีบั๊กเยอะอะไรเลยค่ะแต่มันอาจจะเกิดจากปัญหาง่ายๆ จากสิ่งที่เรียกว่า “Test Data” ของเรา ที่มันไม่ independentคือไม่เป็นอิสระต่อกัน

6 วิธีง่ายๆ ที่ทำให้ Test Stable ขึ้นได้ทันที . ไม่ว่าคุณจะเพิ่งเริ่มเขียน Gherkin เพื่อใช้เป็น Acceptance Criteriaหรือ เอาไปใช้เป็น Feature File ใน Automation Test อยู่แล้ว มีสิ่งนึงที่เราทุกคนเจอเหมือนกันค่ะ เขียน Scenario ไปหมดแล้ว Given-When-Then ครบทุกข้อแต่ทีมก็ยังอ่านไม่รู้เรื่อง ไม่มีใครเข้าใจว่าจะเทสอะไรหรือถ้าใช้ใน Automation Test อยู่ ก็พังหมดจนตามแก้แทบไม่ไหว ปัญหาไม่ใช่ว่า Gherkin ไม่ดีแต่อยู่ที่วิธีที่เราเขียนมันต่างหาก วันนี้พี่กิ่งเอา checklist 6 ข้อมาฝากกันค่ะเอาไปทำตามกันได้เลย . 📌 1. บอกว่า “ต้องการอะไร” ไม่ใช่ “ทำยังไง” Gherkin ที่ดี ต้องบอก behavior ค่ะ สิ่งที่ต้องการจะทำคืออะไรไม่ใช่ implementation ว่าทำยังไง ขั้นตอนเป็นยังไง เรามาลองดูตัวอย่างกันค่ะ ❌

ทีมใครใช้ BDD กันอยู่บ้างคะ ตอนที่พี่กิ่งได้ยินคำว่า BDD ครั้งแรกมันมาคู่กับคำว่า Cucumber ค่ะ 🥒 แล้วทุกคนก็บอกว่าเราจะเริ่มเขียน Test และ Acceptance Criteria แบบนี้กันนะทุกคนก็ไปเริ่มทำตาม รวมทั้งพี่กิ่งด้วย ทั้งที่ตอนนั้นยังไม่รู้เลยว่า BDD คืออะไรรู้แค่ว่า Cucumber มันเขียน Given-When-Then แล้วเราก็เริ่ม ทำ BDD กัน จนผ่านมาซักพักนั่นแหละค่ะถึงได้รู้ว่าเราไม่ได้เข้าใจอะไรมันจริงๆ เลยสักนิด 😅 . 🤔 Cucumber ≠ BDD นี่คือความเข้าใจผิดที่เจอบ่อยที่สุดในวงการ QA เลยค่ะ BDD ไม่ใช่ CucumberBDD ไม่ใช่ GherkinBDD ไม่ใช่ Given-When-Then ไม่ใช่อะไรซักอย่าง แล้วมันคืออะไรกันแน่ จริงๆ แล้วทุกอย่างที่พูดไปมันคือคนละเรื่องกันเลยค่ะ . 💡 BDD คือ วิธีคิดและวิธีทำงานของทีม Behavior-Driven Development

💡 เลิกกางตำราเขียน Test Case แล้ว EP/BVA จะมีค่าขึ้นมาทันที จาก Test Design Workshop ครั้งที่แล้ว มีคำถามนึงที่คนถามเข้ามาเยอะก็คือ EP BVA ไอ้ตัวย่ออะไรพวกนี้เนี่ย มันคืออะไร ซึ่งวันนั้นพี่กิ่งบอกไว้ว่า ยังไม่ต้องสนใจ เพราะจริงๆแล้วเราไม่ควรเริ่มต้นจากสิ่งนี้ค่ะ  วันนี้เลยจะอยากมาขยายความเพิ่มเติมให้อีกนิด เผื่อว่าจะช่วยตอบคำถามของหลายๆ คนในวันนั้นได้นะคะ คิดว่าหลายๆ คนน่าจะเจอปัญหาคล้ายกัน ที่ตอนเรียนเราก็เข้าใจดีอยู่หรอกว่ามันคืออะไร แต่พอเจองานจริง เจอ Requirement จริง ก็ไม่รู้จะเอาไปใช้ยังไง หรือบางคนเริ่มมาก็กางตำรา ใส่เทคนิคเข้าไปรัวๆ เสร็จแล้วก็ไม่มั่นใจอยู่ดีว่า Test Case ครบหรือไม่ครบกันแน่ อย่างที่พี่กิ่งย้ำบ่อยๆ ค่ะ สิ่งที่สำคัญที่สุดคือ “วิธีที่เราเริ่มต้นคิด” ต่างหาก ที่จะบอกว่าเราเป็น QA ทั่วไป หรือ เป็น QA ร่างทอง ถึงตรงนี้ถ้าใครยังไม่รู้จักว่า EP BVA คืออะไร สามารถเข้าไปดูในโพสเก่าได้นะคะ ในนี้จะมีอธิบายพื้นฐานเอาไว้ เดี๋ยวเรามาลองตัวอย่าง Requirement

เคยเป็นเหมือนกันมั้ยคะเขียน Test Case ไปเป็น 100 ข้อ เช็คครบทุกอย่างแล้ว แต่พอ Release ไปจริงๆลูกค้าดันเจอบั๊กที่เราไม่เคยคิดถึงเลย 🫠 ปัญหาไม่ได้อยู่ที่เราเทสน้อยเกินไปค่ะ แต่เราอาจจะกำลังเทสไม่ตรงจุดเพราะเราแตก task ย่อยเกินไป อย่างสมมติว่าเราต้องเทสหน้า Login พอเห็นปุ๊บเราก็จะคิดทันทีว่ามี Username / มี Password / มีปุ่ม Login → เช็คไปทีละอัน พอครบก็ผ่าน มันไม่ได้ผิดค่ะ แค่… ไม่พอ เพราะ User จริงๆ เค้าใช้งานระบบค่ะ เค้าอาจจะ Login ผิดซ้ำ 2-3 รอบเพราะจำ password ไม่ได้เค้าอาจจะปิดแท็บไป แล้วกลับมาใหม่ หรือเค้าอาจจะเปิดค้างไว้จน session หมด บั๊กที่หลุดไปส่วนใหญ่ ไม่ได้หลุดเพราะแต่ละ field ทำงานไม่ถูก แต่มันหลุดเพราะ ช่วงรอยต่อระหว่างแต่ละส่วนที่เราไม่ได้คิดถึงค่ะ ลองดูตัวอย่างต่อจากหน้า Login กันค่ะ ❌ แบบที่คนมักทำ (เช็ค