เขียน Automation Test Scenario เป็น Gherkin ไว้ 40 ข้อ
ลองรันบนเครื่องก็ผ่านหมด ส่งขึ้นไปบน CI/CD ก็ผ่าน
ทีมภูมิใจมาก เรามี Automation Test ที่ Test Coverage ดีเยี่ยม ครอบคลุมครบทุก requirement
ผ่านไป 2 สัปดาห์ มีการอัพเดต UI เข้ามา
🔴 เทสพังไป 38 ข้อ
ทีมต้องวิ่งวุ่นไปไล่อัพเดตจุดที่หน้า UI เปลี่ยน
ปัญหาไม่ได้เกิดเพราะโค้ดพัง แต่เพราะเขียนผิดวิธีมาตั้งแต่แรก
.
เรื่องนี้เป็นอีกหนึ่งปัญหาที่เจอบ่อยมากๆ ในทีมที่เพิ่งทำ Automation Test ค่ะ
วันนี้จะพาทุกคนไปรู้จักกับวิธีเขียน Scenario 2 แบบ คือ Imperative กับ Declarative กันค่ะ
และถ้าเลือกผิด ชีวิตอาจจะเปลี่ยนโดยไม่รู้ตัว
.
📌 Imperative = เขียนแบบเน้น How บอกทุก step
Imperative คือการเขียน Scenario แบบ บอกว่าต้องทำอะไร ทีละขั้น ต้องกดตรงไหน เช็คตรงไหน
ลองดูตัวอย่างนะคะ ระบบ Food Delivery อันเดิม
Scenario: Place a food order
Given I open the app and I am on Home page
When I click on Search bar and type “Pad Kra Prao”
And I click on the first restaurant in the result
And I click “Add to Cart” button on the first menu item
And I click the cart icon on the top right
And I click the “Place Order” button
Then I see the Order Confirmation Page
อ่านแล้วเป็นยังไงกันบ้างคะ ก็ดูครบดีใช่มั้ยคะ แต่…
.
❌ ปัญหาของ Imperative:
📌 ผูกติดกับ UI ทุก step – แก้ปุ่ม เปลี่ยน layout = กระทบทันที
📌 อ่านแล้วไม่รู้ว่า Scenario นี้ต้องการอะไร เป้าหมายคืออะไร รู้แค่ว่าต้องกดอะไรบ้าง
📌 การ Maintain คือนรกมาก – ถ้ามีการเปลี่ยน UI ต้องไปไล่แก้ทุก Scenario ที่เกี่ยวข้อง
นี่แหละค่ะ ที่เทสพังไป 38 ข้อ ก็เพราะแบบนี้
.
✅ Declarative = เขียนแบบบอก What (ต้องการอะไร)
Declarative คือการเขียน Scenario ที่บอกว่าต้องการอะไร โดยที่ไม่ต้องบอกว่าทำยังไง สนแค่ว่า business rule คืออะไร
ลองดู Scenario เดิม ว่าเราจะเขียนเป็น Declarative ได้ยังไง
Scenario: Place a food order
Given I am logged into the app
When I order “Pad Kra Prao” from an available restaurant
Then I receive an order confirmation
Scenario เดียวกัน แต่อ่านแล้วรู้สึกต่างกันเลยใช่มั้ยคะ
แบบแรกบอกว่า “ต้องทำอะไร” ส่วนแบบที่สองบอกว่า “ต้องการอะไร”
แค่เปลี่ยนมุมมองจาก How เป็น What ก็ทำให้ Scenario นี้มีคุณค่าและอยู่รอดได้นานกว่าเดิมมากค่ะ
.
✅ ข้อดีของ Declarative:
📌 UI เปลี่ยน ก็ไม่ต้องไล่แก้ทุก Scenario – ไปแก้แค่ใน Step Definition ก็พอ
📌 อ่านแล้วเข้าใจ business logic ได้ทันที ทั้ง Dev, PO, QA
📌 Scenario ไม่พังง่ายเวลาแก้ เพราะไม่ได้ผูกกับ implementation
📌 สามารถใช้เป็น Living Documentation ได้เลย ทุกคนเข้ามาอ้างอิงได้ว่าระบบทำงานยังไง ซึ่งจุดนี้เป็นเป้าหมายหลักของ BDD เลยค่ะ
.
📌 ลองดู Before / After อีกหนึ่งตัวอย่าง:
❌ Imperative:
Scenario: Add item to cart
Given I am on the Product Detail page of “Sony Headphones”
When I click the quantity dropdown and select “2”
And I click the blue button labeled “Add to Cart”
Then I see the cart icon badge change to “2”
(ใครอยากฝึก ลองปิดด้านล่างไว้ แล้วไปลองเปลี่ยนให้เป็น Declarative ดูค่ะ)
✅ Declarative:
Scenario: Add item to cart
Given I am viewing the product “Sony Headphones”
When I add 2 units to my cart
Then my cart contains 2 items
.
💡 หลักการง่ายๆ ที่เอาไปใช้ได้เลย:
ถ้า step ไหนมีคำว่า click / type / select / scroll
แปลว่าเราเขียนแบบ Imperative อยู่ ลองเขียนใหม่ให้เน้นผลลัพธ์แทน
.
💡 ใครยังไม่เห็นภาพ ลองมาดูเหตุการณ์ในชีวิตจริง
สมมติเรามีระบบที่ใช้งานได้อยู่แล้ว แต่ Designer ตัดสินใจปรับ UI ใหม่
โดยเปลี่ยนปุ่ม “Add to Cart” เป็น icon ตะกร้าแทน
และ เอา dropdown เลือกจำนวนออก เปลี่ยนเป็นปุ่ม +/-
ถ้าเขียนไว้แบบ Imperative:
🔴 Scenario พังทันที! ต้องเข้าไปไล่แก้ทุก Scenario ที่มี step เกี่ยวกับเรื่องนี้
🔴 ถ้ามีอยู่ 40 ข้อ ก็แปลว่าแก้ 40 ครั้ง อาจจะเสียเวลาหลายชั่วโมง
🔴 อาจจะลืมแก้บางข้อไป ทำให้ test เฟล กลายเป็น false negative ที่ต้องมาเสียเวลาหากันอีก
ถ้าเขียนแบบ Declarative:
✅ Scenario ไม่พังง่ายๆ เพราะเราเข้าไปแก้แค่ Step Definition ที่เกี่ยวข้อง
✅ Gherkin ที่เขียนไว้ยังใช้ได้ เพราะเป็น business logic เดิม ไม่ต้องรื้อ scenario
✅ จากแก้ 40 ที่ อาจจะเหลือแค่ 3 ที่ใน Step Definition ที่เกี่ยวกับ UI นี้
QA ร่างทอง เขียน Scenario เพื่อใช้สื่อสารว่าเราต้องการจะเทสอะไรค่ะ
ไม่ใช่เพื่อเป็น script ว่าเราต้องกดตรงไหนบ้าง
เพราะสุดท้ายสิ่งที่สำคัญจริงๆ ก็คือ business value
เราต้องตอบให้ได้ว่าเขียน Scenario นี้มาเพื่อตอบ business rule ส่วนไหน
.
Automation Test ไม่ได้ยากเพราะ code อย่างเดียวค่ะ
การเขียน code ได้ เป็นแค่จุดเริ่มต้น
แต่สิ่งที่สำคัญคือ เราคิดแบบไหน ก่อนที่จะเริ่มเขียน
ครั้งหน้าลองถามตัวเองก่อนนะคะว่า Scenario ที่เราจะเขียนนี้ตอบ business rule ส่วนไหน
ถ้าตอบไม่ได้ นั่นแหละคือสัญญาณว่าเราอาจจะมาผิดทางอยู่ค่ะ
ถ้าตอบได้ ก็ลุยเลยค่ะ 🙌