อ่านเอกสารเรื่อง The Road to DevTestOps แล้วน่าสนใจดี
ซึ่งมีการพูดเรื่อง DevTestOps Manifesto ประกอบไปด้วย
- Continuous testing over testing at the end
- Embracing all testing activities over only automated functional testing
- Testing what gives value over testing everything
- Testing across the team over testing in silos testing department
- Product coverage over code coverage
แค่นี่ก็น่าสนใจแล้ว เพราะว่ามันส่งผลกระทบต่อการทำงานในปัจจุบันอย่างมาก
จึงทำการสรุปไว้นิดหน่อยดังนี้
จากที่ DevOps ได้รับความนิยม
ทำให้หลาย ๆ องค์กรเริ่มนำแนวคิดนี้
มาช่วยปรับปรุงขั้นตอนการทำงานและส่งมอบ software ให้ดีขึ้น
ทำงานเป็น working group มากกว่าต่างทีมต่างทำกันไป
ดังจะเห็นได้ว่ามีแนวคิดอื่น ๆ ตามมา เช่น
DevSecOps, BizDevOps, UXOps เป็นต้น
แต่ส่วนของการทดสอบหรือ testing กลับไม่ได้พูดถึงมากนัก
ตามจริงใน DevOps นั้นเรื่องของ testing นั้นสำคัญมาก ๆ
ดังนั้นในเอกสารชุดนี้จึงเน้นเรื่องของ testing
เพื่อทำให้เข้าใจมากขึ้นว่าเป็นอย่างไร
เนื่องจากการพัฒนา software ส่วนใหญ่นั้น
การ testing มักจะอยู่ช่วงท้ายของการพัฒนา
หรือทำก่อนที่จะส่งมอบนั่นเอง
ทำให้มองว่า การ testing นั้นเป็นคอขวด
ทำให้การการส่งมอบช้าลง ส่งผลต่อรายได้ที่จะเข้ามาอีก
แต่ก็มีบางอุตสาหกรรมที่ยอมให้ช่วงของการ testing ยาวนานได้
ยกตัวอย่างเช่น สายการแพทย์และพวก aerospace เป็นต้น
จากปัญหาดังกล่าวของการ testing
เมื่อเรื่องของ Automation testing เข้ามา
เราก็เอามาช่วยการทดสอบในส่วนของ functional เป็นหลัก
เช่น UI testing และ API testing บ้าง
ทำให้ความเร็วของการทดสอบอาจจะเร็วขึ้น
แต่ช่วงของการสร้างชุดการทดสอบก็ใช้เวลาเยอะ
และทำการทดสอบในช่วงท้ายของการพัฒนาอยู่
รวมทั้งมีปัญหาเรื่องความไม่เสถียรของการทดสอบอีก
ใช้เวลาการทดสอบนานมาก ๆ !!
ส่งผลให้ทีมพัฒนาได้รับ feedback ที่ช้ามาก ๆ
ทำให้การแก้ไขช้าไปอีก
ดูท่าจะมีปัญหามากกว่านะ !!
หนักกว่านั้น การ testing ยังเป็นหน้าที่ของทีม QA/Tester อีก
ฝั่งหนึ่งสร้าง ฝั่งหนึ่งทดสอบ แยกกันไป
หรือเราเรียกการทำงานแบบนี้ว่า Silo
ก็ให้เกิดปัญหาและ overhead สูงมาก ๆ
หลาย ๆ องค์กรเริ่มนำแนวทางการพัฒนาแบบ Iterative and Incremental มาใช้
นั่นคือทำงานเป็นรอบสั้น ๆ
แต่ก็พบว่าการ testing มักอยู่ช่วงท้ายของรอบการทำงานเช่นเดิม
หรือเรามักเรียกว่า การทำงานแบบ mini-waterfall
ดังจะเห็นได้จาก board การทำงานว่า
จะมีชื่อว่า waiting to test, ready to test หรือ tested เป็นต้น
แน่นอนว่า ปัญหาไม่ได้หายไป แต่กลับหนักกว่าเดิม !!
จากปัญหาต่าง ๆ ที่เกิดขึ้นมานั้น
ได้ผ่านการเรียนรู้ ลองผิดลองถูก
จนทำให้ตกผลึกว่า เราน่าจะมีแนวคิดหรือแนวทางใหม่ ๆ
นั่นคือ DevTestOps นั่นเอง
เพื่อช่วยให้การพัฒนา software ส่งมอบได้รวดเร็วพร้อมมีคุณภาพมากขึ้น
ในเอกสารได้กำหนด Principle ของ DevTestOps ไว้ดังนี้
- Platform ของการ test ต้องง่ายต่อการสร้างและดูแลรักษา
- Test ต้องพร้อมรับต่อการเปลี่ยนแปลง ดังนั้นชุดการทดสอบต้องไม่ผูกมักกับ technology ของระบบ
- Test ต้องสามารถ scale ได้ หรือนำไปทำงานบน cloud ได้
- สามารถ integrate หรือทำงานใน Delivery process ได้ดีและเร็ว เพื่อให้ได้รับ feedback ที่เร็ว
- คำว่าคุณภาพต้องได้รับการกำหนดและพัฒนาขึ้นอย่างต่อเนื่อง
- การ testing ต้องถูกฝังหรือรวมเป็นหนึ่งกิจกรรมของทีม ไม่ใช่เฉพาะใครหรือกลุ่มใดกลุ่มหนึ่งเท่านั้น รวมทั้งผลการทดสอบทีมต้องได้รับรู้อย่างสม่ำเสมอ เช่นส่งเข้า communication tool ของทีมเป็นต้น อย่าแอบ
มาถึงตรงนี้น่าจะทำให้เห็นว่า DevTestOps นั้น
ไม่ใช่เรื่องใหม่อะไร
เพียงสร้างอีกคำขึ้นมา เพื่ออธิบายให้ชัดเจนยิ่งขึ้น
เข้าใจของการทำงานร่วมกันเป็นทีมหรือ Whole Team Approach นั่นเอง
เพื่อช่วยเติ่มเติมช่องว่าระหว่าง
Business, Stakeholder, Development, Operation และอื่น ๆ อีกมากมาย
เป้าหมายหลักคือ ส่งมอบ software ได้อย่างรวดเร็วและมีคุณภาพสูงนั่นเอง
และอีกอย่างหนึ่งคือ การ testing จะเกิดขึ้นอย่างต่อเนื่องและตลอดเวลา
นั่นคือ Continuous Testing และ Keep testing visible ครับ