AI for QA and Software Testing

รายละเอียดหลักสูตร

อบรม 2 วัน วันละ 6 ชั่วโมง รวม 12 ชั่วโมง (09:00-16:00 น.) รูปแบบบรรยายพร้อม Workshop ลงมือทำกับระบบจริง ระดับ Beginner ถึง Intermediate หลักสูตรนี้เน้นวิธีคิดและกระบวนการทดสอบมากกว่าการเจาะลึกเครื่องมือใดเครื่องมือหนึ่ง จึงนำไปปรับใช้กับ Framework อื่นได้ ผู้ที่ต้องการลงลึกเฉพาะ Playwright แนะนำหลักสูตร Playwright ทดสอบเว็บอัตโนมัติแบบ End-to-End แยกต่างหาก ผู้เรียนจะได้ชุด Prompt Template สำหรับงาน QA ทุกขั้นตอน Template Test Plan, Test Case, Defect Report และ Quality Report พร้อมสคริปต์ตัวอย่างกลับไปใช้งานจริง

Day 1: ออกแบบการทดสอบด้วย AI

Section 1: AI ในงาน QA และขอบเขตที่ควรใช้

• งาน QA ที่กินเวลามากที่สุดและจุดที่ AI ช่วยได้จริง
• งานที่ AI ทำแทนไม่ได้ เช่น การตัดสินว่าอะไรเสี่ยงพอที่จะต้องทดสอบ
• ภาพรวมเส้นทางทั้งหมดตั้งแต่วางแผนจนถึงรายงานคุณภาพ
• ความเสี่ยงเรื่องข้อมูลลับของลูกค้าเมื่อใช้เครื่องมือ AI ภายนอก
• การเตรียมเครื่องมือและบัญชีให้พร้อมใช้ตลอดสองวัน

Section 2: วิเคราะห์ Requirement และวางแผนทดสอบ

• การอ่าน Requirement เพื่อหาจุดที่กำกวมและเงื่อนไขที่ยังไม่ระบุ
• การใช้ AI ตั้งคำถามกลับไปยังทีมพัฒนาเพื่อปิดช่องว่างก่อนเริ่มทดสอบ
• การประเมินความเสี่ยงเพื่อจัดลำดับว่าจะทดสอบอะไรก่อน
• องค์ประกอบของ Test Plan ที่กระชับและใช้งานได้จริง
• Lab: เขียน Test Plan จาก Requirement ของระบบที่ผู้เรียนดูแลอยู่

Section 3: ออกแบบ Test Case ด้วยเทคนิคมาตรฐาน

• Equivalence Partitioning และ Boundary Value Analysis
• Decision Table และ State Transition สำหรับเงื่อนไขที่ซับซ้อน
• การเขียน Test Case ที่ระบุเงื่อนไขเริ่มต้น ขั้นตอน และผลลัพธ์ที่คาดหวังชัดเจน
• การใช้ AI ขยายชุด Test Case ให้ครอบคลุมกรณีที่คนมักมองข้าม
• การตัดกรณีซ้ำซ้อนออกเพื่อไม่ให้ชุดทดสอบบวมเกินจำเป็น
• Lab: สร้างชุด Test Case จากฟีเจอร์จริงพร้อมตรวจความครอบคลุม

Section 4: การเตรียม Test Data

• ประเภทของข้อมูลทดสอบและกรณีขอบที่ต้องมีเสมอ
• การใช้ AI สร้างข้อมูลจำลองที่สมจริงโดยไม่ใช้ข้อมูลจริงของลูกค้า
• การทำข้อมูลให้ไม่ระบุตัวตนและข้อควรระวังตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล
• การเตรียมชุดข้อมูลให้ทดสอบซ้ำได้ผลเหมือนเดิมทุกครั้ง
• Lab: สร้างชุด Test Data ครอบคลุมทุกกรณีของ Test Case ที่ออกแบบไว้

Section 5: Exploratory Testing อย่างมีทิศทาง

• ความต่างระหว่างการทดสอบตาม Script กับ Exploratory Testing
• การเขียน Charter เพื่อกำหนดขอบเขตและเป้าหมายของแต่ละรอบ
• การใช้ AI ช่วยตั้งสมมติฐานว่าระบบน่าจะพังตรงไหน
• การบันทึกสิ่งที่ทำและสิ่งที่พบให้ตรวจสอบย้อนหลังได้
• Lab: ทำ Exploratory Session กับระบบจริงแล้วสรุปผลที่พบ

Section 6: การทดสอบ API

