Testing Foundations#

ระบบ Workshop Hub ผ่าน test cases ที่ทีมเขียนไว้ทั้งหมด แต่ผู้เรียนยังจองกิจกรรมที่เริ่มไปแล้วได้ ปัญหาไม่ได้เกิดจาก “test น้อยเกินไป” อย่างเดียว แต่อาจเกิดจาก test objective ไม่ครอบ risk, requirement ไม่บอก cutoff, oracle ตัดสินผลผิด หรือทีมตรวจเฉพาะสิ่งที่ระบบทำตามสเปกโดยไม่ถามว่าสเปกตอบความต้องการจริงหรือไม่

Testing มีเป้าหมายมากกว่าหา Bug#

ISTQB Foundation Level syllabus 4.0.1 อธิบาย testing เป็นกิจกรรมเพื่อค้นหา defects และประเมินคุณภาพของ work products โดย objective เปลี่ยนตาม test object, test level, risk, SDLC และ business context เป้าหมายที่พบบ่อย ได้แก่:

• ประเมิน requirement, design, code, configuration หรือระบบที่รันอยู่
• ทำให้ failure ปรากฏเพื่อค้นหา defect
• ตรวจ coverage ของ behavior, structure หรือ risk ที่ตกลงกัน
• ลดความเสี่ยงที่ software quality ไม่เพียงพอ
• ให้ข้อมูลแก่ stakeholder เพื่อตัดสินใจ release
• สร้าง confidence ภายใต้ scope และ evidence ที่ระบุ

คำว่า “tests ผ่าน” จึงไม่มีความหมายพอถ้าไม่รู้ว่า tests ถูกออกแบบเพื่อพิสูจน์อะไร สิ่งใดอยู่นอก scope และ oracle ใช้อะไรตัดสิน expected result

Error → Defect → Failure#

แยกคำเหล่านี้เพื่อไม่ให้ diagnosis สับสน:

Root cause: ทีมไม่มีเจ้าของกติกา cutoff ที่ชัด
Error: developer เข้าใจว่าเริ่มกิจกรรมแล้วยังยกเลิกได้
Defect: condition ใช้ startsAt <= now ผิดทิศ
Failure: ผู้ใช้กด Cancel หลังเริ่มกิจกรรมแล้วระบบยอมรับ
Impact: จำนวนที่นั่งและรายชื่อผู้เข้าร่วมไม่ตรงการดำเนินงานจริง

Error เป็นการกระทำ/ความเข้าใจของมนุษย์ Defect อยู่ใน work product เช่น requirement, code หรือ config Failure คือ behavior ที่สังเกตได้เมื่อ defect ถูก execute แต่ defect บางตัวอาจไม่สร้าง failure ใน test data/path ที่เลือก ส่วน root cause เป็นเงื่อนไขต้นทางที่ทำให้ error/defect เกิดซ้ำได้

Verification กับ Validation#

Verification ถามว่า “สร้างตรงกับ specification หรือไม่” เช่น API คืน 422 CUTOFF_PASSED ตาม contract Validation ถามว่า “สิ่งที่สร้างตอบความต้องการของผู้ใช้และ stakeholder ในบริบทจริงหรือไม่” เช่น cutoff policy เหมาะกับการจัด workshop และผู้ใช้เข้าใจข้อความที่แสดงหรือไม่

ทีมอาจ verify requirement ทุกข้อได้แต่ยังส่ง product ที่แก้ปัญหาผิด นี่คือ absence-of-defects fallacy: software ที่ตรง specification ไม่ได้แปลว่าจะบรรลุ business goal หรือ user need เสมอ Strategy ต้องมีทั้ง 2 คำถาม

Static และ Dynamic Testing#

Testing ไม่ได้เริ่มเมื่อ application รันได้:

Requirement review ที่พบว่า “ยกเลิกก่อนเริ่ม” ไม่มี timezone หรือ owner เป็น defect ที่แก้ได้ก่อนเขียน code Dynamic test อาจตรวจได้เมื่อ implementation เสร็จแล้วแต่มีค่า setup/diagnosis สูงกว่า ทั้ง 2 แนวทางเสริมกัน และพบ defect คนละชนิด

Testing ไม่ใช่ Debugging#

Testing ออกแบบและดำเนินการเพื่อประเมิน test object หรือทำให้ failure ปรากฏ ส่วน debugging เริ่มจาก failure/defect แล้ว reproduce, diagnose และแก้สาเหตุ หลังแก้ต้องมี:

• Confirmation testing — ยืนยันว่า defect ที่แก้ไม่สร้าง failure เดิมอีก
• Regression testing — ตรวจว่า change ไม่ทำ behavior เดิมส่วนอื่นเสีย

Test ที่ค้นพบปัญหาไม่จำเป็นต้องบอกบรรทัด code ที่ผิด แต่ evidence ที่ดีควรลด search space ให้คน debug

หลัก Testing 7 ข้อ#

