ยกระดับการเขียนบั๊กด้วย AI: พาชม Skill ใหม่ของ Claude Code ในการสร้างรายงานบั๊กจากหลักฐานจริง
เจาะลึกบทความตอนที่ 8 ของซีรีส์ Automating Playwright กับการสร้าง Skill บน Claude Code ที่แปลงปัญหาที่พบให้เป็นรายงานบั๊กพร้อมส่ง พร้อมระบบ Guardrails ป้องกันข้อมูลเท็จ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เป็นตอนที่ 8 ของซีรีส์ Automating Playwright with Claude Code เน้นการสร้าง Skill รายงานบั๊ก
- นำปัญหาที่ตรวจจับได้จากตอนที่ 6 มาแปลงเป็นรายงานบั๊กที่มีขั้นตอนการทำซ้ำจากหลักฐานจริง
- ใช้รูปแบบ Guardrails จากตอนที่ 7 ป้องกันการกุข้อมูลและบังคับให้มนุษย์ตรวจสอบก่อนกดส่งจริง
- รายงานประกอบด้วยชื่อหัวข้อ ขั้นตอน ผลลัพธ์ที่คาดหวัง ผลลัพธ์จริง หลักฐาน และระดับความรุนแรง
เดินทางมาถึงตอนที่ 8 แล้วสำหรับซีรีส์ "Automating Playwright with Claude Code" โดยในบทความนี้เป็นการต่อยอดจากตอนที่ 6 ที่ระบบของเราสามารถตรวจจับปัญหาอย่างเทสที่รันไม่ผ่านเป็นครั้งคราวหรือปัญหาเรื่อง Locator ได้แล้ว และตอนที่ 7 ที่ว่าด้วยเรื่องรูปแบบการป้องกันความปลอดภัย (Guardrails) มารวมกันเพื่อสร้างเป็น Skill ตัวใหม่ที่มีชื่อว่า Bug-Reporter
ที่ผ่านมา Skill ของ Claude มักจะจบลงแค่การแจ้งเตือนว่ามีบางอย่างผิดพลาดเกิดขึ้น แต่ในบทความนี้ได้ปิดช่องว่างดังกล่าวด้วยการสร้าง Skill ที่เปลี่ยนความล้มเหลวที่ Claude เพิ่งค้นพบ ให้กลายเป็นรายงานบั๊กที่พร้อมนำไปใช้งานจริง โดยมีขั้นตอนการทำซ้ำที่อ้างอิงจากหลักฐาน ไม่ใช่การคาดเดา
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ก่อนที่จะลงมือเขียนโค้ดสำหรับ Skill นี้ จำเป็นต้องกำหนดฟิลด์ข้อมูลที่รายงานบั๊กที่ดีควรมี ซึ่งจะกลายเป็นเทมเพลตผลลัพธ์ของ Skill เช่น ชื่อหัวข้อ ขั้นตอนการทำซ้ำ ผลลัพธ์ที่คาดหวัง ผลลัพธ์จริง หลักฐาน และสภาพแวดล้อม พร้อมกับนำกฎ Guardrails จากตอนที่ 7 มาบังคับใช้ทันที เนื่องจากรายงานบั๊กที่ถูกกุขึ้นมาเองจะสร้างความเสียหายและเสียเวลาให้แก่ทีมนักพัฒนาอย่างมาก
การนำ AI มาช่วยรายงานบั๊กโดยอัตโนมัติมีความเสี่ยงเรื่อง "การกุข้อมูล" (Hallucination) ที่ AI อาจพยายามเติมเต็มช่องว่างของข้อมูลที่ขาดหายไปเพื่อให้รายงานดูสมบูรณ์ การที่บทความนี้เน้นย้ำเรื่อง Guardrails ห้ามใส่ขั้นตอนที่ไม่ได้ทำจริง และห้ามส่งเข้าเครื่องมือติดตามบั๊กอัตโนมัติทันที จึงเป็นแนวทางปฏิบัติที่ปลอดภัยและช่วยรักษาความน่าเชื่อถือของกระบวนการพัฒนาซอฟต์แวร์
กฎเหล็กของ Guardrails ในระบบนี้ประกอบด้วย:
- ห้ามใส่ขั้นตอนการทำซ้ำใดๆ ที่ไม่ได้ปฏิบัติจริงและสังเกตเห็นด้วยตาตัวเองระหว่างเซสชันนั้น
- หากหลักฐานในฟิลด์ใดขาดหายไป เช่น ไม่มี Log หรือภาพหน้าจอ ให้ระบุลงไปตรงๆ ว่าไม่มี แทนที่จะเว้นว่างหรือคาดเดาเอง
- ห้ามส่งตั๋วปัญหาเข้าสู่ระบบติดตามโดยอัตโนมัติ ต้องแสดงรายงานให้ผู้ใช้ยืนยันก่อนเสมอเพื่อป้องกันตั๋วซ้ำ
ตัวอย่างการทำงานจริง เมื่อทดสอบหน้าชำระเงินที่พบปัญหาปุ่ม "Place Order" สามารถกดคลิกได้ทันทีโดยที่ยอดรวมในตะกร้าราชายังอัปเดตไม่เสร็จ ระบบ playwright-flaky-test-debugger จากตอนที่ 6 จะทำงานก่อนเพื่อเก็บหลักฐาน Trace จากนั้น playwright-bug-reporter จะสร้างรายงานออกมาในรูปแบบที่กำหนด เช่น ระบุว่าปุ่มยังคงคลิกได้ในช่วงเวลาที่กำลังคำนวณใหม่ และมีหลักฐานจาก Trace ที่แสดงว่า Element มีค่า aria-busy="true" อยู่ ณ Timestamp 00:04.211
"Checkout — "Place Order" clickable before cart total finishes updating"
ชื่อรายงานบั๊กตัวอย่างจากบทความ
เทมเพลตที่สร้างขึ้นนี้ถูกออกแบบมาให้เป็นกลางไม่ผูกติดกับระบบติดตามบั๊กตัวใดตัวหนึ่ง เพื่อให้ทีมงานสามารถนำไปปรับ ใชักับ Jira, GitHub Issues หรือเครื่องมืออื่นๆ ได้ตามต้องการ โดยการปิดวงจรจากการค้นหาปัญหาไปสู่การสร้างประโยชน์นี้ ทำให้ชุดเครื่องมือตั้งแต่ตอนที่ 6 และ 8 สามารถทำงานร่วมกันได้อย่างครบวงจรตั้งσό แต่การตรวจจับ วินิจฉัย ไปจนถึงการเขียนรายงานในรูปแบบที่ตรวจสอบได้
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น