Beyond the Bug: คุณภาพซอฟต์แวร์คืออะไรกันแน่?
ก่อนจะเรียนเรื่องการทดสอบ เราต้องตอบคำถามที่ดูเหมือนง่ายแต่ไม่ง่ายให้ได้ก่อน — "คุณภาพ" ของซอฟต์แวร์ตัวหนึ่งวัดจากอะไร? ถ้าตอบแค่ว่า "ไม่มีบั๊ก" คุณจะพลาดอีกครึ่งหนึ่งของเรื่องนี้ไปทั้งหมด
จบบทนี้แล้วคุณจะ...
- อธิบายได้ว่า "ซอฟต์แวร์ใช้งานได้" ไม่เท่ากับ "ซอฟต์แวร์คุณภาพดี"
- แยกแยะ functional quality กับ non-functional quality จากสถานการณ์จริงได้
- บอกความต่างระหว่าง validation กับ verification โดยใช้คำของตัวเอง
- อ่านเคสปัญหาแล้วระบุได้ว่ากระทบคุณภาพในมิติไหน
ระบบผ่านทุก Test Case แต่ทำไมลูกค้าถึงหนี?
ลองนึกตามสถานการณ์นี้ คุณเปิดแอปจองตั๋วคอนเสิร์ตในวันที่ตั๋วเปิดขาย คุณเลือกที่นั่ง กดชำระเงิน แล้วระบบก็หมุนวน 45 วินาที ก่อนจะขึ้นหน้าว่างเปล่า คุณลองกดใหม่ ระบบตอบว่า "ที่นั่งนี้ถูกจองแล้ว" แต่ในอีเมลไม่มีตั๋วมาให้ คุณโทรไป call center ซึ่งก็บอกว่า "ระบบทำงานปกตินะครับ ลองเช็กอีกครั้ง"
ถ้าถามทีม QA ของแอปนี้ว่า "ระบบทำงานตามสเปกไหม" คำตอบอาจจะคือ "ใช่" — เพราะในทุก test case ระบบก็คำนวณราคา ตัดบัตรเครดิต และอัปเดตฐานข้อมูลได้ถูกต้อง แต่สำหรับคุณในฐานะผู้ใช้ นี่คือแอปคุณภาพแย่มาก และสำหรับบริษัท นี่คือลูกค้าที่จะไม่กลับมาใช้อีก
นี่คือจุดที่หลักสูตรนี้อยากพาคุณเริ่ม — "ทำงานได้" กับ "คุณภาพดี" ไม่ใช่สิ่งเดียวกัน การที่สคริปต์ทดสอบผ่านทั้งหมดไม่ได้การันตีว่าคุณกำลังสร้างซอฟต์แวร์ที่ยอดเยี่ยม คุณภาพวัดจากว่าผู้ใช้จริงทำสิ่งที่ต้องการได้สำเร็จหรือไม่ และทำได้ดีแค่ไหน
Fitness for Purpose: คุณภาพไม่ใช่ค่าสัมบูรณ์
"คุณภาพ" ไม่ใช่ค่าสัมบูรณ์ (absolute) — ซอฟต์แวร์ที่ดีคือซอฟต์แวร์ที่ "เหมาะสมต่อจุดประสงค์ที่จะใช้" เหมือนมีด sashimi ที่ยอดเยี่ยมสำหรับหั่นปลาดิบ แต่เอาไปเดินป่าจะล้มเหลว ในขณะที่มีดพก Swiss Army จะเก่งตรงข้ามกันพอดี
ซอฟต์แวร์ก็เหมือนกัน ระบบจัดการคิวโรงพยาบาลกับระบบเกมออนไลน์มี "ความดี" คนละแบบสิ้นเชิง ระบบโรงพยาบาลต้องเสถียร แม่นยำ ตรวจสอบได้ ส่วนเกมออนไลน์ต้องลื่น ตอบสนองไว และสนุก ถ้าเอาเกณฑ์ของระบบหนึ่งไปวัดอีกระบบหนึ่งจะได้คำตอบผิดทันที
จำไว้แบบนี้ คุณภาพของซอฟต์แวร์ = "ระบบนี้ตอบสิ่งที่ผู้ใช้และธุรกิจต้องการ ในบริบทที่มันถูกใช้งานจริง ได้ดีแค่ไหน" ไม่ใช่ "ระบบนี้มีบั๊กกี่ตัว"
สังเกตว่าคำนิยามนี้มีสามเสาหลักซ่อนอยู่ — ผู้ใช้, ธุรกิจ, และ บริบท หากขาดตัวใดตัวหนึ่งไป เราจะตัดสินคุณภาพของระบบไม่ได้ นี่คือเหตุผลที่ QA มืออาชีพต้องเข้าใจโดเมนของระบบที่ตัวเองทดสอบเสมอ ไม่ใช่แค่กดตามสคริปต์
Functional quality vs Non-functional quality
ย้อนกลับไปที่แอปจองตั๋วตอนต้นบท ลองแยกปัญหาออกเป็นสองกอง
| Functional quality | Non-functional quality |
|---|---|
| ระบบ "ทำอะไร" ได้ถูกต้องไหม | ระบบ "ทำสิ่งนั้นอย่างไร" |
| คำนวณราคาตั๋วถูกต้อง | ตอบสนองภายใน 2 วินาที |
| ตัดบัตรเครดิตได้จริง | รองรับคน 10,000 คนพร้อมกัน |
| บันทึกที่นั่งในฐานข้อมูล | ไม่ล่มเวลามีคนเยอะ |
| ส่งอีเมลยืนยันเมื่อจองสำเร็จ | ผู้ใช้เข้าใจสถานะคำสั่งซื้อได้ตลอดเวลา |
แอปจองตั๋วในตัวอย่างอาจ "ผ่าน" ทุกข้อในฝั่ง functional แต่ล้มเหลวโดยสิ้นเชิงในฝั่ง non-functional ผลลัพธ์คือผู้ใช้ไม่ได้ตั๋วและไม่รู้ว่าเกิดอะไรขึ้น สำหรับลูกค้าและธุรกิจ นี่คือความล้มเหลว แม้ทุก unit test จะผ่านก็ตาม
ในคอร์สนี้เราจะกลับมาที่ non-functional quality บ่อย ๆ เพราะเป็นจุดที่ทีมส่วนใหญ่มักจะลืมทดสอบจนกระทั่งระบบขึ้น production แล้วมีปัญหา
Verification vs Validation
สองคำนี้ฟังดูคล้ายกันมากจนหลายคนใช้สลับกัน แต่มันต่างกันในเชิงปฏิบัติอย่างชัดเจน และการแยกให้ออกจะช่วยให้คุณคุยงานกับ PM, BA และ dev ได้ตรงประเด็นขึ้น
| Verification | Validation |
|---|---|
| "เราสร้างตรงสเปกหรือเปล่า?" | "สิ่งที่เราสร้างตอบสิ่งที่ผู้ใช้ต้องการจริงหรือเปล่า?" |
| ตรวจสอบว่าสิ่งที่ทีมสร้างขึ้นมาตรงกับ requirement, design document, หรือ specification ที่ตกลงกันไว้หรือไม่ — เป็นการเทียบของที่ได้กับ "พิมพ์เขียว" | ตรวจสอบว่าของที่เราทำเสร็จมันแก้ปัญหาจริงของผู้ใช้ได้หรือไม่ — แม้สเปกจะเขียนถูก แต่สเปกเองอาจเข้าใจผู้ใช้ผิดตั้งแต่ต้น |
วิธีจำที่ไม่ลืม Verification = Did we build the thing right? Validation = Did we build the right thing?
จุดที่สำคัญที่สุด — ระบบสามารถ verification ผ่าน แต่ validation ไม่ผ่าน ได้ นี่คือสถานการณ์ที่ "ทำตามสเปกครบทุกข้อ แต่ผู้ใช้ไม่ได้อยากได้แบบนั้นตั้งแต่แรก" และเป็นสาเหตุสำคัญที่ทำให้โปรเจกต์เสียเวลาและงบประมาณมากที่สุดในอุตสาหกรรมนี้
เรื่องเล่า: ปุ่ม "ลบ" ที่ทำตามสเปกเป๊ะ ทีมหนึ่งได้ requirement ว่า "เพิ่มปุ่มลบรายการในตะกร้า" ทีม dev ก็ทำปุ่มลบ ทีม QA ก็ทดสอบว่ากดแล้วรายการหายจริง — verification ผ่าน ขึ้น production อาทิตย์ถัดมามีลูกค้าโทรมาร้องเรียนว่ากดลบโดยไม่ได้ตั้งใจ แล้วของในตะกร้าหายหมดทันที ทั้งที่ตั้งใจจะลดจำนวนสินค้าแค่ชิ้นเดียว ทีมพบว่าสเปกไม่ได้บอกเรื่อง confirmation dialog เพราะคนเขียนสเปกก็ไม่ได้คิดถึงเคสนี้ — validation ไม่ผ่าน แม้ทุกอย่างในฝั่ง verification จะถูกต้องทั้งหมด
อ่านแล้วบอกได้ไหม อันไหนคือ verification อันไหนคือ validation?
ก่อนจะถึงแบบฝึก ลองดูตัวอย่างที่ติดป้ายมาให้แล้ว สังเกตว่าทำไมถึงติดป้ายแบบนั้น
Verification — "ระบบคำนวณภาษี 7% จากยอดก่อนส่วนลด ตามที่ระบุใน requirement ข้อ 3.2" เรากำลังเทียบของที่ได้กับสเปก ไม่ได้ถามว่าผู้ใช้อยากได้แบบนี้จริงไหม — ถ้าสเปกเขียนผิด เราก็ verification ผ่านได้อยู่ดี
Validation — "ให้ผู้ใช้จริง 5 คนลองใช้ feature checkout แล้วสังเกตว่าทำสำเร็จกี่คน" เรากำลังถามว่าของที่ทำเสร็จมันตอบโจทย์คนใช้จริงไหม ไม่ว่าสเปกจะเขียนว่ายังไง
Verification — "code review ว่า function นี้จัดการกรณี null ตามที่ design doc กำหนด" เทียบ implementation กับ design — อยู่ในโลก verification เพราะ design คือ "พิมพ์เขียว"
Validation — "สัมภาษณ์ลูกค้าหลังใช้งาน 1 สัปดาห์ว่า feature ใหม่ช่วยให้งานเร็วขึ้นจริงหรือไม่" เรากำลังตรวจว่าคุณค่าที่ส่งมอบตรงกับที่ธุรกิจตั้งใจไว้ไหม — นี่คือ validation ระดับสูงสุด
แบบฝึก: วินิจฉัยปัญหาคุณภาพจากสถานการณ์จริง
ดูภาพสรุปแต่ละเคสก่อน แล้วลองตอบในใจว่าปัญหาอยู่ที่มิติไหน จากนั้นกด "ดูคำตอบแนะนำ" เพื่อเปรียบเทียบ ไม่ต้องกลัวตอบผิด — การผิดในขั้นนี้คือส่วนหนึ่งของการเรียนรู้
ระบบธนาคารออนไลน์โอนเงินสำเร็จทุกครั้ง ยอดถูกต้อง แต่ผู้สูงอายุใช้ไม่เป็นเพราะปุ่มเล็กมาก และข้อความยืนยันใช้ศัพท์เทคนิค
ดูคำตอบแนะนำ
Functional quality ผ่าน (ระบบโอนถูก) แต่ non-functional quality (usability / accessibility) ล้มเหลว และในมุม validation ก็ไม่ผ่านสำหรับกลุ่มผู้ใช้จริงบางกลุ่ม — ทีมอาจ verification ผ่านทั้งหมด แต่ระบบไม่ fit for purpose ของผู้ใช้ที่ตั้งใจจะบริการ
ทีม dev ทำ feature ส่งออก CSV ตาม requirement ทุกบรรทัด ทดสอบแล้วไฟล์ออกมาถูกต้อง แต่พอถึงมือ finance พบว่า format ไม่ตรงกับระบบบัญชีที่ใช้จริง ต้องแก้ด้วยมือทุกครั้ง
ดูคำตอบแนะนำ
Verification ผ่าน (ทำตามสเปก) แต่ validation ไม่ผ่าน (สเปกเองเข้าใจ workflow ของ finance ไม่ครบ) นี่คือตัวอย่างคลาสสิกที่ "build the thing right but not the right thing"
แอปโหลดช้ามากในช่วง flash sale จนผู้ใช้จำนวนมากกดซื้อไม่ทัน ระบบไม่ล่ม ไม่ error แค่ช้า
ดูคำตอบแนะนำ
Functional quality ยังอยู่ (ระบบไม่พัง) แต่ non-functional quality ด้าน performance ล้มเหลว และกระทบ business outcome โดยตรง — ลูกค้าซื้อไม่ได้ = ธุรกิจเสียรายได้ เป็นเคสที่ทำให้เห็นว่าคุณภาพด้าน performance ไม่ใช่ "เรื่องเสริม" แต่เป็นส่วนหลักของคุณภาพ
ทีมเขียน unit test ครบ 100% ทุก function ผ่าน แต่ลูกค้ายังบ่นว่า feature ที่ทำมา "ไม่ใช่สิ่งที่ขอ"
ดูคำตอบแนะนำ
เป็นสัญญาณว่าทีมโฟกัสที่ verification อย่างเดียวและละเลย validation coverage 100% บอกแค่ว่า code ทำงานตามที่ dev คิดว่ามันควรทำ แต่ไม่ได้บอกว่าสิ่งที่ทำมาตอบโจทย์จริง — นี่คือเหตุผลที่ต้องมีการทดสอบระดับอื่น (acceptance, UAT, usability) เสริมเข้ามา ไม่ใช่เพียง unit test
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- คุณภาพซอฟต์แวร์ = fitness for purpose ในบริบทที่ผู้ใช้จริงใช้งาน ไม่ใช่แค่ "ไม่มีบั๊ก"
- Functional quality (ทำอะไร) และ non-functional quality (ทำอย่างไร) ต้องดูพร้อมกันเสมอ — ขาดข้างใดข้างหนึ่งไม่พอ
- Verification = สร้างตรงสเปกไหม / Validation = สเปกนั้นถูกตั้งแต่ต้นไหม ทั้งสองต้องผ่านถึงจะเรียกว่าคุณภาพดี
- บทบาทของ tester ไม่ใช่แค่ "หาบั๊ก" แต่คือการช่วยทีม ตรวจสอบคุณภาพหลายมิติ และทำให้ทีมมั่นใจว่าระบบพร้อมใช้งานจริง