โดย Nokka (นก-กา) | 2 พ.ย. 2026

ภาพประกอบ: ห้องทำงานมืดที่มีหน้าจอเดียวแสดงเส้นทางหลายเส้นวิ่งไปมาระหว่างกล่องสี่เหลี่ยมเล็ก ๆ และมีแว่นขยายวางอยู่ข้างคีย์บอร์ด

การทดสอบซอฟต์แวร์ปกติเริ่มจากคำถามว่า "ระบบควรทำอะไร"

แต่มีแอปจำนวนมากที่ไม่มีใครตอบคำถามนี้ได้อีกแล้ว เพราะคนที่เขียนเอกสารลาออกไปนานแล้ว หรือเพราะโค้ดถูกสร้างด้วย AI ในหนึ่งสัปดาห์จนไม่มีใครจดว่ามันควรทำงานแบบไหน

TestMu AI ออกเครื่องมือใหม่มาปิดช่องว่างตรงนี้ เปิดตัว 30 ต.ค. 2026 ในชื่อ Kane CLI Exploration [1]

แนวคิดสั้นมาก: ให้ URL หนึ่งเส้น แล้วปล่อยให้ agent เดินสำรวจทั้งแอปเอง ก่อนที่ใครจะเขียนเทสต์

ปัญหาที่มันเข้ามาแก้

บริษัทอธิบายไว้ในประกาศเปิดตัวว่าทีมจำนวนมากเขียนไฟล์คำสั่งอย่างละเอียดให้ agent ที่เขียนโค้ด แต่ agent ที่ตรวจโค้ดกลับได้แค่ URL แล้วจบ [2]

ผลคือเวลาไม่มีสเปกเหลืออยู่ agent ทดสอบจะวัดแอปด้วยตัวแอปเอง [2]

ประโยคนี้ฟังดูธรรมดา แต่มันคือหัวใจของปัญหาทั้งบท

ถ้าไม่มีใครบอกว่าควรเป็นอย่างไร สิ่งเดียวที่ agent รู้ก็คือมันเป็นอย่างไรอยู่จริง สองอย่างนี้ไม่เหมือนกัน

สำรวจอย่างไรในทางปฏิบัติ

ผู้ใช้รันคำสั่งเดียว [1] [3]

npm install -g @testmuai/kane-cli kane-cli login # ค่าเริ่มต้นของ 0.10.0 คือโหมดที่ส่งฟอร์มได้ kane-cli explore run --url https://yourapp.com # ถ้าต้องการโหมดอ่านอย่างเดียว ต้องระบุเอง kane-cli explore run --url https://yourapp.com --policy read_only

จากจุดนั้น agent จะเปิดหน้าเว็บ ไล่ดูทุกหน้าที่ยังเข้าถึงได้ เก็บว่ามีปุ่มอะไร เมนูอะไร ช่องกรอกอะไร และแต่ละหน้าเชื่อมไปหน้าไหน [1]

จุดที่ผมคิดว่าคนมักมองข้ามคือการเก็บ สถานะของหน้าจอ ด้วย เช่น ฟอร์มตอนยังไม่กรอก กับฟอร์มตอนกรอกผิดและขึ้นข้อความเตือน [1]

รายละเอียดนี้ทำให้แผนที่ที่ได้ไม่ใช่แค่ผังหน้าเว็บ แต่เป็นผังพฤติกรรม

แผนที่ที่โตขึ้นทุกครั้งที่รัน

จุดนี้ผมไม่เห็นในคำโปรยตอนเปิดตัว แต่เป็นส่วนที่ทำให้เครื่องมือนี้ต่างจาก scraper ทั่วไป

แผนที่ไม่ได้เริ่มใหม่ทุกครั้ง การรันรอบใหม่จะเพิ่มหน้าจอ เส้นทาง และข้อค้นพบเข้าแผนที่เดิม แล้วเทียบกับรอบก่อนว่าอะไรใหม่ อะไรเปลี่ยน [1]

ทุกเส้นทางมีสถานะกำกับ ได้แก่ ตรวจแล้ว เปลี่ยนแล้ว พัง หรือยังไม่ได้ตรวจ [1]

แปลว่าถ้าใช้ต่อเนื่อง แผนที่นี้จะกลายเป็นตัววัดสุขภาพของแอปในแต่ละรอบไปด้วย

ตอนจบการรัน ระบบยังเขียนไฟล์สรุปสิ่งที่เรียนรู้เกี่ยวกับแอป เช่น วิธีล็อกอิน แบ่งกลุ่มหน้าจอเป็นกี่พื้นที่ธุรกิจ และอื่น ๆ [1]

ผมคิดว่าส่วนนี้มีค่ามากสำหรับทีมที่คนเข้า ๆ ออก ๆ เพราะความรู้เรื่องระบบจะถูกเขียนค้างไว้ในไฟล์ ไม่ได้อยู่ในหัวใครคนเดียว

