CupCode.cc
Section 01 · Module 01 · Lesson 02 · ~15–20 นาที

ทำไมต้องทดสอบ ถ้าโปรแกรมเมอร์เก่งอยู่แล้ว?

คำถามนี้ฟังดูกวน ๆ แต่เป็นคำถามที่หลายองค์กรถามจริง ๆ — และคำตอบของมันก็เป็นเหตุผลว่าทำไม testing ถึงไม่ใช่แค่ "ขั้นตอนก่อนปล่อย" แต่เป็นส่วนหนึ่งของการส่งมอบคุณค่าให้ธุรกิจ

เวลาเรียน: 15–20 นาที ต้องรู้มาก่อน: Lesson 01 รูปแบบ: อ่าน + แบบฝึกสั้น ๆ

จบบทนี้แล้วคุณจะ...

  • อธิบาย "cost of defects" และทำไมยิ่งเจอช้ายิ่งแพง
  • เปรียบเทียบผลของการเจอบั๊กใน dev, QA, production ได้
  • อธิบายว่า testing ไม่ใช่การ "พิสูจน์ว่าไม่มีบั๊ก" แต่คือการลดความเสี่ยง
  • เข้าใจว่าคุณภาพเป็นความรับผิดชอบของทั้งทีม ไม่ใช่แค่ QA
1 · เริ่มจากเรื่องจริง

บั๊กตัวเดียวที่ราคาแพงกว่าทั้งโปรเจกต์

ปี 1999 NASA ส่งยานสำรวจดาวอังคารชื่อ Mars Climate Orbiter มูลค่า 125 ล้านดอลลาร์ ไปถึงปลายทางหลังเดินทาง 9 เดือน พอถึงดาวอังคาร ยานก็หายไปเฉย ๆ สาเหตุคือ ทีมหนึ่งคำนวณแรงขับเป็น pound-seconds ในขณะที่อีกทีมใช้ค่านั้นในหน่วย newton-seconds — หน่วยไม่ตรงกัน ยานคำนวณวงโคจรผิด แล้วพุ่งเข้าชั้นบรรยากาศจนพัง

นี่คือบั๊กที่ "code ทุกบรรทัดถูก" ในมุมมองของแต่ละทีม แต่พอนำมาเชื่อมกันกลับล้มเหลว ถ้ามีใครสักคนเทสต์ integration ระหว่างสองระบบก่อนปล่อย — แค่นั้นก็อาจช่วยประหยัดเงิน 125 ล้านดอลลาร์ได้

เราไม่ได้กำลังจะทำยานอวกาศในหลักสูตรนี้ แต่หลักการเดียวกันใช้กับทุกระบบ — defect ที่หลุดไปถึงผู้ใช้จะมี "ราคา" เสมอ และราคานั้นเพิ่มขึ้นตามเวลาที่ผ่านไป

2 · กฎที่ QA ทุกคนต้องรู้

Cost of defects: ยิ่งเจอช้า ยิ่งแพงแบบทวีคูณ

งานวิจัยตั้งแต่ยุค Barry Boehm ในช่วง 1980s (และมีการยืนยันซ้ำในยุคใหม่) บอกเราเหมือนกันว่า ต้นทุนในการแก้ไข defect จะเพิ่มขึ้น "แบบทวีคูณ" ตาม phase ที่เจอ ไม่ใช่เชิงเส้น ตัวเลขต่างกันในแต่ละรายงาน แต่รูปร่างของกราฟเหมือนกันทุกครั้ง

Phase ที่เจอบั๊ก ต้นทุนสัมพัทธ์ เกิดอะไรขึ้น
Requirement 1x แก้คำในเอกสารก่อนทีมเริ่มทำ — แทบไม่มีต้นทุน
Design ~5x ต้องปรับ architecture, data model, หรือ flow ก่อนลงมือ code
Development ~10x Dev แก้ code, เพิ่ม test, ทำ code review ใหม่
QA / Staging ~20x หลายทีมเกี่ยวข้อง — dev, QA, PM และต้อง regression test ใหม่
Production 50–100x+ แก้ + deploy hotfix + incident response + ชดเชยลูกค้า + กู้ชื่อเสียง

ตัวเลขไม่ใช่ประเด็น — ประเด็นคือรูปร่างของกราฟ บั๊กที่เจอตอน requirement อาจใช้แค่แก้หนึ่งประโยคในเอกสาร บั๊กเดียวกันที่เจอตอน production อาจต้องประชุมฉุกเฉิน 6 คน เขียน hotfix ภายในคืนเดียว และยังต้องเจอกับลูกค้าที่โกรธในเช้าวันถัดมา

