การทดสอบซอฟต์แวร์ และการประกันคุณภาพ (QA)
สำหรับแพลตฟอร์ม Grocery POS
สัปดาห์ที่ 12 เปลี่ยนโฟกัสจาก “ซอฟต์แวร์ที่รันได้บนเครื่องผู้พัฒนา” สู่ “ระบบขายหน้าร้านที่เชื่อถือได้ในสถานการณ์จริง” โดยออกแบบการทดสอบตั้งแต่ Unit Test, Integration Test, Test Case ที่เป็นระบบ ไปจนถึงการทดสอบการใช้งานกับผู้ใช้กลุ่มเป้าหมายและการวัดผล QA
เกณฑ์การประเมินด้านที่ 4: ความครอบคลุมของการทดสอบและ QA (สัปดาห์ที่ 12)
| ระดับคะแนน | ช่วงคะแนน | หลักฐานที่ต้องแสดงในการตรวจประเมิน |
|---|---|---|
| ดีเยี่ยม | 22–25 | ออกแบบ Test Cases ครอบคลุมทั้ง Unit Test และ Integration Test มีบันทึก Test Results Log ความครอบคลุมสูง และมีรายงาน Usability Testing จากผู้ใช้จริงพร้อมแนวทางปรับปรุงที่ชัดเจน |
| ดี | 18–21 | มี Test Cases และ Test Results Log ครอบคลุมฟังก์ชันหลักของระบบ มีการสรุปผล Usability Testing เบื้องต้น |
| พอใช้ | 14–17 | ทดสอบเฉพาะฟังก์ชันพื้นฐาน ขาด Test Cases ที่เป็นระบบ หรือรายงาน Usability Testing มีรายละเอียดไม่ครบถ้วน |
| ปรับปรุง | 0–13 | ขาดการทดสอบตามหลักการ QA ไม่มีเอกสาร Test Cases หรือผลการทดสอบระบบ |
หลังจบคาบเรียนนี้นักศึกษาจะสามารถ:
โครงสร้างฐานข้อมูลและจุดเสี่ยง ของแพลตฟอร์ม Grocery POS
จากโครงสร้างโครงงานปี 2 ระบบ POS ร้านค้าปลีกมีองค์ประกอบที่พึ่งพากันสูง ตั้งแต่หน้าจอขาย ฐานข้อมูลเชิงสัมพันธ์ 6 ตารางหลัก ไปจนถึงการตัดสต็อกแบบเรียลไทม์ คลิกแต่ละชั้นด้านซ้ายเพื่อสำรวจความเสี่ยงและประเภทการทดสอบที่ต้องใช้
หน้าจอรับออเดอร์แคชเชียร์ (POS Order Screen)
จุดสัมผัสแรกของผู้ใช้ (แคชเชียร์ร้านชำ/มินิมาร์ท) ต้องรองรับการสแกนบาร์โค้ดต่อเนื่อง การค้นหาสินค้าไม่มีบาร์โค้ด (เช่น ผัก ผลไม้) และการกดชำระเงินได้เร็วผิดพลาดน้อยที่สุด
พีระมิดการทดสอบซอฟต์แวร์ (The Testing Pyramid)
ทีมวิศวกรรมซอฟต์แวร์ไม่ควรพึ่งการคลิกทดสอบด้วยมือทั้งหมด (Ice-Cream Cone Anti-pattern) เพราะช้าและเกิดช่องว่างของ Regression Suite มากขึ้นเรื่อยๆ ตามจำนวนฟีเจอร์ ลองปรับสัดส่วนชุดทดสอบด้านขวาเพื่อเปรียบเทียบผลลัพธ์
จำลองกลยุทธ์การทดสอบ (Strategy Simulator)
Unit Testing & Test Isolation ด้วย Mock / In-Memory Gateway
อ้างอิงแนวคิดจาก Robert C. Martin: การเขียน Unit Test ก่อนหรือคู่กับโค้ด (Red → Green → Refactor) บังคับให้เราแยก Business Logic ออกจากฐานข้อมูลจริงได้ ด้วยการใช้ Mock Object หรือ InMemoryProductGateway ทำให้ทดสอบระบบ POS ได้รวดเร็วโดยไม่ต้องรอต่อ Database ทุกครั้ง
- ห้ามเขียน Production Code จนกว่าจะมี Unit Test ที่ Fail (Red)
- เขียน Test เท่าที่จำเป็น ให้พอล้มเหลวหรือคอมไพล์ไม่ผ่าน
- เขียน Production Code เท่าที่จำเป็น เพื่อทำให้ Test ผ่าน (Green) แล้วจึง Refactor
// ตัวอย่างโครงสร้าง Unit Test (Isolated Order Logic)
function calculateLineSubtotal(price, qty, discountPct = 0) {
if (qty <= 0) throw new Error('Invalid quantity');
const raw = price * qty * (1 - discountPct / 100);
return Math.round(raw * 100) / 100;
}
// ใช้ InMemoryInventory แทน Real SQL DB เพื่อความเร็ว
test('TC-U01: คำนวณราคาน้ำมันพืช 2 ขวด ลด 10%', () => {
expect(calculateLineSubtotal(55, 2, 10)).toBe(99.00);
});ทดลองจำลอง Bug และรัน Unit Test Suite
| Test ID | กรณีทดสอบ (Unit Specification) | Expected | Actual | ผลลัพธ์ |
|---|
Integration Testing และการป้องกันสต็อกตัดขนานพร้อมกัน
Unit Test ยืนยันว่าฟังก์ชันย่อยถูกต้อง แต่ไม่สามารถจับปัญหาเมื่อ UI, API, Payment และ Database ทำงานร่วมกัน โดยเฉพาะความเสี่ยงสำคัญในเอกสารโครงงาน: ปัญหาสต็อกตัดขนานพร้อมกันเมื่อแคชเชียร์หลายจุดสั่งซื้อสินค้าชิ้นสุดท้ายพร้อมกัน (Race Condition)
จำลองเครื่อง POS #1 และ POS #2 ขายสินค้าชิ้นสุดท้ายพร้อมกัน
| เวลา (ms) | POS #1 (Cashier A) | POS #2 (Cashier B) | สถานะ Database |
|---|
ขอบเขตของ Integration Test ใน Grocery POS
- API + Database: สร้าง Orders และ Order_Items พร้อมตัด Inventory.stock_quantity ใน Transaction เดียว (ถ้าขั้นตอนใดพังต้อง Rollback ทั้งหมด)
- Payment Webhook: จำลอง PromptPay QR สำเร็จ / หมดเวลา (Timeout) / ยิงซ้ำ (Idempotency) เพื่อไม่ให้สร้างใบเสร็จซ้ำ
- Low-Stock Alert Trigger: ตรวจสอบว่าการขายที่ทำให้ stock_quantity <= reorder_level สร้างการแจ้งเตือนทันที
-- Risk Mitigation SQL (Atomic Conditional Update)
UPDATE Inventory_Ingredients
SET stock_quantity = stock_quantity - :qty
WHERE ingredient_id = :id
AND stock_quantity >= :qty;
-- Integration Test ต้อง Assert ว่า affected_rows === 1
-- สำหรับเครื่องแรก และ 0 (HTTP 409 Conflict) สำหรับเครื่องที่สองการออกแบบ Test Cases ด้วย Boundary Value และบันทึก Test Results Log
การได้คะแนนระดับดีเยี่ยมต้องแสดงหลักฐานการออกแบบ Test Case ที่เป็นระบบ (ไม่ใช่แค่ “ทดสอบแล้วใช้ได้”) โดยครอบคลุมค่าปกติ (Valid Equivalence), ค่าขอบ (Boundary Value Analysis) และกรณีผิดพลาด (Negative Case) นักศึกษาสามารถเพิ่มและส่งออก Test Results Log เป็น CSV ได้ด้านล่าง
เพิ่มรายการ Test Case ลงใน Log (บันทึกอัตโนมัติ)
ตารางบันทึกผลการทดสอบ (POS Test Results Log)
4 Cases| ID | เทคนิค | ข้อมูลนำเข้า / สถานการณ์ | ผลลัพธ์ที่คาดหวัง | สถานะ | จัดการ |
|---|
Acceptance Testing และการตรวจสอบจริยธรรมข้อมูล (PDPA)
Acceptance Test คือ “ข้อตกลงที่รันตรวจสอบได้” ร่วมกับลูกค้า (Black-box) โดยเขียนด้วยภาษาธุรกิจ (Given-When-Then) พร้อมทั้งต้องตรวจการคุ้มครองข้อมูลส่วนบุคคล (PDPA) ตามข้อกำหนดรายวิชา เช่น การไม่เปิดเผยเบอร์โทร เลขบัตรประชาชน หรือ password_hash ในรายงานและชุดทดสอบ
Acceptance Criteria: User Story ของระบบ POS
“ในฐานะแคชเชียร์ ฉันต้องการคิดเงินและตัดสต็อกสินค้าอัตโนมัติพร้อมแจ้งเตือนสินค้าใกล้หมด เพื่อให้บริการลูกค้าได้รวดเร็วและสั่งเติมสินค้าทันเวลา”
| Given (เงื่อนไขเริ่มต้น) | When (การกระทำ) | Then (ผลลัพธ์ที่ยอมรับได้) |
|---|---|---|
| สินค้า SKU-101 มีสต็อก 6 ชิ้น (reorder_level = 5) | แคชเชียร์สแกนขาย 1 ชิ้น และชำระ PromptPay สำเร็จ | สร้างใบเสร็จ สต็อกเหลือ 5 ชิ้น และขึ้นแจ้งเตือน Reorder ทันที |
| มียอดรวมในตะกร้า 240 บาท | ลูกค้ารับเงินสด 200 บาท (น้อยกว่ายอดรวม) | ระบบปฏิเสธการปิดบิล และแจ้งข้อความให้รับเงินเพิ่ม 40 บาท |
| ผู้จัดการส่งออกสรุปยอดขาย CSV | เปิดไฟล์สรุปยอดขายประจำวัน | ไม่พบเบอร์โทรศัพท์ รหัสบัตรประชาชน หรือข้อมูลระบุตัวตนลูกค้า (PDPA) |
ตรวจสอบ Payload ส่งออกรายงาน POS
Usability Testing กับผู้ใช้เป้าหมายของร้านค้าปลีก
ซอฟต์แวร์ที่ผ่าน Unit Test 100% อาจยังใช้งานไม่ได้จริงหากแคชเชียร์หาปุ่มไม่เจอ การได้คะแนนระดับดีเยี่ยมต้องมีรายงาน Usability Testing จากผู้ใช้เป้าหมายจริง (เช่น แคชเชียร์ พนักงานขาย เจ้าของร้าน 3–5 คน) พร้อมข้อมูลเชิงปริมาณและแนวทางแก้ไขที่ชัดเจน
ขั้นตอนและภารกิจทดสอบ (Task Scenarios)
- Task 1 (คิดเงินเร่งด่วน): สแกนสินค้า 4 รายการ + ค้นหาสินค้าไม่มีบาร์โค้ด 1 รายการ + ชำระ PromptPay (เกณฑ์เป้า: ≤ 45 วินาที)
- Task 2 (แก้ไขความผิดพลาด): ลดจำนวนสินค้าที่สแกนเกินและยกเลิกบิลก่อนรับเงิน (เกณฑ์เป้า: ≤ 15 วินาที, Error = 0)
- Task 3 (ตรวจสต็อก): เปิดดูรายการสินค้าที่ต่ำกว่า reorder_level
เครื่องมือบันทึกผล Usability Testing (Usability Session Logger)
| ผู้ใช้ | ภารกิจ | เวลา (วิ) | Errors | คะแนน | แนวทางปรับปรุง |
|---|
การติดตามและจัดการข้อผิดพลาด (Bug Tracking & GitHub Workflow)
เมื่อพบ Bug จากการทดสอบ ต้องบันทึกเป็น Issue ที่มีข้อมูลครบถ้วน (Steps to Reproduce, Expected vs Actual, Test Cases Checklist) และเชื่อมกับ Pull Request ผ่านบอร์ด Todo → In Progress → Awaiting Review → Done
บอร์ดคัดแยก Bug ของ Grocery POS (Interactive Defect Triage)
| Bug ID | อาการที่พบ (Issue Summary) | ระดับความรุนแรง (Severity) | สถานะบน Board |
|---|
โครงสร้าง Bug Fix PR Template มาตรฐาน
# Bug Fix Title: [BUG-104] ป้องกันสต็อกติดลบเมื่อขายพร้อมกัน
### Issue Description
เครื่อง POS 2 จุดสแกนสินค้าชิ้นสุดท้ายพร้อมกัน ทำให้ stock_quantity กลายเป็น -1
### Steps to Reproduce
1. ตั้งค่าสินค้า SKU-008 ให้ stock_quantity = 1
2. กด Confirm Order จาก POS-01 และ POS-02 พร้อมกัน
### Expected Behavior
POS-01 สำเร็จ (stock = 0); POS-02 แจ้งเตือน "สินค้าหมด"
### Solution & Test Cases
- [x] ใช้ Atomic UPDATE WHERE stock_quantity >= qty
- [x] เพิ่ม Integration Test จำลอง Concurrent Requestsตัวชี้วัดคุณภาพซอฟต์แวร์ (QA Metrics) และการกำกับดูแล AI Test Agents
“สิ่งที่วัดไม่ได้ ย่อมควบคุมไม่ได้” — ทีมควรติดตามตัวชี้วัดผลลัพธ์จริง (Outcome Metrics) มากกว่าจำนวนบรรทัดโค้ด และหากใช้ AI ช่วยเขียน Test Scripts ต้องตรวจทานคุณภาพโดยมนุษย์เสมอ (อ้างอิงผลวิจัย AI SDLC และ Hacon Test Engineering)
5 ตัวชี้วัดหลักที่ทีม Project ควรติดตาม
- Test Pass Rate & Coverage: สัดส่วน Test Cases ที่ผ่านจริงบน CI
- Defect Density & Escaped Defects: จำนวน Bug ที่หลุดไปถึงตอนสาธิต/ใช้งานจริง
- Change Failure Rate (CFR): % ของการ Deploy ที่ทำให้ระบบหลักพัง
- MTTR (Mean Time to Recovery): เวลาเฉลี่ยในการแก้ Bug และ Deploy ซ้ำ
- Agent Success Rate (กรณีใช้ AI): % ของ Test ที่ AI สร้างแล้วรันเขียวจริงบนระบบ พร้อมผ่านการตรวจความอ่านง่าย (Readability) และไม่มี Test Smells
เช็กลิสต์ส่งมอบงานสัปดาห์ที่ 12 และประเมินระดับคะแนนคาดการณ์
ตรวจสอบหลักฐานการทดสอบทั้งหมดที่ทีม Grocery POS ต้องเตรียมส่งอาจารย์ที่ปรึกษาและคณะกรรมการ (บันทึกสถานะอัตโนมัติในเซสชันนี้)
สรุปประเด็นสำคัญ สัปดาห์ที่ 12 และแหล่งอ้างอิงรายวิชา
คุณภาพของแพลตฟอร์ม Grocery POS ไม่ได้เกิดจากการ “ตรวจตอนจบ” แต่เกิดจากการออกแบบระบบให้ทดสอบได้ (Testability) ตั้งแต่วันแรก และยืนยันผลทั้งด้วยชุดทดสอบอัตโนมัติและผู้ใช้จริงหน้าร้าน
Unit Test ช่วยแยก Business Logic ให้สะอาด
การใช้ In-Memory Gateway / Mock Object ทำให้ทดสอบกฎการคิดเงินและสต็อกได้ในเสี้ยววินาทีและลดความเปราะบางของโค้ด
Integration Test ป้องกันความล้มเหลวรอยต่อระบบ
ปัญหาสต็อกตัดขนานพร้อมกัน (Concurrency) และ PromptPay Webhook ซ้ำซ้อน ต้องถูกดักจับด้วย Integration Test บน Database จริง
Usability Testing คือบทพิสูจน์หน้าเคาน์เตอร์
ให้แคชเชียร์และเจ้าของร้านจริงทำภารกิจสำคัญ สังเกตจุดติดขัดโดยไม่ชี้นำ แล้วแปลงปัญหาเป็นรายการแก้ไขที่วัดผลได้
วัดผลด้วย Metrics และคุ้มครอง PDPA
ติดตาม Pass Rate, Escaped Defects, Lead Time และตรวจความถูกต้องของ Test ที่สร้างจาก AI พร้อมลบข้อมูลส่วนบุคคลออกจาก Test Dataset เสมอ
- เอกสารแนวทางโครงงานรายวิชา (02 ตุ๊กตา project ปี 1–3) และเกณฑ์ประเมินความครอบคลุมของการทดสอบซอฟต์แวร์และการประกันคุณภาพ (ด้านที่ 4 สัปดาห์ที่ 12)
- หลักสูตร วท.บ. วิทยาการข้อมูลและการประยุกต์ (มคอ.2) — รายวิชา 1145 204 Sophomore Project
- Robert C. Martin — Agile Principles, Patterns, and Practices in C# (TDD, Test Isolation, InMemoryGateway, Acceptance Tests)
- McMaster Research Software Development Team — Using GitHub Projects for Agile (Kanban Flow & Bug Fix PR Template)
- ASEAN University Network Quality Assurance (AUN-QA) — แนวทางการสัมภาษณ์และการฟังอย่างตั้งใจ (Mirroring, Using Silences, Acknowledging)
- Port.io AI SDLC: A Practical Guide to SDLC AI Agents, Agile Analytics, และงานวิจัย Human-AI Collaboration for Scaling Agile Regression Testing (Hacon Study)