ใช้ AI ตรวจ QC-QA เว็บจริง 8 หมวด 163 ข้อ — คะแนนจาก 49% เป็น 89%
ทดลองใช้ AI deep research หา QC-QA checklist สำหรับโปรเจกต์เว็บ ได้ 236 prompts, 32 tools, 195 checklist จัดเป็น 8 หมวด แล้วเอาไปตรวจเว็บแอปจริง — ทั้ง Functional Testing, Security, Performance, Accessibility, SEO และอีก 3 หมวด พร้อม prompt ที่ใช้จริงทุกข้อ
Functional Testing — จาก 56% ถึง 87% ด้วย AI
จุดเริ่มต้น — ทำไมต้องสร้างระบบ QC-QA ด้วย AI?
ในทีมมีน้องที่ทำ QC-QA ตรวจงานเว็บ — แต่ปัญหาคือ ตรวจช้า ตรวจไม่ครบ แล้วก็ไม่มี standard ชัดเจนว่า "ครบ" คือแค่ไหน.
โปรเจกต์เว็บหลายตัวมูลค่า 10 ล้านขึ้นไป. Bug หลุดไป production ครั้งหนึ่ง อาจหมายถึงเงินหลักแสน. แต่ถ้าให้คนตรวจทุกอย่างเอง — ใช้เวลา 2-3 วันต่อ release.
ต้องการวิธีที่จะทำให้ทีม QC-QA ทำงานได้ไวและมีคุณภาพ โดยใช้ AI.
นี่คือโจทย์. แล้วก็เริ่มถาม AI.
Deep Research Prompt — คำถามแรกที่ถาม AI
ในโลกนี้ สำหรับการ QC, QA งานด้าน web application, mobile application, web design ของโครงการที่มากกว่า 10 ล้านบาทขึ้นไป จะต้องมีการ QC, QA อะไรยังไงบ้าง ให้ deep research หามาให้ดูหน่อย ทั้งของฟรีและจ่ายเงิน รวม prompts สำหรับสั่ง AI ช่วยตรวจ, tools ที่ใช้ได้จริง, และ checklist items ที่ต้องตรวจให้ครบ
AI deep research กลับมาใน 15 นาที — ได้ผลลัพธ์ที่เหนือความคาดหมาย.
236 prompts. 32 tools. 195 checklist items. — จากแค่คำถามเดียว.
แต่ข้อมูลดิบขนาดนี้ ถ้าเอามากองตรงหน้าน้องในทีม — เขาก็ตายอยู่ดี. ต้องจัดการมันให้ใช้งานได้จริง.
ให้ AI จัดหมวดหมู่ — ได้ 8 หมวด
จากข้อมูล 236 prompts, 32 tools, 195 checklist items ที่ได้มา: 1. แยกว่าอันไหนฟรี อันไหนจ่ายเงิน 2. จัดหมวดหมู่ แยกตามประเภทการ Scan ตาม item ย่อย 3. แยกตาม tech stack (Next.js, React, Vue, etc.) 4. ถ้าอยากทำไวๆ ให้แยกตามหมวดระบบ 5. วางเมนูหลักตามจำนวนหมวดที่ได้
AI บอกว่ามี 8 หมวด — จัดมาให้ครบ พร้อมจำนวน items แต่ละหมวด.
Planning
10 itemsDevelopment
21 itemsFunctional Testing
19 itemsPerformance
19 itemsSecurity
20 itemsAccessibility
16 itemsSEO & Analytics
18 itemsDeployment
15 itemsแต่ละหมวดมี prompt สำเร็จรูป กด Copy วางใน Cursor ได้เลย พร้อม tool ที่แนะนำ + install command. ทีมไม่ต้องจำเอง ไม่ต้อง Google เอง.
19 ข้อตรวจอะไรบ้าง?
วันนี้จะลงลึกหมวด Functional Testing ที่มี 19 ข้อ — เพราะนี่คือหมวดที่ใช้จริงกับโปรเจกต์ ScanlyIQ แล้วเจอ bug สำคัญ 5 ตัว.
Functional Testing แบ่งเป็น 4 กลุ่ม:
กลุ่มที่ 1 — E2E Testing (10 ข้อ)
| # | หัวข้อ | ระดับ | Tool |
|---|---|---|---|
| 1 | Happy Path ทุก User Flow | CRITICAL | Playwright |
| 2 | Form Validation | HIGH | Playwright |
| 3 | Authentication Flow | CRITICAL | Playwright |
| 4 | Authorization (RBAC) | CRITICAL | Playwright |
| 5 | CRUD Operations | HIGH | Playwright |
| 6 | Search & Filter | MEDIUM | Playwright |
| 7 | Pagination | LOW | Playwright |
| 8 | File Upload/Download | MEDIUM | Playwright |
| 9 | Payment Flow | CRITICAL | Playwright |
| 10 | Email Notifications | MEDIUM | Mailtrap |
กลุ่มที่ 2 — Cross-Browser (4 ข้อ)
| # | Browser | ระดับ | Tool |
|---|---|---|---|
| 11 | Chrome | HIGH | Playwright |
| 12 | Firefox | MEDIUM | Playwright |
| 13 | Safari | MEDIUM | Playwright |
| 14 | Edge | LOW | Playwright |
กลุ่มที่ 3 — Responsive Design (4 ข้อ)
| # | ขนาดหน้าจอ | ระดับ | Tool |
|---|---|---|---|
| 15 | Mobile (320-480px) | HIGH | Responsively |
| 16 | Tablet | MEDIUM | Responsively |
| 17 | Desktop | MEDIUM | Responsively |
| 18 | Large Screen | LOW | Responsively |
กลุ่มที่ 4 — Error Pages (1 ข้อ)
| # | หัวข้อ | ระดับ | Tool |
|---|---|---|---|
| 19 | Error Pages: 404/500 | MEDIUM | Playwright |
ทุกข้อมี prompt สำเร็จรูป — กด Copy แล้ววางใน Cursor ให้ AI ตรวจโปรเจกต์ให้เลย.
ผลตรวจจริง — เจอ Bug ร้ายแรง 5 ตัวที่ซ่อนอยู่
เอา prompt จากหมวด Functional Testing ไปวางใน Cursor แล้วสั่งให้ Claude ตรวจโปรเจกต์ ScanlyIQ จริงๆ — ไม่ได้แค่อ่าน checklist แล้วติ๊ก ✅ เอง.
AI อ่าน code ทุกไฟล์ ตรวจ route ทุก endpoint ดู middleware ดู auth logic — แล้วให้คะแนนกลับมา.
ผลลัพธ์? สะเทือนใจ.
คะแนนก่อนแก้แค่ 56% — จาก 190 คะแนนเต็ม ได้แค่ 110. นี่คือโปรเจกต์ที่ "คิดว่า" พร้อม deploy.
ZONE 1 — ปัญหาร้ายแรงที่ AI จับได้
5 ปัญหาร้ายแรง — ถ้าไม่ตรวจ มันจะหลุดไป production แน่นอน:
🔴 ZONE 1 — แก้แล้วเสี่ยง (ต้อง test staging ก่อน)
| # | ปัญหา | ทำไมเสี่ยง |
|---|---|---|
| 1 | Payment race condition — stripeSessionId อาจ null ตอน webhook fire | User จ่ายเงินแต่ไม่ได้ credit |
| 2 | Google OAuth bypass isActive — user ถูก ban แต่ login ผ่าน Google ได้ | ระบบ ban ไม่ทำงาน |
| 3 | allowDangerousEmailAccountLinking: true | Attacker hijack account ได้ |
| 4 | Credit deduction race condition — concurrent requests overdraw | User ใช้ credit ได้เกินที่มี |
| 5 | File delete ลบ disk ก่อน DB | ถ้า DB fail → file หายแต่ DB ยังเห็น |
ข้อ 1 นี่สำคัญมาก — Payment race condition. ถ้า Stripe webhook fire เร็วกว่าที่ระบบบันทึก stripeSessionId user จ่ายเงินแล้วแต่ไม่ได้ credit. จะรู้ตอนไหน? ตอน user มาด่า.
ข้อ 3 ยิ่งน่ากลัว — allowDangerousEmailAccountLinking เปิดอยู่. ชื่อมันบอกอยู่แล้วว่า "dangerous" แต่ไม่เคยสังเกต. AI จับได้.
ZONE 2 — แก้ได้เลย ไม่กระทบระบบ
🟢 ZONE 2 — แก้ได้เลย (ไม่กระทบระบบ)
| # | ปัญหา | วิธีแก้ | Effort |
|---|---|---|---|
| 1 | /api/auth/register ไม่มี → สมัครไม่ได้ | สร้าง endpoint ใหม่ | L |
| 2 | Email functions ไม่ถูกเรียก | เพิ่ม sendEmail calls | S |
| 3 | ไม่มี error.tsx / not-found.tsx | สร้าง custom 404/500 | S |
| 4 | File size limit mismatch (50MB vs 20MB) | แก้ให้ตรงกัน | XS |
| 5 | OKLCH CSS ไม่มี fallback | เพิ่ม HSL fallback | M |
| 6 | ไม่มี browserslist | เพิ่มใน package.json | XS |
| 7 | Large screen ไม่มี max-width | เพิ่ม max-w-7xl | XS |
AI แก้ทั้ง 12 ข้อ — ใน Session เดียว
สั่ง AI: "คุณทำให้ทั้งหมดเลยได้ไหม"
AI แก้ทั้ง 12 ข้อ. ตั้งแต่สร้าง register endpoint, แก้ payment race condition, ปิดช่องโหว่ OAuth, สร้าง error pages, จนถึงเพิ่ม CSS fallback — ทั้งหมดใน session เดียว.
| # | สิ่งที่แก้ | ก่อน → หลัง |
|---|---|---|
| 1 | Register endpoint | ไม่มี → สมัครได้ + hash password + referral + bonus |
| 2 | Error pages | Default Next.js → Custom 404/500 ภาษาไทย |
| 3 | File size mismatch | Server 20MB ≠ Client 50MB → ตรงกัน |
| 4 | Payment race condition | Webhook หาไม่เจอ → Fallback ด้วย metadata |
| 5 | OAuth security | dangerousLinking: true → false |
| 6 | OAuth ban bypass | ไม่เช็ค isActive → เช็คใน JWT callback |
| 7 | Credit race condition | Check นอก transaction → ย้ายเข้า $transaction |
| 8 | File delete race | ลบ disk ก่อน → Soft-delete DB ก่อน |
| 9 | Email notifications | ไม่ส่ง → ส่ง welcome + job completed |
| 10 | OKLCH CSS fallback | OKLCH only → HSL fallback + @supports |
| 11 | browserslist | ไม่มี → last 2 versions, >0.5% |
| 12 | Large screen max-width | ไม่จำกัด → max-w-7xl mx-auto |
คะแนนสุดท้าย — แต่ละข้อ
| หัวข้อ | คะแนน | ผล |
|---|---|---|
| E2E: Happy Path | 0 → 8/10 | ✅ Register ใช้ได้แล้ว |
| Form Validation | 5/10 | ⚠️ แก้ mismatch แล้ว |
| Auth Flow | 3 → 8/10 | ✅ Register + OAuth fixed |
| Authorization (RBAC) | 9/10 | ✅ ดีมากตั้งแต่แรก |
| CRUD Operations | 6/10 | ⚠️ ขาด operations บางส่วน |
| Search & Filter | 8/10 | ✅ |
| Pagination | 6/10 | ⚠️ เพิ่ม storage pagination แล้ว |
| File Upload/Download | 5/10 | ⚠️ Upload ✅ Download ❌ |
| Payment Flow | 6 → 8/10 | ✅ แก้ race condition แล้ว |
| Email Notifications | 1 → 7/10 | ✅ ส่ง email แล้ว |
| Chrome / Edge | 9/10 | ✅ |
| Firefox / Safari | 6 → 8/10 | ✅ เพิ่ม CSS fallback |
| Responsive (Mobile/Tablet/Desktop) | 8-9/10 | ✅ |
| Large Screen | 5 → 8/10 | ✅ เพิ่ม max-width |
| Error Pages | 1 → 8/10 | ✅ Custom 404/500 |
ทำไม Prompt ดีกว่า Tool แพง — แล้ว Workflow ทำยังไง?
เคยซื้อ tool QA ราคาหลักหมื่นต่อเดือน — มันตรวจได้แค่ "ผิวนอก". Lighthouse score, broken links, SSL expiry. แค่นั้น.
แต่ prompt ที่ดี + AI ที่อ่าน code ได้? มันเจอ race condition ในโค้ด. มันเจอ OAuth bypass. มันเจอว่า email function สร้างแล้วแต่ไม่ได้ถูกเรียก.
นี่คือสิ่งที่ tool ตัวไหนก็ทำไม่ได้ — เว้นแต่คุณจะมี senior developer มานั่ง code review ให้.
❌ QA Tool แบบเดิม
- ❌ ตรวจแค่ผิวนอก (UI, performance, SEO)
- ❌ ไม่อ่าน source code
- ❌ ไม่เจอ race condition / logic bugs
- ❌ ราคาหลักหมื่น/เดือน
- ❌ ต้องเรียนรู้วิธีใช้
✅ AI + Prompt ที่ดี
- ✅ อ่าน code ทุกบรรทัด
- ✅ เจอ race condition, auth bypass, dead code
- ✅ แก้ให้ได้เลย ไม่ใช่แค่บอก
- ✅ ค่าใช้จ่าย: ค่า AI subscription เท่านั้น
- ✅ สั่งเป็นภาษาคน
Workflow จริง — 5 Steps
Step 1 — เปิด QC Dashboard → เลือกหมวด
เปิด Enterprise 360 QC-QA Tools → ไปที่ Tab Prompts → เลือกหมวด (เช่น Functional Testing)
Step 2 — กด Copy Prompt
แต่ละหมวดมี prompt สำเร็จรูป กด Copy Prompt ปุ่มเดียว
Step 3 — วางใน Cursor (Cmd+L)
เปิด Cursor → Cmd+L → วาง prompt → สั่ง AI ตรวจ
Step 4 — AI ตรวจ + ให้ผลลัพธ์
AI อ่าน code ทุกไฟล์ ตรวจทุก endpoint แล้วให้ผลเป็น Zone 1 (เสี่ยง) + Zone 2 (แก้ได้เลย) + คะแนน
Step 5 — สั่ง AI แก้
บอก AI ว่า "แก้ให้หมดเลย" → AI แก้ code → รัน build → verify
ทั้ง 5 steps ใช้เวลารวม ไม่ถึง 1 ชั่วโมง — สำหรับการตรวจ + แก้ 19 หัวข้อ 12 issues. ถ้าให้คนทำเอง? 2-3 วัน.
ลองทำเลย — Prompt + FAQ
นี่คือ prompt จริงที่ใช้ — copy ไปวางใน Cursor ได้เลย:
[ROLE] คุณเป็น Senior QC Engineer ตรวจสอบ web project [PROJECT] Framework: nextjs | Path: ./ [URL] Dev: http://localhost:3000 | Prod: (ยังไม่กำหนด) [SCOPE] ตรวจสอบอย่างเดียว ห้ามแก้ไขไฟล์ ตรวจ "🧪 Functional Testing" — 19/19 ข้อ: 1. [CRITICAL] E2E: Happy Path ทุก User Flow 2. [HIGH] E2E: Form Validation 3. [CRITICAL] E2E: Authentication Flow 4. [CRITICAL] E2E: Authorization (RBAC) 5. [HIGH] E2E: CRUD Operations 6. [MEDIUM] E2E: Search & Filter 7. [LOW] E2E: Pagination 8. [MEDIUM] E2E: File Upload/Download 9. [CRITICAL] E2E: Payment Flow 10. [MEDIUM] E2E: Email Notifications 11. [HIGH] Cross-Browser: Chrome 12-14. [MEDIUM-LOW] Cross-Browser: Firefox, Safari, Edge 15. [HIGH] Responsive: Mobile (320-480px) 16-18. [MEDIUM-LOW] Responsive: Tablet, Desktop, Large Screen 19. [MEDIUM] Error Pages: 404/500 [OUTPUT] ===== สรุปผลการตรวจสอบ ===== ## ZONE 1 — แก้แล้วเสี่ยง (backup/test staging ก่อน) ## ZONE 2 — แก้ได้เลย (ไม่กระทบระบบ) ## Score — ก่อนแก้: XX% → หลังแก้: XX%
เปลี่ยน [PROJECT] เป็น framework และ path ของคุณ เปลี่ยน [URL] เป็น dev URL ของคุณ — แล้วสั่ง AI ได้เลย.
FAQ — คำถามที่คนถามบ่อย
Q: ต้องรู้ code ไหมถึงจะใช้ prompt นี้ได้?
ไม่ต้อง. แค่เปิด Cursor กับ project ที่จะตรวจ copy prompt วาง สั่ง AI — มันอ่าน code ให้เองหมด. ผลลัพธ์เขียนเป็นภาษาคนอ่านเข้าใจ.
Q: ใช้กับ project ภาษาอะไรก็ได้?
ได้ครับ. Prompt นี้ออกแบบมาสำหรับ web app ทุก framework — Next.js, React, Vue, Angular, PHP, Django. แค่เปลี่ยน [PROJECT] Framework.
Q: 19 ข้อนี้พอไหม? ไม่มี Security, Performance?
Functional Testing คือ 1 ใน 8 หมวด. Security (20 ข้อ), Performance (19 ข้อ), SEO (18 ข้อ) อยู่หมวดอื่น — แต่ละหมวดมี prompt แยก. ใช้ QC Dashboard เปิดทีละหมวดได้.
Q: AI แก้ code เองแล้ว safe ไหม? ไม่พังอะไรเพิ่ม?
แนะนำให้ตรวจก่อนเสมอ. สั่ง AI ตรวจก่อน (ห้ามแก้ไขไฟล์) → ดูผลลัพธ์ → ถ้าเห็นด้วยค่อยสั่งแก้. แล้ว commit ทุกขั้นตอน เผื่อต้อง rollback.
Q: ทำไมไม่ใช้ Playwright ตรงๆ แทน AI ตรวจ code?
Playwright ตรวจ "พฤติกรรม" (กดปุ่มแล้วเกิดอะไร). AI ตรวจ "โครงสร้าง" (code มี race condition ไหม, auth ปลอดภัยไหม). ดีที่สุดคือใช้ทั้งคู่ — แต่ถ้าเลือกได้อย่างเดียว AI ตรวจ code เจอปัญหาลึกกว่า.
Planning — จาก 33% ถึง 85% ด้วย AI
ทำไม Planning ต้องตรวจ? — มันคือรากฐาน
หลังจากรันหมวด Functional Testing จน ScanlyIQ ขึ้นจาก 56% เป็น 87% — ก็เริ่มสงสัยว่า "ถ้าตรวจหมวดอื่นล่ะ จะเจออะไรอีก?"
เปิด QC Dashboard ไปที่หมวด Planning — 10 ข้อ. หมวดนี้ไม่ได้ตรวจว่า code มี bug ไหม — แต่ตรวจว่า โปรเจกต์มีโครงสร้างพร้อม scale ไหม. มี test ไหม? มี CI/CD ไหม? มี monitoring ไหม? มี security headers ไหม?
ผลลัพธ์? แย่กว่า Functional Testing อีก.
33 จาก 100. โปรเจกต์ที่ "ทำงานได้" แต่ไม่มีรากฐานอะไรเลย — ไม่มี test แม้แต่ไฟล์เดียว, ไม่มี CI/CD, ไม่มี monitoring, ESLint config พังจนใช้ไม่ได้.
10 ข้อตรวจอะไรบ้าง?
[ROLE] คุณเป็น Senior QC Engineer ตรวจสอบ web project [PROJECT] Framework: nextjs | Path: ./ [SCOPE] ตรวจสอบอย่างเดียว ห้ามแก้ไขไฟล์ ตรวจ "📋 Planning" — 10/10 ข้อ: 1. [MEDIUM] กำหนด Browser/Device Matrix 2. [HIGH] กำหนด Performance Budget (LCP<2.5s, CLS<0.1) 3. [HIGH] กำหนด Accessibility Standard (WCAG 2.1 AA) 4. [MEDIUM] กำหนด SEO Requirements 5. [CRITICAL] กำหนด Security Requirements (OWASP Top 10) 6. [HIGH] วาง Test Strategy (Unit/Integration/E2E) 7. [MEDIUM] กำหนด Code Quality Standards 8. [MEDIUM] ตั้ง Error Budget & Monitoring Plan 9. [MEDIUM] วาง CI/CD Pipeline Design 10. [LOW] กำหนด Definition of Done (DoD)
คะแนนก่อนแก้ — รายข้อ
| # | หัวข้อ | Priority | คะแนน | สถานะ |
|---|---|---|---|---|
| 1 | Browser/Device Matrix | MEDIUM | 5/10 | ⚠️ มี browserslist แต่ไม่มี document |
| 2 | Performance Budget | HIGH | 2/10 | ❌ ไม่มี budget/tracking |
| 3 | Accessibility (WCAG 2.1 AA) | HIGH | 3/10 | ⚠️ มี aria-invalid พื้นฐานเท่านั้น |
| 4 | SEO Requirements | MEDIUM | 4/10 | ⚠️ มี metadata แต่ไม่มี robots/sitemap |
| 5 | Security (OWASP Top 10) | CRITICAL | 7/10 | ✅ Auth + Zod + Rate Limit ดีมาก |
| 6 | Test Strategy | HIGH | 0/10 | ❌ ไม่มี test แม้แต่ไฟล์เดียว |
| 7 | Code Quality | MEDIUM | 5/10 | ⚠️ TS strict ดี แต่ ESLint พัง |
| 8 | Monitoring | MEDIUM | 1/10 | ❌ ไม่มี error tracking เลย |
| 9 | CI/CD Pipeline | MEDIUM | 2/10 | ❌ มีแค่ Docker |
| 10 | Definition of Done | LOW | 4/10 | ⚠️ มีใน CLAUDE.md แต่ไม่ formal |
รวม: 33/100 — ข้อที่โดน 0/10 คือ Test Strategy. โปรเจกต์ที่มี 56 API routes แต่ไม่มี automated test แม้แต่ตัวเดียว.
ZONE 1 — เรื่องที่แก้แล้วอาจพังได้
🔴 ZONE 1 — ต้อง test staging ก่อน
| # | ปัญหา | ทำไมเสี่ยง |
|---|---|---|
| 1 | ไม่มี Security Headers (CSP, HSTS, X-Frame-Options) | HSTS บังคับ HTTPS ทันที — ถ้า SSL ไม่พร้อมจะเข้าเว็บไม่ได้ |
| 2 | ESLint config พัง | แก้แล้วอาจ surface errors เยอะมากที่ต้องแก้ตาม |
ZONE 2 — Quick Wins แก้ได้ทันที
🟢 ZONE 2 — แก้ได้เลย ไม่กระทบระบบ
| # | ปัญหา | วิธีแก้ | Effort |
|---|---|---|---|
| 1 | ไม่มี robots.txt | สร้าง src/app/robots.ts | XS |
| 2 | ไม่มี sitemap.xml | สร้าง src/app/sitemap.ts | S |
| 3 | ไม่มี metadataBase | เพิ่มใน layout.tsx | XS |
| 4 | ไม่มี Viewport export | เพิ่มใน layout.tsx | XS |
| 5 | ไม่มี Prettier | ติดตั้ง + config | S |
| 6 | ไม่มี Test framework | ติดตั้ง Vitest + เขียน test แรก | M |
| 7 | ไม่มี CI/CD | สร้าง GitHub Actions workflow | M |
| 8 | ไม่มี Monitoring | ติดตั้ง Sentry SDK | M |
| 9 | ไม่มี Structured Data | เพิ่ม JSON-LD | S |
| 10 | ไม่มี Performance Budget | สร้าง document กำหนด targets | XS |
AI แก้ทั้ง 10 ข้อ — ผลลัพธ์
สั่ง AI: "ให้คุณดำเนินการทั้งหมดให้เลย" — เหมือนที่ทำกับ Functional Testing.
AI ทำทั้ง 10 ข้อจบใน session เดียว:
| # | สิ่งที่ทำ | ก่อน → หลัง |
|---|---|---|
| 1 | แก้ ESLint config | พัง (Oops! Something went wrong) → ทำงานได้ + เจอ 15 warnings |
| 2 | ติดตั้ง Prettier | ไม่มี → .prettierrc + format:check script |
| 3 | เพิ่ม Security Headers | 0 headers → HSTS, X-Frame-Options, X-Content-Type + 3 อื่นๆ |
| 4 | เพิ่ม metadataBase + viewport | ไม่มี → ครบ meta, OG, icons, locale |
| 5 | สร้าง robots.ts + sitemap.ts | ไม่มี → dynamic generated ทั้งคู่ |
| 6 | เพิ่ม Structured Data | ไม่มี → JSON-LD WebApplication schema |
| 7 | ติดตั้ง Vitest + test แรก | 0 tests → 9 unit tests ผ่านหมด |
| 8 | สร้าง CI/CD | ไม่มี → GitHub Actions (lint + type-check + test + build) |
| 9 | ติดตั้ง Sentry | ไม่มี → client + server + edge config + error capture |
| 10 | สร้าง Performance Budget | ไม่มี → document LCP/CLS/INP targets + bundle budget |
คะแนนหลังแก้ — รายข้อ
| หัวข้อ | คะแนน | ผล |
|---|---|---|
| Browser/Device Matrix | 5 → 7/10 | ✅ มี browserslist + Tailwind breakpoints |
| Performance Budget | 2 → 8/10 | ✅ มี document + targets กำหนดชัด |
| Accessibility | 3 → 6/10 | ⚠️ ยังต้อง audit เพิ่ม |
| SEO Requirements | 4 → 9/10 | ✅ robots + sitemap + JSON-LD + OG ครบ |
| Security (OWASP) | 7 → 9/10 | ✅ เพิ่ม 6 security headers |
| Test Strategy | 0 → 8/10 | ✅ Vitest + 9 tests + CI/CD run auto |
| Code Quality | 5 → 9/10 | ✅ ESLint ทำงาน + Prettier + TS strict |
| Monitoring | 1 → 8/10 | ✅ Sentry ครบ 3 layers |
| CI/CD Pipeline | 2 → 9/10 | ✅ GitHub Actions full pipeline |
| Definition of Done | 4 → 7/10 | ✅ มี quality gates + budget |
รวม: 33/100 → 85/100 — เพิ่มขึ้น 52 คะแนน. ข้อที่ขึ้นมากที่สุดคือ Test Strategy (0 → 8) กับ CI/CD (2 → 9).
สิ่งที่เรียนรู้จากหมวด Planning
Planning ไม่ใช่แค่ "วางแผน" — มันคือ โครงสร้างพื้นฐานของโปรเจกต์. โปรเจกต์ที่ทำงานได้แต่ไม่มี test, ไม่มี CI/CD, ไม่มี monitoring — เหมือนบ้านที่อยู่ได้แต่ไม่มีเสาเข็ม.
ตลกตรงที่ AI ชี้ให้เห็นว่า ESLint ที่ควรจะเป็น "ด่านแรก" ของ code quality — มันพังมาตลอดโดยไม่มีใครรู้ตัว. ตรวจ pnpm lint ได้ "Oops! Something went wrong!" แต่ไม่เคยสังเกต เพราะ build ผ่าน.
อีกเรื่องคือ 0 test files สำหรับ 56 API routes. ไม่ใช่เพราะขี้เกียจ — แต่เพราะ "ไม่รู้จะเริ่มยังไง". AI ตั้ง Vitest, เขียน test แรก, setup CI/CD ให้ — ทั้งหมดใน 1 session. ตอนนี้ทุก push ไป GitHub จะ lint + type-check + test + build อัตโนมัติ.
Security Testing — จาก 71% ถึง 100% ด้วย AI
ทำไม Security ถึงน่ากลัวกว่าหมวดอื่น?
Functional Testing เจอ bug ที่ทำให้ระบบพัง. Planning เจอช่องว่างด้านโครงสร้าง. แต่ Security? — เจอช่องโหว่ที่ทำให้คนอื่นเข้ามาขโมยข้อมูลได้.
โปรเจกต์ 10 ล้านขึ้นไป ถ้าข้อมูล user หลุด — ไม่ใช่แค่เสียเงินแก้ระบบ แต่เสียความไว้วางใจทั้งหมด.
เปิด QC Dashboard ไปที่หมวด Security — 20 ข้อ แล้วรันตรวจ ScanlyIQ:
71% ฟังดูดี — แต่ในด้าน Security "ดี" ไม่พอ. ข้อที่ไม่ผ่านแค่ข้อเดียวอาจทำให้ถูก hack ได้.
20 ข้อตรวจอะไรบ้าง?
[ROLE] คุณเป็น Senior QC Engineer ตรวจสอบ web project [PROJECT] Framework: nextjs | Path: ./ [SCOPE] ตรวจสอบอย่างเดียว ห้ามแก้ไขไฟล์ ตรวจ "🛡️ Security" — 20/20 ข้อ: 1. [CRITICAL] OWASP ZAP (0 High/Critical) 2. [CRITICAL] SQL Injection Test 3. [CRITICAL] XSS Test 4. [HIGH] CSRF Protection 5. [HIGH] Content Security Policy (CSP) 6. [HIGH] HTTPS Everywhere 7. [HIGH] HSTS Header 8. [MEDIUM] X-Content-Type-Options 9. [MEDIUM] X-Frame-Options 10. [MEDIUM] Referrer-Policy 11. [LOW] Permissions-Policy 12. [HIGH] Cookie Flags (Secure/HttpOnly/SameSite) 13. [HIGH] Rate Limiting on API 14. [HIGH] File Upload Validation 15. [CRITICAL] Dependency Scan (0 Critical) 16. [HIGH] SSL Grade A+ 17. [MEDIUM] SRI (Subresource Integrity) 18. [CRITICAL] Secrets Scan (0 leaks) 19. [HIGH] Input Validation client+server 20. [MEDIUM] Security Headers Score A+
หมายเหตุ: 6 ข้อ (#1, #16, #17, #20 และอีก 2 ข้อ) ต้อง deployed URL หรือ external tools — AI ตรวจได้ 14/20 ข้อจาก code review + pnpm audit
คะแนนก่อนแก้ — รายข้อ
| # | หัวข้อ | Severity | ผล |
|---|---|---|---|
| 1 | OWASP ZAP | CRITICAL | ⏭️ SKIP — ต้องติดตั้ง ZAP |
| 2 | SQL Injection | CRITICAL | ✅ Prisma ORM ทั้งหมด ไม่มี raw SQL |
| 3 | XSS Test | CRITICAL | ✅ dangerouslySetInnerHTML มีแค่ JSON-LD |
| 4 | CSRF Protection | HIGH | ✅ NextAuth v5 + SameSite cookies |
| 5 | CSP Header | HIGH | ❌ ไม่มี CSP เลย |
| 6 | HTTPS Everywhere | HIGH | ✅ HSTS บังคับ HTTPS |
| 7 | HSTS Header | HIGH | ⚠️ มี แต่ขาด preload flag |
| 8 | X-Content-Type-Options | MEDIUM | ✅ nosniff |
| 9 | X-Frame-Options | MEDIUM | ✅ DENY |
| 10 | Referrer-Policy | MEDIUM | ✅ strict-origin-when-cross-origin |
| 11 | Permissions-Policy | LOW | ✅ camera, mic, geo ปิดหมด |
| 12 | Cookie Flags | HIGH | ✅ Secure + HttpOnly + SameSite |
| 13 | Rate Limiting | HIGH | ❌ ไม่มีเลย — ทุก endpoint เปิดรับ unlimited |
| 14 | File Upload Validation | HIGH | ⚠️ มี MIME check แต่ไม่มี magic number |
| 15 | Dependency Scan | CRITICAL | ❌ 9 vulnerabilities (2 HIGH) |
| 16 | SSL Grade A+ | HIGH | ⏭️ SKIP — ต้อง deployed URL |
| 17 | SRI | MEDIUM | ⏭️ SKIP |
| 18 | Secrets Scan | CRITICAL | ✅ .env อยู่ใน .gitignore ไม่มี hardcoded secrets |
| 19 | Input Validation | HIGH | ⚠️ ส่วนใหญ่ดี แต่ LINE webhook ไม่มี Zod |
| 20 | Security Headers Score | MEDIUM | ⏭️ SKIP |
ตรวจได้ 14 ข้อ: ผ่าน 10, ไม่ผ่าน 2, เตือน 2 → คิดเป็น 71%
ZONE 1 — เรื่องที่แก้แล้วอาจพังได้
🔴 ZONE 1 — ต้อง test staging ก่อน
| # | ปัญหา | ทำไมเสี่ยง |
|---|---|---|
| 1 | ไม่มี Rate Limiting — ทุก API endpoint ไม่จำกัด requests | Brute-force login, credit burn attack, upload DoS ได้ไม่จำกัด |
| 2 | 9 Dependency Vulnerabilities (2 HIGH) — hono via shadcn | hono มีช่องโหว่ arbitrary file access + auth bypass |
| 3 | ไม่มี CSP Header | XSS attack สามารถ inject script จาก external source ได้ |
ข้อ 1 น่ากลัวที่สุด — ไม่มี Rate Limiting เลย. หมายความว่าใครก็ตามสามารถยิง request ไปที่ /api/auth/register หรือ /api/upload/slip ได้ไม่จำกัด. Brute-force password? ทำได้. เผา credit ของ user? ทำได้. ส่งไฟล์ขนาดใหญ่ซ้ำๆ จน server ล่ม? ทำได้.
ข้อ 2 — dependency hono ที่มาพร้อม shadcn มี 9 ช่องโหว่ รวม 2 ตัว HIGH ที่ทำให้เข้าถึงไฟล์ใดๆ บน server ได้.
ZONE 2 — Quick Wins แก้ได้ทันที
🟢 ZONE 2 — แก้ได้เลย ไม่กระทบระบบ
| # | ปัญหา | วิธีแก้ | Effort |
|---|---|---|---|
| 1 | HSTS ขาด preload | เพิ่ม ; preload ใน middleware | XS |
| 2 | Path traversal ใช้แค่ includes("..") | เปลี่ยนเป็น path.resolve() ตรวจ boundary | S |
| 3 | File upload ไม่ตรวจ magic number | เพิ่ม magic bytes check (JPEG/PNG/WebP) | S |
| 4 | LINE webhook ไม่มี Zod validation | เพิ่ม schema validation | S |
| 5 | Error response บอก credit balance จริง | Return "เครดิตไม่เพียงพอ" ไม่ต้องบอกตัวเลข | XS |
| 6 | Job cancellation race condition | ย้าย item count query เข้า Prisma transaction | S |
AI แก้ทั้งหมด — ผลลัพธ์
สั่ง AI: "ดำเนินการทั้งหมดให้เลย" — เหมือนที่ทำกับ 2 หมวดก่อนหน้า.
| # | สิ่งที่ทำ | ก่อน → หลัง |
|---|---|---|
| 1 | เพิ่ม Rate Limiting | ไม่มี → In-memory limiter: auth 10/min, upload 20/min, API 60/min |
| 2 | แก้ Dependency Vulnerabilities | 9 vulns (2 HIGH) → 0 vulnerabilities |
| 3 | เพิ่ม CSP Header | ไม่มี → Content-Security-Policy ครบ directives |
| 4 | HSTS preload | ไม่มี preload → เพิ่ม preload flag |
| 5 | Path traversal fix | includes("..") → path.resolve() + boundary check |
| 6 | Magic number validation | ไม่มี → ตรวจ file header JPEG/PNG/WebP |
| 7 | LINE webhook validation | ไม่มี → Zod schema validation |
| 8 | Error message cleanup | บอก balance จริง → "เครดิตไม่เพียงพอ" กลางๆ |
| 9 | Race condition fix | Query นอก transaction → ย้ายเข้า transaction |
สิ่งที่ดีอยู่แล้ว — AI ชมเลย
SQL Injection = 0
ใช้ Prisma ORM 100% ไม่มี raw query แม้แต่บรรทัดเดียว
Auth แข็งแกร่ง
NextAuth v5 + JWT + bcrypt(12) + email verification ครบ
Input Validation ครบ
Zod schema validation ทุก endpoint (ยกเว้น LINE webhook ที่แก้แล้ว)
Webhook Security
Stripe + PromptPay มี signature verification ป้องกัน replay attack
สิ่งที่เรียนรู้จากหมวด Security
Security ต่างจากหมวดอื่นตรงที่ ไม่มีข้อไหนที่ "ไม่สำคัญ". Functional Testing เจอ bug ที่กด register ไม่ได้ — แก้แล้วก็จบ. แต่ Security เจอว่าไม่มี Rate Limiting — หมายความว่า ถ้ามีคนอยากทำร้าย ทำได้เลยตอนนี้.
อีกเรื่องที่น่าสนใจ: dependency vulnerability. ตัว hono ที่มีช่องโหว่ ไม่ได้ import ตรงๆ — มันมาพร้อม shadcn ซึ่งเป็น UI library. ไม่มีทางรู้ถ้าไม่รัน pnpm audit. AI จับให้ แล้วแก้ด้วย pnpm overrides ใน 2 นาที.
สรุป: Security ไม่ใช่สิ่งที่ "ทำทีเดียวแล้วจบ" — ต้องตรวจซ้ำทุกครั้งที่ update dependencies หรือเพิ่ม feature ใหม่. QC Dashboard ทำให้ตรวจซ้ำได้ง่าย — copy prompt วาง สั่ง AI ไม่ถึง 1 ชั่วโมง.
Performance — จาก 45% ถึง 82% ด้วย AI
ทำไม Performance ถึงเป็นเรื่องที่มองข้ามง่ายที่สุด?
Functional Testing เจอ bug ที่ระบบพัง. Security เจอช่องโหว่ที่ถูก hack ได้. แต่ Performance? — มันไม่พังเดี๋ยวนั้น มันค่อยๆ ฆ่าแบบเงียบๆ.
เว็บโหลดช้าไป 1 วินาที = bounce rate เพิ่ม 32%. โหลดช้าไป 3 วินาที? ครึ่งหนึ่งของ user ปิดหน้าต่างไปเลย. แต่ตอน dev กดทดสอบบน localhost ทุกอย่างดูเร็วหมด — ปัญหาโผล่ตอน production ที่มี user จริง.
เปิด QC Dashboard ไปที่หมวด Performance — 19 ข้อ แล้วรันตรวจ ScanlyIQ:
45% — หมวดที่ได้คะแนนต่ำที่สุดรองจาก Planning. ปัญหาหลักคือ ไม่มี code splitting เลย ทั้ง project, ไม่มี lazy loading, images ไม่ได้ optimize. ทุกอย่างโหลดพร้อมกันหมด.
19 ข้อตรวจอะไรบ้าง?
[ROLE] คุณเป็น Senior QC Engineer ตรวจสอบ web project [PROJECT] Framework: nextjs | Path: ./ [URL] Dev: http://localhost:3000 | Prod: (ยังไม่กำหนด) [SCOPE] ตรวจสอบอย่างเดียว ห้ามแก้ไขไฟล์ ตรวจ "⚡ Performance" — 19/19 ข้อ: 1. [HIGH] Lighthouse Performance >= 90 2. [HIGH] LCP < 2.5s 3. [HIGH] INP < 200ms 4. [HIGH] CLS < 0.1 5. [MEDIUM] TTFB < 800ms 6. [MEDIUM] FCP < 1.8s 7. [MEDIUM] Total Blocking Time < 200ms 8. [MEDIUM] Speed Index < 3.4s 9. [MEDIUM] Load Test: 100 concurrent users 10. [HIGH] API Response < 200ms (p95) 11. [LOW] Stress Test: 500 users 12. [HIGH] Memory Leak Check 13. [HIGH] DB Query < 100ms 14. [MEDIUM] Images Compressed (WebP) 15. [MEDIUM] CSS/JS Minified 16. [MEDIUM] Gzip/Brotli Enabled 17. [HIGH] Bundle < 500KB gzipped 18. [MEDIUM] Code Splitting ถูกต้อง 19. [MEDIUM] Lazy Loading below-the-fold
หมายเหตุ: 9 ข้อ (#1-4, #6-9, #11) ต้อง external tools หรือ deployed URL — AI ตรวจได้ 10/19 ข้อจาก code review + curl + build analysis
คะแนนก่อนแก้ — รายข้อ
| # | หัวข้อ | Priority | ผล |
|---|---|---|---|
| 1 | Lighthouse >= 90 | HIGH | ⏭️ ต้อง lighthouse CLI |
| 2 | LCP < 2.5s | HIGH | ⏭️ ต้อง deployed URL |
| 3 | INP < 200ms | HIGH | ⏭️ ต้อง deployed URL |
| 4 | CLS < 0.1 | HIGH | ⚠️ ใช้ <img> ไม่มี width/height → CLS สูง |
| 5 | TTFB < 800ms | MEDIUM | ✅ Login 130ms, Register 112ms |
| 6 | FCP < 1.8s | MEDIUM | ⏭️ ต้อง lighthouse |
| 7 | TBT < 200ms | MEDIUM | ⏭️ ต้อง lighthouse |
| 8 | Speed Index < 3.4s | MEDIUM | ⏭️ ต้อง lighthouse |
| 9 | Load Test: 100 users | MEDIUM | ⏭️ ต้อง k6 |
| 10 | API p95 < 200ms | HIGH | ❌ /api/auth/session cold: 1.6s |
| 11 | Stress Test: 500 users | LOW | ⏭️ ต้อง k6 |
| 12 | Memory Leak Check | HIGH | ⚠️ autoAdvance callback ไม่ memoized |
| 13 | DB Query < 100ms | HIGH | ✅ Prisma queries ใช้ select ค่อนข้างดี |
| 14 | Images Compressed (WebP) | MEDIUM | ❌ ไม่มี WebP config |
| 15 | CSS/JS Minified | MEDIUM | ✅ Next.js auto-minify ใน prod |
| 16 | Gzip/Brotli | MEDIUM | ✅ Content-Encoding: gzip |
| 17 | Bundle < 500KB gzipped | HIGH | ❌ JS 13MB+ (dev), ไม่มี dynamic import |
| 18 | Code Splitting ถูกต้อง | MEDIUM | ❌ 0 dynamic imports ทั้ง project |
| 19 | Lazy Loading | MEDIUM | ❌ ใช้ <img> แทน <Image> |
ตรวจได้ 10 ข้อ: ผ่าน 4, ไม่ผ่าน 5, เตือน 1 → คิดเป็น ~45%
ZONE 1 — เรื่องที่แก้แล้วอาจพังได้
🔴 ZONE 1 — ต้อง test staging ก่อน
| # | ปัญหา | ทำไมเสี่ยง |
|---|---|---|
| 1 | ไม่มี Code Splitting เลย — heavy libs (recharts 70KB, framer-motion 30KB, exceljs 1MB) โหลดพร้อมกันหมด | แก้ผิดอาจทำให้ SSR/hydration พัง |
| 2 | เปลี่ยน <img> → <Image> (3 จุดใน slip-ocr page) | Image component ต้อง width/height หรือ fill, อาจ layout shift |
| 3 | เพิ่ม Cache-Control headers ให้ API routes | Cache ผิดจะทำให้ user เห็น data เก่า |
ข้อ 1 สำคัญที่สุด — 0 dynamic imports ทั้ง project. หมายความว่า library หนักๆ อย่าง recharts (70KB), framer-motion (30KB), exceljs (1MB) โหลดมาพร้อมกันหมด ไม่ว่าจะอยู่หน้าไหน. ทำให้ initial bundle ใหญ่เกินจำเป็น.
ZONE 2 — Quick Wins แก้ได้ทันที
🟢 ZONE 2 — แก้ได้เลย ไม่กระทบระบบ
| # | ปัญหา | วิธีแก้ | Effort |
|---|---|---|---|
| 1 | ไม่มี WebP config | เพิ่ม images.formats ใน next.config.ts | XS |
| 2 | framer-motion import ตรงๆ ใน 8 landing components | เปลี่ยนเป็น LazyMotion + domAnimation | S |
| 3 | React Query staleTime สั้น (30s) | เพิ่มเป็น 5 นาทีสำหรับ dashboard data | XS |
| 4 | autoAdvance callback ไม่ memoized | ครอบด้วย useCallback | XS |
| 5 | projectsWithStats คำนวณซ้ำทุก render | ครอบด้วย useMemo | XS |
AI แก้ทั้งหมด — ผลลัพธ์
สั่ง AI: "ดำเนินการทั้งหมดให้เลย" — เหมือนทุกหมวดที่ผ่านมา.
| # | สิ่งที่ทำ | ก่อน → หลัง |
|---|---|---|
| 1 | เพิ่ม WebP/AVIF config | ไม่มี → images.formats: ['image/webp', 'image/avif'] + cache 1 ชม. |
| 2 | LazyMotion สำหรับ landing pages | motion import ตรง → LazyMotion + domAnimation (8 ไฟล์) |
| 3 | React Query staleTime | default 30s → 5 นาที สำหรับ dashboard queries |
| 4 | เปลี่ยน <img> → <Image> | 3 จุดใน slip-ocr: <img> → next/image + fill + sizes |
| 5 | Cache-Control headers | ไม่มี → s-maxage=300, stale-while-revalidate=60 (4 API routes) |
| 6 | TypeScript check + build | 0 errors → build ผ่าน |
Heavy Dependencies ที่ตรวจสอบ
recharts (~70KB)
ใช้เฉพาะ project detail page — App Router route-split อยู่แล้ว ✅
framer-motion (~30KB)
ใช้ใน 8 landing components — เปลี่ยนเป็น LazyMotion แล้ว ✅
exceljs + docx + pdfkit
ใช้ใน server-side export route เท่านั้น — ไม่กระทบ client bundle ✅
@sentry/nextjs (~50KB)
Global monitoring — tree-shake ถูกต้อง ตรวจแล้ว ✅
คะแนนหลังแก้
| หัวข้อ | คะแนน | ผล |
|---|---|---|
| TTFB < 800ms | ✅ 130ms | ✅ ดีอยู่แล้ว |
| API p95 < 200ms | 1.6s → 190ms (warm) | ✅ cold start ยังช้า แต่ warm ผ่าน |
| DB Query < 100ms | ✅ | ✅ Prisma select ดี |
| Images (WebP) | ❌ → ✅ | ✅ WebP + AVIF auto-serve |
| CSS/JS Minified | ✅ | ✅ Next.js auto |
| Gzip/Brotli | ✅ | ✅ gzip confirmed |
| Bundle size | ❌ → ⚠️ | ⚠️ ลดลงจาก LazyMotion + route split |
| Code Splitting | 0 → 8 components | ✅ LazyMotion + Image lazy |
| Lazy Loading | ❌ → ✅ | ✅ next/image + fill + sizes |
| CLS | ⚠️ → ดีขึ้น | ✅ Image มี width/height แล้ว |
ตรวจได้ 10 ข้อ → ผ่าน 9, เตือน 1 → คิดเป็น ~82% (จาก 45% เพิ่มขึ้น +37%)
สิ่งที่เรียนรู้จากหมวด Performance
Performance ต่างจากหมวดอื่นตรงที่ ตรวจครบต้องใช้ external tools. Lighthouse, k6, PageSpeed Insights — หลายตัวต้อง deployed URL ถึงจะวัดได้จริง. แต่ AI ตรวจจาก code ได้เกือบครึ่ง — และสิ่งที่เจอก็สำคัญไม่แพ้กัน.
เรื่องที่น่าตกใจคือ 0 dynamic imports ทั้ง project. ไม่ใช่เพราะลืม — แต่เพราะ "ไม่รู้ว่าต้องทำ". Next.js App Router ทำ route-level splitting ให้อัตโนมัติ แต่ถ้า component ภายในหน้าไม่ lazy load ก็ยังโหลดมาทั้งก้อน.
อีกเรื่องคือ API cold start 1.6 วินาที สำหรับ /api/auth/session — request แรกช้ามาก แต่ request ต่อไปแค่ 190ms. เรื่องนี้แก้ได้ด้วย cache headers + stale-while-revalidate ที่ AI เพิ่มให้.
สรุป: Performance ต้องตรวจ 2 รอบ — รอบแรกจาก code (AI ทำได้), รอบสองจาก production URL (ใช้ Lighthouse + PageSpeed). QC Dashboard ให้ prompt ทั้ง 2 รอบพร้อมใช้.
Development — จาก 52% ถึง 81% ด้วย AI
ทำไม Development QC ถึงสำคัญกว่าที่คิด?
หมวดนี้คือ "พื้นฐานที่มองข้าม" — ไม่ใช่เรื่อง feature หรือ UX แต่เป็นเรื่อง คุณภาพของ code ที่เขียน. ถ้า code base เป็นระเบียบ ทุกอย่างที่ตามมาจะง่ายขึ้น. ถ้า code base รก — ทุกอย่างจะพังเป็นโดมิโน.
โปรเจกต์ ScanlyIQ สร้างด้วย AI ทั้งหมด ใช้ Next.js + TypeScript + Prisma. "AI เขียนให้ = code ดี" — คิดแบบนี้มาตลอด. จนกว่าจะตรวจจริง.
52% — ครึ่งเดียวของ Development checklist ไม่ผ่าน. ทั้งที่ build ผ่าน deploy ได้ ไม่มี error สักตัว.
21 ข้อตรวจอะไรบ้าง?
[ROLE] คุณเป็น Senior QC Engineer ตรวจสอบ web project [PROJECT] Framework: nextjs | Path: ./ [SCOPE] ตรวจสอบอย่างเดียว ห้ามแก้ไขไฟล์ ตรวจ "💻 Development" — 21/21 ข้อ: 1. [HIGH] ESLint 0 errors 2. [MEDIUM] Prettier format ผ่าน 3. [HIGH] TypeScript strict mode 0 errors 4. [HIGH] Unit Test Coverage >= 80% 5. [MEDIUM] Component Test ครบ 6. [HIGH] API Route Test ทุก Method 7. [CRITICAL] Dependency Vulnerabilities = 0 Critical 8. [LOW] License Compliance 9. [HIGH] Code Review ผ่าน 10. [MEDIUM] SonarLint Quality Check 11. [MEDIUM] ไม่มี console.log/debugger 12. [CRITICAL] Environment Variables ครบ 13. [HIGH] Database Migration ทดสอบแล้ว 14. [HIGH] API Error Handling ครบ 15. [HIGH] Input Validation ทุก Form 16. [MEDIUM] Image Optimization 17. [MEDIUM] Bundle Size ไม่เกิน budget 18. [LOW] Git Hooks ทำงานถูกต้อง 19. [MEDIUM] ไม่มี unused dependencies 20. [MEDIUM] ไม่มี circular imports 21. [CRITICAL] ไม่มี secrets ใน codebase
21 ข้อ. แบ่งตาม severity: 3 CRITICAL, 7 HIGH, 9 MEDIUM, 2 LOW. Tools ที่ใช้: ESLint, Prettier, TypeScript, Vitest, npm audit, depcheck, madge — ส่วนใหญ่ฟรี.
คะแนนก่อนแก้ — รายข้อ
| # | หัวข้อ | Severity | ผล |
|---|---|---|---|
| 1 | ESLint 0 errors | HIGH | ✅ 0 errors (มี 16 warnings) |
| 2 | Prettier format | MEDIUM | ❌ 188 ไฟล์ไม่ผ่าน format |
| 3 | TypeScript strict | HIGH | ✅ strict: true, 0 errors |
| 4 | Unit Test Coverage | HIGH | ❌ มีแค่ 1 test file, ไม่มี coverage config |
| 5 | Component Test | MEDIUM | ❌ ไม่มี component test เลย |
| 6 | API Route Test | HIGH | ❌ ไม่มี API test ใดๆ |
| 7 | Dep Vulnerabilities | CRITICAL | ✅ 0 critical (มี 2 high จาก hono indirect) |
| 8 | License Compliance | LOW | ⏭️ SKIP — ยังไม่ติดตั้ง license-checker |
| 9 | Code Review | HIGH | ⏭️ N/A — ต้อง review via GitHub PR |
| 10 | SonarLint | MEDIUM | ⏭️ SKIP — ยังไม่ติดตั้ง |
| 11 | ไม่มี console.log | MEDIUM | ❌ พบ 19 จุดใน production code |
| 12 | Env Variables ครบ | CRITICAL | ⚠️ .env.example ขาด 4 ตัว (Sentry vars) |
| 13 | DB Migration | HIGH | ❌ ใช้ db push ไม่มี migration files |
| 14 | API Error Handling | HIGH | ⚠️ 95% ดี แต่ 4 routes ขาด try/catch |
| 15 | Input Validation | HIGH | ✅ 90%+ routes ใช้ Zod |
| 16 | Image Optimization | MEDIUM | ⚠️ ไม่พบ next/image ใน components |
| 17 | Bundle Size | MEDIUM | ⚠️ shared 102KB, บาง pages ถึง 314KB |
| 18 | Git Hooks | LOW | ❌ ไม่มี Husky / .husky directory |
| 19 | Unused dependencies | MEDIUM | ❌ 7 unused deps + 7 unused devDeps |
| 20 | Circular imports | MEDIUM | ✅ 0 circular dependencies |
| 21 | Secrets in codebase | CRITICAL | ✅ .env อยู่ใน .gitignore, ไม่มี secrets committed |
ผ่าน 6 ข้อ, เตือน 5, ไม่ผ่าน 7, ข้าม 3 → คิดจาก 18 ข้อที่ตรวจได้ = 52%
ที่น่าตกใจคือ build ผ่าน TypeScript ไม่มี error — แต่ ไม่มี test เลย. Unit test มีแค่ 1 ไฟล์ (validations.test.ts) ที่ทดสอบ Zod schema. Component test? ศูนย์. API test? ศูนย์. ทั้งโปรเจกต์.
ZONE 1 — เรื่องที่แก้แล้วอาจพังได้
🔴 ZONE 1 — ต้อง backup ก่อนแก้
| # | ปัญหา | ทำไมเสี่ยง | วิธีแก้ที่ปลอดภัย |
|---|---|---|---|
| 1 | Build FAIL — admin pages หาย | 3 route directories ว่างเปล่า (credits, referrals, settings) ทำให้ Next.js หา page module ไม่เจอ | ลบ empty directories ออก หรือสร้าง page.tsx ให้ครบ |
| 2 | DB ใช้ db push ไม่มี migration | Production deploy ไม่มี migration history — rollback ไม่ได้ schema drift เสี่ยง | สร้าง baseline migration จาก schema ปัจจุบัน แล้วเปลี่ยนมาใช้ prisma migrate |
| 3 | Unit test FAIL 1 ข้อ | registerSchema ไม่ validate confirmPassword — ทำให้ password mismatch หลุดเข้าระบบได้ | เพิ่ม confirmPassword + .refine() ใน Zod schema |
ข้อ 1 คือตัวอย่างที่ดีว่า "build ผ่าน" ≠ "ทุกอย่างดี". dev server ทำงานปกติ แต่ production build พัง เพราะ Next.js collecting page data จะ scan ทุก directory — ถ้าเจอ folder ว่าง ก็ error.
ZONE 2 — Quick Wins แก้ได้ทันที
🟢 ZONE 2 — แก้ได้เลย ไม่กระทบระบบ
| # | ปัญหา | วิธีแก้ | ผลที่ได้ |
|---|---|---|---|
| 1 | Prettier 188 ไฟล์ไม่ผ่าน | pnpm format (prettier --write .) | Code style สม่ำเสมอทั้ง project |
| 2 | ESLint 16 warnings | ลบ unused imports / prefix _ | Clean lint output, ลด noise |
| 3 | console.log 19 จุด | ลบ debug logs ใน workers, webhooks, API routes | Production ไม่ print ข้อมูลไม่จำเป็น |
| 4 | 7 unused dependencies | pnpm remove date-fns docx googleapis pdfkit react-dropzone | node_modules เบาลง, install เร็วขึ้น |
| 5 | ไม่มี Git Hooks | npx husky init + pre-commit (lint, format, tsc) | ป้องกัน broken code เข้า repo |
| 6 | .env.example ไม่ sync | เพิ่ม GEMINI_API_KEY ใน .env.example | Developer ใหม่ onboard ง่ายขึ้น |
| 7 | API routes ขาด try/catch | เพิ่ม try/catch + return 500 ใน 4 routes | ป้องกัน unhandled errors ใน production |
| 8 | hono vulnerabilities (2 high) | pnpm update หรือ overrides ใน package.json | ลด vulnerability count |
Quick wins 8 ข้อนี้ ทำได้ภายใน 30 นาที. ส่วนใหญ่แค่รัน command เดียว — pnpm format แก้ 188 ไฟล์ทีเดียว, pnpm remove ลบ unused deps ทีเดียว.
188 ไฟล์ format ไม่ผ่าน — แต่แก้ด้วย command เดียว. นี่คือสิ่งที่ QC Dashboard ช่วยได้: บอกปัญหา + บอกวิธีแก้ + ใช้ AI ทำให้เลย.
AI แก้ทั้งหมด — ผลลัพธ์
สั่ง AI: "ดำเนินการทั้งหมดให้เลย" — เหมือนทุกหมวดที่ผ่านมา.
| # | สิ่งที่ทำ | ก่อน → หลัง |
|---|---|---|
| 1 | ลบ empty admin directories (3 ตัว) | Build FAIL → Build PASS |
| 2 | แก้ registerSchema + confirmPassword | 1 test FAIL → 9/9 tests PASS |
| 3 | Prettier format ทั้ง project | 188 ไฟล์ไม่ผ่าน → 0 |
| 4 | ลบ unused imports (16 warnings) | 16 warnings → 0 |
| 5 | ลบ console.log จาก production code | 19 จุด → 0 |
| 6 | ลบ unused dependencies (5 ตัว) | 7 unused → 2 (ที่ใช้ใน CSS) |
| 7 | Sync .env.example | ขาด GEMINI_API_KEY → ครบ |
| 8 | เพิ่ม try/catch ใน API routes | 4 routes ขาด → ครบทุก route |
คะแนนหลังแก้
| หัวข้อ | คะแนน | ผล |
|---|---|---|
| ESLint 0 errors | ✅ 0 errors 0 warnings | ✅ PASS |
| Prettier format | ✅ 0 files with issues | ✅ PASS |
| TypeScript strict | ✅ 0 errors | ✅ PASS |
| Unit Tests | 9/9 pass | ⚠️ ผ่าน แต่ coverage ต่ำ |
| Component Test | ❌ ยังไม่มี | ❌ ต้องเขียนเพิ่ม |
| API Route Test | ❌ ยังไม่มี | ❌ ต้องเขียนเพิ่ม |
| Dep Vulnerabilities | 0 critical | ✅ PASS |
| console.log | 0 จุด | ✅ PASS |
| Env Variables | .env.example synced | ✅ PASS |
| DB Migration | ยังใช้ db push | ❌ ต้องเปลี่ยนเป็น migrate |
| API Error Handling | ครบทุก route | ✅ PASS |
| Input Validation | Zod + refine | ✅ PASS |
| Unused deps | ลบ 5 ตัว | ✅ PASS |
| Circular imports | 0 | ✅ PASS |
| Secrets in codebase | 0 leaks | ✅ PASS |
ตรวจได้ 18 ข้อ → ผ่าน 12, เตือน 1, ไม่ผ่าน 2 → คิดเป็น ~81% (จาก 52% เพิ่มขึ้น +29%)
สิ่งที่เรียนรู้จากหมวด Development
หมวดนี้สอนบทเรียนสำคัญ: "ทำงานได้" กับ "ทำงานดี" ต่างกันมาก. Code อาจ build ผ่าน deploy ได้ ไม่มี TypeScript error สักตัว — แต่ข้างในอาจมี 188 ไฟล์ที่ format ไม่ตรง, 19 จุดที่ debug log หลุดไป production, และ 7 dependencies ที่ไม่ได้ใช้แต่โหลดมาทุก install.
ที่น่าสนใจคือ ปัญหาส่วนใหญ่แก้ได้ด้วย command เดียว. Prettier format ทั้ง project ใช้เวลาไม่ถึงวินาที. ลบ unused deps ก็แค่ pnpm remove. แต่ถ้าไม่มี checklist บอก — จะไม่มีวันรู้ว่ามีปัญหา.
สิ่งที่ AI ทำไม่ได้ในรอบนี้: เขียน test. Component test กับ API test ต้องคนเขียน logic ว่า "ต้องทดสอบอะไร". AI ช่วย generate test boilerplate ได้ แต่ test ที่มีค่าต้องมาจากคนที่เข้าใจ business logic. นี่คือ 2 ข้อที่ยังไม่ผ่าน — และต้องลงแรงจริง.
Deploy & Monitor — จาก 50% ถึง 90% ด้วย AI
ทำไม Deploy ถึงเป็นด่านสุดท้ายที่คนส่วนใหญ่ตก?
Code สวย, test ผ่าน, performance ดี — แต่พอจะ deploy จริง กลับพังตั้งแต่ขั้นตอนแรก. Build ไม่ผ่าน, env vars ผิด, DNS ยังไม่ชี้, migration ไม่มี — ปัญหาที่ไม่เคยเจอตอน dev.
หมวด Deploy & Monitor ไม่ได้แค่ "กด deploy แล้วจบ" — มันคือการตรวจสอบว่า ระบบพร้อมสำหรับ production จริงไหม ตั้งแต่ build, database, DNS, SSL, monitoring ไปจนถึง backup strategy.
50% ของ Deploy checklist ไม่ผ่าน — ทั้งที่ dev server ทำงานปกติมาตลอด. Production กับ Development เป็นคนละโลก.
17 ข้อตรวจอะไรบ้าง?
[ROLE] คุณเป็น Senior QC Engineer ตรวจสอบ web project [PROJECT] Framework: nextjs | Path: ./ [SCOPE] ตรวจสอบอย่างเดียว ห้ามแก้ไขไฟล์ ตรวจ "🚀 Deploy & Monitor" — 17/17 ข้อ: 1. [CRITICAL] Production Build 0 Errors 2. [CRITICAL] Env Variables Production ครบ 3. [CRITICAL] Database Migration Applied 4. [HIGH] DNS Configuration OK 5. [HIGH] SSL Certificate Valid 6. [CRITICAL] Smoke Test: Homepage 7. [CRITICAL] Smoke Test: Login 8. [CRITICAL] Smoke Test: Core Features 9. [HIGH] API Health Check 10. [HIGH] Sentry Error Rate Normal 11. [MEDIUM] UptimeRobot Green 12. [MEDIUM] PageSpeed Maintained 13. [MEDIUM] SSL Labs A+ 14. [MEDIUM] Mozilla Observatory A+ 15. [MEDIUM] Search Console: No Errors 16. [HIGH] Backup Strategy Verified 17. [HIGH] Rollback Plan Documented
17 ข้อ แบ่งเป็น: 6 CRITICAL, 6 HIGH, 5 MEDIUM. ข้อสำคัญ — 7 ข้อ (#5, #8, #11-15) ต้อง deployed URL ถึงจะตรวจได้ ดังนั้น AI ตรวจได้แค่ 10/17 ข้อ ที่เหลือต้องตรวจหลัง deploy.
คะแนนก่อนแก้ — รายข้อ
| # | หัวข้อ | Severity | ผล |
|---|---|---|---|
| 1 | Production Build 0 Errors | CRITICAL | ✅ pnpm build สำเร็จ |
| 2 | Env Variables Production ครบ | CRITICAL | ⚠️ มี 36 ตัว แต่ค่ายังเป็น dev (localhost, development) |
| 3 | Database Migration Applied | CRITICAL | ❌ ไม่มี prisma/migrations/ — ใช้ db push อยู่ |
| 4 | DNS Configuration OK | HIGH | ❌ www.scanlyiq.com → NXDOMAIN ยังไม่ได้ตั้ง |
| 5 | SSL Certificate Valid | HIGH | ⏭️ SKIP — ต้อง deployed URL |
| 6 | Smoke Test: Homepage | CRITICAL | ✅ static pages render ได้จาก build |
| 7 | Smoke Test: Login | CRITICAL | ✅ /login เป็น static page |
| 8 | Smoke Test: Core Features | CRITICAL | ⏭️ SKIP — ต้อง running server + DB |
| 9 | API Health Check | HIGH | ⚠️ มี /api/health แต่ไม่เช็ค DB/Redis จริง |
| 10 | Sentry Error Rate | HIGH | ⚠️ Config มีครบ แต่ SENTRY_DSN ว่าง — ยังไม่ได้ตั้งค่า |
| 11 | UptimeRobot Green | MEDIUM | ⏭️ SKIP — ต้อง deployed URL |
| 12 | PageSpeed Maintained | MEDIUM | ⏭️ SKIP — ต้อง deployed URL |
| 13 | SSL Labs A+ | MEDIUM | ⏭️ SKIP — ต้อง deployed URL |
| 14 | Mozilla Observatory A+ | MEDIUM | ⏭️ SKIP — ต้อง deployed URL |
| 15 | Search Console: No Errors | MEDIUM | ⏭️ SKIP — ต้อง verified property |
| 16 | Backup Strategy Verified | HIGH | ✅ Documented ครบ — DB daily, uploads weekly, restore procedure |
| 17 | Rollback Plan Documented | HIGH | ⚠️ มี backup/restore แต่ไม่มี Dockerfile — rollback ยาก |
ตรวจได้ 10 ข้อ → ผ่าน 4, เตือน 3, ไม่ผ่าน 2, ข้าม 1 → คิดเป็น 50%
ที่น่าสนใจคือ Backup Strategy ผ่าน — ใน deployment guide มี script สำเร็จรูปสำหรับ backup DB รายวัน, backup uploads รายสัปดาห์, remote backup, และ restore procedure ครบถ้วน. แต่ปัญหาคือ ยังไม่มี Dockerfile — แผน deploy ที่เขียนไว้หมดอยู่บน Docker แต่ตัว Dockerfile ยังไม่ได้สร้าง.
ZONE 1 — เรื่องที่แก้แล้วอาจพังได้
🔴 ZONE 1 — ต้อง backup ก่อนแก้
| # | ปัญหา | ทำไมเสี่ยง | วิธีแก้ที่ปลอดภัย |
|---|---|---|---|
| 1 | ไม่มี Prisma migrations | db push ใน production อาจทำ data loss — ไม่มี migration history สำหรับ rollback | สร้าง baseline migration: npx prisma migrate diff --from-empty --to-schema-datamodel แล้ว resolve ใน dev ก่อน |
| 2 | Env vars ยังเป็น dev values | Deploy ด้วย NODE_ENV=development + AUTH_URL=localhost จะ expose ข้อมูลและ auth ไม่ทำงาน | สร้าง .env.production แยก — ตรวจทุกค่าก่อน deploy |
ข้อ 1 คือปัญหาที่ร้ายแรงที่สุด — db push ทำงานได้ดีตอน dev แต่ใน production มันอาจ drop column หรือ recreate table ถ้า schema เปลี่ยน. Prisma Migrate ป้องกันเรื่องนี้ด้วย migration history ที่ track ทุกการเปลี่ยนแปลง.
ZONE 2 — Quick Wins แก้ได้ทันที
🟢 ZONE 2 — แก้ได้เลย ไม่กระทบระบบ
| # | ปัญหา | วิธีแก้ | ผลที่ได้ |
|---|---|---|---|
| 1 | DNS ยังไม่ได้ตั้ง | เพิ่ม A record → VPS IP ที่ DNS provider | เข้าถึง domain ได้ |
| 2 | Health endpoint ไม่เช็ค DB/Redis | เพิ่ม Prisma $queryRaw + Redis ping ใน /api/health | Monitoring ตรวจจับ outage ได้จริง |
| 3 | Sentry ยังไม่ได้ตั้งค่า | สร้าง Sentry project + เติม DSN, ORG, PROJECT | Error tracking ทำงานจริง |
| 4 | ไม่มี Dockerfile | สร้าง multi-stage Dockerfile (deps → build → runner) | Deploy ด้วย Docker ได้ + rollback ง่าย |
AI แก้ทั้งหมด — ผลลัพธ์
สั่ง AI: "ดำเนินการทั้งหมดให้เลย"
| # | สิ่งที่ทำ | ก่อน → หลัง |
|---|---|---|
| 1 | สร้าง Prisma baseline migration | ไม่มี migrations/ → 1 baseline (1,068 lines SQL) + resolve applied |
| 2 | ปรับ /api/health | แค่ return "ok" → เช็ค DB ($queryRaw SELECT 1) + Redis ping จริง |
| 3 | สร้าง Dockerfile (multi-stage) | ไม่มี → 3-stage build (deps → build → runner) + standalone output |
| 4 | สร้าง docker-compose.prod.yml | ไม่มี → app + postgres + redis + health checks + volumes |
| 5 | สร้าง .env.production template | ไม่มี → 108 lines พร้อม comments ทุกค่า |
| 6 | แก้ Resend lazy init | Build พังเพราะ Resend API key ว่าง → lazy init ไม่พังตอน build |
คะแนนหลังแก้
| หัวข้อ | คะแนน | ผล |
|---|---|---|
| Production Build | ✅ 0 errors | ✅ PASS |
| Env Variables | .env.production template พร้อม | ✅ PASS |
| DB Migration | baseline applied | ✅ PASS |
| DNS | ยังไม่ได้ตั้ง (ต้องทำเอง) | ❌ ต้องตั้ง A record |
| Smoke Tests (Homepage/Login) | Build ผ่าน + pages render | ✅ PASS |
| API Health Check | เช็ค DB + Redis จริง | ✅ PASS |
| Sentry Config | Config พร้อม รอเติม DSN | ⚠️ ต้องสร้าง project |
| Backup Strategy | Documented ครบ | ✅ PASS |
| Rollback Plan | Dockerfile + docker-compose พร้อม | ✅ PASS |
ตรวจได้ 10 ข้อ → ผ่าน 8, เตือน 1, ไม่ผ่าน 1 → คิดเป็น ~90% (จาก 50% เพิ่มขึ้น +40%)
สิ่งที่เรียนรู้จากหมวด Deploy & Monitor
หมวดนี้มี ข้อจำกัดสำคัญ: 7 ใน 17 ข้อต้อง deployed URL ถึงจะตรวจได้ (SSL Labs, PageSpeed, Mozilla Observatory, UptimeRobot, Search Console, SSL cert, core feature smoke test). ดังนั้น Deploy QC ต้องทำ 2 รอบ — ก่อน deploy (ตรวจจาก code) และหลัง deploy (ตรวจจาก URL จริง).
สิ่งที่ AI ทำได้ดีคือ เตรียม infrastructure — สร้าง Dockerfile, docker-compose, .env template, migration baseline, health endpoint. ทุกอย่างที่ต้อง "สร้างไฟล์" AI ทำได้หมด. แต่สิ่งที่ AI ทำไม่ได้คือ กด deploy จริง — ตั้ง DNS, สร้าง Sentry project, provision VPS ยังต้องทำเอง.
บทเรียนสำคัญ: Resend API key ว่าง = build พัง. Library หลายตัว throw error ตอน instantiate ถ้า API key เป็น empty string — ต้องใช้ lazy initialization (สร้าง instance ตอนเรียกใช้จริง ไม่ใช่ตอน import). เรื่องแบบนี้ไม่มีทาง debug ได้ถ้าไม่ได้ลอง build จริง.
Accessibility — จาก 44% ถึง 100% ด้วย AI
ปัญหา — เว็บ "ใช้ได้" แต่ไม่ "เข้าถึงได้"
Accessibility เป็นหมวดที่ dev มักข้ามเพราะ "ดูด้วยตาก็ปกติ" — แต่พอตรวจจริงด้วย pa11y + Lighthouse กลับพบว่า หน้า Landing ได้แค่ 96%, หน้า Login ได้ 98%. ฟังดูสูง แต่ในมาตรฐาน WCAG AA ต้อง 100% ถึงจะถือว่าผ่าน.
QC Checklist 16 ข้อ ตรวจพบว่า 9 ข้อไม่ผ่าน — ผ่านแค่ 44%.
Prompt ที่ใช้
ตรวจ Accessibility ของเว็บแอป ScanlyIQ ตาม WCAG 2.1 AA: 1. ตรวจ landmark structure — มี main, nav, header ครบไหม 2. ตรวจ skip navigation link 3. ตรวจ aria-label บน icon-only buttons ทุกตัว 4. ตรวจ alt text ของ images ทั้งหมด — ต้อง descriptive 5. ตรวจ touch target ≥ 44px ทุก interactive element 6. ตรวจ focus styles — ทุก element ที่ focus ได้ต้องมี visible indicator 7. ตรวจ color contrast ratio ≥ 4.5:1 (WCAG AA) 8. ตรวจ prefers-reduced-motion support ใช้ pa11y + Lighthouse วัดผลก่อน/หลังแก้
ZONE 1 — AI ตรวจเจอเอง + แก้ได้ทันที (8 ข้อ)
🔴 ZONE 1 — ปัญหาที่ AI ตรวจเจอจาก prompt
| # | ปัญหา | ความรุนแรง | วิธีแก้ |
|---|---|---|---|
| 1 | ไม่มี <main> landmark ใน auth layout | 🔴 สูง | เปลี่ยน <div> → <main id="main-content"> |
| 2 | ไม่มี Skip Navigation Link | 🔴 สูง | เพิ่ม sr-only link + focus:not-sr-only ใน root layout |
| 3 | Icon buttons ไม่มี aria-label (bell + user menu) | 🟡 กลาง | เพิ่ม aria-label="การแจ้งเตือน" / "เมนูผู้ใช้" ใน topbar |
| 4 | Alt text ไม่ descriptive ในหน้า slip-ocr | 🟡 กลาง | เปลี่ยนจาก "image" → อธิบายเนื้อหาจริง + aria-label ทุกปุ่ม |
| 5 | Progress dots touch target 8px | 🟡 กลาง | เพิ่ม padding ให้ clickable area = 44px (WCAG minimum) |
| 6 | DateCell ไม่มี focus style | 🟡 กลาง | เพิ่ม focus-visible:ring-2 ใน field-cell.tsx |
| 7 | Color contrast ไม่พอ ใน trusted-by section | 🟡 กลาง | text-slate-500 → text-slate-400 (contrast 4.04:1 → ~5.6:1) |
| 8 | ไม่รองรับ prefers-reduced-motion | 🟡 กลาง | เพิ่ม @media (prefers-reduced-motion: reduce) ใน globals.css |
ZONE 2 — Lighthouse ตรวจเจอเพิ่ม
🟢 ZONE 2 — ปัญหาที่เครื่องมือจับได้หลังแก้ ZONE 1
| # | ปัญหา | วิธีแก้ | ผลที่ได้ |
|---|---|---|---|
| 1 | Disabled link contrast ต่ำ — "ลืมรหัสผ่าน?" สีจางบน dark bg (contrast 2.33:1) | เพิ่ม aria-disabled="true" + tabIndex={-1} + เปลี่ยนสีให้ contrast ≥ 4.5:1 | Lighthouse Login 98% → 100% |
AI แก้ทั้งหมด — ผลลัพธ์
สั่ง AI: "ตรวจ Accessibility ตาม WCAG AA ทั้งหมด — แก้ให้เลย"
| # | ไฟล์ที่แก้ | ก่อน → หลัง |
|---|---|---|
| 1 | layout.tsx (auth) | ไม่มี main landmark → <main id="main-content"> |
| 2 | layout.tsx (root) | ไม่มี skip nav → sr-only link โผล่ตอน focus |
| 3 | topbar.tsx | icon buttons ไม่มี label → aria-label ครบ 2 ปุ่ม |
| 4 | slip-ocr page.tsx | alt="image" → descriptive alt + aria-labels + touch target 44px |
| 5 | field-cell.tsx | ไม่มี focus ring → focus-visible:ring-2 ring-blue-500 |
| 6 | trusted-by-section.tsx | contrast 4.04:1 → ~5.6:1 (text-slate-400) |
| 7 | globals.css | ไม่มี reduced-motion → ปิด animation + transition ทั้งหมด |
| 8 | login/page.tsx | disabled link contrast 2.33:1 → ≥4.5:1 + aria-disabled |
คะแนนหลังแก้
| เครื่องมือ | หน้า | ก่อน | หลัง |
|---|---|---|---|
| Lighthouse | Login | 98% | 100% |
| Lighthouse | Landing | 96% | 100% |
| pa11y | Login | 1 error | 0 errors |
| pa11y | Landing | 1 error | 0 errors |
| TypeScript | ทั้ง project | 0 errors | 0 errors |
ตรวจได้ 16 ข้อ → ผ่านทั้ง 16 ข้อ → 100% (จาก 44% เพิ่มขึ้น +56%)
สิ่งที่เรียนรู้จากหมวด Accessibility
Touch target ขนาด 8px ใช้ mouse คลิกได้ แต่ใช้นิ้วจิ้มไม่ได้ — progress dots ที่เล็กกว่า 44px ไม่ผ่าน WCAG minimum. ทั้งที่ดูด้วยตาก็ "กดได้ปกติ" แต่พอทดสอบบนมือถือจริง แทบจิ้มไม่โดน. เรื่องนี้ตรวจด้วย AI ได้เร็วมาก — แค่ถามว่า "interactive element ไหนที่ touch target ต่ำกว่า 44px" ก็ได้คำตอบทันที.
อีกเรื่องที่น่าสนใจ: Lighthouse score 96-98% ฟังดูดี แต่ยังไม่ผ่าน WCAG AA. ปัญหาที่ทำให้ไม่ผ่านคือ color contrast ของ disabled link (2.33:1 ขณะที่ต้อง ≥4.5:1). Element ที่ "ปิดการใช้งาน" ก็ยังต้อง contrast เพียงพอ — เพราะผู้ใช้ screen reader ยังเห็น element นั้นอยู่.
บทเรียนสำคัญ: prefers-reduced-motion ลืมได้ง่าย — ต้องเพิ่ม @media rule ใน CSS เพื่อปิด animation/transition ให้ผู้ใช้ที่ต้องการ. ใช้ AI สร้าง CSS rule นี้ได้ใน 10 วินาที แต่ถ้าลืมก็ไม่มีทาง WCAG compliant.
SEO & Standards — จาก 38% ถึง 91% ด้วย AI
ปัญหา — เว็บ "มีอยู่" แต่ Google หาไม่เจอ
SEO & Standards เป็นหมวดสุดท้ายที่ตรวจ — และเป็นหมวดที่ปัญหาเยอะที่สุด. Lighthouse SEO score ของหน้า Landing ได้แค่ 91% ซึ่งฟังดูดี แต่พอดูรายละเอียดจริงพบว่า: sub-pages ไม่มี meta title เลย, ไม่มี OG image, ไม่มี structured data, ไม่มี sitemap, ไม่มี robots.txt.
QC Checklist 21 ข้อ ตรวจพบว่า 13 ข้อไม่ผ่าน — ผ่านแค่ 38%.
Prompt ที่ใช้
ตรวจ SEO & Web Standards ของเว็บแอป ScanlyIQ ตาม checklist: 1. ตรวจ meta title + description ทุกหน้า (unique, ความยาวเหมาะสม) 2. ตรวจ Open Graph tags — og:title, og:description, og:image 3. ตรวจ Twitter Card tags — twitter:card, twitter:image 4. ตรวจ Structured Data (JSON-LD) — Organization, WebApplication, FAQPage 5. ตรวจ Canonical URLs + metadataBase 6. ตรวจ robots.txt + sitemap.xml 7. ตรวจ Semantic HTML — heading hierarchy (H1 → H2 → H3 ไม่ข้าม) 8. ตรวจ Image alt text ครบทุกรูป 9. วัด Lighthouse SEO score ก่อน/หลังแก้ ใช้ Lighthouse + Google Rich Results Test ตรวจ
ZONE 1 — AI ตรวจเจอเอง + แก้ได้ทันที (13 ข้อ)
🔴 ZONE 1 — ปัญหาที่ AI ตรวจเจอจาก prompt
| # | ปัญหา | ความรุนแรง | วิธีแก้ |
|---|---|---|---|
| 1 | Sub-pages ไม่มี meta title — Login, Register, Pricing, Dashboard | 🔴 สูง | เพิ่ม metadata export ทุก page (title + description) |
| 2 | ไม่มี OG image — share link แล้วไม่มีรูป preview | 🔴 สูง | เพิ่ม openGraph config + og:image ใน root layout |
| 3 | ไม่มี Twitter Card | 🟡 กลาง | เพิ่ม twitter: { card: "summary_large_image" } ใน metadata |
| 4 | ไม่มี Structured Data — Google ไม่รู้จักเว็บ | 🔴 สูง | เพิ่ม JSON-LD: Organization + WebApplication + FAQPage schemas |
| 5 | ไม่มี metadataBase — canonical URLs ไม่สมบูรณ์ | 🟡 กลาง | เพิ่ม metadataBase: new URL("https://scanlyiq.com") ใน root layout |
| 6 | ไม่มี robots.txt | 🟡 กลาง | สร้าง src/app/robots.ts — Allow all + link to sitemap |
| 7 | ไม่มี sitemap.xml | 🔴 สูง | สร้าง src/app/sitemap.ts — auto-generate จาก routes |
| 8 | Heading hierarchy ข้ามระดับ — H1 → H3 (ข้าม H2) | 🟡 กลาง | แก้ heading tags ให้เรียงลำดับถูกต้อง |
| 9 | Landing page ไม่มี lang attribute | 🟡 กลาง | เพิ่ม lang="th" ใน root layout |
| 10 | API routes ไม่มี force-dynamic — build fail ตอน collect page data | 🔴 สูง | เพิ่ม export const dynamic = "force-dynamic" ใน API routes ที่ใช้ Resend |
| 11 | IORedis type error ตอน build | 🔴 สูง | แก้ dynamic import + type assertion ใน health route |
| 12 | Dashboard pages ไม่มี metadata | 🟡 กลาง | เพิ่ม metadata export ให้ทุก dashboard page (slip-ocr, transcription, projects ฯลฯ) |
| 13 | FAQ section ไม่มี FAQPage schema | 🟡 กลาง | เพิ่ม JSON-LD FAQPage ใน landing page FAQ section |
ZONE 2 — ต้องทำเอง (Manual)
🟢 ZONE 2 — ต้อง deploy + ตั้งค่าภายนอก
| # | รายการ | เหตุผลที่ AI ทำไม่ได้ | สถานะ |
|---|---|---|---|
| 1 | Google Search Console — verify ownership | ต้อง login Google account + verify domain | ⚠️ ต้องทำเอง |
| 2 | OG image file จริง — ต้อง design + upload | AI สร้าง config ได้แต่ไม่มีรูปจริงใน public/ | ⚠️ ต้อง upload รูป |
AI แก้ทั้งหมด — ผลลัพธ์
สั่ง AI: "ตรวจ SEO ทั้งหมด — meta tags, structured data, sitemap, robots.txt — แก้ให้เลย"
| # | สิ่งที่ทำ | ก่อน → หลัง |
|---|---|---|
| 1 | Meta titles ทุกหน้า | แค่ Home มี title → ทุกหน้ามี unique title + description |
| 2 | Open Graph tags | ไม่มีเลย → og:title, og:description, og:image ครบ |
| 3 | Twitter Card | ไม่มี → summary_large_image ทุกหน้า |
| 4 | JSON-LD Structured Data | ไม่มี → Organization + WebApplication + FAQPage schemas |
| 5 | robots.ts | ไม่มี → Allow all crawlers + sitemap link |
| 6 | sitemap.ts | ไม่มี → Auto-generate จาก routes (/, /login, /register, /pricing) |
| 7 | metadataBase | ไม่มี → canonical URLs สมบูรณ์ |
| 8 | force-dynamic on API routes | Build fail ตอน collect data → Build compile ผ่าน |
คะแนนหลังแก้
| เครื่องมือ | หน้า | ก่อน | หลัง |
|---|---|---|---|
| Lighthouse SEO | Landing (/) | 91% | 100% |
| Lighthouse SEO | Login | ไม่มี title | มี title + meta ครบ |
| Lighthouse SEO | Pricing | ไม่มี title | มี title + meta ครบ |
| Structured Data | Landing | ไม่มี | 3 schemas (Organization, WebApplication, FAQPage) |
| TypeScript | ทั้ง project | 0 errors | 0 errors |
| All pages HTTP | login, register, pricing, home | 200 | 200 |
ตรวจได้ 21 ข้อ → ผ่าน 19 ข้อ, รอ manual 2 ข้อ → คิดเป็น ~91% (จาก 38% เพิ่มขึ้น +53%)
สิ่งที่เรียนรู้จากหมวด SEO & Standards
Structured Data (JSON-LD) ทำให้ Google "เข้าใจ" เว็บ — ไม่ใช่แค่ crawl ได้. Organization schema บอก Google ว่าเว็บนี้เป็นของบริษัทอะไร, WebApplication บอกว่าเป็น SaaS product, FAQPage ทำให้คำถามที่พบบ่อยขึ้น Rich Snippets ใน search results. ทั้ง 3 schemas นี้ AI สร้างให้ได้ภายใน 1 นาที — แต่ถ้าไม่มี Checklist ก็ไม่มีทางรู้ว่าต้องทำ.
อีกปัญหาที่ AI ช่วยได้มาก: Build fail จาก Resend API key ว่าง. Next.js พยายาม collect page data ตอน build ทำให้ API routes ถูก instantiate — ถ้า library throw error ตอน constructor (เช่น Resend ต้องมี API key) build จะพังทั้งหมด. วิธีแก้คือเพิ่ม export const dynamic = "force-dynamic" ให้ Next.js ข้าม page data collection. เรื่องนี้ AI debug ได้ทันทีเพราะเห็น error stack trace.
บทเรียนสำคัญ: SEO ที่ "ดูเหมือนดี" (91%) อาจพลาดเรื่องสำคัญ — Lighthouse SEO score สูงไม่ได้แปลว่า Google เข้าใจเว็บ. ต้องมี structured data, sitemap, robots.txt, unique meta titles ทุกหน้า. ถ้าใช้แค่ Lighthouse วัดโดยไม่มี Checklist จะพลาดเรื่อง structured data และ sitemap ทั้งหมด.
สรุปผลรวม — 8 หมวด ครบ 100%
ผลลัพธ์ทั้งหมด
| หมวด | ก่อน | หลัง | เพิ่มขึ้น |
|---|---|---|---|
| Functional Testing (19 ข้อ) | 56% | 87% | +31% |
| Planning (10 ข้อ) | 33% | 85% | +52% |
| Security (20 ข้อ) | 71% | 100% | +29% |
| Performance (19 ข้อ) | 45% | 82% | +37% |
| Development (21 ข้อ) | 52% | 81% | +29% |
| Deploy & Monitor (17 ข้อ) | 50% | 90% | +40% |
| Accessibility (16 ข้อ) | 44% | 100% | +56% |
| SEO & Standards (21 ข้อ) | 38% | 91% | +53% |
| รวม 8 หมวด (163 ข้อ) | 49% | 89% | +40% |
สิ่งที่เรียนรู้จากการตรวจ QC-QA ด้วย AI ทั้ง 8 หมวด
AI ทำ 80% ได้เลย
จาก 163 ข้อ AI ตรวจเจอและแก้เองได้ประมาณ 130 ข้อ — เหลือแค่ ~33 ข้อที่ต้องทำ manual (deploy, DNS, third-party services)
8 หมวด ใน 1 วัน
ถ้าคนตรวจเอง 163 ข้อ ใช้เวลา 3-5 วัน. ใช้ AI ตรวจ + แก้ ทั้ง 8 หมวดเสร็จภายในวันเดียว
Checklist สำคัญกว่า Tools
Lighthouse ให้ score สูงแต่พลาดเรื่อง structured data, sitemap, migration baseline. Checklist 163 ข้อ ตรวจได้ครอบคลุมกว่า
ZONE 1 + ZONE 2 = ครบ
ทุกหมวดมี 2 zones: ZONE 1 AI ทำได้เลย, ZONE 2 ต้อง manual. รู้ว่าอะไรต้องทำเองช่วยวางแผนได้ดีขึ้น
ครบทุกหมวดแล้ว — 8 หมวด, 163 ข้อ, จาก 49% เป็น 89%. ทุก prompt และ checklist ที่ใช้มีอยู่ใน QC Dashboard พร้อมใช้ทันที.
ลองใช้ Enterprise 360 QC-QA Tools ได้เลย
236 Prompts, 32 Tools, 195 Checklist — ครบ 8 หมวด พร้อมใช้ทันที ไม่ต้อง install
เปิด QC Dashboard →ชอบบทความนี้ใช่ไหม?
สมัครสมาชิก Idea2Level เพื่อเข้าถึง Content, Template และ Community คุณภาพสูง
สมัครสมาชิกบทความที่เกี่ยวข้อง
สร้าง idea2logic.com ด้วย AI — เปิดโครงสร้าง 30+ หน้า 40+ API ทั้งระบบ
สร้าง idea2logic.com ทั้งระบบด้วย AI — 30+ หน้า, 40+ API, 14 database tables ค่า server ไม่ถึง 1,000 บาท/เดือน บทความนี้เปิดโครงสร้างทั้งหมดด้วย Interactive Diagram
สั่ง AI วาง DevOps Infrastructure ครบ 12 Phase — จาก Zero ถึง Production-Ready
ออกแบบ DevOps Infrastructure ทั้งระบบด้วย AI ครอบคลุม GitLab, CI/CD, Monitoring, Backup, Security, Incident Response ครบ 12 Phase — ไม่เขียน code เอง ได้แผนพร้อมใช้ใน 1 วัน
สร้างระบบ QC-QA ครบ 208 หัวข้อด้วย AI — ใช้เวลาไม่ถึง 2 ชั่วโมง
เล่าเรื่องการใช้ Cursor + Claude สร้าง Enterprise 360 QC-QA Dashboard ที่มี checklist 208 ข้อ, เครื่องมือฟรี 25 ตัว, Health Score, Quality Gate — ทั้งหมดใน single HTML file ใช้เวลาไม่ถึง 2 ชั่วโมง