ISTQB รวบรวมหลักทั่วไป 7 ข้อซึ่งใช้เป็นคำเตือน ไม่ใช่สูตรออกแบบ suite:

1. Testing แสดงการมี defect ไม่ใช่พิสูจน์ว่าไม่มี — no failures found หมายถึงยังไม่พบภายใต้ tests นี้
2. Exhaustive testing เป็นไปไม่ได้ — input, state, timing และ environment combinations โตเกินทดสอบครบ
3. Early testing ประหยัดเวลาและต้นทุน — review requirement/design ก่อน defect ไหลไป work product ถัดไป
4. Defects มักกระจุกตัว — modules ที่ซับซ้อน/เปลี่ยนบ่อย/เคยมี incident ควรเป็น input ของ risk analysis
5. Tests wear out — regression ชุดเดิมยังกันการย้อนกลับได้ แต่หา defect ใหม่ลดลงถ้าไม่ปรับ data/ideas
6. Testing ขึ้นกับ context — safety-critical system, content site และ prototype ไม่ใช้ strategy เดียวกัน
7. ไม่มี defect ที่พบไม่ได้แปลว่า product สำเร็จ — validation และ business outcome ยังต้องพิสูจน์

หลักข้อ 2 คือเหตุผลที่บทต่อไปต้องมี strategy model และ test design techniques: เมื่อทดสอบทุกอย่างไม่ได้ ทีมต้องเลือกอย่างมีเหตุผลและบอก residual risk

Test Basis, Condition, Case และ Oracle#

Test basis: cancellation policy v3 + API contract
Test condition: learner cancels after cutoff
Test data: workshop starts 2030-06-15T09:00Z; cutoff 08:00Z; request at 08:01Z
Expected result: status 422, code CUTOFF_PASSED, reservation remains CONFIRMED
Oracle: approved policy examples + API schema + inquiry post-condition

Test basis คือข้อมูลที่ใช้วิเคราะห์ เช่น requirement, risk, architecture, incident Test condition คือสิ่งที่จะตรวจ Test case ทำ condition ให้ execute ได้ ส่วน oracle คือแหล่งตัดสินผล Oracle อาจเป็น specification, domain expert, mathematical invariant, previous trusted implementation หรือ independent calculation

Coverage เป็นหลายมิติ#

Line coverage ตอบเพียงว่า code line ถูก execute หรือไม่ ไม่ตอบว่า assertion ถูก, requirement ครบ หรือ risk สูงถูกตรวจ Strategy อาจติดตาม:

• requirements/acceptance-criteria coverage
• risk coverage
• input partitions และ boundaries
• states/transitions และ decision rules
• code statements/branches เมื่อเหมาะ
• browsers/devices/environments ตาม support policy
• quality characteristics เช่น security, performance, accessibility, reliability

Coverage 100% ในมิติหนึ่งยังเหลือช่องว่างในอีกมิติ ให้รายงาน dimension และ scope ทุกครั้ง

Whole-team Quality และ Independence#

Testing เป็นความรับผิดชอบทั้งทีม Developer มี context ของ code, tester มีทักษะตั้งคำถาม/ออกแบบ evidence, product/domain owner รู้ intent และ operations มีข้อมูล failure จริง Independence ช่วยให้คนที่ไม่ได้สร้างสิ่งนั้นเห็น assumption ต่างออกไป แต่ handoff ไป “ทีม QA ตอนท้าย” ทำ feedback ช้า

ใช้ review, example workshop และ risk session ร่วมกันตั้งแต่ refinement แล้วให้ automation เป็นส่วนหนึ่งของ strategy ไม่ใช่กิจกรรมที่เริ่มหลัง feature complete

Lab: เขียน Test Objective#

สำหรับ feature “Join waitlist” เขียนเอกสาร 1 หน้า:

1. stakeholder และการตัดสินใจที่ต้องการจาก evidence
2. product risks อย่างน้อย 5 รายการ
3. verification questions และ validation questions
4. static work products ที่ review ได้ก่อน code
5. dynamic conditions ที่ต้อง execute
6. oracle/owner/version ของแต่ละ expected result
7. coverage dimensions และ residual risk ที่ยอมรับ

ห้ามเริ่มจากรายชื่อ tools หรือจำนวน test cases เพราะนั่นเป็น implementation decision ในขั้นหลัง

รายการตรวจสอบ#

• Test objective ผูกกับ decision, risk หรือ quality claim
• Verification และ validation ไม่ถูกใช้แทนกัน
• Static testing เริ่มก่อน executable system พร้อม
• Error, defect, failure และ root cause แยกชัดในรายงาน
• Expected result มี oracle และ policy owner
• Coverage ระบุมิติ ไม่ใช้เปอร์เซ็นต์ลอย ๆ
• รายงานสิ่งที่ tests ไม่ได้พิสูจน์และ residual risk

อ่านเพิ่มเติม#

• ISTQB Certified Tester Foundation Level syllabus 4.0.1
• ISO/IEC/IEEE 29119 software testing overview