มีคำถามที่พี่กิ่งได้ยินบ่อยมากตอนบอกให้ใครแตก e2e ยาวๆ ออกเป็น scenario ย่อยๆ คือ “แล้วเราจะรันสเต็ปเดิมซ้ำหลายรอบเหรอ”“แบบนี้เทสก็จะเพิ่มขึ้นเยอะเลย”“จะไม่เสียเวลารันนานเกินไปเหรอ” พี่กิ่งจะมาเล่าสิ่งที่เคยเจอให้ฟังค่ะ . ตอนที่พี่กิ่งเริ่มเขียน automation test ใหม่ๆ ก็เขียนเป็น flow ยาวๆ เหมือนกันค่ะคิดว่าไหนๆ ก็เทสแล้ว ก็ทำให้ครบไปทีเดียวเลย Login -> สร้าง product -> verify -> แก้ไข product -> verify -> ลบทิ้ง รันผ่านก็ดีใจ รันครั้งเดียว ไปใส่ result ว่าผ่านได้หลายข้อเลย แต่พอมันพังขึ้นมา… ก็งงว่ามันพังตรงไหนเสียเวลาไล่หาไปอีกเป็นวัน . รอบสอง “ฉันจะแยก” ทีนี้ก็ทำแบบที่เราคุยกันไปโพสก่อนหน้านี้ค่ะไปแตก test scenario ออกให้ย่อยลงไปอีก เพื่อให้มันเทสแค่อย่างเดียว ตอนนี้การ “แก้ไข product” ก็เลยมี test scenario แยกออกมาเป็นของตัวเองทำให้อ่านง่ายขึ้นมาก

ใครเคยเขียน scenario แบบนี้บ้างคะ Scenario: ทดสอบการ checkoutGiven ผู้ใช้ login แล้วWhen เพิ่มสินค้าลงตะกร้าAnd กรอกที่อยู่จัดส่งAnd เลือกวิธีชำระเงินAnd กด confirm orderThen ระบบแสดงหน้า order successAnd ส่ง email ยืนยันAnd ตัดยอดบัญชีWhen ผู้ใช้ดู order historyThen เห็น order history ถูกต้อง . Scenario เดียว เทสมันให้หมดทุกอย่างไหนๆ ก็ทำไปแล้ว ก็เทสให้ครบไปเลย จะได้ไม่เสียเวลา พี่กิ่งเข้าใจความรู้สึกนี้มากๆ เลยค่ะเพราะเป็นคนนึงที่เคยทำแบบนี้มาก่อน! แล้วก็ต้องมาชดใช้กรรม หาวิธีแก้สิ่งที่ตัวเองทำไว้ 😅 เพราะจริงๆ scenario ด้านบน ถือว่าไม่ได้ทำตามหลักของ BDD แล้วค่ะ . ❌ ปัญหาคืออะไร? Scenario ที่ดี ต้องเทสแค่ 1 behavior

เขียน Automation Test Scenario เป็น Gherkin ไว้ 40 ข้อลองรันบนเครื่องก็ผ่านหมด ส่งขึ้นไปบน CI/CD ก็ผ่าน ทีมภูมิใจมาก เรามี Automation Test ที่ Test Coverage ดีเยี่ยม ครอบคลุมครบทุก requirement ผ่านไป 2 สัปดาห์ มีการอัพเดต UI เข้ามา 🔴 เทสพังไป 38 ข้อทีมต้องวิ่งวุ่นไปไล่อัพเดตจุดที่หน้า UI เปลี่ยน ปัญหาไม่ได้เกิดเพราะโค้ดพัง แต่เพราะเขียนผิดวิธีมาตั้งแต่แรก . เรื่องนี้เป็นอีกหนึ่งปัญหาที่เจอบ่อยมากๆ ในทีมที่เพิ่งทำ Automation Test ค่ะ วันนี้จะพาทุกคนไปรู้จักกับวิธีเขียน Scenario 2 แบบ คือ Imperative กับ Declarative กันค่ะและถ้าเลือกผิด ชีวิตอาจจะเปลี่ยนโดยไม่รู้ตัว . 📌 Imperative

👻❌ เคยเจอผีหลอกตอนรัน 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