💡 สิ่งที่คุณควรเอาไปใช้ ถ้าคุณสามารถ "ย้ายการเจอบั๊ก" จาก production มาอยู่ที่ QA หรือจาก QA มาอยู่ที่ dev หรือจาก dev มาอยู่ที่ requirement — นั่นคืองานที่มี ROI สูงที่สุดที่ QA ทำได้ นี่เรียกว่า shift left testing และจะกลับมาตลอดหลักสูตร

3 · กรอบคิดที่ถูกต้อง

Testing ไม่ใช่การพิสูจน์ว่า "ไม่มีบั๊ก"

นี่คือหนึ่งในสิ่งที่คนนอกสาย QA มักเข้าใจผิด — พวกเขาคิดว่าถ้าทีม QA ทำหน้าที่ดี ระบบจะต้อง "ไม่มีบั๊กเลย" ซึ่งเป็นไปไม่ได้ในทางปฏิบัติ และยังเป็นเป้าหมายที่ผิดตั้งแต่ต้น

❌ เป้าหมายแบบผิด ✓ เป้าหมายแบบถูก
"ทดสอบจนมั่นใจว่าไม่มีบั๊กเหลือเลย" "ลดความเสี่ยงให้อยู่ในระดับที่ธุรกิจยอมรับได้"
พิสูจน์ไม่ได้ในทางตรรกะ เน้นทดสอบส่วนที่เสี่ยงสูงก่อน
ต้องทดสอบ input ทุกแบบที่เป็นไปได้ — เป็นอนันต์ ยอมรับว่าบางบั๊กจะหลุดไป production — แต่ต้องไม่ใช่บั๊กใหญ่
ทำให้ทีมรู้สึกผิดเมื่อมีบั๊กหลุด ทั้งที่เป็นเรื่องธรรมชาติ วัดผลได้จริง เช่น ไม่มี critical bug ใน flow การจ่ายเงิน

Edsger Dijkstra Testing shows the presence, not the absence of bugs.

การทดสอบบอกได้แค่ว่า "มีบั๊กอยู่" เมื่อเราเจอมัน แต่ไม่สามารถบอกได้ว่า "ไม่มีบั๊กเหลือแล้ว" ไม่ว่าจะทดสอบกี่รอบก็ตาม เมื่อเข้าใจข้อนี้แล้ว งานของ QA จะเปลี่ยนจาก "การไล่จับผิด" ไปเป็น "การบริหารความเสี่ยง" — คุณเลือกที่จะเทสต์อะไร ทำไม และจะหยุดเทสต์เมื่อความเสี่ยงที่เหลือต่ำพอจะรับได้

เรื่องเล่า: ทีมที่เทสต์ทุกอย่าง แต่ไม่เคยเทสต์ถูกจุด ทีมหนึ่งภูมิใจมากว่าเขียน test case ครบ 2,000 เคส ครอบคลุมทุกหน้าจอ แต่เมื่อระบบขึ้น production กลับพบบั๊กใหญ่ในฟังก์ชันคำนวณดอกเบี้ย ที่ทีมไม่เคยเทสต์เคสของลูกค้าที่มียอดค้างเกิน 180 วัน — เพราะเคสแบบนั้นในเอกสาร requirement เขียนไว้สั้น ๆ แค่บรรทัดเดียว ทีมจึงไม่ได้ให้น้ำหนัก ทั้งที่เป็นลูกค้ากลุ่มที่มีความเสี่ยงสูงสุดของธุรกิจ นี่คือตัวอย่างที่ "เทสต์เยอะ ≠ เทสต์ดี" — การเข้าใจความเสี่ยงของธุรกิจคือส่วนที่สำคัญที่สุดของงาน QA

4 · คุณภาพเป็นของทุกคน

Quality ownership: ไม่ใช่แค่งาน QA

ถ้าในทีมมีใครพูดว่า "ฉันเขียน code ของฉันเสร็จแล้ว ที่เหลือปล่อยให้ QA จัดการ" นั่นคือสัญญาณว่าทีมกำลังมีปัญหาเรื่อง quality ownership คุณภาพไม่ใช่สิ่งที่ "ใส่เข้าไปตอนปลายทาง" แต่เป็นสิ่งที่ต้องใส่เข้าไปทุกขั้นตอน

