หลักสูตร AI for QA & Software Testing เป็นการอบรมการใช้ AI ในทุกขั้นตอนงานทดสอบ ตั้งแต่วิเคราะห์ Requirement ออกแบบ Test Case สร้าง Test Data ทดสอบ API ดูแลสคริปต์อัตโนมัติ จนถึงเลือก Regression และรายงานคุณภาพ พร้อมรู้ข้อจำกัดของ AI เหมาะกับ QA Engineer, Software Tester, Manual Tester และ QA Lead
งาน QA ส่วนใหญ่หมดไปกับงานที่ทำซ้ำ เขียน Test Case ทีละข้อจากเอกสารที่ไม่ครบ เตรียมข้อมูลทดสอบทีละชุด ไล่รันสคริปต์ที่พังเพราะหน้าจอเปลี่ยนนิดเดียว แล้วยังต้องสรุปผลส่งทีมอีก พอเวลาไม่พอก็ต้องเลือกว่าจะทดสอบอะไรและปล่อยอะไรผ่านไป ซึ่งเป็นจุดที่บั๊กมักหลุดขึ้น Production หลักสูตรนี้ใช้ AI ตัดเวลางานซ้ำเหล่านั้นออก แล้วเอาเวลาที่ได้คืนไปทุ่มกับการคิดว่าอะไรควรทดสอบและอะไรเสี่ยงที่สุด ผู้เรียนจะได้ใช้ AI ช่วยตั้งแต่วิเคราะห์ Requirement
เพื่อหาความเสี่ยง ออกแบบ Test Case ด้วยเทคนิคมาตรฐานอย่าง Equivalence Partitioning และ Boundary Value สร้าง Test Data ที่ครอบคลุมโดยไม่ใช้ข้อมูลจริงของลูกค้า ทำ Exploratory Testing แบบมีทิศทาง ทดสอบ API ตามสเปก เขียนและซ่อมสคริปต์อัตโนมัติ เลือกชุด Regression ตามความเสี่ยง วิเคราะห์ผลที่ล้มเหลวและเขียนรายงาน Defect ที่นักพัฒนาแก้ต่อได้ทันที ไปจนถึงการสรุปคุณภาพเสนอผู้บริหาร พร้อมบทที่ว่าด้วยขอบเขตที่ AI เชื่อไม่ได้และต้องตรวจเองเสมอ ปิดท้ายด้วย Capstone ที่วางแผนและทดสอบระบบหนึ่งตัวครบวงจร (อบรม 2 วัน วันละ 6 ชั่วโมง รวม 12 ชั่วโมง ระดับ Beginner ถึง Intermediate)
รายละเอียดหลักสูตร
อบรม 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 พร้อมสคริปต์ตัวอย่างกลับไปใช้งานจริง
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 จากสเปกจริง
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: นำเสนอผลงานและทบทวนแนวทางร่วมกันกับวิทยากร
ขณะนี้ยังไม่มีรอบอบรมเปิดรับสมัคร ลงชื่อจองไว้ได้เลย ทีมงานจะติดต่อกลับเป็นกลุ่มแรกเมื่อเปิดรอบถัดไป หรือสอบถามทางไลน์ หรือโทร 02-570-8449 หรือ 088-807-9770
Boundary Value Analysis คือการเลือกค่าทดสอบที่ขอบของช่วงข้อมูล เพราะข้อผิดพลาดมักเกิดตรงขอบ เช่น ช่องอายุที่รับค่า 18 ถึง 60 ให้ทดสอบ 17 18 60 และ 61 มักใช้คู่กับ Equivalence Partitioning ที่แบ่งค่าเป็นกลุ่มที่ระบบควรทำงานเหมือนกัน แล้วเลือกตัวแทนกลุ่มละหนึ่งค่า ทั้งสองเทคนิคช่วยลดจำนวน Test Case โดยยังครอบคลุมจุดเสี่ยงสำคัญ
เริ่มจากให้ Requirement หรือ User Story ที่ชัดเจนพร้อมกฎทางธุรกิจ แล้วสั่งให้ AI ใช้เทคนิคที่ระบุ เช่น Boundary Value หรือ Decision Table และกำหนดรูปแบบผลลัพธ์ให้มีเงื่อนไขเริ่มต้น ขั้นตอน และผลที่คาดหวัง จากนั้นให้ AI เสนอกรณีที่คนมักมองข้าม แล้วคนตรวจทานตัดกรณีที่ซ้ำหรือผิด และจัดลำดับตามความเสี่ยง ไม่ควรใส่ข้อมูลจริงของลูกค้าลงในเครื่องมือ AI ภายนอก
Flaky Test คือเทสต์ที่ผลไม่คงที่ บางครั้งผ่าน บางครั้งล้ม ทั้งที่โค้ดไม่ได้เปลี่ยน สาเหตุที่พบบ่อยคือการรอหน้าจอไม่ถูกจังหวะ ข้อมูลทดสอบที่ใช้ร่วมกัน หรือ Selector ที่ผูกกับโครงสร้างหน้าเว็บ ควรแยกเทสต์ที่ไม่นิ่งออกมาก่อนเพื่อไม่ให้ทีมเลิกเชื่อผลทดสอบ แล้วหาต้นเหตุจาก Log ภาพหน้าจอ หรือ Trace และตัดสินใจว่าจะซ่อมหรือตัดทิ้ง AI ช่วยวิเคราะห์สาเหตุและเสนอวิธีแก้ได้
เหมาะกับ QA Engineer และ Software Tester ที่ต้องการลดงานซ้ำและเพิ่มความครอบคลุม Manual Tester ที่อยากเริ่มทำงานอัตโนมัติแต่ไม่ได้มาสายเขียนโปรแกรม นักพัฒนาที่ต้องทดสอบงานตัวเอง และ QA Lead ที่ต้องวางแผนและรายงานคุณภาพ ควรเข้าใจกระบวนการพัฒนาซอฟต์แวร์และเคยมีส่วนร่วมกับการทดสอบมาบ้าง ใช้คอมพิวเตอร์ได้คล่อง ไม่จำเป็นต้องเขียนโปรแกรมเป็น
เขียน Test Plan จาก Requirement ออกแบบ Test Case ด้วยเทคนิคมาตรฐานร่วมกับ AI สร้าง Test Data จำลองที่ไม่ใช้ข้อมูลจริงของลูกค้า ทำ Exploratory Testing อย่างมีทิศทาง ทดสอบ API ด้วย Postman จากสเปก OpenAPI แปลง Test Case เป็นสคริปต์อัตโนมัติและดูแลไม่ให้เปราะ เลือกชุด Regression ตามความเสี่ยง และจัดทำรายงานคุณภาพ ผู้ผ่านการอบรมได้รับใบประกาศนียบัตร (Certificate of Completion) ที่มีเลขที่ของตัวเองและตรวจสอบออนไลน์ได้
ได้ หลักสูตรนี้จัดเป็นการอบรมแบบ In-house ให้ทีมในองค์กรได้ และปรับตัวอย่างให้ตรงกับงานของทีม เช่น ใช้ระบบหรือเว็บที่ทีมดูแลอยู่เป็นโจทย์ทำ Test Plan และชุดทดสอบตลอด Workshop ขอใบเสนอราคาได้จากหน้านี้ หรือติดต่อทาง LINE @itgenius โทร 02-570-8449
การทดสอบเว็บด้วยมือทุกครั้งก่อนปล่อยของทำให้ทีมเสียเวลามาก และยิ่งระบบใหญ่ขึ้นก็ยิ่งทดสอบไม่ทั่วถึง สุดท้ายบั๊กที่ผู้ใช้เจอมักเป็นจุดที่ไม่มีใครได้กดซ้ำ Playwright เป็นเครื่องมือทดสอบอัตโนมัติจาก Microsoft ที่สั่งเบราว์เซอร์ทำงานแทนคนได้ครบทั้ง Chromium,…
งานวิเคราะห์และออกแบบระบบใช้เวลาไปกับการเขียนเอกสารและวาด Diagram มากกว่าการคิดออกแบบจริง กว่าจะได้ Use Case ครบ วาด Process Flow เสร็จ ทำ ER Diagram ให้ตรงกับที่คุยไว้ แล้วยังต้องเขียนสเปก API และร่างสถาปัตยกรรมอีก พอความต้องการเปลี่ยนกลางทาง…
