Screen Shot 2558-10-15 at 6.55.08 PM
การเรียนรู้จากข้อผิดพลาด ถือเป็นแนวทางหนึ่งที่ดีมาก ๆ
ซึ่งมันช่วยให้เราสามารถปรับ และ เปลี่ยน เพื่อทำให้ถูกต้อง
แต่ถ้าผิดเรื่องเดิมซ้ำ ๆ มันก็ไม่ดีนะ

เรื่องของ Test Automation หรือ การทดสอบแบบอัตโนมัติ ก็เช่นเดียวกัน
เราสามารถเรียนรู้จากความผิดพลาดได้เช่นกัน
ดังนั้น มาดูว่ามีความผิดพลาดอะไรบ้าง ?
และอย่าเอาเป็นเยี่ยงอย่าง หรือ ทำตามนะครับ

1. ไม่มีเวลามาสร้าง Test Automation หรอกนะ !!

นั่นหมายความว่า
เมื่อเวลาผ่านไป
จำนวนของ manual testing ยิ่งสูงมากขึ้น และมากขึ้นเรื่อย ๆ
ส่งผลให้มีหลายจุดใน software ที่ไม่ถูกทดสอบ !!
เป็นที่มาของ software ที่ไร้คุณภาพหรือเปล่านะ ?

รวมทั้งส่งผลต่อ ความเร็วในการพัฒนา software
ที่จะช้าลงอย่างต่อเนื่อง ตามจำนวน feature ที่มากขึ้น !!

2. วัดคุณค่าของ Test Automation ด้วยจำนวน test case !!

จงจำไว้ว่า
จำนวนของ test case ไม่ได้ส่งผลต่อคุณภาพของ software เลย
แต่คุณภาพของ test case มาจาก
test case เหล่านั้นทำการทดสอบ feature ต่าง ๆ ตาม requirement หรือไม่ ?
test case เหล่านั้นมีความน่าเชื่อถือหรือไม่ ?

ดังนั้น อย่าวัดค่าด้วยจำนวนเด็ดขาด !!

3. เราทำ Test Automation เฉพาะ End-to-End test ผ่าน User Interface ของระบบเท่านั้น

การทดสอบผ่าน User Interface มันช้ามาก ๆ
การทดสอบผ่าน User Interface มันผิดพลาดได้ง่ายมาก ๆ

ดังนั้น ควรยึดหลักตาม Pyramid Testing นะครับ
นั่นคือ พยายามสร้าง Test Automation ในระดับล่าง ๆ ให้เยอะที่สุด
นั่นคือ Unit testing, Integration testing เป็นต้น

4. เราไม่ได้เผื่อเวลาไว้สำหรับแก้ไข Test Automation ที่มันผิดพลาด​

เมื่อไรก็ตามที่การทดสอบมันทำงานผิดพลาด
ให้ทำการแก้ไขทันที

ไม่ต้องรอขอแก้ไขตาม process การทำงาน
ไม่ต้องถามหาว่าใครทำ
ไม่ต้องถามหาคนทำผิด
แต่ให้ช่วยกันแก้ไข เพื่อให้มันกลับทำงานได้อย่างถูกต้อง

5. ชุดการทดสอบมันพังง่ายมาก ๆ หรือ ขึ้นอยู่กับ test case อื่น ๆ

บางครั้งทำงานได้ถูก
บางครั้งทำงานผิดพลาด
บางวันทำงานได้ถูก
บางวันทำงานผิดพลาด
หรือบาง test case จะทำงานได้ ต้องผ่านการทำงานบาง test case ก่อนเสมอ
หรือบาง test case ทำงานผิดพลาด แล้ว
ส่งผลให้ test case อื่น ๆ อีกมากมายผิดพลาด

ถ้ามีปัญหาแบบนี้ทำการแก้ไขได้เลย
เนื่องจากแต่ละ test case ควรทำงานเป็นอิสระต่อกัน

6. ชุดการทดสอบไม่เคยผิดเลย แม้การทำงานจะผิดก็ตาม !!

เคยเจอ test case ที่ไม่ว่าจะอย่างไร
ผลการทำงานก็ผ่าน และ ถูกเสมอบ้างไหม ?