ขีดจำกัดที่บริษัทเขียนเอง

ส่วนที่ผมชอบที่สุดในบล็อกของ TestMu AI คือเขาเขียนข้อจำกัดไว้เองก่อนที่คนใช้จะเจอ [1]

  • สำรวจได้เฉพาะเว็บ ขณะที่ Kane CLI ตัวหลักทดสอบได้ทั้งเว็บและมือถือ
  • หยุดที่กำแพงล็อกอิน ถ้าไม่ให้ข้อมูลเข้า ระบบไปต่อไม่ได้
  • โหมดอ่านอย่างเดียวไปไม่ถึงหน้าหลังฟอร์ม เพราะโหมดนี้ไม่ส่งฟอร์ม
  • แยกไม่ออกระหว่างบั๊กกับดีไซน์ที่ตั้งใจ ถ้าไม่มีสเปกให้เทียบ

ข้อสุดท้ายคือข้อที่ผมจะกลับมาพูดถึงอีกที เพราะมันไม่ใช่ข้อบกพร่องเล็ก ๆ

โหมดการทำงานและขอบเขตที่ตั้งได้

ก่อนเริ่มสำรวจ ผู้ใช้กำหนดได้ว่า agent แตะอะไรได้บ้าง [1] และมีจุดที่ต้องระวังมาก: ตั้งแต่เวอร์ชัน 0.10.0 ค่าเริ่มต้นของ explore run คือ โหมดที่ส่งฟอร์มได้ ไม่ใช่โหมดอ่านอย่างเดียว [5]

โหมดอ่านอย่างเดียว ดู คลิก ตรวจสอบได้ แต่ไม่ส่งฟอร์ม (ต้องระบุ --policy read_only) โหมดส่งฟอร์มได้ ค่าเริ่มต้นของ 0.10.0 กรอกและส่งฟอร์มได้ ใช้กับแอปที่มีข้อมูลทดสอบทิ้งได้ โดเมนและคำต้องห้าม ระบุโดเมนที่อนุญาต โดเมนที่ห้ามเปิด และคำที่ห้ามคลิก เช่น Delete account (ใช้ในโหมดส่งฟอร์มได้)

การเลือกโหมดผิดมีผลตรง ๆ กับความเสียหาย เพราะโหมดที่สองคือค่าเริ่มต้น ถ้ารันบนระบบจริงโดยไม่ระบุ --policy read_only และไม่มีข้อมูลสำรอง สิ่งที่ agent กรอกอาจไปปนกับข้อมูลลูกค้า

ตัวเลขจากการทดลองของบริษัท

TestMu AI ทดลองกับ Automation Exercise ซึ่งเป็นเว็บสาธิตสำหรับฝึกเขียนเทสต์ [1]

หลังสำรวจ 6 รอบ แผนที่ได้ 15 หน้าจอ แบ่งเป็น 4 กลุ่มธุรกิจ มี 21 เส้นทาง และตรวจผ่านครบ 14 เส้นทาง

ระหว่างนั้นระบบเก็บข้อค้นพบได้ 64 รายการ แยกเป็นระดับสูง 20 กลาง 35 และข้อมูลประกอบ 9 [1]

ตัวเลข 64 นี้ไม่ใช่จำนวนบั๊ก และบริษัทเองก็เขียนไว้เช่นนั้น [1]

ข้อค้นพบทุกใบทีมต้องมาจัดประเภทเองหกแบบ คือบั๊ก ซ้ำ ทำงานตามที่ออกแบบ ไม่เสถียร (flaky) สภาพแวดล้อมทดสอบ และกรณีที่ตัดสินใจไม่แก้ [1]

ผมชอบที่บริษัทเลือกใช้คำว่า "ข้อค้นพบ" ไม่ใช่ "บั๊ก" เพราะมันตรงกับความจริงของงานทดสอบมากกว่า

ปัญหาที่ใหญ่กว่าตัวเครื่องมือ

กลับมาที่ข้อจำกัดข้อสุดท้าย

ถ้าระบบคำนวณส่วนลดผิดมาตั้งแต่แรก และ agent สำรวจแล้วเห็นว่ามันคิดแบบนี้ทุกครั้ง มันจะสรุปว่าพฤติกรรมนี้คือสิ่งที่ถูกต้อง

จากนั้นมันจะเขียน Acceptance Criteria ที่ยืนยันความผิดพลาดนั้น และรันเป็นเทสต์ผ่านทุกครั้งใน CI

ในวงการทดสอบเรียกปัญหานี้ว่า Oracle Problem หรือปัญหาการไม่มีคำตอบอ้างอิงที่เชื่อถือได้

นี่ไม่ใช่ปัญหาของ Kane CLI โดยเฉพาะ แต่เป็นข้อจำกัดของแนวทาง "เรียนรู้จากตัวระบบ" ทั้งหมด

