6 วิธีง่ายๆ ที่ทำให้ Test Stable ขึ้นได้ทันที
.
ไม่ว่าคุณจะเพิ่งเริ่มเขียน Gherkin เพื่อใช้เป็น Acceptance Criteria
หรือ เอาไปใช้เป็น Feature File ใน Automation Test อยู่แล้ว
มีสิ่งนึงที่เราทุกคนเจอเหมือนกันค่ะ
เขียน Scenario ไปหมดแล้ว Given-When-Then ครบทุกข้อ
แต่ทีมก็ยังอ่านไม่รู้เรื่อง ไม่มีใครเข้าใจว่าจะเทสอะไร
หรือถ้าใช้ใน Automation Test อยู่ ก็พังหมดจนตามแก้แทบไม่ไหว
ปัญหาไม่ใช่ว่า Gherkin ไม่ดี
แต่อยู่ที่วิธีที่เราเขียนมันต่างหาก
วันนี้พี่กิ่งเอา checklist 6 ข้อมาฝากกันค่ะ
เอาไปทำตามกันได้เลย
.
📌 1. บอกว่า “ต้องการอะไร” ไม่ใช่ “ทำยังไง”
Gherkin ที่ดี ต้องบอก behavior ค่ะ สิ่งที่ต้องการจะทำคืออะไร
ไม่ใช่ implementation ว่าทำยังไง ขั้นตอนเป็นยังไง
เรามาลองดูตัวอย่างกันค่ะ
❌ Procedure-driven
Scenario: Add to cart
Given the user opens a web browser
And the user navigates to the shopping website
And the user clicks on the product page
When the user clicks the Add to Cart button
Then the item should be in the cart
✅ Behavior-driven
Scenario: Add item to cart successfully
Given the user is on the product page
When the user adds the item to the cart
Then the item appears in the cart
เราไม่ต้องบอกก็ได้ว่ากดอะไรบ้างเพื่อเพิ่มสินค้าลงตะกร้า
ใน Automation Test ขั้นตอนพวกนี้จะไปอยู่ตอนที่เราเขียน step definition แทนค่ะ
การเขียนแบบนี้ ถ้า UI เปลี่ยน หรือ flow เปลี่ยน
เราจะไม่ต้องกลับมาแก้ Feature File เลย
และยังทำให้อ่านเข้าใจง่ายกว่าด้วยว่า Scenario นี้ต้องการจะทำอะไร
.
📌 2. One Scenario, One Behavior
Scenario 1 ข้อ ต้องเช็ค behavior เดียวเท่านั้น
ไม่ควรทำหลายอย่างในข้อเดียว หรือ ทำเป็น flow ต่อกันยาวๆ
สังเกตง่ายๆ
ถ้ามี When-Then มากกว่าหนึ่งที่ใน Scenario เดียวเมื่อไหร่
ให้หยุดทันทีค่ะ แล้วไปดูว่าเราจะแยกมันออกมาได้ยังไง
❌ หลาย behavior ใน Scenario เดียว
Scenario: Shopping cart
Given the user is on the product page
When the user adds the item to the cart
Then the item appears in the cart
When the user views the cart
Then the total price is correct
เห็น When-Then 2 คู่มั้ยคะ = สัญญาณเตือนให้หยุดก่อน
ตอนนี้เรากำลังเช็คสองอย่างว่า เพิ่มของลงตะกร้าได้มั้ย และ คิดราคาถูกมั้ย
ถ้า Scenario นี้พัง เราจะไม่รู้เลยค่ะว่ามันพังเรื่องไหนกันแน่ นอกจากจะเข้าไปไล่เช็ค
✅ แยกตาม behavior
Scenario: Add item to cart successfully
Given the user is on the product page
When the user adds the item to the cart
Then the item appears in the cart
Scenario: Cart shows correct total price
Given the user has items in the cart
When the user views the cart
Then the total price is correct
แบบนี้ ถ้า Automation Test พัง หรือเราเห็นว่า Scenario ไหนเฟล
เราจะรู้ทันทีว่าเรื่องไหนกันแน่ที่พัง โดยที่ไม่ต้องไล่ debug เลย
เรื่องนี้ยังมีรายละเอียดให้คุยกันอีกเยอะเลยค่ะ ไว้จะมาเล่าในโพสถัดๆไป
ตอนนี้จำเอาไว้ว่า When-Then 1 คู่ ต่อ Scenario 1 ข้อเท่านั้น
.
📌 3. เรียงตามลำดับเวลาเท่านั้น
Given -> When -> Then เรียงตามนี้เสมอ ห้ามสลับ
ฟังดูเหมือนจะเป็นคอมม่อนเซนส์ แต่พอเขียนเร็วๆ หรือก๊อปปี้มาจาก Test เก่าๆ มักจะเผลอทำไปโดยไม่รู้ตัวค่ะ
❌ Step ไม่เรียงตามลำดับ
Scenario: Add item to cart
Given the user clicks Add to Cart
When the user is on the product page
Then the item appears in the cart
จริงๆ เราต้องไปหน้า product page ก่อน ค่อยกด Add to Cart
✅ ลำดับถูกต้อง
Scenario: Add item to cart
Given the user is on the product page
When the user clicks Add to Cart
Then the item appears in the cart
แบบนี้จะเป็น flow จริงที่เกิดขึ้น ทำให้เข้าใจง่ายกว่า
และไม่มีปัญหาเรื่อง state ค้างจากขั้นก่อนก่อนหน้าด้วยค่ะ
.
📌 4. เขียน step ให้ถูกและชัดเสมอ
เราต้องทำให้ Gherkin ของเราเหมือน Document ชิ้นนึงค่ะ
เพราะฉะนั้นต้องจริงจังกับรูปแบบการเขียนด้วย
ควรจะเขียนให้ถูกตามหลักภาษาเสมอ เพื่อลดโอกาสที่จะเกิดความเข้าใจผิดค่ะ
✅ ใช้ present tense เสมอ
✅ มี subject ในทุก step ห้ามตัดประธานในประโยคออก
✅ เขียนให้เป็นภาษาที่ถูกต้อง ทั้ง grammar และ ตัวสะกด (ต้องเรียนภาษาอังกฤษไปอีก)
❌ ไม่ถูกหลักภาษา
When clicks the Add to Cart button
ไม่ใส่ subject ในประโยค ทำให้อ่านแล้วไม่รู้ว่าใครคลิกกันแน่
✅ ถูกเป๊ะตามแกรมม่า
When the user clicks the Add to Cart button
กลายเป็น step ที่ชัดเจน ทุกคนเข้าใจตรงกัน คนอื่นก็เอาไป reuse ได้ง่ายขึ้นด้วย
.
📌 5. ชื่อ Scenario ต้องบอก behavior ได้เลย
ชื่อ Scenario ที่ดี ต้องไม่เกิน 1 บรรทัด กระชับ
อ่านแล้วรู้ทันทีว่าต้องการเช็คอะไร
และที่สำคัญ หลีกเลี่ยงคำเชื่อมต่างๆ เช่น And, Or, But
เมื่อไหร่ที่มี แปลว่ามีอะไรซักอย่างไม่ถูกแล้วค่ะ
❌ ชื่อที่ไม่บอก behavior
Scenario: Add to Cart and verify stock and check total
บอกจะ verify แต่ไม่รู้ verify อะไร แถมยังมี And อีก แปลว่าเรากำลังเช็คหลายเรื่องในข้อนี้
✅ ชื่อที่ชัด
Scenario: Add item to cart successfully
Scenario: Show out-of-stock error when item is unavailable
แบบนี้ถ้า Scenario ที่ 2 พัง เราก็รู้ทันทีว่าเรื่องเช็คสต็อคมีปัญหา โดยที่ยังไม่ต้องเปิดดูโค้ดหรืออะไรเลย
.
📌 6. สั้น กระชับ ได้ใจความ!
Scenario ที่ดี แค่กวาดตาดูผ่านๆ ก็ควรจะพอเข้าใจแล้วค่ะ
ลองเช็คดูง่ายๆ ถ้าข้อไหนมีเกิน 10 steps เมื่อไหร่ ต้องมาดูแล้วว่าเกิดอะไรขึ้น
เราอาจจะเขียนเป็นแบบ procedure ที่บอกขั้นตอนเยอะเกินไป
หรือ เราอาจจะกำลังเช็คหลายอย่างใน Scenario เดียวอยู่ก็ได้ค่ะ
❌ ยาวเกินไป
Scenario: Shopping cart checkout
Given the user is on the homepage
And the user searches for a product
And the user selects the product
And the user clicks Add to Cart
And the user opens the cart
And the user clicks checkout
When the user fills in shipping details
And the user selects payment method
And the user confirms the order
Then the order is placed successfully
And the confirmation email is sent
แบบนี้ใช้เวลานานกว่าจะอ่านเข้าใจ แถมถ้ามีอะไรเปลี่ยน ก็ต้องมาไล่แก้ตาม
✅ สั้น focus ที่ behavior เดียว
Scenario: Place order successfully
Given the user has items in the cart and shipping details filled
When the user confirms the order
Then the order is placed and confirmation email is sent
พอเปลี่ยนเป็นแบบนี้ จะเห็นว่าอ่านเข้าใจง่ายกว่ามาก
ทำให้ debug ง่าย และดูแลง่ายตามไปด้วยค่ะ
.
Gherkin ที่ดี ไม่ได้วัดว่าเราเขียนละเอียดแค่ไหน ลงดีเทลแค่ไหน
แต่เราวัดกันว่า เราเขียนให้คนอื่นอ่านแล้วเข้าใจตรงกันแค่ไหน
และ Test ของเรา stable แค่ไหน 🎯
ลองเอา 6 ข้อนี้ไปปรับใช้กันได้เลยนะคะ
.
ไว้เราจะมาลงลึกกันเรื่อง Procedure-driven vs Behavior-driven และ One Scenario, One Behavior กันในโพสต่อๆไปค่ะ และสองเรื่องนี้ก็เป็นสิ่งสำคัญที่จะช่วยให้ Automation Test ของเราดูแลง่ายขึ้น และ stable ขึ้นมากๆ ฝากติดตามกันด้วยนะคะ