หนึ่งในแนวคิดที่น่าสนใจใน Test Automation
โดยเฉพาะในส่วนของ UI testing ไม่ว่าจะเป็น web app และ mobile app
นั่นคือ Self-Healing
เพื่อช่วยทำให้การทดสอบมัน stable มากยิ่งขึ้น
อะไรที่มันผิดก็พยายาม run ใหม่ หรือ แก้ไขเพื่อทำให้ test ผ่านแบบอัตโนมัติ (Retry until green !!)
เนื่องจากในฝั่งของ UI (User Interface) นั้นออกแบบมาเพื่อคนใช้งาน
ไม่ใช่ออกแบบมาเพื่อ machine หรือ computer นั่นเอง
ที่เน้นเรื่องของ user experience ที่ดีต่อผู้ใช้งาน
ดังนั้นเราจะพบปัญหาในการทดสอบ UI บ่อย ๆ คือ
- ไม่ได้ทำงานแบบ synchronous และ ทำงานแบบ dynamic อย่างมาก
- มีการเปลี่ยนแปลง locator ในการเข้าถึง element ต่าง ๆ (Locator strategies) แต่พฤติกรรมการใช้งานยังคงเหมือนเดิม
- ระบบงานไม่ stable ทำให้เดี๋ยวผ่านบ้างไม่ผ่านบ้าง ทั้ง ๆ ที่ไม่ได้เปลี่ยนแปลงอะไร
ส่งผลให้การทดสอบไม่มีความน่าเชื่อถือ
ซึ่งก็มีวิธีแก้ไขที่หลากหลาย อยู่ที่รูปแบบของการทำงานด้วยว่าเป็นอย่างไร
รวมทั้งเรื่องความรู้และความเข้าใจใน technology ที่ใช้งานอีกด้วย
ตัวอย่างเช่นในการทดสอบ web app ด้วย Playwright
จะมีการเข้าถึง element ต่าง ๆ ด้วย strategy เยอะมาก ๆ
โดยทาง Playwright จะแนะนำให้ใช้งานผ่าน Role ของ element นั้น ๆ
หรือ อาจจะใช้งานผ่าน id/name ก็ได้ หรือ ผ่าน test id ก็ว่าไป
แต่เมื่อมีการเปลี่ยนแปลง role และ id แล้วจะเกิดอะไรขึ้น ?
หรือถ้าในหน้าจอ element เหล่านั้นไม่แสดงขึ้นมา หรือ ไม่ทัน จะเกิดอะไรขึ้น ?
ผลคือ การทดสอบ fail นั่นเอง
แนวทางการแก้ไขนั้น เราก็ไม่อยากจะ rework กัน
ดังนั้นจะมีแนวคิดของ self-healing เข้ามาช่วย
ด้วยการนำเครื่องมือหรือพวก AI เข้ามาช่วย
เพื่อทำการหา locator ของ element นั้น ๆ ใหม่ (เมื่อ failure ขึ้นมา)
โดยจะทำการดึงข้อมูล element ในหน้าจอนั้น ๆ มา
จากนั้นใช้แนวคิดความน่าจะเป็นว่า
การเข้าถึง element นั้น ๆ ควรเป็น locator อะไร
เช่นใช้งานผ่าน Playwright CLI หรือ Agent Browser เป็นต้น
ร่วมกับ LLM มาเพื่อเลือกและเข้าถึง element นั้น ๆ ต่อไป
ซึ่งก็ช่วยแก้ไขปัญหาได้เช่นกัน
แต่เดี๋ยวก่อน มันคือ Solution หรือ Workaround กันแน่ ?
ต้นเหตุที่แท้จริงของปัญหานี้คืออะไรกันแน่ ?
- ทำไมถึงมารู้ว่าเปลี่ยนตอน run test ?
- ก่อนเปลี่ยนไม่คุย หรือ ตกลงร่วมกัน ?
- ต่างฝ่ายต่างแยกกันทำงาน ?
- ปัญหามาจากการทำงานร่วมกันไหม ? communication and collaboration problem ?
- ทำงานเป็น silo คือ ต่างคนต่างทำงานไหม ?
- ทำการทดสอบบ่อยไหม ?
- ต้องแก้ไขซ้ำ ๆ กันหลายที่ (งานเยอะ แต่ไม่ยาก)
- ระบบไม่ stable รวมทั้งไม่สามารถควบคุม dependency ต่าง ๆ ได้
เช่น ถ้าตกลงกันก่อนเปลี่ยน
จะได้วิเคราะห์และประเมินผลกระทบก่อนลงมือทำทั้งพัฒนาและทดสอบ
เช่นถ้า run test ไม่บ่อย
ก็ทำการปรับให้ทดสอบได้บ่อยขึ้น
เช่นถ้าทีมพัฒนาแก้ไข code แล้ว
ต้องรอให้ทีมทดสอบมา run test case แบบนี้ช้าไหม ?
มากำหนด process การทำงานร่วมกันเลยไหม
ว่าแก้ไขไป run test ไปด้วยเลย (Detect changes !!)
มันลด effort การทำงานลงไปเยอะมาก ๆ นะ ลองไหม ?
คำว่า done = coded + tested
เช่นถ้าต้องแก้ไขหลายที่ในเรื่องเดิม ๆ
น่าจะต้องทำการ refactor test case
เพื่อลด duplication
และจัดการโครงสร้างให้ชัดเจน เพื่อให้ maintain ได้ง่ายขึ้น
การเปลี่ยนแปลงมันเป็นเรื่องปกติอยู่แล้ว
แต่เราจะทำการจัดการมันอย่างไรมากกว่า
ยิ่งปล่อยไว้นาน ยิ่งก่อให้เกิดปัญหาตามมาเยอะ
และส่งผลต่อการแก้ไขอีกด้วย ว่าจะแก้ไขที่ต้นเหตุ หรือ ปลายเหตุ
ไม่มีผิดมีถูก แต่ดูจากผลที่ออกมามากกว่า คุ้มกับการลงทุนหรือไม่
ลองทำการปรับปรุง หรือ ปรับเปลี่ยน
ให้เหมาะสมกับปัญหา ทีม และ รูปแบบการทำงาน
สามารถใช้หลาย ๆ แนวทาง เครื่องมือ มาช่วยกันได้
เราสร้างทุกอย่างขึ้นมา เพื่อดูแลนั่นเอง
ดังนั้นทำให้มันดูแลได้ง่าย จะเป็นแนวทางที่น่าจะดีกว่าให้มันเสร็จ ๆ ไป
Reference websites
