วันนี้ได้กลับไปอ่านหนังสือ Continuous Delivery อีกครั้ง
โดยในรอบนี้เน้นไปในเรื่อง Automated Acceptance Testing ซึ่งอยู่ในบทที่ 8
พบว่ามีเรื่องที่น่าสนใจมากมาย ดังต่อไปนี้
1. ทำไมเราต้องให้ความสำคัญกับ Acceptance Testing ล่ะ ?
ทำไมเราต้องสนใจ และ ใส่ใจด้วยล่ะ ?
เมื่อเรามีประสบการณ์ไปได้สักระยะหนึ่ง
จะพบว่า ถ้าเราไม่มี Acceptance test ที่มันดี ๆ
และครอบคลุมส่วนการทำงานต่าง ๆ แล้วมักจะเกิดปัญหาดังต่อไปนี้
- ใช้เวลาในการค้นหา และ แก้ไขข้อผิดพลาดต่าง ๆ สูงมาก
- ใช้เวลาในการทำ manual test และ regression test สูงมาก (ส่วนใหญ่ชอบทำ !!)
- คุณภาพของระบบ หรือ software ที่ส่งมอบมันต่ำมาก ๆ
2. จะสร้างชุดการทดสอบของ Automated Acceptance Testing ที่มันดี และ ดูแลง่าย ๆ ต้องทำอย่างไร ?
พูดถึงเรื่องแนวการสร้างที่ดี ซึ่งควรมีคุณสมบัติ INVEST
อธิบายแบบง่าย ๆ คือ
- ต้องมีคุณค่าต่อผู้ใช้งาน
- สามารถทดสอบได้ง่าย
ต่อจากนั้น Automated Acceptance test ที่ดีประกอบไปด้วย 3 layer คือ
- Acceptance criteria อยู่ในรูปแบบ Given-When-Then หรือ xUnit style
- Test implementation เป็นชุดของ code ในรูปแบบเฉพาะตาม business domain นั้น ๆ ไม่ผูกติดกับ User Interface เด็ดขาด
- Application driver layer ทำการแปลงภาษาจาก Test implementation เพื่อทำงานกับระบบงานที่ทดสอบจริง ๆ และส่งผลการทำงานกลับไป
การสร้างอย่างเดียวมันยังไม่พอ
ต้องทำการ refactor code ของการทดสอบอยู่อย่างเสมอ
เพื่อทำให้มันชุดการทดสอบมันดีอยู่ตลอดเวลา
ทั้งเรื่องของการจัดการพวก state, timeout
รวมถึงการนำ Test double มาใช้งาน
3. แล้วใครล่ะ ? มีหน้าที่สร้าง Acceptance test ?
ไม่ใช่หน้าที่ของ Tester เพราะว่าในตำแหน่งมีคำว่า Test
ไม่ใช่หน้าที่ของ SA/BA เพราะว่ารู้เรื่อง business
ไม่ใช่หน้าที่ของ Developer เพราะว่ารู้เรื่องการเขียน code
แต่เป็นหน้าที่ของทุกคนที่เกี่ยวข้อง
เพื่อร่วมกันกำหนด acceptance criteria ของแต่ละ feature
ซึ่งทำให้ทุกคนมีความเข้าใจร่วมกัน
ว่าแต่ละ feature คืออะไร ทำงานอย่างไร
และจะทำการทดสอบอย่างไร
4. Acceptance criteria สามารถเขียนได้กี่รูปแบบ ?
ในหนังสือทำการแยกออกเป็น 2 แบบคือ
รูปแบบที่ 1 Internal DSL
เขียนด้วยภาษาโปรแกรมที่ developer ถนัด และ คุ้นเคย
เช่นใช้งานพวก xUnit test เป็นต้น
แต่คนทางฝั่ง business หรือทาง QA/Tester จะกลัวมันอย่างมาก
สุดท้าย developer ก็รับผิดชอบไปก็แล้วกัน !!!
รูปแบบที่ 2 External DSL
เขียนด้วยรูปแบบที่คนทั่วไปสามารถอ่านได้ เข้าใจได้ง่าย
เช่น plain test, HTML, CSV และ Given-When-Then เป็นต้น
ทำให้ใคร ๆ ก็สามารถเขียน แก้ไข และ ดูแลมันได้
5. วินัย และ ข้อปฏิบัติ เมื่อสร้าง Automated Acceptance Test
เมื่อมันทำงานช้า ให้ทำการหยุดหาสาเหตุ และ ปรับปรุงมันซะ
เมื่อมันทำงานไม่ผ่าน ให้ทำการหยุดหาสาเหตุ และ แก้ไขมันซะ
เมื่อมันทำงานไม่ผ่าน อย่าไป ignore มัน การ ignore test เป็นวินัยการทำงานที่แย่มาก ๆ
เมื่อมันทำงานไม่ผ่าน ให้ทำการบันทึกไว้ เพื่อให้ง่ายต่อการหาสาเหตุ
ดังนั้นยิ่งจำนวนของการทดสอบยิ่งมาก ค่าใช้จ่ายยิ่งสูง
ทั้งการสร้าง ทั้งการดูแลรักษา
ดังนั้นทำแต่ละการทดสอบให้ดี
ถ้าเห็นว่าไม่ดี ให้รีบทำการแก้ไขซะ
ถ้าอยากเดินไปให้เร็ว ก็เดินไปในทางที่ดี
วันนี้คุณมี Automated Acceptance Test แล้วหรือยัง ?
ปล.
แปลกนะว่า หนังสือเล่มเดิม เนื้อหาเดิม
แต่เมื่อเวลาผ่านไป เรากลับเข้าใจมันมากขึ้น
