Screen Shot 2558-08-10 at 12.05.27 PM
จากการแบ่งปันเรื่อง Automated Acceptance Test with Robotframework
มีคำถามที่น่าสนใจ คือ

มีแนวทางสำหรับการเขียน Acceptance test ที่ดีแนะนำไหม ?

ดังนั้นผมจึงขอสรุปแนวทางไว้ดังนี้

Acceptance test นั้นสามารถนำไปประยุกต์ใช้งาน

ในทุกส่วนตั้งแต่ story/feature ไปยังรายละเอียดระดับ task
จากนั้นจึงนำไปสร้างด้วยเครื่องมือต่าง ๆ หรือ test framework
เพื่อให้ทำงานแบบอัตโนมัติต่อไป

โดยที่ acceptance test นั้นจะช่วย

  • บอกทีมพัฒนาว่าแต่ละ story/feature/task จะเสร็จอย่างไร ไม่มโน หรือ คิดไปเอง
  • ช่วยทำให้ทุกคนเข้าใจว่า สิ่งที่กำลังสร้างคืออะไร เป็นอย่างไร เพื่อใคร มีประโยชน์อะไร

คำถาม มีแนวทางการสร้างอย่างไรบ้าง ?

1. เขียนให้ชัดเจนว่าประโยชน์ของสิ่งที่กำลังสร้างมีอะไรบ้าง

มันคือการบังคับให้คุณเข้าใจว่า
สิ่งที่กำลังสร้างคืออะไร ?
สิ่งที่กำลังสร้างมีประโยชน์อย่างไร?
สิ่งที่กำลังสร้างเพื่อใคร ?
สิ่งที่กำลังสร้าง สร้างไปทำไม ?
สิ่งที่กำลังสร้างเราเข้าใจหรือไม่ ?

เป็นการสรุปจากการพูดคุยระหว่าง
เจ้าของ requirement กับ ทีมพัฒนา

เมื่อทุกคนเข้าใจในสิ่งที่กำลังสร้างแล้ว
ทำให้ทุกคนสามารถมีแนวคิดเพื่อปรับปรุงให้มันดีขึ้นอีกด้วย
ไม่ใช่เพียงสร้างให้มันเสร็จ ๆ ไปเท่านั้น

2. กำหนดเงื่อนไขต่าง ๆ ในการตรวจรับซะ

ในแต่ละ story/feature/task ควรกำหนดด้วยว่ามี acceptance criteria อย่างไรบ้าง ?
เพื่อทำให้เรารู้ และ เข้าใจในสิ่งที่กำลังสร้าง
รวมทั้งเพื่อให้เรามีสมาธิในแต่ละส่วนอีกด้วย

บ่อยครั้งเราพบว่างานที่พัฒนาไม่เสร็จ
จะเป็นงานที่เราบอกว่า “requirement มันไม่ชัดเจน”
แต่งานที่เราทำเสร็จ แต่ requirement ไม่ชัดเจน เราไม่พูด !!

3. ทำการกำหนดว่าจะทดสอบอย่างไรบ้าง

ต้องกำหนดว่า จะทดสอบอะไรบ้าง เช่น

  • Happy path
  • Failure path
  • Error path
  • หรือ path อื่น ๆ

มันทำให้เราเห็นปัญหา และ issue ต่าง ๆ ตั้งแต่เริ่มต้น
ไม่ต้องมานั่งเดา หรือ หาสาเหตุกันภายหลัง
และรู้เลยว่า ต้องทำการทดสอบอะไรบ้าง

เรากำลังพัฒนาระบบงานแบบ Proactive หรือ Prevent นะครับ

ที่สำคัญ คือ ในแต่ละการทดสอบ
ควรมีตัวอย่างข้อมูล หรือ example data สำหรับการทดสอบด้วยเสมอ
เป็นข้อมูลจริง ๆ ไม่ใช้ข้อมูลจำลองขึ้นมา เช่น test test a b c 1234 เป็นต้น
มันช่วยให้การพัฒนามันง่าย และ ชัดเจนขึ้นอย่างมาก
รวมทั้งช่วยให้เราคิด และ พูดคุยถึงปัญหาต่าง ๆ ที่เกี่ยวข้องได้

มีคนถามว่า ถ้ามันไม่ครอบคลุม หรือ เพียงพอล่ะ ทำอย่างไร
ตอบง่าย ๆ คือ ก็ทำการเพิ่มไปสิครับ

4. แยกแต่ละ acceptance test ด้วย behaviour หรือ พฤติกรรมการทำงาน

ใน acceptance test แต่ละตัวควรมี acceptance criteria เดียว หรือเน้นเรื่องเดียวเท่านั้น
ไม่ควรสร้าง acceptance test ที่มี acceptance criteria จำนานมาก

ซึ่งมันจะช่วยทำให้แต่ละ story/feature/task
มันเป็นอิสระต่อกัน ไม่ผูกมัดกันมาก
ส่งผลให้ acceptance test มันเข้าใจง่าย ทดสอบง่าย
มันสะท้อนไปยังสิ่งที่เรากำลังสร้างอีกด้วยนะ !!

ดังนั้น acceptance test ก็ควรเป็นอิสระแก่กัน
ทำงานชัดเจนไปเลย ไม่ควรทำการซ้ำซ้อนกัน
เนื่องจากสิ่งที่มันซ้ำซ้อนกันนั้น มันมีค่าใช้จ่ายในการดูแลรักษาสูงมาก ๆ
ให้ระมัดระวังกันด้วยนะครับ

5. สิ่งที่เขียนขึ้นมามันสามารถทำงานแบบอัตโนมัติได้

เมื่องานมันเยอะขึ้น
การทดสอบแบบ manual นั้นมันมีค่าใช้จ่ายสูงขึ้นเรื่อย ๆ
ดังนั้นเราจึงต้องการระบบการทดสอบแบบอัตโนมัติ
ซึ่งเราควรลงทุนสำหรับการสร้างมันขึ้นมา
ทั้งเรื่องของความรู้ความเข้าใจของคนในทีม
ทั้งเรื่องความรู้ความเข้าใจของเครื่องมือที่เหมาะสม

สุดท้ายแล้ว

Acceptance test มันช่วยบอกทีมพัฒนาว่า

  • สิ่งที่ต้องสร้างคืออะไร ?
  • ประโยชน์ และ ความสำคัญของสิ่งที่สร้างคืออะไร ?
  • เข้าใจตรงกันว่า คำว่า เสร็จ มันคืออะไร ด้วยเงื่อนไขอะไร ?

สิ่งที่สำคัญมาก ๆ คือ
บอกว่าเราควรหยุดในการสร้างแต่ละ story/feature/task เมื่อใด
มันทำให้ไม่ต้องสร้างระบบแบบ over หรือ เผื่อมากๆ แบบที่เคยเป็นมา
และที่สำคัญไม่ต้องมานั่ง มโน หรือ เดา กันอีกต่อไป

แล้วคุณล่ะเขียน Acceptance test กันบ้างไหม ?