มันเป็นผลมาจาก ข้อมูลในการทดสอบมันไม่ครบถ้วน
หรือเกิดจากความมักง่ายของผู้สร้าง
ซึ่งเป็นกรณีที่น่ากลัวอย่างมาก
และไม่ควรทำโดยเด็ดขาด

เช่นอาจจะเจอเขียนการตรวจสอบใน test case แบบนี้ก็ได้
assert True;
แบบนี้ทำงานผ่านตลอดไปแน่นอน !!

7. มีชุดการทดสอบที่แย่ ๆ มากมาย

ตัวอย่างเช่น
ชุดการทดสอบที่เข้าใจยาก
ชุดการทดสอบที่ซ้ำซ้อน
ชุดการทดสอบที่ผูกติดกับ User Interface มากจนเกินไป
ส่งผลให้การดูแลรักษายากมาก ๆ

ดังนั้น การ review test case จึงมีความสำคัญอย่างมาก

8. มี Specialist หรือ Test Automation Team ขึ้นมาดูแลโดยเฉพาะ !!

มันอาจจะดี ในมุมมองของการสร้าง Test Automation นะ
แต่มันยากที่จะขยาย และ รองรับงานที่ใหญ่ขึ้น
สุดท้ายทีมนี้จะกลายเป็นคอขวด
แถมยังมีการทำงานแบบทีมใครทีมมัน
นี่มันคือ การทำงานแบบ Silo นี่หว่า !!

ทางที่ดีกว่า คือ
ให้ทำการกระจาย และ แบ่งปันความรู้เรื่อง Test Automation
ไปยังทีมต่าง ๆ น่าจะดีกว่านะครับ

9. บังคับให้คนที่ไม่ชอบ ไม่มีความสนใจ ไม่ชอบเขียน Test Automation มาทำ !!

ถ้าคน ๆ นั้น ไม่มีความสนใจ
ถ้าคน ๆ นั้น ไม่มีความใส่ใจ
และโดนบังคับให้ทำ เช่นการเขียน Test Automation แล้ว
ผลที่ได้ออกมา มันจะแย่มาก ๆ

ดังนั้น เริ่มจากการสร้างแรงบันดาลใจดีกว่า
ว่าเรามีปัญหาอะไร ทำไมต้องสร้างมันด้วยล่ะ
น่าจะเป็นแนวทางที่ดี และ ยั่งยืนกว่า

10. สร้าง Test Automation แต่ไม่ยอม run หรือ ทดสอบ !!

แล้วจะสร้างไปทำแมวอะไร ?
แม้แต่คนสร้าง ยังไม่ทดสอบเลย
มันน่ากลัวมากเลยนะครับ

11. ทำการ Ignore test !!

เมื่อเราทำการ run test แล้วมันเกิดข้อผิดพลาดขึ้นมา
สิ่งที่ชอบทำกันก็คือ Ignore test นั้น ๆ ไปเลย
มันบ่งบอกว่า ไม่มีใครสนใจ test เลย
เพียงแค่ทำให้มันเสร็จ ๆ
อะไรที่มันไม่ผ่านก็ Ignore หรือ หนักกว่านั้น คือ ลบมันไปเลย !!
สุดท้ายเราก็จะได้ test ที่ห่วยแตกมาก ๆ

สิ่งที่ทุก ๆ คนต้องทำ และ มีวินัยคือ
ถ้า test case มันเกิดข้อผิดพลาดต้องรีบแก้ไข
ไม่มี test ของใครคนใดคนหนึ่ง
มีแต่ของทีมนะ

สุดท้ายขอฝากไว้ว่า

Test automation มันสำคัญมาก ๆ
ดังนั้น ต้องดูแลมัน เหมือนกับ production code
หรือ code ที่ส่งมอบให้ลูกค้า

ให้มันทำงานแบบอัตโนมัติผ่านระบบ Continuous Integration ซะ
ดังนั้น ไม่มีการทำงานแบบ manual นะ

ถ้ามันเกิดข้อผิดพลาดขึ้นมา ให้รีบแก้ไขมันซะ
อย่าปล่อยปละละเลยอย่างเด็ดขาด

และต้องทำงานเป็นทีม หรือ Whole-Team Approach
เพราะว่า เรื่องของคุณภาพของ software
มันคือหน้าที่ของทุก ๆ คน