จากการแบ่งปันเรื่อง 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 กันบ้างไหม ?
