QA คือการวางมาตรฐานและกระบวนการเพื่อ “ป้องกัน” ข้อบกพร่องตั้งแต่ก่อนลงมือพัฒนา ส่วน QC คือการทดสอบ/ตรวจสอบงานที่สร้างแล้วเพื่อ “ค้นหา” ข้อบกพร่องให้เจอเร็วที่สุด ในโปรเจกต์เว็บควรทำทั้งคู่ควบกันตั้งแต่วันแรกถึงวันปล่อยจริงและหลังปล่อย
QA vs QC ในงานพัฒนาเว็บไซต์: ต่างกันยังไง ทำอะไร ใครรับผิดชอบ
สำหรับ PM/Lead/Marketing–Tech ความเข้าใจผิดทั่วไปคือ “มีการเทสต์แล้ว = มี QA” ทั้งที่จริง QA เน้นป้องกันผ่านมาตรฐาน/เวิร์กโฟลว์ ส่วน QC เน้นตรวจจับผ่านการเทสต์/รีวิวผลลัพธ์ บทความนี้สรุปให้ทีมจัดระบบได้ภายใน 14 วัน
ตารางสรุป: ความแตกต่างหลัก
| หัวข้อ |
QA (Quality Assurance) |
QC (Quality Control) |
ผลต่อโปรเจกต์เว็บ |
| เป้าหมาย |
ป้องกันข้อผิดพลาดเชิงกระบวนการ |
ค้นหา/ยืนยันข้อผิดพลาดในงานจริง |
ลด rework และบั๊กหลุดสู่โปรดักชัน |
| เวลา |
ก่อนเริ่ม/ระหว่างพัฒนา (proactive) |
ระหว่าง/ก่อนปล่อย/หลังปล่อย (reactive) |
ยิ่งเริ่ม QA เร็ว ต้นทุนแก้ไขยิ่งถูก |
| กิจกรรมหลัก |
มาตรฐานโค้ด, DoD/Acceptance, Test strategy, Template/Checklist, CI policy |
Unit/Integration/E2E, A11y, Performance (CWV), Security, SEO/Content review |
คุณภาพสม่ำเสมอ + ลดความเสี่ยงก่อน go-live |
| ผู้รับผิดชอบ |
QA Lead/PM/Tech Lead (ทั้งทีมมีส่วนร่วม) |
QA/Test Engineer/Developer/Content/SEO |
ความชัดเจนบทบาท ลดช่องว่างงานค้าง |
| เอกสาร/ผลลัพธ์ |
Test plan, Definition of Done, Coding standards, Workflow |
Bug report, Test report, Lighthouse/A11y/OWASP findings |
ติดตามย้อนกลับได้ วัดผลปรับปรุงต่อเนื่อง |
ตัวอย่าง “งานจริง” ที่แบ่ง QA กับ QC ชัดเจน
| หมวดงานเว็บ |
QA: ป้องกัน |
QC: ตรวจจับ |
เครื่องมือที่แนะนำ |
| ประสิทธิภาพ (Core Web Vitals) |
กำหนดงบภาพ, preload LCP, หลัก no heavy 3rd-party |
Lighthouse run, CrUX/INP monitor ก่อนปล่อย |
Chrome Lighthouse, PageSpeed/API, GSC |
| การเข้าถึง (A11y) |
Design tokens/คอนทราสต์, โครงหัวข้อ, โฟกัสลำดับ |
เครื่องมือสแกน + manual keyboard/screen-reader |
axe DevTools, Lighthouse A11y, WCAG checklist |
| ความปลอดภัย |
Policy headers, auth flow, input validation, secret mgmt |
Security test ตาม OWASP, DAST/SAST เบื้องต้น |
OWASP WSTG, ZAP, Snyk/GitHub Dependabot |
| SEO & โครงข้อมูล |
กฎตั้ง Title/Meta/Canonical, สคีมา, hreflang |
ตรวจ indexability, structured data, ลิงก์เสีย |
Search Console, Rich Results Test, crawlers |
| คอนเทนต์ & ภาษาดีไซน์ |
Tone/Voice guide, microcopy pattern, IA/เมนู |
Content QA (typo/ความสอดคล้อง), CTA clicks |
Checklist ทีมคอนเทนต์, GA4 events |
| ฟังก์ชัน/การทำงาน |
Acceptance Criteria, contract API/mock |
Unit/Integration/E2E (สำคัญ: ฟอร์ม/เช็คเอาต์) |
Jest, Playwright/Cypress, Postman |
Deliverables & เจ้าของงาน (ทำให้เห็น–วัดได้)
| Deliverable |
เจ้าของ |
คำอธิบายสั้น |
สถานะสำเร็จ |
| Test Strategy + DoD |
QA Lead/PM |
กำหนดช่วงการเทสต์, scope, เกณฑ์ผ่าน |
เอกสารลงรีโป/Confluence และสื่อสารทีม |
| Coding/Content Standards |
Tech Lead/Content Lead |
ESLint/Stylelint, โทนข้อความ, สคีมา |
มี linter/PR check + template |
| Automated Test Pipelines |
Dev/QA |
Unit/Integration/E2E + Lighthouse CI |
รันใน CI ทุก PR + รายงาน |
| Release Checklist |
PM |
SEO/A11y/Security/Perf พร้อมหลักฐาน |
เช็กลิสต์ผ่าน 100% ก่อน deploy |
ตัวอย่าง Workflow: รัน Playwright + Lighthouse CI บน GitHub Actions
name: web-qa-qc
on: [pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 20 }
- run: npm ci
- run: npx playwright install --with-deps
- run: npm run test:unit
- run: npm run test:e2e
- name: Lighthouse CI
run: |
npm i -g @lhci/cli
lhci autorun --upload.target=temporary-public-storage
HowTo: ตั้ง “QA + QC สำหรับเว็บ” ให้ทำงานได้ใน 14 วัน
- วัน 1–2: ระบุเป้าหมายคุณภาพ (CWV, A11y, SEO, Security) และเกณฑ์ผ่าน (DoD)
- วัน 3–5: ตั้งโครง CI + unit/integration/E2E, กำหนดมาตรฐานโค้ด/คอนเทนต์
- วัน 6–8: ทำ test data/mock, เขียนเคสสำคัญ (ฟอร์ม/เช็คเอาต์/SSO)
- วัน 9–11: เพิ่ม Lighthouse/A11y scan + OWASP checks ที่เสี่ยงสูง
- วัน 12–13: Dry-run release checklist + แก้ประเด็นคอขวด
- วัน 14: Go/No-go review พร้อมหลักฐานครบชุด
บริการที่เกี่ยวข้อง (Internal Links)
อ่านต่อ (บทความที่เกี่ยวข้อง)
อ้างอิงภายนอก (มาตรฐาน/แนวทาง)
- ASQ — ความต่าง Quality Assurance vs Quality Control: asq.org
- ISO/IEC 25010 — Software Product Quality Model: iso.org
- W3C/WAI — WCAG 2.2: w3.org
- OWASP — Web Security Testing Guide: owasp.org
- Chrome for Developers — Lighthouse Overview/CI: developer.chrome.com
FAQ (People Also Ask)
QA กับ QC ต่างกันสั้น ๆ ยังไง?
QA คือกระบวนการป้องกันข้อบกพร่องตั้งแต่ต้นน้ำ ส่วน QC คือการทดสอบ/ตรวจจับข้อบกพร่องในงานที่สร้างแล้ว เพื่อยืนยันว่าตรงตามข้อกำหนด
ทีมเล็กควรเริ่มตรงไหนก่อน?
นิยาม DoD + ตั้ง CI รัน Unit/E2E + Lighthouse/A11y scan สำหรับหน้าเงิน แล้วเพิ่มขอบเขตตามความเสี่ยง
ต้องอิงมาตรฐานไหนบ้าง?
อย่างน้อยอ้างอิง ISO/IEC 25010 (คุณภาพซอฟต์แวร์), WCAG 2.2 (การเข้าถึง), OWASP WSTG (ความปลอดภัย) และใช้ Lighthouse วัดประสิทธิภาพ
อัปเดตล่าสุด: 21 Aug 2025
เกี่ยวกับผู้เขียน
Vision X Brain Team — ทีม Website/SEO/CRO & Webflow สำหรับธุรกิจไทย เราจัดระบบ QA/QC ให้เว็บผ่าน CWV, A11y, Security และ SEO พร้อมหลักฐานตรวจสอบได้ ดูงานบริการได้ที่ บริการทั้งหมด
