สถานที่เรียน: โรงแรมใกล้รถไฟฟ้า BTS

ถ้ามี Requirement เข้ามา 1 ชุด
อย่าเพิ่งให้ AI เขียน Test Case ค่ะ

พี่แทนอยากชวนลองทำอย่างหนึ่ง

สมมติว่าเช้าวันจันทร์
PO ส่ง Requirement ใหม่มาให้

ถ้าเป็นเมื่อก่อน เราอาจเปิด AI แล้วพิมพ์ว่า

“ช่วยสร้าง Test Case จาก Requirement นี้ให้หน่อย”

ไม่ผิดนะคะ

และ AI ก็อาจสร้าง Test Case ออกมาให้เราได้ภายในไม่กี่วินาทีด้วย

แต่พี่แทนอยากให้ลอง ยังไม่ Generate Test Case

แล้วถอยออกมามอง Requirement ชุดนั้นก่อน

.

STEP 1 — ให้ AI เข้าใจ Context ก่อน

ก่อนถามว่า “ต้อง Test อะไร”

ลองให้ AI เข้าใจก่อนว่า

System นี้ทำอะไร
User คือใคร
Feature นี้เกี่ยวข้องกับอะไร
มี Business Rule อะไรบ้าง
และมีข้อจำกัดอะไรที่ต้องรู้

เพราะถ้า Context ผิด

ต่อให้ Test Case ออกมาสวยแค่ไหน
มันก็อาจกำลัง Test คนละเรื่องกับที่ระบบต้องการ

.

STEP 2 — อย่าเพิ่งหา Test Case ให้หา “สิ่งที่น่าสงสัย”

ให้ AI ช่วยมอง Requirement ว่า

ตรงไหนยังไม่ชัด?

ตรงไหนข้อมูลขัดกัน?

มี Business Rule ไหนที่ยังตอบไม่ได้?

มี Assumption อะไรซ่อนอยู่?

มีคำถามอะไรที่ QA ควรกลับไปถาม PO / BA?

ตรงนี้พี่แทนชอบมาก

เพราะบางครั้งคุณค่าของ AI
ไม่ใช่การ ตอบให้เรา

แต่คือการช่วยให้เราเห็นว่า

“เรายังต้องถามอะไรอีก?”

.

STEP 3 — ค่อยวิเคราะห์ Risk และ Test Condition

เมื่อ Context เริ่มชัดแล้ว

ค่อยให้ AI ช่วยคิดว่า

ถ้า Feature นี้ผิด
อะไรจะกระทบบ้าง?

Happy Path อยู่ตรงไหน?

Negative Case มีอะไร?

Boundary อยู่ตรงไหน?

Integration ไหนน่ากังวล?

ข้อมูลหรือสถานะอะไรที่ควรถูกทดสอบ?

ตอนนี้เรายังไม่ได้รีบเขียน Test Case นะคะ

เรากำลังช่วยกันคิดว่า

“อะไรควรถูกทดสอบ?”

ก่อน

.

STEP 4 — แล้วค่อยไป Test Design

เมื่อรู้แล้วว่าอะไรควร Test

ค่อยให้ AI ช่วยแตกออกมาเป็น

Test Scenario
Test Case
Test Data
Expected Result

ตามรูปแบบที่ทีมเราใช้

ตรงนี้ AI ทำงานได้เร็วมากค่ะ

แต่ยังไม่จบ

.

STEP 5 — QA กลับเข้ามา

นี่คือ Step ที่พี่แทนไม่อยากให้หายไป

Review AI Output

ถามกลับว่า

มันตกอะไรไปไหม?

มันคิดเกิน Requirement หรือเปล่า?

มี Test Case ที่ดูดีแต่ไม่มี Business Value ไหม?

มันกำลัง Assume อะไรเองหรือเปล่า?

Risk สำคัญถูก Cover จริงหรือยัง?

แล้วสุดท้าย

QA เป็นคน Decide

ว่าอะไรควรเอาไปใช้กับงานจริง

.

สังเกตไหมคะ

Requirement ชุดเดิม
AI ตัวเดิม

แต่เราเปลี่ยนจาก

Requirement → Generate Test Case

เป็น

Requirement & Context
↓
Clarify & Question
↓
Risk & Test Condition
↓
Test Design
↓
Review AI Output
↓
QA Decision

นี่แหละค่ะที่พี่แทนหมายถึงคำว่า

“ทำงานกับ AI แบบ Coworker”

ไม่ใช่ให้ AI ทำทุกอย่างแทนเรา

แต่เราออกแบบว่า

ตรงไหนให้ AI ลงแรง
ตรงไหนให้ AI ช่วยคิด
และตรงไหน QA ต้องกลับมาเป็นคนตัดสินใจ

.

และใน Claude Cowork for QA

เราไม่ได้มานั่งดูพี่แทน Demo อย่างเดียวค่ะ

พี่แทนอยากให้ทุกคน
ลงมือทำ Workflow แบบนี้ด้วยตัวเอง

เพราะพี่แทนอยากให้หลังจบ Workshop

เวลา Requirement ใหม่เข้ามา

สิ่งแรกที่เราคิดไม่ใช่แค่

“วันนี้จะใช้ Prompt อะไร?”

แต่เป็น

“งานชิ้นนี้ ฉันกับ AI จะแบ่งงานกันยังไง?”

.

Claude Cowork for QA Workshop

3 ตุลาคม 2569
09:00–17:00 น.

4 ที่นั่งแรก 4,900 บาท/คน
หากสิทธิ์ยังไม่เต็ม

หลังจากนั้น
Early Bird 5,900 บาท/คน ถึง 30 ก.ย.

ราคาปกติ 9,900 บาท

สถานที่เรียน: โรงแรมใกล้รถไฟฟ้า BTS
(แจ้งชื่อภายหลัง)

ถ้าอยากลองเปลี่ยนจาก

“ให้ AI Generate งาน”

มาเป็น

“ออกแบบให้ AI ทำงานร่วมกับเรา”

พิมพ์ COWORK
มาที่ LINE OA @tan-sorn-ai

พี่แทนส่งรายละเอียด Workshop ให้ดูก่อนได้ค่ะ

Work Smarter. Test Better.

#พี่แทนใจทดสอบซอฟต์แวร์
#พี่แทนใจAIสำหรับคนทำงาน
#ClaudeCoworkforQA