บทบาท รับผิดชอบคุณภาพของ ตัวอย่างการทำ
PM / BA Requirement เขียน requirement ให้ชัด ทดสอบได้ · ระบุ edge case ที่ธุรกิจแคร์ · จัดลำดับตาม business risk
Developer Code เขียน unit test ก่อน commit · ทำ code review อย่างจริงจัง · ทดสอบในเครื่องตัวเองก่อนส่ง QA
QA / Tester กระบวนการทดสอบ ออกแบบ test strategy ตามความเสี่ยง · หา defect ก่อนถึงมือผู้ใช้ · เป็น "เสียงของผู้ใช้" ในทีม
DevOps / SRE Production monitoring และ alerting ที่เหมาะสม · rollback และ incident response · ทำให้ deploy ปลอดภัย

บทบาทของ QA ในทีมที่เก่งจริง ๆ ไม่ใช่ "คนรับผิดชอบคุณภาพทั้งหมด" แต่คือ "คนที่ทำให้ทั้งทีมคิดเรื่องคุณภาพเป็น" — ชวนคุยเรื่อง edge case ในประชุม refinement, ถามคำถามที่ยากตอน design review และช่วย dev คิดว่าจะทดสอบ code ของตัวเองอย่างไร

5 · ลองดูของจริง

ตัวอย่างของ testing ที่คุ้มค่าและที่ไม่คุ้ม

ก่อนจะถึงแบบฝึก ลองดูตัวอย่างที่ติดป้ายมาให้แล้ว ว่ากิจกรรม testing แบบไหนที่ช่วยลดความเสี่ยงจริง และแบบไหนที่แค่เพิ่มงานโดยไม่ช่วยอะไร

คุ้มค่า — "ก่อน sprint เริ่ม QA นั่งกับ BA 30 นาที เพื่อถาม edge case ของ requirement ใหม่" นี่คือ shift left ระดับสูงสุด — เจอความคลุมเครือที่ phase requirement ซึ่งแก้แค่ "1x" แทนที่จะเจอตอน production ("100x")

ไม่คุ้ม — "QA run regression suite 2,000 เคสทุกครั้งก่อน deploy แม้ว่า sprint นี้จะแตะแค่ 2 ไฟล์" การทดสอบเยอะไม่ใช่คุ้มค่าเสมอไป — ถ้าไม่มีการเลือกเคสตามความเสี่ยง ทีมจะเสียเวลามหาศาลกับการรันเทสต์ที่ไม่เกี่ยวข้อง

คุ้มค่า — "Dev เขียน unit test ครอบคลุม flow การจ่ายเงินทุก branch ก่อน merge" ทดสอบส่วนที่มี business risk สูง (payment) ในช่วงที่แก้ถูกที่สุด (dev phase) — คุ้มเกือบทุกโปรเจกต์

ไม่คุ้ม — "QA ทดสอบด้วยการ click ไปมาแบบ random เพื่อ 'หาบั๊กตามใจฉัน'" ไม่ใช่ว่า exploratory testing ไม่ดี แต่ถ้าไม่มี hypothesis หรือ risk model ประกอบ ก็เป็นแค่การเสียเวลาโดยไม่รู้ว่าทดสอบอะไรไปแล้วบ้าง และยังเหลืออะไรไม่เทสต์

Practice

แบบฝึก: ลองคิดเหมือน QA มืออาชีพ

