สิ่งที่ควรทำสำหรับ Automated Acceptance Testing

จากการลงมือทำ 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 ต่อไปครับ