• การอ่านสเปก OpenAPI เพื่อถอดรายการสิ่งที่ต้องทดสอบ
• การออกแบบชุดทดสอบทั้งกรณีปกติ กรณีข้อมูลผิด และกรณีไม่มีสิทธิ์
• การตรวจสอบรหัสสถานะ โครงสร้างข้อมูลตอบกลับ และข้อความแจ้งข้อผิดพลาด
• การใช้ AI สร้างชุดทดสอบ API จากสเปกและตรวจว่าครบทุกจุด
• Lab: สร้างและรันชุดทดสอบ API ด้วย Postman จากสเปกจริง

Day 2: อัตโนมัติ วิเคราะห์ผล และรายงาน

Section 7: ใช้ AI เขียนสคริปต์ทดสอบอัตโนมัติ

• เกณฑ์การตัดสินว่า Test Case ไหนคุ้มที่จะทำอัตโนมัติและไหนควรทดสอบด้วยมือ
• การแปลง Test Case เป็นสคริปต์ด้วย AI และการตรวจสิ่งที่ AI เขียนมา
• การเลือก Selector ให้ทนต่อการเปลี่ยนหน้าจอ
• การจัดโครงสร้างสคริปต์ให้ดูแลต่อได้ ไม่ใช่เขียนทิ้ง
• Lab: แปลง Test Case เป็นสคริปต์อัตโนมัติแล้วรันกับระบบจริง

Section 8: ดูแลสคริปต์ไม่ให้เปราะ

• สาเหตุที่สคริปต์ทดสอบพังบ่อยและวิธีป้องกันตั้งแต่ตอนเขียน
• การจัดการการรอคอยและสถานะของหน้าจอให้ผลการทดสอบนิ่ง
• การจัดการ Flaky Test ที่ผลไม่คงที่และการตัดสินใจว่าจะซ่อมหรือตัดทิ้ง
• การใช้ AI ช่วยวิเคราะห์สาเหตุที่สคริปต์ล้มเหลวและเสนอวิธีแก้
• Lab: ซ่อมสคริปต์ที่พังจากการเปลี่ยนหน้าจอให้กลับมาทำงานได้

Section 9: เลือกชุด Regression ตามความเสี่ยง

• ปัญหาของการรัน Regression ทั้งชุดทุกครั้งเมื่อเวลาไม่พอ
• การวิเคราะห์ว่าโค้ดที่เปลี่ยนกระทบส่วนใดของระบบบ้าง
• การใช้ AI ช่วยเสนอชุดทดสอบที่ควรรันจากรายการสิ่งที่แก้ไข
• การจัดชั้นชุดทดสอบเป็น Smoke, Critical Path และ Full Regression
• การวางจังหวะรันในแต่ละรอบการพัฒนาให้เหมาะกับเวลาที่มี

Section 10: วิเคราะห์ผลและเขียนรายงาน Defect

• การอ่านผลที่ล้มเหลวและแยกว่าเป็นบั๊กจริงหรือปัญหาที่ตัวสคริปต์เอง
• องค์ประกอบของรายงาน Defect ที่นักพัฒนาแก้ต่อได้ทันทีโดยไม่ต้องถามกลับ
• การใช้ AI ช่วยเรียบเรียงขั้นตอนการเกิดซ้ำและจัดระดับความรุนแรง
• การจัดกลุ่มบั๊กที่มีสาเหตุเดียวกันเพื่อไม่ให้รายงานซ้ำซ้อน
• Lab: เขียนรายงาน Defect จากผลการทดสอบจริงที่ทำมาในคลาส

Section 11: รายงานคุณภาพและข้อจำกัดของ AI

• ตัวชี้วัดคุณภาพที่มีความหมายและตัวชี้วัดที่ทำให้ทีมปั่นตัวเลข
• การสรุปสถานะคุณภาพให้ผู้บริหารเข้าใจโดยไม่ต้องลงรายละเอียดเทคนิค
• จุดที่ AI มักพลาดในงานทดสอบ เช่น Test Case ที่ดูดีแต่ไม่ได้ทดสอบอะไรจริง
• การตรวจทานผลลัพธ์ของ AI ก่อนนำไปใช้และการรักษาความรับผิดชอบไว้ที่คน
• Lab: จัดทำรายงานคุณภาพหนึ่งหน้าสำหรับรอบการทดสอบที่ผ่านมา

Section 12: Capstone และการนำไปใช้จริง

• โจทย์: วางแผนและทดสอบฟีเจอร์หนึ่งชุดตั้งแต่วิเคราะห์ Requirement จนถึงรายงานผล
• การนำเสนอเหตุผลของการเลือกขอบเขตและลำดับการทดสอบ
• แนวทางนำกระบวนการนี้กลับไปใช้กับทีมและการเริ่มจากจุดที่ได้ผลเร็วที่สุด
• Workshop: นำเสนอผลงานและทบทวนแนวทางร่วมกันกับวิทยากร