LambdaTest

@kane_cli now tests everything before the code is shipped, we have @github PR integration available to run the impacted tests on the PR directly github.com/LambdaTest/kane-cli/tree/main/integrat…

Kane CLI Exploration คืออะไร? AI ที่สำรวจเว็บก่อนใครเขียนเทสต์ และจุดที่มันยังตัดสินแทนเราไม่ได้ โดย 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) · testmuai.com [2] TMCnet · ข่าวประชาสัมพันธ์ "TestMu AI Launches Kane CLI Exploration" (30 ต.ค. 2026) · tmcnet.com [3] TestMu AI Docs · Kane CLI quickstart (เข้าถึง 2 พ.ย. 2026) · testmuai.com [4] TestMu AI · Pricing (เข้าถึง 2 พ.ย. 2026) · testmuai.com [5] GitHub · LambdaTest/kane-cli release 0.10.0 (28 ต.ค. 2026) · github.com/LambdaTest/kane-cli/releases/tag/0.10.0 บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

me: i'm good at code review. @kane_cli, 90 seconds later: sure buddy. Great booth game from @testmuai at #GitHubUniverse, go try it if you're around. #KaneCLI #FindTheBugs LambdaTest/kane-cli

Let your coding agent prove its UI changes work: Kane CLI in 5 minutes --- title: Let your coding agent prove its UI changes work: Kane CLI in 5 minutes published: true tags: testing, ai, cli, webdev canonical_url: testmuai.com --- Coding agents can build a feature from a prompt, but they can't tell you whether it actually works in a real browser. Kane CLI closes that loop: you describe a user flow in plain English, it runs it, and it returns an evidence-backed pass or fail. Disclosure: I work at TestMu AI, which builds Kane CLI. Install npm install -g @testmuai/kane-cli # Node.js 18+ # or: brew install LambdaTest/kane/kane-cli kane-cli login Run your first check kane-cli run --url https://example.com "Click the 'More information' link and verify the page loads" No selectors, scripts or test framework. Every run saves steps, screenshots, console and network logs, and the verdict as an evidence file. Hook it into your coding agent - Claude Code, Codex CLI, Gemini CLI: npx @testmuai/kane-cli-skill - Cursor, Copilot: point the agent to AGENTS.md - Run with --agent --headless to get structured NDJSON output. Exit codes: 0 pass, 1 fail, 2 setup/auth error, 3 timeout, so the agent (or CI) can gate on them. Where it runs Web in real Chrome, API, Android Emulator, iOS Simulator and real devices. It runs headless in GitHub Actions, GitLab CI, Jenkins and Bitbucket Pipelines, and any recorded flow exports to Playwright code. It's free to install; runs use KaneAI credits, and new users get free credits to start. Repo: LambdaTest/kane-cli · Docs: testmuai.com How are you verifying agent-written code today?

Rook before you are cooked 🤯 try it now: github.com/LambdaTest/rook/blob/main/README.md t.co

kane-cli 0.9.0 🚀 📱 Real devices from any machine. Live device window. 🧩 Runtime vars: global, smart in {{…}}. 📎 Upload once, reuse as {{file.alias}} all session. ⏱️ Replays wait for the page to settle, not a timer. Real devices, steadier replays github.com/LambdaTest/kane-cli/releases/tag/0.9.0

Meet rook: test your AI agents’ workflows, tools, and actions. Catch failures before they ship. Give it a try ⭐ LambdaTest/rook t.co