สำหรับผมน่ามาครั้งแรกเลย โดยงานจัดล่าสุด 2009-2014 มาปีนี้เลย ใน Theme Master the Basics. Boost w/Automation. Boost w/AI หัวข้อที่ผมจดมาตามนี้ครับ
AI Governance เบื้องต้นคนทำงานต้องรู้ ต้องทราบ เพื่อนำไปปฏิบัติ
Speaker ดร.อภิวดี ปิยธรรมรงค์
-Free vs จ่ายเงิน Pro แต่มันไม่ได้นะ Data Privacy & Security
📌 สัญญามี 2 แบบ
- Personal จ่ายเงิน เพื่อให้สิทธิการใช้งาน เช่น จำนวน Model / Token Limit
- Enterpise - จ่ายเงิน เพื่อใช้งานแบบ Personal และมีการทำสัญญา เพื่อตกลง Data Privacy & Security
- คำที่ควรรู้ และ Use-Case AI + Data Privacy
📌 Use-Case Speaker เล่า Use Case ของ Apple Card (Data Owner)+ Goldman sachs (Data Owner) ที่ผู้ชายได้วงเงินมากกว่าผู้หญิงมาก ซึ่งปัญหามันเกิดจาก Data แต่พอตอบไม่ชัดเจนเลยมีการร้องเรียน NYDPS ซึ่งใช้เวลา 16 เดือนตรวจสอบ จนพบว่าถึงแม้ว่าจะไม่ได้ Design ให้ Bias แต่ Model มันไปหา Proxy Variable มาเชือมโยงได้
📌 คำที่ควรรู้
- Proxy Variable: แม้ว่าเราตัดบาง Field ป้องกัน Bias เพศ (Gender) แต่โมเดลก็อาจจะสามารถเรียนรู้และแยกแยะเพศผ่าน ตัวแปรอื่น ๆ เช่น ประวัติสินเชื่อ หรือสถิติการเป็นเจ้าของบ้าน/รถยนต์ ซึ่งสุดท้าย Bias อยู่
- Disparate Impact: การที่ระบบ AI อย่างเท่าเทียมและผู้พัฒนาไม่ได้ตั้งใจเลือกปฏิบัติ แต่ผลลัพธ์สุดท้ายกลับพบว่ากลุ่มคนกลุ่มหนึ่ง เช่น ผู้หญิง ได้รับอนุมัติวงเงินต่ำกว่าอีกกลุ่มอย่าง และไม่สามารถอธิบายสาเหตุได้
- Model Card: สรุป AI แต่ละตัว ว่าทำหน้าที่อะไร เหมาะสมกับใคร มีข้อจำกัดหรือข้อห้ามใช้อย่างไรบ้าง ซึ่งเป็นเครื่องมือสำคัญในการทำ AI Governance.
- Human-in-the-loop: การออกแบบให้มีคนเข้ามาตรวจสอบหรือแก้ไขผลลัพธ์ก่อนที่จะส่งถึงมือลูกค้า ซึ่งมี 3 ระดับคือ:
- Human-in-the-loop: มนุษย์มีส่วนร่วมตัดสินใจในทุก Step ก่อนระบบไปต่อ.
- Human-on-the-loop: ปล่อยให้ระบบทำงานไปเอง แต่คอยดูอยู่ห่าง ๆ และเข้าควบคุมเมื่อเกิดสิ่งผิดปกติ
- Human-over-the-loop: มนุษย์ไม่มีส่วนร่วมในทำงานเลย
- Model Drift: เวลาเปลี่ยน ข้อมูลที่ใช้เทรนยังคงเป็นของเดิม เช่น ชื่อนายก คุณภาพและความถูกต้องของผลลัพธ์จาก AI จะค่อย ๆ ลดลง
- Reason Code: บอกว่าทำไม Model ถึงตัดสินใจแบบนี้ ถ้าทำได้จะ Explainablity ถ้าตัวอย่างใกล้ตัวธนาคารที่กำหนด Code ของแต่ละ Action
-เรื่องของกฏหมาย
⚖️ ถึงแม้ว่าตอนนี้ยังมีแค่ร่าง พรบ AI แต่เราสามารถอ้างอิงเคสจาก EU AI Act เอามาเป็น Check List ได้ ซึ่งต้องยอมรับบางเรื่องยังเป็น Idea และไม่ได้มีข้อสรุป ตรวจยังไง ลงโทษยังไง เช่น เคส Self Driving Car มันชัดกับ Innovation
⚖️ หรือ อาจจะไปอิง ฝั่ง US มี NIST AI Risk Management Framework (AI RMF) ซึ่งประกอบไปด้วย 4 เสาหลักคือ Mapping (ระบุความเสี่ยง), Measure (วัดผล), Manage (จัดการ) และ Govern (การกำกับดูแล)
⚖️ ถ้าจะเริ่มต้น AIGPC (AI Governance Practice Center) ของ ETDA
- AI Life Cycle
เราสามารถนำ AI Governance เข้ามาประยุกต์ใช้ในแต่ละช่วงการทำงานได้นะ
📌 Scope & Risk
- ดู Project มีความเสี่ยงระดับใด อยู่ในกลุ่ม High Risk กระทบกับสิทธิคน ตามมาตรฐานสากล (เช่น EU AI Act)
- ทำ AI Impact Assessment เพื่อประเมินและควบคุมความเสี่ยงตั้งแต่เนิ่น ๆ
- Key Accounability ใครดูแล
- ถ้าทำ Project ใหม่แต่ละ Role รู้ระดับไหน Check List Vendor อันนี้ PO (Biz Req) / Dev (Awareness) / QA (Awareness) / AI Goverance (Central Unit)
- Product Team สำคัญนะ อารมณ์ On Top Security > AI
📌 Data
- Faireness / No discrimination
- Key Fair คุม Proxy / Disparate Impact หรือ เดาจากอดีต
- เคส Apple ใครมารับผิดชอบ (Apple Data Owner) / Goldman Sack ( Data Processor)
📌 Model
- ตอบว่าทำไหมได้ไหม Transparency & Explainablity
- Model Card / Reason Code
- Model Registry & Versioning
- Token Economic
📌 Testing & Validation
- สร้าง Golden Set หรือชุดข้อมูลอ้างอิงกลางที่รวม Edge cases / Corner cases เข้าไว้ด้วยกัน เพื่อใช้วัดผลความถูกต้อง
- ทำ Subgroup Evaluation
- ทำ Red Teaming ทดลองเจาะช่องโหว่หรือหลอกล่อให้ AI ทำงานผิดพลาด (Jailbreak)
- ร่วมกับทีม Cybersecurity เพื่อป้องกันไม่ให้ข้อมูลหรือระบบ AI รั่วไหล
📌 Operation & Monitoring
- ทำการตรวจสอบความถูกต้องอยู่ตลอดเวลา เพื่อตรวจจับ Model Drift
- Audit Log / Incident Response Plan ตอบยังไงไม่ให้ราดน้ำมันลงไปอีก
วิวัฒนาการของ สิ่งเล็ก ๆ ที่เรียกว่า BUG สู่ BDD (Bug Driven Development)
Speaker สมเกียรติ ปุ๋ยสูงเนิน
-อะไร คือ ฺBug ?
📌 Computer Bug ถ้าที่เรารู้ เป็นแมลงติดในเครื่องคอมยุคนั้น
📌 คำว่า Bug มาจาก Thomas Edison ตอนครื่องใช้ไฟฟ้าทำงานผิด
-The Classical Bug & Debugging Loop
Computer Fail > Find the Cause > Remove the Cause > Debug the machine📌 คำว่า Debugging มาจากยุคนี้ -หา Root Cause แต่ปัจจุบันลองคิดเราแก้ตามอาการ หรือ หาสาเหตุจริง
📌 Code != Correctness (Make it work > Make it Right > Make it Fast) Flow
Code > Run > Observice Failure > Debug >
| |
Run Again < Modify Code 📌 เรามี Staging ENV ช่วยหาปัญหาเจอก่อนลูกค้า
📌 วิธีการในยุคนี้ดี แต่พอระบบใหญ่ขึ้น มันมาพร้อมกับ 2C
- Complexity - ความซับซ้อนที่เรารู้เรื่อง
- Complicate - ความยุ่งเหยิงที่เราไม่รู้ แก้แล้วพัง
- 1970s Test Spec & Executable
📌 หลายคำที่เราคุ้นๆมาจากยุคนี้ Unit Testing / Integation Testing/ System Testing / Test Plans / Regression Testing / QA Team / Defect Traacking
📌 Test Again Looping เจ็บแล้วจำ จากเดิมจดเอกสาร บันทึกวิธีแก้ + ทดสอบ ขยับมาให้เป็น Executable Spec ที่สามารถทำซ้ำได้ ก่อนทำ ต้องรู้ว่าใครใช้ต่อ ทำอะไร
📌 "Regression Test" มาในยุคนี้ ทดสอบเพื่อป้องกันการเกิดซ้ำ มีแบบ Run All / Select Hot Area ใช้บ่อย / Prioritize ตาม Biz Impact
📌 Softwate Complexity เพิ่มขึ้นด้วย
- 1980s RISE of Quality
📌 Bug Kill Human (1985-1987 Therac-25 Case) จากปัญหานีทำ Test เข้มข้นไปอีก มันจะไปสาย Formal Verification เน้นๆ คุณภาพ !!!
📌 ต้องกลับมาคิด Quantity vs Quanlity อันนี้เป็นแนวคิดที่ส่งผลกับ Product ยังมีประเด็นนี้ถึงปัจจุบันนะ - เวลาเวลาพัฒนา Feature ไหม ต้อง Balance เวลา - bugfix
📌 Functional + Non Functional แยกออกมาแล้ว เราทำ Func ก่อน แล้วกลับมาดู Non Func หรือป่าว จริงดูแต่แรก
📌 นอกจาก Bug 1988 Morris Worm-99 lines ที่พังระบบ เลยได้ศัพทใหม่ มุม Security
Bug > Security & Vulnerability ---> Network propagation --> Large Scale incident
| | |
Security Coding ------> Security Testing -----> Pentest
| | |
Static Code Analysis ---> DDOS ----------------> Data Leaks📌พอยุค 2000 มี OWASP Guildeline ขยับมาเรื่อยๆ web / api / CI/CD / mobile / LLM / Agent
-1990s Risk of Bug Tracking
Bug Report > Bug Repo > PM Assign Dev📌ระบบใหญ่ ของมีเยอะ ต้องจดไว้ มีวิธีการ Bug Pyramid - พอมีปัญหาต้องมาจดเยอะ
📌จดเยอะ Overhead เพิ่มขึ้น - จัดการสถานะ Ticket / Capture ข้อมูล หน้าจอ VDO ลงประกอบ แต่ยังเกิดซ้ำซ่าก เพราะ องค์กรส่วนใหญ่ยังเน้นแก้ปัญหาที่ปลายเหตุ (รักษาตามอาการ) - ขาด Lesson Learn ที่ทำได้จริง ไม่ใช้ติด Loop Meeting'
-2000s Proactive
📌จาก Reactive พังก่อนค่อยแก้ มาเป็น Proactive แก้ก่อนแต่เนิ่นๆ
📌ปรับรูปแบบการพัฒนา Iterative + Incremental Development รอบสั้นๆ ให้ได้ของ มายุค Agile - Scrum
📌Automation Test เริ่มเข้ามาแล้ว เพราะโจทย์ แต่ละรอบต้องตรวจของเดิมไปด้วย Manual มันไม่ไหวแน่ๆ Manual เอาไปใช้พวก UX/UI จะดีกว่า แต่ Automation Test มันคิดพวก ENV / Data / Time มันหัวข้อใน blog ตอบอยู่
📌เพื่อให้ได้ Frequent Accurate Specific Timely > Feedback Loop
-2010s CI /CD Turn Bug to Automate Feedback
📌ปรับการทำงาน มี Pipeline ที่ทำงาน Automate ตรวจสอบตาม Quality Gate เกิด Continue testing
Test ผ่าน Coverage 100 ไม่บอกว่ามี Bug ต้องสร้างความเชื่อมั่นมาจากในตัว Product แล้วค่อยสะท้อนผ่าน Test
📌 เริ่มมี Roleใหม่ DevOps มันขยาย DevSecOps / DevTestOps / AgentOps .... - Goal คนละแบบเอามาจูนให้ Product สำเร็จได้แบบไม่ติด Silo
-2020s - More ENV / Production-Driven Development !!
📌 แยก ENV สำหรับ Test DEV / Stating / UAT / Test On Prod (มาจากการทดสอบชุดเกราะ เล่นจิงเจ็บจิง)
📌 พอมีหลาย Env มีหลายท่า Test On Prod เช่น Blue Green Deployment ต้องมี Budget / Prepare Data ทำได้ Rollover ผ่าน / Rollback ถ้าตุย
📌 Production-Driven Development - มีของที่เก็บเยอะ
App > Log / Trace / Metric > Observability > Detection > Create bug > Investigate+Fix > Deploy
/ Error Report
/ Busines Event -2025 2026 AI Agent Era
📌 ไม่ควรเอา Flow เดิมๆมาใช้ ที่ควร
📌 หา Flow ที่เหมาะกับเรา
- Knowledge Base + Sand Box ให้มันรู้ก่อนอะไรควรไม่ควร
- Human on the Loop ลด Overhead
- Focus ระบบผู้ใช้งาน
-ปิดท้าย
📌 Bug ไมใช่สิ่งที่ผิด แต่มันวัดว่าเราเข้าใจในงานชิ้นนั้นๆไหม
📌 Shift Left Testing ไม่ใช่ เฉพาะ QA นะ ทุกคน
📌 ใช้ AI ต้องตรวจวานให้ได้นะ
Resource: Blog พี่ปุ่ย / Slide
Handling Dependencies and Test Data in Automation Testing: Pros and Cons
Speaker ธวัชชัย จงสุวรรณไพศาล
-เมื่อ Test ที่เขียวอยู่กลับมาเป็นแดง
📌 Solution ไล่ log > Code > ถามตำนานใน บ แต่เวลาไล่หาวัน สัปดาห์ เดือน หรือ ยอมรับ ?
📌 หาครั้ง Test พังเพราะ Code จริงเหรอ แต่เรามีราคาทีต้องจ่าย เวลา จากปัญหา่ต่างๆ เช่น
- Share User Account - Test พัง เพราะ State ตั้งต้นไม่ตรง เช่น เงินไม่พอ เพราะมีอีกคนใช้ User เดียวกัน Test
- Test หลายเคสทำชนกัน จากทีมลองเอง Dev / QA หรือระบบ CI/CDฅ
- พัง เพราะ พึ่งของที่ไม่สามารถคุมได้ เช่น External API / Env sandbox ของ parther ล่ม
- ไม่รู้ภาพรวมมันใช้อยู่ หรือ มีการเปลี่ยนแปลง - DB Schema / API Change เงียบ -> Test พังเยอะ
- Update Package เช่น ขยับ Lib Dev หรือ ตัว Test อย่างพวก Robot / Browser -> ผีเข้าผีออก เมื่อวานเขียว วันนี้แดง
ถ้าไม่ได้พังจาก Code บ่อยๆ จนทีมยอมรับมัน อันนั้นอันตราย เพราะสุดท้าย ถ้ามีเคสจริงเข้ามาทีม Ignore มัน
📌 เข้าใจถึง Level ของการ Test ก่อน พวก Quality Gate
- Unit Test มันตรวจ Business ได้เลย
- แต่ Unit Test ไม่การันตีการทำงานร่วมกัน - ถ้าเน้น Level ทำให้เกิด False Negative - Bug แท้ แต่ Test ไม่เจอ มันจะเจอตอนเอามาทำงานร่วมกัน ต้องมาดู API Test / UI Test ต่อ
- ถ้าไม่คุยกัน กว่าจะรู้มาเจอตอนรวมน่างกันแล้วในช่วง UAT SIT
-อะไรที่เราเห็น และไม่เห็นตอนทำ Automation Testing
📌 ส่วนที่เหนือน้ำ ที่เอามาถกกัน
- Tools Playwright / Cypress / Robot Framework
- Framework Page Object Model / Locator Strategy
- Metric No of Test Case / Pass Rate
📌 ส่วนใต้น้ำ - สำคัญแต่ไม่ได้คุยกัน - มันต้องคุยตั้งแต่แรก มันมีราคาที่ต้องจ่ายในแต่ละวิธีการ
- dependency strategy ของจริง Mock หรือแชร์ หรือ แยกกัน
- test data strategy + life cycle ใครสร้าง ใครใช้ ใครต้องเอาออก ทำซ้ำกันไหม
- env provisioning สมัยนี้มันง่ายพวก Container หรือ Cloud แต่มี Cost
- ความเป็นเจ้าของข้อมูลที่ทดสอบ PII PDPA ใครต้องสร้าง เติมมัน
- Skill Set
- ใครดูแลมันในอีก xx เท่าไหร่
- How to Handling Dependencies
📌 ก่อนอื่นต้องมารู้ Architecture ก่อนว่ามีอะไรบ้าง - Share ENV (Paymeny GW / Shipping GW)
Test -> Web App -> Order Service -> Paymeny GW (External)
-> Shipping GW (External)
-> Inventory
-> Database
แต่ละแบบต้องมาวัด ได้อะไร / จ่ายอะไร / เหมาะสมตอนไหน และราคาที่ต้องจ่าย
📌 แบบที่ 1 ต่อของจริงทั้งหมด - Share ENV
-> Payment GW-External (Share ENV)
-> Shipping GW-External (Share ENV)
Test -> Web App -> Order Service -> Inventory (Share ENV)
-> Database (Share ENV)
- ได้อะไร - ข้อมูลตามจริง Integration ของจริง
- จ่ายอะไร - ช้า ช้า ไม่สถียร แย่งกันใช้ ข้อมูลปน รอคิว
- เหมาะสมตอนไหน - ทำ Smoke ก่อน Release ตรวจความเข้ากันได้
- ราคาที่ต้องจ่าย
- Test พัง จากปัญหาจุกจิกพวก Data
- เราไปแล้ว แต่เพื่อนไม่ขยับ Service
- 3rd Party Payment GW / Shipping GW มันจะล่มเมื่อไหร่ ก็ได้ Cert หมดอายุ / เวลาเปิด ปิด ถ้าพังฝั่งเค้าเรา Debug ไม่ได้
📌 แบบที่ 2 ต่อของจริง แต่คุมได้จาก Container / Test Container ส่วนคุมไม่ได้ Share ENV
-> Payment GW-External (Share ENV)
-> Shipping GW-External (Share ENV)
---------------- Containerize (Docker Compose) ------------------------------
Test -> Web App -> Order Service -> Inventory
-> Database
---------------- Containerize (Docker Compose) ------------------------------
- ได้อะไร - ของจริงเฉพาะฉัน มัน Lock Commit Version / Test Parallel ได้
- จ่ายอะไร - Pipeline กินเวลาสร้าง ENV / Resource ที่ใช้เพิ่ม Container / Test Container
- เหมาะสมตอนไหน - อะไรที่ Containerize ได้
- ราคาที่ต้องจ่าย
- ของที่ Containerize หลุด
- 3rd Party Payment GW / Shipping GW มันจะล่มเมื่อไหร่ ก็ได้ Cert หมดอายุ / เวลาเปิด ปิด ถ้าพังฝั่งเค้าเรา Debug ไม่ได้
📌 แบบที่ 3 ต่อของจริง แต่คุมได้จาก Container / Test Container ส่วนไม่ได้ Vendor ทำ Sandbox แยกมาให้เรา
-> Payment GW-External (Sandbox)
-> Shipping GW-External (Sandbox)
---------------- Containerize (Docker Compose) ------------------------------
Test -> Web App -> Order Service -> Inventory
-> Database
---------------- Containerize (Docker Compose) ----
- ได้อะไร - Sandbox ของเราเอง ทำให้ลองเพื่อทดสอบ Behavior ได้
- จ่ายอะไร - มันจะล่มเมื่อไหร่ ก็ได้ Cert หมดอายุ / เวลาเปิด ปิด ถ้าพังฝั่งเค้าเรา Debug ไม่ได้
- เหมาะสมตอนไหน - external service ที่เราทดสอบไม่ได้ ไม่รู้ Behavior
- ราคาที่ต้องจ่าย - 3rd Party เรายังต้องพึ่งพา
📌 แบบที่ 4 ต่อของจริง แต่คุมได้จาก Container / Test Container ส่วนของ Vendor เรา Mock / Stub ของตัวเอง
-> Payment GW-External (Mock)
-> Shipping GW-External (Mock)
---------------- Containerize (Docker Compose) ------------------------------
Test -> Web App -> Order Service -> Inventory
-> Database
---------------- Containerize (Docker Compose) ----
- ได้อะไร - คุมได้เองหมด / run local ได้
- จ่ายอะไร - ต้องมีคนดูพวก Mock / Stub External
- เหมาะสมตอนไหน - ต้องการควบคุมความเร็ว และอยากลองเคสแปลกๆที่ทำกับ External ของ Vendor ไม่ได้ เราไปยิงเค้ารัวๆ
- ราคาที่ต้องจ่าย - บอกได้แค่ตามสมมติฐาน Mock / Stub ไม่ได้ลองของจริง
📌 แบบที่ 5 Mock / Fake / Stub ให้หมด
-> Payment GW-External (Mock)
-> Shipping GW-External (Mock)
---------------- Containerize (Docker Compose) ------------------------------
Test -> Web App -> Order Service (Mock) -> Inventory (Mock)
-> Database (Mock)
---------------- Containerize (Docker Compose) ----
- ได้อะไร - เร็วสุด ไม่ต้องวุ่นเรื่อง Network
- จ่ายอะไร - Code สลับได้ว่าจะใช้ของปลอม หรือตัวจริง อาจจะให้ DI Inject ให้
- เหมาะสมตอนไหน - Test Logic เน้นไว
- ราคาที่ต้องจ่าย - ไม่เห็นเรื่อง Http / Serialization / Timeout / Latency จริง
สุดท้ายนอกจากจัดการ Sevice Dependency ต้องดู Code / Test Dependencies จาก CI/CD ด้วย
- Browser Update เอง - Pin Version
- Pacakge Wildcard ได้ของใหม่ - Pin Version / Local Lib Repo + Schedule Upate
- Base Image Lastest - Local Lib Repo + Schedule Upate
- Driver ไม่ตรงกับ Browser -> แยก Log ให้ชัดว่าส่วนไหนของ APP / Test
- How to Handling Test Data
📌 ต้องมาตกลงกันก่อนว่า ใครสร้าง / ใครใช้ / ใครลบ / ใครเป็นเจ้าของ
📌 จากนั้นมาเลือก Test Data
| View/Data | Prod + Mask | Shared Seed | Per Test Seed | Ephermeral DB + Per Test Seed |
|---|---|---|---|---|
| ได้อะไร | - เหมือนจริง - มีเคสจริง | - ง่ายเร็ว | - จัดการตัวเอง Setup>Cleanup | - เริมจาก 0 |
| จ่ายอะไร | - PII / PDPA - แก้ทีต้องมา ปรับ Script | - ทุกคนแตะได้ พังได้ด้วย - ลำดับการแก้ | - เพิ่ม Code Seeddata / Cleanup | - Setup Pipeline - HW |
| เหมาะสม | - Perf Test | - Read Only | - Write | - Write ไม่อยาก กังวัล Cleanup |
| ราคาที่ต้องจ่าย | - Mask พลาด Test ที่พึ่งจะพัง - ถ้าหลุด PDPA | - Test พังบ้าง ไม่พังจาก Data | - Cleanup จะได้ ขยะสะสม | - Containrize ได้จะดี พวก TestContainer |
สุดท้ายเลือกวิธีไหน Ephermeral DB + Per Test Seed สะดวก Dev แต่ก่อนขึ้น Prod ต้องทำเสมือนจริงนะ และ Ephermeral DB ใช้ Container จะดีมาก ผมเคยใช้ VM รอเป็น 10 นาทีกว่าจะจบ Scenario นึง
AI ช่วยได้ไหม - เขียนTest ได้ แต่ยังจัดการ Data Dependency ไม่ได้ AI ทำให้เห็น Feedback Loop ไว้ ช่วยส่วนอยู่เหนือน้ำเท่านั้น
และปัญหาข้างต้น น่าลองกลับมาตอบกันได้ และมีผลอะไรกับการเลือก Solution แต่ละแบบ
Q&A
- Q: Test Data โตเรื่อยๆ ต้องทำยังไง
A: จัดกลุ่ม อันไหนที่ทำซ้ำได้ขนานได้ และอย่าลืม Optimize เอาตัวที่ไม่ใช้ออก
เมื่อ AI ต้องถูกทดสอบควรเป็นหน้าที่ใคร - น่านน้ำใหม่ของ QA จริงไหม?
Speaker สุทธินัย เสียงใส
📌 ช่วงนี้ตลาดงาน IT ในไทยตอนนี้ซบเซาลง จากการมาของ AI + เศรษฐกิจ AI ตอนนี้นอกจาก
- Chat ทั่วไปแล้ว ยังเอามาสร้างรูป / ถามที่สงสัย / ใช้สรุปประชุม / ทำ gap requirements / ใช้ design testcase
- ถ้ามุม Agent อย่าง Coding Agent ฝั่ง Test มี TestSprite / Tester.ai เป็นต้น
📌 งานส่วน AI จะมี 2 มุม AI Assistant in Testing / Testing AI System โดยอันนี้ Speaker ดู Trend จาก Bootcamp ของ ตปท อย่าง EnGenius AI Career Acceleator รวมถึงตำแหน่งงาน LinkedIn / Indeed สำหรับในไทยเริ่มประกาศตำแหน่งในส่วนของ Testing AI System สรุป JD ประมาณนี้
- ทดสอบ AI Feature - Chat , AI Agent , LLM App , Workflow ตรวจการทำงาน และระบบที่เกี่ยวข้อง
- เข้าใจ AI ทำงานยังไง และมาสามารถหาทดสอบ วัดจาก Accuracy (ถูกต้อง) / Precision (แม่นยำ) / Relevant (ความสอดคล้อง) ในสิ่งที่ AI ตอบ
- ใช้เครื่องมือ AI ในการช่วยเขียน Test Script (Classic App / AI App) รวมถึง Manual ส่วนที่จำเป็นได้
- สามารถเตรียม Test Data ของ AI รวมถึงสามารถทำ Eval Pipeline ของ AI ได้จากระบบ CI/CD
- นอกจากนี้ งานตำแหน่ง Junior / Senior แยกจุดแตกต่างกัน
- Junior - เข้าใจ SDLC และ STLC / มีความคุ้นเคยการใช้ หรือ ทดสอบ AI App
- Senior - เรียนรู้ได้เอง เข้าใจ และหาวิธีทดสอบ Non-deterministic ของ AI ได้
-ทำไมต้องทดสอบ AI
📌 เพื่อพัฒนา Product และ เพื่อให้สอดคล้องกับกฏหมาย EU AI ACT / ร่าง พรบ AI (มี 7 หมวด พวก 1.นิยาม / 2.การทำ Sandbox / 3.การควบคุมความเสี่ยงจาก AI / 4.การควบคุมดูแล / 5.มาตรการฉุกเฉิน กรณีมีเหตุรุนแรง / 6.การกำกับดูแล และ 7.บทลงโทษ //Speaker เน้น 1 / 3 ที่เกี่ยวกับ App ต้องเข้าใจ
📌 หมวด 3.การควบคุมความเสี่ยงจาก AI
- มาตรา35 อะไรที่นับว่าเสี่ยงสูง - ความมั่นคงของรัฐ / สุขภาพ / สิ่งแวดล้่อม / พลังงาน / Telecom / Logistic / สาธารณปโภค
- มาตรา36 แนวทางดูแลความเสี่ยง //ไม่กล้าย่อแปะเต็มๆดีกว่า
- (๑) มาตรการบริหารและจัดการความเสี่ยงของระบบปัญญาประดิษฐ์ตลอดวงจรการพัฒนา การทดสอบ การนำออกใช้ และการติดตามภายหลังการใช้งาน
- (๕) มาตรฐานการออกแบบ พัฒนา ทดสอบ ประเมิน และตรวจสอบระบบปัญญาประดิษฐ์ รวมถึงการจัดทำเอกสารทางเทคนิค (Model Card ?) ที่จำเป็นต่อการกำกับดูแลและการตรวจสอบ
- (๘) มาตรการกำกับดูแลโดยมนุษย์ การกำหนดผู้รับผิดชอบ และการจัดให้มีช่องทางในการเฝ้าระวัง ติดตาม หรือแทรกแซงการทำงานของระบบปัญญาประดิษฐ์เมื่อมีความจำเป็น //Human In The Loop
📌 ตอนนี้กฏหมาย ยังมีจุดที่ต้องตีความอีกเยอะ โอกาศงานยังไม่เข้าสาย QA ตรงๆ ที่ฟังมาเหมือนจะไปสายกฏหมาย Audit
-AI Product Testing
📌 เข้าก่อน AI มันเป็น Non-deterministic ไม่ใช่ INPUT > PROCESS > OUTPUT แต่ OUTPUT มันเหวี่ยงได้
📌 Model Evaluate != Product Evaluate อย่างตัว Model มี 2 กลุ่มที่วัด
- Model - Benchmark ต่างๆ MMLU / MMLU-Pro / MATH GSM85 / SWE-bench / LiveCodeBench
- Product มี หลายกลุ่ม
- Result: Answer Accurecy / Context Relevace / Response Groudness
- AI Agent Efficiency: Tool Calling Accuracy / Trajectory Effiency
- Responsible AI: Bias / Toxicity / Faithfulness
📌 กระบวนการทดสอบ AI Product
Pre Deploy
- Create Success Criteria จาก Use Case เสี่ยงการวัด Metric ที่ตอบคำถามว่าสนะท้านอะไรได้
- Create DataSet เล็ก 10-20 Case ที่สำคัญ โดยต้องทำกับ Expert ในด้านนั้นๆ
- Creaate Evalute Metric
- เลือก Test เหมาะกับทั้ง Human / Code / LLM Judge (เช่น การตอบคำถามของ Customer Support)
- สร้าง Rubric ที่ละเอียด มีตัวอย่างชัดเจน อ่านเข้าใจ ตีความน้อยสุด
Rubric - Test Case ของ AI ต่างกับว่า Test Pass / Fail แต่ Rubric ประเมินเป็น Scale แทนว่าอันไหนใกล้เคียงสุด
Post Deploy - Loop Improvement / Handle Drift
- Deploy & Monitoring - อะไรที่สุ่มตรวจได้ และ กำหนดเหตุการณ์ที่ผลกับธุรกิจ สูง กลาง ต่ำ
- Feedback - รวบรวมข้อมูลที่ใช้จริง จัดความลำดับ และ impact กับ Business vs Cost แล้วต้องดูด้วย ว่ามันไปพังส่วนอื่นไหม เข่น การปรับ System Prompt แล้วเอ๋อ
- Root Cause Analysis - วิเคราะห์ระบุปัญหา
- Impact สูง Guardrail หรือ BLock ให้คนมาดู
- เพิ่ม Rubric ตามข้อมูลจริง - Regression - ทดสอบซ้ำ แต่ยอมรับว่ากันยาก เอาของที่ดีสุด และต้องมี Fast Feedback
📌 ทำไม AI Product Testing มันถึงยาก
- เรียนรู้ตลอดเวลา เพราะมันเปลี่ยนไปไวมาก
- ไม่มีอะไรที่ตรงไปตรงมา ทุกอย่างการ Trade Off
- Tool Evaluate ตามหลัง Implement ตอนนี้ }
- ChatBot > Agent > Multi-Agent คอนนี้ยังไม่มี Tools - ประเภท Input / Output ที่หลากหลาย พวก Multi Model Model อันนี้มีผลกับ Data Set ทั้ง
- ภาพ แสงชัด
- เสียง สำเนียง - ทำงานกับผู้เชี่ยวชาญ ที่คำตอบมันเป็น ปัจเจก ไม่ตรงตัว เช่น ลายไม้ หรือ ลายกระเบื่อง อันไหนที่เหมือนเดิม
- อื่นๆ
- พวก Red-Teaming
- ความขัดแย้งของ Tools เข่น Harness ทำไม่เหมือนกัน ผลต่างกัน
- รวมถึงความขัดแย้งของ Tools Acedamic Paper ต่างๆ
5 ปัญหาที่พบกับ Automation Tests วิธีการแก้ไข และ 5 ปัญหาที่กำลังจะเกิดขึ้นในอนาคตอันใกล้ AI ในการทำงานของ SW Tester
Speaker ประธาน ด่านสกุลเจริญกิจ
-5 ปัญหาที่พบกับ Automation Tests วิธีการแก้ไข
📌 ปัญหา เราลงทุนทำ Test แต่ไม่รู้ว่าทำไป เพื่ออะไร และวัดอย่างไร ?
วิธีการแก้ไข
- แก้เพื่ออะไร - ลดเวลา Feedback Loop
- วัดยังไง ระยะเวลาตำเนินการทดสอบ และ ทราบผล As Is > To Be ในส่วน Functional Test / Regression Test / Sanity Test ลดจาก 30-60 นาที เหลือ 3 นาที
ถ้ามุมของ CI/CD ใน Extreme Programming จะกำหนดไว้ 10 นาที - ถ้าสนใจเพิ่ม Blog Recap The F5 Experience จากงาน dotnet อันนี้ Idea ที่ช่วยทำ Feedback Loop ส่วน Local Development ไว้ขึ้น
- แล้ว 3 นาที มันต้องมีที่มานะ แบบลองถาม Dev แล้ว ถ้าเค้าจะยอม Run Test เค้ารอได้นานแค่ไหน
- รวมถึงการแก้ปัญหา ไม่ใช่ของ QA นะ ต้องมาจากความร่วมมือของแผนกอื่นๆด้วย ถ้า Test เร็วแล้ว Dev ยอมรันก่อน Commit & Push
📌 ปัญหา ต่างคนต่างทำ Test เริ่มจากอะไร กลยุทธ์แบบไหน หลายที่เน้นทำพวก UI Test แต่ไม่ได้คุยกันว่า
UI Test (Web / Mobile) มันเปราะ และใช้ Resource ในการ Maintain สูงมาก
วิธีการแก้ไข ใช้แนวคิด "Automation Testing Pyramid" จากส่วนยอด
- Workflow UI - ควรทำเมือมี Logic อยุ่นั้น - ถ้า UI ปรับอะไรมันพังง่าย
- Business Rule / Business Process - Service / Layer API
- Coditional Logic - Unit Test + Mocking / Stubbing
นอกจากนี้
- Test มันควรรันที่ไหนก็ได้นะ ต้องปรับ Mindset ด้วย
- บริเวณที่ควรทำ Automation เคสที่เกิดจริงบน Prod แล้วค่อยมา ลงทุนว่าจะทำในส่วน UI / Business Rule / Unit Test
- การจัดการเรื่องพวกนี้ ควรเป็นระดับ Manager ที่มีอำนาจตัดสินใจ จะได้กำหนดทิศทางไปชัดเจน เวลาคุยกับ Management ต้องมาเทียบกับเหตุการณ์จริง จะได้เห็นภาพรวมกัน เช่น การซักผ้า (มือ > semi auto > full auto)
📌 ปัญหา ขาดนิยามของ Automation เข้าใจไปกันคนละทาง
วิธีการแก้ไข ตกลงนิยาม / Owner ให้เข้าใจตรงกัน และปรับกระบวนการทำงานให้ส่งเสริมกัน เช่น
- Automation Test > Change Detector บอกอะไรทีเปลี่ยนแล้วกระทบของเดิม จริงมันสอดคล้องกับนิยาม Regression Test ของ ISTQB (Functional / Non Functional )
- Regression Test คืออะไร แล้ว Run แบบไหร
- All ใจปั๊ม/เวลาเยอะ เอาหมดเ
- Base On Data (User Access / Git Commit) - Select Test / Priority Test - Change ใครเป็นคนตรวจ ต้องมานิยาม คนที่ปรับต้องตรวจเบื่องต้นก่อน อาทิ เช่น
- Fixed Defect / New Feature> SA / DEV / BA
- SW Config Change > SA / Sale
- Env Change (Hardware / Network) > Infra
- 3rd Service > คุมไม่ได้ ถ้าคนนอก แต่ถ้า บ เดียวกันทำคนละหน่วย คนแก้ต้องตรวจก่อน และประกาศ - ทบทวน Expected Result ใน Test Case ใหม่ด้วย ต้องชัดเจน ไม่กำกวม แบบคำนวณได้ถูกต้องเหมาะสม อะไรถูกต้อง / เหมาะสม ?
- ไม่ได้ตกลงเรื่อง Data ว่าใครดูแล ใครคุม ใครลบ ทำให้ผลลัพธ์ มันเหวี่ยง
- ไม่ได้เอา Software Arch มาวาง และกำหนด System Under Test / Dependency / Tools ต่างๆ เป็นต้น ตอนมีปัญหา หรือเสริมอะไร มันจะไปคนละทิศทาง
- การจำลองพฤติกรรม มี Tools เยอะ Container / Mock + Stub แต่ไม่บอกลองพฤติกรรมระบบจริง เช่น Response Time ระบบ x 5-10 Sec แต่ตัว Mock มันคืนทันที มันจะไม่เห็นผลเสมือนจิง
พอนิยามไม่ตรงกัน แล้วมันเกิดความวุ่นวาย จนส่งผล Test Fail บ่อยๆ คนจะไปหา Manual มั่นใจกว่า
📌 ปัญหา ไม่มีการตัดสินใจที่ชัดเจน ว่าอะไร Manaul หรือ Automation แต่แรก
วิธีการแก้ไข
- อย่าตัดสินใจแนวๆ ทำๆ Manual ไปก่อน Automate ที่หลัง มันไม่เกิด
เสริม ของ บ ผม เจอ ผู้ใหญ่ให้เอา Automate Test ออก ผล Quality เละเลย พอไมมี Automate Test คุม การโตของ Code มันจะไปตามดวง - จริงๆ ต้องตกลงกันว่า Flow ไหนควร Automation / Manual เพราะมันต้องเตรียมไว้ก่อน เช่น พวก UI Test ใช้ Locator มันไม่ได้เห็น UI มันเห็น Code นะ ต้องวาง Locator มาให้ แต่ถ้ามันผ่านไปแล้ว การกลับจะแก้ไขมันจะยาก
- พอได้ข้อสรุปแล้ว ต้องมากำหนดนิยาม / Coding Standard ช่วย และใครที่ต้องมาแก้ มันต้องมาปรับ Process การทำงานนี่แหละ เรื่อง Locator
- Dev วางแรก
- หรือ เปิดสิทธิให้ QA เข้าไปเติมได้ - กำหนดวัด Cut Off ให้เป็น Automation รวมถึง Test ในอนาคต
ถ้าทำตามหลัง Later is Never เป็นมรดกเลือดต่อไป
📌 ปัญหา ขาดความเอาใจใส่
วิธีการแก้ไข - มันเป็นอะไรที่สะสมมาจากปัญหาข้างต้น เช่น
- Production Likely Test Data พังตลอด เวลาเปลี่ยน ENV
ก่อนทำมันต้องคุย Dev / QA รวมถึงตัว Script ต้อง Restore / Backup ได้ ทำซ้ำ Update ได้ - ไม่ได้คุยว่ามี Dependency System อะไรบาง ของจริงเลยแตก -คุยกัน
- Test มันควรรันที่ไหนก็ได้นะ ต้องปรับ Mindset ด้วย รวมถึงปรับวิธีการสร้าง ENV มันต้อง Work ในทุก จะได้ไม่เกิดปัญหา It work on my machine
- Test เดิมไม่ได้ช่วยตรวจไป ต้องมา Update ปรับ หรือการกำหนด Strategy ในการวาง Test Scenario ต่างๆ (Sucess / Alternative / Exception) บาง Tools ถ้าวางในที่เดียวกัน อาจจะช้าได้ มีผลกับ Feedback Loop
- ฝึกคน เช่น Dev ต้องไม่เอาของพังขึ้น Repo / BA Aware วิธีการทดสอบด้วย ซึ่งการฝึกต้องมีระยะเวลาที่นานพอสมควร ทำซ้ำ 66 วัน หรือ ถ้าให้ซึ่มซับต้องหลักปี
-5 ปัญหาที่กำลังจะเกิดขึ้นในอนาคตอันใกล้ของ AI ในการทำงานของ SW Tester
📌การตั้งเป้าหมาย (KPI) ของ AI Adoption ที่ผิดวัตถุประสงค์ หลายที่โยน Tools ลงไปตุ้ม แล้วให้ใช้ Token เยอะๆ มันแต่ไม่ได้กลับมาวัดว่า ที่ทำไปนั้นสร้างผลประโยชน์ หรือ ช่วยให้ Testing ดีขึ้นยังไง รวมถึงเราได้เรียนรู้อะไรบ้าง
📌 การเขียน Prompt สั้นๆ แล้วคาดหวังว่าได้คำตอบที่ครบ+ละเอียด เช่น Test Case มันทำไม่ได้นะ เพราะ ตัว AI เองมันไม่ได้รู้ตัว Requirement ที่ได้นะ ตอน Prompt มันต้องใส่รายละเอียด ขมวดสรุปเข้าไป รวมถึง Condition ต่างๆ สุดท้ายเราจะได้ Prompt ยาว ภาพผมมันอีก Spec อีกชุดนึง ส่วนตัวเวลาให้่ AI Gen Code ต้องทำ Spec ยาวๆ เหมือนกัน และแก้ให้ AI Gen มา
📌 พอเรา Burn Token เยอะๆ หากไม่รู้ข้อจำกัด การวางแผนใช้ที่ดี อาจจะทำให้งานสะดุดได้ บางทีเอา Account มาแชร์กัน ลดค่าใช้จ่าย พอมีใครพลาดใช้เยอะๆจนติด limit คนที่เหลือจะอดไปด้วย หรือ ต้องจ่ายเงินเพิื่มเพื่อปลด Lock
📌 เราตามสิ่งที่ AI มัน Geneate ไม่ทัน และอาจจะเชื่อทันที โดยที่ไม่ได้วัดผลมัน + ไม่ได้เรียนรู้จากมัน
📌 ถ้าไม่ได้เรียนรู้จากมัน พอไม่ไช้ Skill นั้นๆนานๆ ความเฉียบคมของเราจะลดลง ซึ่งทำให้เปิดปัญหาหน้างานจริงๆได้ เช่น ต้องแก้ Prod ที่ไม่ได้มี AI มาช่วย หรือ ราคาของ AI ที่แพงขึ้น
คุ้มเงิน และเวลาที่ลงไป จริง ๆ กับการทำ Automation Test ROI
Speaker กรัณย์ ศิวารัตน์
-ปัญหา ROI จริงในหน้ากระดาษ กับการทำจริงมันต่างกัน
ที่นี้ใน Session นี้จะมาแตกว่าที่เราบอกว่ามันลด Cost ได้ ROI เยอะ มันช่วยจริงไหม โดยมีปัจจัย เช่น จำนวน Scenario / เวลาที่ใช้ทำมือ / จำนวนรอบของการทดสอบ / ค่าวางระบบครั้งแรก / ค่าแรงรายชั่วโมงของ Tester
ถ้าตีเป็นเงิน
- Manual -
เวลา Test Per Scenario x จำนวน Test sceanrio x รอบต่อเดือน x 12 x ค่าแรงต่อชั่วโมง - Automation -
ค่าวางระบบ + ค่าเขียน Test + ค่ารัน + ค่าดูแล+ เวลาที่ใช้
ถ้าเราเปลี่ยนค่าของปัจจัย เช่น จำนวน Scenario / จำนวนรอบของการทดสอบ / ค่าแรง มันส่งผลความคุ้มทุนได้
สิ่งที่ซ่อนไว้ค่า Maintenance Test Suite != 0
-ความเข้าใจผิด Maintainance Cost เป็น 0 แต่จริงๆมันของที่ซ่อนอยู่
- ทำแล้ว Test มันจะซ่อมตัวเองได้
- มันซ่อมไม่ได้ ต้องแก้มือ ต้องกลับไปนิยาม
- เสริม อย่าง บ ผมปัจจุบันยังมีคนเข้าใจ Automate Test มันจะงอกซ่อมเองได้ - พอรู้ว่ามันซ่อมเองไม่ได้ จะเอา AI มาช่วย มันมีค่า Token / Data Governance ที่ซ่อนไว้
- ยิ่งมี ENV Test Cost ของการสร้าง ENV เพิ่มขึ้นด้วย DEV / SIT / UAT / STAGING ต้องมาเตรียม .
- Test Data
- Script Initial ENV รวมถึงตัวไหนที่ต้อง Mock / Sandbox
- Config ขา App รองรับกับ ENV
- เตรียม Infra / CI CD - เวลาในการหาสาเหตุว่า Test พัง เพราะอะไร แต่ไม่ได้ตรงกับจุดประสงค์ของการทำ Automate Test ที่เป็น Change Detector เช่น
- UX เพิ่ม UI Transition อีกสัก 0.1 วิ แล้ว Test พัง เพราะเวลาที่ดัก มันช้ากว่า Test เดิม
- มีอีกทีมลอง Test อีก Scenario เปิด-ปิด Payment Gateway ระหว่าง Run Test
- Network Issue
- ฝั่ง Infra ตอน Scale ระบบ Up/Down ทำให้ Test มัน Fail
ถ้าเกิดขึ้นบ่อยๆ คนจะไม่สนใจ Automation Test และ ถ้าแดงข่างมัน หรือ โยนกันในแต่ละฝ่าย รวมถึงแต่ละรอบมันมี Cost ด้วย จะกลายเป็นว่า อาจจะโดนตัดออก
สุดท้ายต้องลงทุน วางแผนการทำ เพื่อ รีด Resource ออกมาได้ Feedback Loop ที่เร็ว โดยที่ Quality ไม่ลดลง จากตัวอย่างระบบที่เล่ามา Speaker มี เคสระบบการเงิน + เรื่องค่าคอมด้วย ตอน Test แยก 3 ส่วน
- ขา API - ดีสุด เพราะกระทบจาก UI น้อยมาก และ Test รวม Business Logic ที่เชื่อมกันด้วย
- ขา Batch API - เหมือน API คความซับซ้อนว่า อาจจะมีการ Businees Logic API ย่อยเชื่อมกันด้วย
- ขา UI - เปราะบางที่สุด แต่จำเป็นต้องมี เชื่อมทดสอบความเข้ากันได้ของ UI (Frontend) + API (Backend)
- ปัญหา เรื่อง Test Data Impact กัน
สิ่งที่ต้องทำ ตกลงให้ชัดเจน อาจจะลองแยก Data Test Id เป็นกลุ่ม เพื่อให้รู้ว่า Test Case ไหน Module อะไร เช่น หลักแรกของ 0 Manaul 1-8 Auto 9 สำรอง แจกแจง Module อะไร รวม Runing No เอาไว้ดักเคสพิเศษ - ปัญหา Mock / Stub ถ้าทำแยก Per Scenario ตอนดู Scale ยาก
สิ่งที่ต้องทำ
- ทำ Logic Mock / Stub ตาม Test Data เช่น ดูเลข Running No กลุ่ม 9000-9999 เคสต้องปฏิเสธ / 2000 รอApprove จะไม่ต้อง มาจัดการ แยกในแต่ละ Case
- Run Parallel เป็น Change Detector ได้นะ บางอัน มันเกิดได้ในชีวจริง เช่น Id ชนกัน เลยทำให้ยอดฝากเงินเป็น 0 - ถามกลับมาด้วยว่า Test Scenario ไหน อะไร ควรจะ Focus ต้องทำก่อน เน้น Automate มีผลกับ Biz
- Path ที่พังแล้วกระทบเงิน ความน่าเชื่อถือ
- ตรวจผลด้วยมือไม่ทัน เพราะมัน Step เยอะ
- Run ทุกรอบที่ Deploy แต่ต้องมี Fake และ Owner ดูแล
- อันไหนที่หลุดไปภายนอกจะมีประเด็น เข้าส่งไป Payment Gateway ตัดเงิน
การทำ Automation Test ระบบพื้นฐานต้อง Stable พวก Infra / Service รอบข้าง ค่าใช้จ่ายในการรักษา Biz มันเดินได้ มันคุ้มกับค่าใช้จ่ายที่ทำ Automate Test ไหม - Quality ที่มาช้า แปลว่าไม่มี Quality ปรับมาจาก ความยุติธรรมที่มาช้า คือความอยุติธรรม
Q&A
- Q: ปัญหาของ Automation ที่พังบ่อย ๆ มีโอกาสไปเกิดบนระบบจริง (Production) ไหม?
A: อาจจะมีโอกาศ - Q: Automation มันต้นทุนสูงและเหนื่อยขนาดนี้ สายงาน QA / Tester ควรไปทิศทางไหนต่อ?
A: ไปสาย Business Analyst / Security Test / Performance Test แต่อย่าลืม ฝึกฝน "ทักษะพื้นฐาน"
Blog ท่านอื่นๆ
📝เมื่อทีมพัฒนาใช้ A-DAPT Blueprint ในการทำงาน จาก physical -> digital -> AI Era เผื่อใครไม่ได้ฟัง Idea คล้านกัน
- ATH2026: Behind The Scene AI Adoption + Extreme Programming
- Arise Tech Meetup #10: Build an AI Knowledge Fabric for Your Organization
📝สรุปของคุณ Parima Seangprohde
- แนวทางการกำกับดูแล AI (AI Governance) และบทบาทใหม่ของ Software Tester - พี่ซี ดร.อภิวดี
- ไผเฮ็ด Test ข่อยพัง? แกะรอยปริศนาตามหาผู้ร้ายตัวจริง - คุณเอ็กซ์ อนรรฆ Jitta Wealth
- เมื่อ AI ต้องถูกทดสอบควรเป็นหน้าที่ใคร - น่านน้ำใหม่ของ QA จริงไหม?
- 5 ปัญหาที่พบกับ Automation Tests วิธีการแก้ไข และ 5 ปัญหาที่กำลังจะเกิดขึ้นในอนาคตอันใกล้ของ AI ในการทำงานของ Software Tester
- คุ้มเงิน และเวลาที่ลงไป จริง ๆ ใช่ไหม กับการทำ Automation Test
ขอบคุณทีมงานทุกท่านที่ร่วมกันจัดงานดีๆขึ้นมาครับ
