จากการลงมือทำ Automated Acceptance Testing นั้น
พบว่ามันไม่ใช่เรื่องง่าย ๆ เลย
ซึ่งมันบั่นทอนชีวิต และ จิตใจอย่างรุนแรง
มันมีเรื่องที่ไม่ควรทำมากมาย
มันไม่มีรูปแบบในการทำที่ตายตัว หรือ ชัดเจน
มันเป็นเรื่องที่ต้องลงมือทำ ดู feedback และปรับปรุงอย่างต่อเนื่อง
ดังนั้นจึงทำการสรุปสิ่งที่ควรทำสำหรับ Automated Acceptance Testing ดังนี้
พบว่าสิ่งที่ยากที่สุด คือ การทำงานร่วมกัน !!
มันง่ายมากที่จะเขียน spec ของงาน
มันง่ายมากที่จะเขียน rule การทำงาน
มันง่ายมากที่จะเขียน data test หรือ example
แต่เรื่องสนุก ๆ มันจะเกิดขึ้น
เมื่อต้องทำการแปลงจากสิ่งที่อยู่ในเอกสารมาเป็น Automated Acceptance Tests เช่น
- ใครกันที่จะมาเขียน ?
- ใครกันที่จะมาดูแล ?
- เมื่อเขียนแล้วสิ่งที่ได้คือ ชุดการทดสอบที่ซับซ้อน อ่านไม่รู้เรื่อง ดูแลยาก ทำงานช้า กลายเป็นปัญหาอีก !!
มันช่างดูขัดแย้งกับเป้าหมายของ Automated Tests นะ ว่าไหม ?
แทนที่จะทำให้เราทำงานได้รวดเร็วขึ้น กลับทำให้ช้าลงไปอีก
แทนที่จะทำให้คุณภาพของระบบงานดีขึ้น กลับไม่ เหมือนไม่ทำอะไรเลย
แทนที่จะ release งานได้เร็ว กลับช้าลงไป หรือ ช้าเหมือนเดิม
แถมยังมีภาระเพิ่มขึ้นอีก !!
ถ้าใครอยู่ในสภาวะนี้ แสดงว่า
สิ่งที่ทำอยู่นั้นไม่น่าจะถูกต้อง หรือ เหมาะกับทีม หรือ งาน นะ !!
ดังนั้นจึงข้อแนะนำสิ่งที่ควรทำ สำหรับ Automated Acceptance Test
1. Acceptance test กับ End-to-End test (e2e) มันต่างกันนะ
หลาย ๆ คนคิด และ เข้าใจว่า มันคือสิ่งเดียวกัน
เพราะว่า มันแยกออกจากกันได้ยากมาก ๆ !!
แต่ในความเป็นจริงมันต่างกันนะ
มาดูความแตกต่างของทั้งสองกันหน่อย
Automated Acceptance Test นั้นจะมีเป้าหมาย และ การทดสอบเพียงอย่างเดียวเท่านั้น
จะทำการทดสอบไปยัง function การทำงานนั้น ๆ โดยตรง
หรือทดสอบไปยัง API หรือ End point ต่าง ๆ เลย
ตัวอย่างเช่น
Given I am a new user
When I visit the product detail
Then I see detail of product A
Automated End-to-End Test นั้นจะครอบคลุม
หรือเป็นเส้นทางการทำงานของระบบตั้งแต่ต้นทางจนถึงปลายทาง
เหมือนกับการใช้งานของผู้ใช้งาน
ซึ่งควรคำกำหนดจำนวน test case ไว้เลย ไม่ให้เยอะจนเกินไป
เนื่องจากใช้เวลาการทดสอบสูงมาก ๆ
ซึ่งต้องพึงระวังอย่างมาก !!
ตัวอย่างเช่น
Given I am a new user
When I visit the product detail
And I add product to my order
Then I see my basket
When I choose and enter my payment detail
And I choose my shipping
Then I see my order confirmation
ดังนั้นควรแยกให้ชัดเจนนะครับ
ซึ่งเราควรเน้นไปที่ Automated Acceptance Test เป็นหลัก
เพราะว่ามันทำงานได้รวดเร็ว และ มีเป้าหมายที่แน่ชัด
2. ให้เน้นว่าต้องการทำอะไร ไม่ใช่เขียนตามระบบงาน
เวลาเขียน scenario ต่าง ๆ ต้องไม่ลงรายละเอียดมากจนเกินไป
เนื่องจากสิ่งที่เราเขียนมานั้น
ต้องให้คนอื่น ๆ เช่น ฝ่าย business อ่าน และ เข้าใจ
พูดง่าย ๆ คือ เขียนให้คนทั่วไปอ่านรู้เรื่อง
รวมทั้งไม่ยาวจนเกินไป
ตัวอย่างเช่น
Given I am a customer
When I go to the promotion page
And I click product A
And I click shipping
Then I see shipping equals 0 THB
เป็นตัวอย่างที่เขียนถึงรายละเอียดของระบบ
หรือการพัฒนามากจนเกินไป
หรือผูกติดกับ technical มากเกินไป
บ่อยครั้งเมื่อเปลี่ยน User Interface กลับมีผลกระทบกับ test อีกด้วย !!
น่าจะเขียนให้ตรงกับความต้องการของเรา
นั่นคือ ต้องการดูว่า product มันฟรีค่าจัดส่งนะ
ตัวอย่างเช่น
Given I am a customer
When I visit the promotion page
Then I see free shipping
ดังนั้นในการเขียน scenario และ feature
ควรเน้นไปที่ว่า ระบบทำอะไร (What)
มากกว่าระบบทำงานอย่างไร (How)
มันจะทำให้เราอ่านง่าย เข้าใจได้ง่าย
แถมเปลี่ยนแปลงได้ง่ายอีกนะครับ
3. การทดสอบต้องเป็นอิสระต่อกัน
ลองคิดดูสิว่า
ถ้าแต่ละการทดสอบมันเป็นอิสระต่อกันแล้ว
เราสามารถแยกการทดสอบออกจากกันได้
เราสามารถให้แต่ละการทดสอบทำงานแบบขนานกันได้
ซึ่งส่งผลให้เวลาการทดสอบน้อยลง
แถมช่วยให้เราหาจุดผิดพลาดได้ง่ายอีกด้วย
ดังนั้นลองคิดดูว่า ถ้ามันเป็นแบบตรงข้าม
จะทำให้การทดสอบมันซับซ้อน
จะทำให้การทดสอบยากลำบากขึ้นมากไหม
จะทำให้การดูแลรักษายากขึ้นมากไหม
4. Automated test มันต้องช่วยลดการทดสอบแบบ manual test ลงไปนะ
การทดสอบนั้น เราไม่ได้เน้นแต่ code coverage เท่านั้น
แต่สิ่งที่เราต้องให้ความสำคัญอย่างมากก็คือ
ประโยชน์จากชุดการทดสอบเหล่านั้นต่างหาก
ดังนั้นลองถามตัวคุณเองสิว่า Automated test ที่เราสร้างขึ้นมานั้น
- มันช่วยลดเวลาในการทดสอบลงไหม ?
- มันช่วยลดเวลาการทำ regression test ลงไหม ?
- มันช่วยเพิ่มคุณภาพให้กับระบบไหม ?
- มันช่วยเรื่อง time to market ไหม ?
- มันช่วยเพิ่มความมั่นใจต่อระบบไหม ?
- มันช่วยทำให้คุณมั่นใจเมื่อต้อง release ระบบไหม ?
คำตอบมันอยู่ที่คุณแล้ว
และผมเชื่อว่า manual test ยิ่งเป็น regression test แล้ว
คงไม่มีใครชอบหรอกนะ !!
5. หน้าที่รับผิดชอบในการดูแล Automated Test เป็นของทุกคนในทีมนะ
ให้เชื่อเถอะว่า
การสร้างทีมเพื่อแยกออกมาเขียน Automated test โดยเฉพาะ
มันไม่เคยได้ดี และ มีประสิทธิภาพที่ดีเลย
เพราะว่า ทีมนี้สนใจเพียงเรื่องการทดสอบ ไม่สนใจระบบเลย
ดังนั้น ถ้าทุกคนในทีมรับผิดชอบเรื่อง คุณภาพ หรือ (Quality Build-in)
มันจะได้ผลลัพธ์ที่แจ่มแมวมาก ๆ
ซึ่งมันอาจจะยากสำหรับการเริ่มต้น
แต่ผลในระยะยาวมันดีอย่างแน่นอน
การทำงานร่วมกันเป็นทีม มันสำคัญอย่างมาก
6. ทำการทดสอบทุกครั้งที่มีการเปลี่ยนแปลง
มีคำถามว่า
จะทดสอบ Automated test บ่อยเท่าไร ?
ตอบได้เลยว่า
ทุกครั้งที่มีการเปลี่ยนแปลง
ไม่ว่าจะเป็น source code
ไม่ว่าจะเป็นชุดการทดสอบ
หรืออะไรก็ตามที่เกี่ยวข้องกับระบบ
จะไม่รอ ให้ครบ 10 test case ก่อน จึงจะทดสอบ
จะไม่รอ ให้ถึงเวลา 16.00 น. ก่อน จึงจะทดสอบ
เพราะว่า สิ่งที่เราต้องการคือ feedback
ของการทดสอบที่รวดเร็ว
เราจะได้รู้ว่าสิ่งที่เราเปลี่ยนแปลงไปนั้น
มันกระทบต่อการทำงานหรือไม่นั่นเอง
ซึ่งมันทำให้คุณมั่นใจทุกการก้าวเดิน
7. ต้อง run test แบบขนาน (Parallel)
เนื่องจากในระบบต่าง ๆ ที่มีชุดของ Automated test นั้น
จะมีจำนวนมากขึ้นเรื่อย ๆ
นั่นหมายความว่า เวลาการทำงานก็นานขึ้นด้วย
ดังนั้น เราต้องลดเวลาการทำงานลงด้วย
การเปลี่ยนจากการ run แบบตามลำดับมาเป็นแบบขนาน
ดังนั้นแต่ละการทดสอบต้องเป็นอิสระต่อกันด้วย
ไม่เช่นนั้นจะทำไม่ได้นะครับ
ที่สำคัญ ไม่ใช่เพียงการทดสอบเร็วขึ้นเท่านั้น
แต่มันยังเป็นการจำลองการใช้งานระบบ
เสมือนว่า ผู้ใช้งานหลาย ๆ คนกำลังใช้งานระบบอีกด้วย
8. ทำการ run Automated End-to-End Test บน production ไปเลย !!
เนื่องจากการทำงาน Automated test
ไม่ว่าจะเป็น Acceptance test และ End-to-End test
ล้วนมีค่าใช้จ่ายที่สูง ดังนั้น
สิ่งที่ได้กลับมาจากการลงทุนต้องมีคุณค่าสมเหตุสมผลด้วยเช่นกัน
เช่น
การ run Enn-to-End test หลักจากที่ทำการติดตั้งระบบบน production server
เพื่อทำให้มั่นใจในการ deploy ว่ามัน work นะ
ซึ่งเป็นคุณค่าที่คุณคู่ควรใช่หรือเปล่า ?
ดังนั้นสิ่งที่คุณ และ ทีมต้องค้นหาก็คือ
คุณค่าที่ได้จากชุดการทดสอบที่สร้างขึ้น
ทั้งการ run บน dev, testing, staging และ production
สุดท้าย อย่าหยุดที่จะทำสิ่งต่าง ๆ เหล่านี้
เนื่องจากทุก ๆ อย่างมันคือ การทดลอง
เพื่อทำให้เราเข้าใกล้เป้าหมายที่ตั้งไว้ของการทำ Automated testing
ซึ่งคุณต้องเรียนรู้ เพื่อ Inspect and Adapt ต่อไปครับ
