qa

Files (1)

• SKILL.md

SKILL.md (first lines)

# QA Session

รัน QA session แบบ interactive ผู้ใช้เล่าปัญหาที่เจอ คุณช่วยถามให้ชัด สำรวจ codebase เพื่อเก็บ context แล้วเปิด GitHub issue ที่คงทน เน้นมุมมองผู้ใช้ และใช้ภาษา domain ของโปรเจกต์

## สำหรับแต่ละ issue ที่ผู้ใช้ยกขึ้นมา

### 1. ฟังก่อน แล้วถามให้ชัดแบบพอดี ๆ

ให้ผู้ใช้เล่าปัญหาด้วยคำพูดของเขาเอง ถามคำถามสั้น ๆ **ไม่เกิน 2-3 ข้อ** โฟกัสที่:

- เขาคาดหวังอะไร vs เกิดอะไรขึ้นจริง
- ขั้นตอน reproduce (ถ้ายังไม่ชัด)
- เกิดทุกครั้งหรือเป็น ๆ หาย ๆ

อย่าสัมภาษณ์ยืดเยื้อ ถ้าคำอธิบายชัดพอจะเปิด issue ได้แล้ว ไปต่อเลย

### 2. สำรวจ codebase เบื้องหลัง

ระหว่างคุยกับผู้ใช้ ให้ยิง Agent (subagent_type=Explore) ทำงานเบื้องหลังเพื่อทำความเข้าใจบริเวณที่เกี่ยวข้อง เป้าหมายไม่ใช่การหาวิธีแก้ — แต่เพื่อ:

- เรียนรู้ภาษา domain ที่ใช้ในบริเวณนั้น (เช็ก UBIQUITOUS_LANGUAGE.md)
- เข้าใจว่า feature นั้นควรทำอะไร
- ระบุขอบเขตพฤติกรรมฝั่งที่ผู้ใช้มองเห็น

context นี้ช่วยให้เขียน issue ได้ดีขึ้น — แต่ตัว issue เองต้องไม่อ้างถึงไฟล์ เลขบรรทัด หรือรายละเอียด implementation ภายใน

### 3. ประเมิน scope: issue เดียวหรือต้องแตกย่อย?

ก่อนเปิด issue ตัดสินใจว่านี่คือ **issue เดียว** หรือควร **แตกย่อย** เป็นหลาย issue

แตกย่อยเมื่อ:

- การแก้กินพื้นที่หลายบริเวณที่เป็นอิสระต่อกัน (เช่น "validation ของ form ผิด แล้วก็ไม่มี success message แล้วก็ redirect พัง")
- มีประเด็นที่แยกจากกันชัดเจนจนคนละคนหยิบไปทำขนานกันได้
- ผู้ใช้เล่าอะไรที่มี failure mode หรืออาการหลายแบบที่แยกจากกัน

คงเป็น issue เดียวเมื่อ:

- เป็นพฤติกรรมเดียวที่ผิดในที่เดียว
- อาการทั้งหมดมาจากพฤติกรรมต้นตอเดียวกัน

### 4. เปิด GitHub issue

สร้าง issue ด้วย `gh issue create` ไม่ต้องให้ผู้ใช้ review ก่อน — เปิดเลยแล้วแชร์ URL

issue ต้อง **คงทน** — อ่านแล้วยังเข้าใจได้แม้ผ่าน refactor ใหญ่ ๆ เขียนจากมุมมองของผู้ใช้

#### สำหรับ issue เดียว

ใช้ template นี้:

```
## What happened

[Describe the actual behavior the user experienced, in plain language]

## What I expected

[Describe the expected behavior]

## Steps to reproduce

1. [Concrete, numbered steps a developer can follow]
2. [Use domain terms from the codebase, not internal module names]
3. [Include relevant inputs, flags, or configuration]

## Additional context

[Any extra observations from the user or from codebase exploration that help frame the issue — e.g. "this only happens when using the Docker layer, not the filesystem layer" — use domain language but don't cite files]
```

#### สำหรับการแตกย่อย (หลาย issue)

สร้าง issue ตามลำดับ dependency (ตัวที่ block คนอื่นก่อน) เพื่อให้อ้างเลข issue จริงได้

ใช้ template นี้กับ sub-issue แต่ละตัว:

```
## Parent issue

#<parent-issue-number> (if you created a tracking issue) or "Reported during QA session"

## What's wrong

[Describe this specific behavior problem — just this slice, not the whole report]

## What I expected

[Expected behavior for this specific slice]

## Steps to reproduce

1. [Steps specific to THIS issue]

## Blocked by

- #<issue-number> (if this issue can't be fixed until another is resolved)

Or "None — can start immediately" if no blockers.

## Additional context

[Any extra observations relevant to this slice]
```

เวลาแตกย่อย:

- **เลือก issue บาง ๆ หลายอันดีกว่า issue หนา ๆ ไม่กี่อัน** — แต่ละอันต้องแก้และตรวจได้อย่างอิสระ
- **ระบุความสัมพันธ์แบบ block กันตามจริง** — ถ้า issue B test ไม่ได้จริง ๆ จนกว่า issue A จะถูกแก้ ก็บอกไปตรง ๆ ถ้าเป็นอิสระต่อกัน ให้ระบุทั้งคู่ว่า "None — can start immediately"
- **สร้าง issue ตามลำดับ dependency** เพื่อให้อ้างเลข issue จริงในช่อง "Blocked by" ได้
- **เน้นให้ขนานกันได้มากที่สุด** — เป้าหมายคือให้หลายคน (หรือหลาย agent) หยิบคนละ issue ไปทำพร้อมกันได้

#### กติกาสำหรับเนื้อหา issue ทุกอัน

- **ห้ามใส่ file path หรือเลขบรรทัด** — พวกนี้ล้าสมัยเร็ว
- **ใช้ภาษา domain ของโปรเจกต์** (เช็ก UBIQUITOUS_LANGUAGE.md ถ้ามี)
- **อธิบายพฤติกรรม ไม่ใช่ code** — "sync service apply patch ไม่สำเร็จ" ไม่ใช่ "applyPatch() throws on line 42"
- **ขั้นตอน reproduce เป็นสิ่งบังคับ** — ถ้าหาไม่ได้ ให้ถามผู้ใช้
- **กระชับเข้าไว้** — dev ควรอ่าน issue จบได้ใน 30 วินาที

From Boom-Vitt/skills-thai, MIT.

More from Boom-Vitt/skills-thai