ใครเคยเขียน scenario แบบนี้บ้างคะ
Scenario: ทดสอบการ checkout
Given ผู้ใช้ login แล้ว
When เพิ่มสินค้าลงตะกร้า
And กรอกที่อยู่จัดส่ง
And เลือกวิธีชำระเงิน
And กด confirm order
Then ระบบแสดงหน้า order success
And ส่ง email ยืนยัน
And ตัดยอดบัญชี
When ผู้ใช้ดู order history
Then เห็น order history ถูกต้อง
.
Scenario เดียว เทสมันให้หมดทุกอย่าง
ไหนๆ ก็ทำไปแล้ว ก็เทสให้ครบไปเลย จะได้ไม่เสียเวลา
พี่กิ่งเข้าใจความรู้สึกนี้มากๆ เลยค่ะ
เพราะเป็นคนนึงที่เคยทำแบบนี้มาก่อน!
แล้วก็ต้องมาชดใช้กรรม หาวิธีแก้สิ่งที่ตัวเองทำไว้ 😅
เพราะจริงๆ scenario ด้านบน ถือว่าไม่ได้ทำตามหลักของ BDD แล้วค่ะ
.
❌ ปัญหาคืออะไร?
Scenario ที่ดี ต้องเทสแค่ 1 behavior เท่านั้นค่ะ
คิดง่ายๆ ว่าเป้าหมายของ scenario นั้น ต้องมีแค่เรื่องเดียวเท่านั้น
ย้อนกลับไปดู scenario ด้านบน จะเห็นว่ามี “When” หลายอัน
นั่นแปลว่า เรากำลังเล่า “ขั้นตอน” ไม่ใช่ “พฤติกรรม” ของระบบ
แล้วมันสำคัญยังไง?
ลองคิดตามนะคะว่าถ้า scenario ด้านบนเฟลขึ้นมา แล้วเราเป็นคนต้องเข้าไปเช็คผล
เราจะตอบได้ยังไงว่าเฟลเพราะอะไร
ก็ต้องไปไล่ดูแต่ละสเต็ปถูกมั้ยคะ ไล่หาว่าเฟลที่จุดไหน
กรอกที่อยู่ไม่ได้ ชำระเงินไม่ได้ email ไม่ส่ง ยอดไม่ตัด
อาจจะเสียเวลาเป็นวันในการเข้าไปไล่หาว่ามันพังตรงไหนกันแน่
นี่แหละค่ะ สัญญาณว่า scenario ของเรายังไม่ clean พอ
.
❌ เขียนยาวๆ อาจจะทำให้ไม่เจอบั๊กบางตัว
การเขียนเป็น scenario ยาวๆ จะทำให้เราเสียโอกาสในการเทสส่วนอื่น
ถ้ามีจุดใดจุดหนึ่งใน scenario นั้นพังด้วยค่ะ
ลองคิดตามนะคะ สมมติเรามีบั๊ก 2 จุดคือ ส่ง email ไม่ได้ กับ Order History ไม่ขึ้น
ถ้าเราเทสแบบ scenario ด้านบน เราจะเจอบั๊กแค่เรื่องเดียวคือส่ง email ไม่ได้
เพราะเคสนี้จะพังไปก่อนที่จะได้เช็ค Order History
แปลว่าเราเสียโอกาสในการเทส Order History ไปเลย
ต้องรอจนแก้ email เสร็จ แล้วมารันดูอีกที ถึงจะรู้ว่า Order History ก็พังเหมือนกัน
แล้วเราจะทำยังไงดี…
.
✅ QA ร่างทองเขียนแบบนี้แทน
Scenario: ชำระเงินสำเร็จแสดงหน้า order success
Given ผู้ใช้มีสินค้าในตะกร้าและกรอกข้อมูลครบแล้ว
When กด confirm order ด้วยบัตรที่มียอดเพียงพอ
Then ระบบแสดงหน้า order success พร้อม order ID
Scenario: ชำระเงินสำเร็จส่ง confirmation email
Given ผู้ใช้ชำระเงินเรียบร้อยแล้ว
When ระบบ process order เสร็จ
Then ส่ง confirmation email ไปที่ email ที่ลงทะเบียนไว้
Scenario: หน้า Order History แสดงออเดอร์ที่ชำระเงินแล้ว
Given ผู้ใช้มีออเดอร์ที่ complete แล้ว
When ไปที่หน้า Order History
Then ออเดอร์แสดงถูกต้องตาม order ID ที่ทำไว้
แบบนี้ ถ้า scenario ไหนพัง เราบอกได้เลยว่าพังตรงไหน ไม่ต้องเดา
และที่สำคัญ ถ้ามีบั๊ก 2 จุด คือ ส่ง email ไม่ได้ กับ Order History ไม่ขึ้น ตามที่คุยกันไปแล้ว
การแยกแบบนี้ เราจะเจอบั๊กทั้ง 2 จุด ในการรันรอบเดียวเลยค่ะ
ทำให้ทีมสามารถไปแก้มาได้ทีเดียวเลย ไม่ต้องรอ
.
💭ใครที่อ่านถึงตรงนี้แล้วมีคำถามว่า แล้วไอ้ “Given ผู้ใช้ชำระเงินเรียบร้อยแล้ว” หรือ “ Given ผู้ใช้มีออเดอร์ที่ complete แล้ว”
มันไม่เป็น Scenario ต่อกันยาวๆ ยังไง เพราะถ้าตรงนี้พัง เทสก็พังอยู่ดี
ใครมีคำถามนี้ ยินดีด้วยนะคะ แปลว่าคุณคือ QA ร่างทอง ตัวจริง!
ถูกต้องเลยค่ะที่การแยก scenario อย่างเดียว ยังไม่พอที่จะทำให้เป็น Automation Test ที่ดี แต่ก็เป็นจุดเริ่มต้นง่ายๆ ที่เราไปเริ่มทำได้เลยค่ะ
ส่วนคำถามนี้ มันคือ concept ของการทำ Test State Setup เพื่อเตรียม environment ของเราให้พร้อมก่อนจะรันเทส เอาไว้โพสต์หน้าจะมาเล่าให้ฟังนะคะ
.
📌 Rule ง่ายๆ ที่เอาไปใช้ได้เลยวันนี้:
ถ้า scenario มี “When-Then” มากกว่า 1 รอบ ให้ “หยุด” เลยค่ะ
แล้วถามตัวเองก่อนว่า “กำลังเทส behavior เรื่องไหนอยู่” หรือ “objective ของ scenario นี้คืออะไร”
ถ้าคำตอบมีมากกว่าหนึ่งเรื่อง ก็ให้แยกมันออกจากกันค่ะ
.
การทำ Automation Test ที่ดี ไม่ใช่แค่ให้มันรันผ่านนะคะ นั่นเป็นแค่จุดเริ่มต้นเท่านั้น
แต่มันต้องทำให้เรารู้ให้เร็วที่สุดว่า มันพังตรงไหน และพังเพราะอะไร โดยที่ไม่ต้องมานั่ง debug กันข้ามคืน
เพราะเมื่อไหร่ที่เรามี Automation Test รันอยู่เยอะๆ แล้วเนี่ย
เวลาที่ใช้ในการมาไล่เช็คผล สำคัญกว่า เวลาในการรันเทส เยอะเลยค่ะ
การแยกเป็นหลายๆ scenario อาจเพิ่มเวลารันไปอีก 1 ชั่วโมง
แต่ประหยัดเวลาไล่เช็คผลได้ 4 ชั่วโมง… คิดว่า trade-off นี้คุ้มมั้ยคะ?
.
และนี่แหละค่ะคือความต่างระหว่าง QA ที่เขียน Automation Test แค่พอให้รันได้
กับ QA ที่ทำให้ทีมทำงานได้เร็วขึ้นและมั่นใจขึ้นจริงๆ
อยากเป็นแบบไหน เราเลือกได้เลยค่ะ