และเป็นเหตุผลว่าทำไมมนุษย์ยังต้องอ่าน Acceptance Criteria ก่อนอนุมัติ แม้ agent จะเขียนได้เร็วแค่ไหน

ตัวอย่างวิธีใช้ที่ผมคิดว่าเข้าท่า

สมมติคุณรับช่วงดูแลระบบเก่าที่ไม่มีเอกสาร และมีหน้าเว็บราว 200 หน้า

วิธีที่ตรงกับจุดแข็งของเครื่องมือนี้คือ

  1. รันโหมดอ่านอย่างเดียวบน staging ก่อน ไม่ใช่ production
  2. ปล่อยให้สำรวจหลายรอบ แล้วดูว่าแผนที่ครอบคลุมส่วนไหนบ้าง
  3. เอาข้อค้นพบระดับสูงมาตรวจด้วยตาก่อน ว่าอันไหนเป็นบั๊กจริง
  4. เขียน Acceptance Criteria ที่ถูกต้องด้วยมือในจุดที่กระทบเงินและข้อมูลลูกค้า
  5. ปล่อยให้ agent สร้างเทสต์ในจุดที่พฤติกรรมชัดเจนและวัดผลได้ง่าย

ทางที่ผมคิดว่าเสี่ยงคือการปล่อยให้มันรันบนระบบจริงตั้งแต่รอบแรก เพราะถ้าไม่ใส่ --policy read_only คุณจะได้โหมดที่ส่งฟอร์มได้ทันทีโดยไม่รู้ตัว

ราคาและการเข้าถึง

Kane CLI Exploration รวมอยู่ในแพ็กเกจ KaneAI Max [1] [2] ซึ่งอยู่ที่ 179 ดอลลาร์ต่อ agent ต่อเดือนเมื่อจ่ายรายปี หรือ 199 ดอลลาร์เมื่อจ่ายรายเดือน [4]

บริษัทระบุว่าแต่ละไลเซนส์รันการสำรวจพร้อมกันได้สามชุด [1] [2]

Kane CLI ตัวหลักเปิดตัวเมื่อ เม.ย. 2026 และรองรับทั้งเว็บและมือถือ ส่วน Exploration ยังจำกัดที่เว็บอย่างเดียวในตอนนี้ [2]

เวอร์ชัน 0.10.0 ที่ออกเมื่อ 28 ต.ค. 2026 ทำให้การสำรวจรันบนคลาวด์เป็นค่าเริ่มต้น และเปิดเบราว์เซอร์คลาวด์ได้สูงสุด 20 ตัวพร้อมกัน [5]

ตัวเลข 20 นี้สำคัญเพราะมันคือสิ่งที่ทำให้แอปใหญ่สำรวจเสร็จในไม่กี่ชั่วโมง แทนที่จะต้องเปิดเครื่องทิ้งไว้ทั้งคืน

สิ่งที่ผมยังไม่ได้ทำ

ผมยังไม่ได้ติดตั้ง Kane CLI และไม่ได้ลองสำรวจเว็บใดด้วยตัวเอง

ผมเปิดบล็อกทางการของ TestMu AI ที่ลงวันที่ 30 ต.ค. 2026 เปิดประกาศข่าวผ่านสำนักข่าวที่เผยแพร่ฉบับเดียวกัน เปิดหน้าตาราคา และตรวจบันทึกการปล่อยเวอร์ชัน 0.10.0 บน GitHub

ตัวเลขทั้งหมดในบทนี้มาจากแหล่งที่ระบุไว้ข้างต้น ตัวเลข 15 หน้าจอ 21 เส้นทาง และ 64 ข้อค้นพบ เป็นผลการทดลองของบริษัทเองบนเว็บสาธิต ไม่ใช่การวัดโดยบุคคลที่สาม

แหล่งอ้างอิง

[1] TestMu AI Blog · "We Built an Agent That Explores a Web App Before Anyone Writes a Test" (30 ต.ค. 2026) · https://www.testmuai.com/blog/ai-agent-explores-web-app/
[2] TMCnet · ข่าวประชาสัมพันธ์ "TestMu AI Launches Kane CLI Exploration" (30 ต.ค. 2026) · https://www.tmcnet.com/usubmit/2026/10/30/10473017.htm
[3] TestMu AI Docs · Kane CLI quickstart (เข้าถึง 2 พ.ย. 2026) · https://www.testmuai.com/docs/kane-cli-quickstart
[4] TestMu AI · Pricing (เข้าถึง 2 พ.ย. 2026) · https://www.testmuai.com/pricing/
[5] GitHub · LambdaTest/kane-cli release 0.10.0 (28 ต.ค. 2026) · https://github.com/LambdaTest/kane-cli/releases/tag/0.10.0

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)