เลือกระบบหนึ่งที่คุณคุ้นเคย (เช่น e-commerce, mobile banking, ระบบจองร้านอาหาร) แล้วตอบคำถามต่อไปนี้ในใจก่อน จากนั้นค่อยเปิดดูคำตอบแนะนำเพื่อเปรียบเทียบ

  1. ถ้าระบบ login ของแอปนั้นใช้ไม่ได้เป็นเวลา 1 ชั่วโมง จะกระทบอะไรบ้าง และใครบ้างที่ได้รับผลกระทบ?

    ดูคำตอบแนะนำ

    ผลกระทบมีหลายชั้น — (1) ผู้ใช้ทุกคนที่พยายามเข้าระบบจะทำ transaction ไม่ได้ (2) call center จะได้รับสายร้องเรียนจำนวนมาก (3) ธุรกิจเสียรายได้ในช่วงนั้น (4) ความเชื่อมั่นของผู้ใช้ลดลง โดยเฉพาะถ้าเกิดบ่อย — นี่คือเหตุผลที่ flow login มักถูกทดสอบเข้มข้นที่สุดและมี monitoring ตลอดเวลา เป็นตัวอย่างของจุดที่ "testing คุ้มค่ามาก"

  2. ถ้าฟังก์ชัน search ยังใช้งานได้ แต่ช้าลงจาก 0.5 วินาทีเป็น 4 วินาที จะกระทบอะไรบ้าง? ควรถือว่าเป็น "บั๊ก" หรือไม่?

    ดูคำตอบแนะนำ

    ในทางเทคนิคอาจยังไม่ถือว่าเป็น functional bug (ระบบยัง return ผลลัพธ์ได้) แต่เป็น non-functional defect ที่กระทบ business โดยตรง — งานวิจัยหลายชิ้นบอกว่าการโหลดช้าขึ้น 1–3 วินาทีทำให้ conversion rate ลดลง 10–30% นี่เป็นเคสที่ทีมมักจะละเลยเพราะ "ไม่มี error" แต่ในมุม cost of defects มันอาจแพงกว่าบั๊กที่มองเห็นได้ชัด

  3. ถ้า email notification ส่งช้าไป 3 ชั่วโมง (แต่ยังส่งถึงทุกคน) ในระบบไหนบ้างที่จะเป็นปัญหาใหญ่ และในระบบไหนที่แทบไม่มีผล?

    ดูคำตอบแนะนำ

    ปัญหาใหญ่: ระบบ 2FA (รหัส OTP หมดอายุ), ระบบจองตั๋วที่ต้องยืนยันเร็ว, ระบบแจ้งเตือน fraud alert ของธนาคาร — ทั้งหมดเป็นเคสที่ "เวลา" เป็นส่วนหนึ่งของฟังก์ชันจริง ๆ

    แทบไม่มีผล: newsletter รายสัปดาห์, email สรุปยอดสิ้นเดือน, แจ้งเตือน promotion — ผู้ใช้ไม่ได้รอในเวลานั้น ช้าหน่อยก็ไม่เป็นไร

    บทเรียน: ความ "เสี่ยง" ของบั๊กเดียวกันขึ้นอยู่กับบริบทของระบบทั้งหมด — กลับไปที่ lesson 01 คำว่า "fitness for purpose"

  4. ทีมของคุณเจอ critical bug ใน production 1 ชั่วโมงก่อนเปิดตัว sale ใหญ่ QA เป็นคนเจอ แต่ dev บอกว่า "นี่มันงานของ QA ที่ไม่เทสต์ดี" ในมุม quality ownership ใครควรรับผิดชอบ?

    ดูคำตอบแนะนำ

    คำตอบคือ ทั้งทีม — ไม่ใช่แค่ QA และไม่ใช่แค่ dev การโทษกันเองไม่ช่วยแก้ปัญหาและเป็นสัญญาณของทีมที่ quality ownership ไม่ดี

    สิ่งที่ทีมที่เก่งจะทำคือ: (1) แก้บั๊กก่อน (2) หลังเหตุการณ์ทำ post-mortem แบบไม่โทษใคร ถามว่า "กระบวนการของเราพลาดตรงไหน" ไม่ใช่ "ใครผิด" (3) ปรับ process ให้ครั้งหน้าเจอบั๊กนี้เร็วขึ้น เช่น เพิ่ม automated test, ปรับ requirement review, หรือทำ canary deployment

    คุณภาพคือสิ่งที่สร้างด้วย ระบบ ไม่ใช่ด้วยการตำหนิคน

สิ่งที่ต้องเอาติดตัวไปจากบทนี้

  • Cost of defects เพิ่มแบบทวีคูณ ตาม phase ที่เจอ — ยิ่ง shift left ยิ่งประหยัด
  • เป้าหมายของ testing ไม่ใช่ "ไม่มีบั๊ก" แต่คือการ ลดความเสี่ยงให้อยู่ในระดับที่ยอมรับได้
  • Dijkstra: Testing shows the presence, not the absence, of bugs. — การทดสอบเป็นเครื่องมือบริหารความเสี่ยง ไม่ใช่เครื่องพิสูจน์
  • Quality ownership เป็นของทั้งทีม — QA ที่เก่งคือคนที่ทำให้ทั้งทีม คิดเรื่องคุณภาพเป็น ไม่ใช่คนที่รับผิดชอบคุณภาพคนเดียว
← บทเรียนก่อนหน้า บทเรียนถัดไป →