วันนี้มีโอกาสแบ่งปันเรื่องของ Test Automation ใน course Agile Testing
แล้วมีคำถามที่เกิดขึ้นมาว่า
- เราทำการสร้างมันไปทำไม ?
- มีเป้าหมายคืออะไรกันแน่ ?
- ทำแล้วมันได้อะไร ? เสียอะไร ?
ลองไปหาคำตอบกันหน่อยสิ
เริ่มต้นด้วยการกลับไปอ่านหนังสือ เรื่อง xUnit Test Pattern: Refactoring Test Code
ซึ่งทำให้เราได้คำตอบดี ๆ เยอะเลย
เราต้องสร้าง Test Automation ไปทำไม ?
ที่สำคัญต้องเขียน code อีกด้วย
เพื่อให้การทดสอบทำงานแบบอัตโนมัติ
ทั้ง Unit Test และ Acceptance Test
ซึ่งมันเยอะเยอะไปหมด !!
ต้องเขียนชุดการทดสอบเหล่านี้ให้มันดีด้วย ซึ่งยากมาก
แถมต้องเขียนให้มันดูแลรักษาง่าย ซึ่งยากยิ่งกว่า
นั่นคือ
All tests pass
All tests clean
มิเช่นนั้น
คุณค่าของการทดสอบจะหายไปอย่างแน่นอน
เนื่องจากมันกลับกลายเป็นภาระต่อเรา !!
สิ่งเหล่านี้มันจำเป็นอย่างมาก
ในการพัฒนาแบบ Agile software development
หรือการทำงานแบบ iterative และ incremental
ประเด็นที่สำคัญมาก ๆ ของ Test Automation ประกอบไปด้วย
- ค่าใช้จ่ายในการสร้าง
- ค่าใช้จ่ายในการดูแลรักษา
- ค่าใช้จ่ายในการอ่าน
- ค่าใช้จ่ายในการทำความเข้าใจ
- ค่าใช้จ่ายในการแก้ไข
ดังนั้น เราจำเป็นต้องลดค่าใช้จ่ายเหล่านี้ลงไปให้ได้ !!
เป้าหมายของ Test Automation คืออะไรกันแน่ ?
- ช่วยปรับปรุงเรื่องของ คุณภาพ software
- ช่วยทำให้เราใจระบบ
- ช่วยลดความเสี่ยงต่าง ๆ
- ง่ายต่อการทดสอบ
- ง่ายต่อการสร้าง และ ดูแลรักษา
- การทดสอบต้องมีค่าดูแลรักษาที่ต่ำมาก ๆ
ทำ Test Automation แล้วมันได้อะไร ? เสียอะไร ?
แน่นอนว่า การจะสร้างอะไรขึ้นมา
มันต้องมีค่าใช้จ่ายเสมอ
ทั้งการสร้าง และ ดูแลรักษา
เรามีเป้าหมายง่าย ๆ คือ
ในทุก ๆ ระบบต้องมี Test Automation เสมอ
และต้องมั่นใจด้วยว่า Test Automation
จะไม่ไปเพิ่มค่าใช้จ่ายของการพัฒนา software
นั่นคือ
มันต้องช่วยลดเวลาจากการทดสอบแบบ manual
มันต้องช่วยลดเวลาของการ debug
มันต้องช่วยลดเวลาของการแก้ไขปัญหา
มาดูกันว่าค่าใช้จ่ายของ Test Automation เป็นอย่างไร ?
จากรูปสามารถอธิบายได้ดังนี้
ในช่วงเริ่มต้นนั้น
จะมีค่าใช้จ่ายสำหรับการเรียนรู้เทคโนโลยี และ แนวปฏิบัติต่าง ๆ ที่สูงขึ้นมาก
แต่เมื่อถึงจุดหนึ่งที่ทีมพัฒนาสามารถเรียนรู้
และ เริ่มเข้าใจ และ พัฒนาตามแนวปฏิบัติต่าง ๆ แล้ว
ค่าใช้จ่ายต่าง ๆ ในการสร้าง Test Automation จะลดลง และ คงที่
และสิ่งที่ได้กลับมา คือ
ทีมพัฒนาได้ประโยชน์จากชุดการทดสอบอย่างต่อเนื่อง
ทั้งเรื่องของความมั่นใจในการสร้าง
ว่าสิ่งที่สร้างมันไม่กระทบต่อส่วนอื่น ๆ นะ
นั่นคือ ลดจำนวน effort ในการพัฒนาลงไป
นั่นคือ จำนวนงาน และ productivity และ คุณภาพของ software ที่ดีขึ้น
ดังนั้น ให้กลับมาถามตัวเราเองสิว่า
เป้าหมายของการสร้าง Test Automation คืออะไรกันแน่ ?
แล้วกลับมาดูว่า
สิ่งที่คุณกำลังสร้างอยู่นั้น มันตอบกับเป้าหมายหรือไม่ ?
ถ้าไม่
แสดงว่า น่าจะกำลังเดินผิดทาง
และต้องทำการปรับปรุงได้แล้วนะ