CupCode.cc
Section 02 · Module 05 · Lesson 01 · ~22–26 นาที

การประเมินความเสี่ยงเพื่อการทดสอบ

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

เวลาเรียน: 22–26 นาที ต้องรู้มาก่อน: Module 04 ทั้งหมด รูปแบบ: อ่าน + ตารางคิดความเสี่ยง + แบบฝึกสั้น

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

  • อธิบายได้ว่าทำไมการทดสอบต้องมองเรื่องความเสี่ยง ไม่ใช่ความครบถ้วนอย่างเดียว
  • แยกองค์ประกอบของ risk เช่น impact, likelihood และ detectability ได้
  • ใช้กรอบง่าย ๆ เพื่อประเมินว่าฟีเจอร์ไหนควรถูกทดสอบหนักกว่าฟีเจอร์อื่น
  • พูดคุยกับทีมเรื่องลำดับความสำคัญของการทดสอบได้อย่างมีเหตุผลมากขึ้น
  • เริ่มเปลี่ยนจาก “เทสต์ตามลำดับที่ได้รับ” เป็น “เทสต์ตามความเสี่ยงที่ธุรกิจรับไม่ไหว”
1 · ทำไม QA ต้องคิดเรื่องความเสี่ยงก่อนเสมอ

เพราะเวลาและพลังของทีมมีจำกัด

ในโลกจริงเราแทบไม่เคยมีสถานการณ์ที่ว่า:

  • requirement ชัดทุกข้อ
  • เวลาเหลือเฟือ
  • environment พร้อมตลอด
  • test data ครบ
  • ทุกฟีเจอร์สำคัญเท่ากัน

สิ่งที่เกิดขึ้นจริงมักตรงข้ามกันพอดี QA จึงต้องเลือกว่าจะลงแรงตรงไหนก่อน และการเลือกนั้นไม่ควรใช้ความรู้สึกอย่างเดียว

ถ้าทดสอบทุกอย่างแบบน้ำหนักเท่ากัน คุณอาจใช้เวลามากกับส่วนที่พังแล้วไม่ค่อยมีใครเดือดร้อน แต่กลับปล่อยส่วนที่พังแล้วธุรกิจเสียหายหนักหลุดไป production

นี่คือเหตุผลที่งานทดสอบที่มีคุณค่าไม่ได้ถามว่า “เราทดสอบเยอะพอหรือยัง” อย่างเดียว แต่ถามด้วยว่า “เราเอาเวลาไปลงในจุดที่เสี่ยงพอหรือยัง”

2 · Risk ในบริบทของงานทดสอบคืออะไร

มองให้ออกว่า “พลาดแล้วเจ็บแค่ไหน” และ “มีโอกาสพลาดมากแค่ไหน”

ในงาน QA คำว่า risk มักหมายถึงโอกาสที่บางอย่างจะผิดพลาด และเมื่อผิดแล้วจะสร้างผลกระทบที่ทีมไม่อยากรับ

กรอบง่ายที่สุดคือ:

องค์ประกอบ แปลแบบง่าย ตัวอย่างคำถาม
Impact ถ้าพังแล้วเจ็บแค่ไหน ถ้าพัง ลูกค้าจ่ายเงินไม่ได้ไหม? ข้อมูลหายไหม? กระทบชื่อเสียงไหม?
Likelihood มีโอกาสพังมากแค่ไหน logic ซับซ้อนไหม? เพิ่งเปลี่ยนเยอะไหม? มี dependency ภายนอกไหม?
Detectability ถ้าพังแล้วสังเกตเห็นง่ายไหม พังแล้วเห็นทันที หรือจะหลบอยู่เงียบ ๆ จนลูกค้าเจอก่อน?

บางทีมใช้สูตรง่าย ๆ เช่น:

Risk Score = Impact x Likelihood

บางทีมเพิ่ม Detectability เข้าไปด้วย แต่ไม่ว่าคุณจะใช้สูตรไหน แก่นสำคัญเหมือนกันคือ:

  • ของที่พังแล้วกระทบหนัก ควรได้เวลาทดสอบมากขึ้น
  • ของที่ซับซ้อนหรือเพิ่งเปลี่ยน ควรได้การทดสอบลึกขึ้น
  • ของที่พังแล้วจับยาก ควรมีการตรวจเช็กและ evidence มากขึ้น
3 · ความเสี่ยงไม่ได้มีแค่เรื่องเงิน

บางอย่างพังแล้วไม่ได้เสียรายได้ตรง ๆ แต่เสียความเชื่อมั่น

เวลาเริ่มประเมิน risk หลายคนจะนึกถึง payment ก่อนเสมอ ซึ่งถูก แต่ยังไม่พอ

ลองดูตัวอย่างความเสี่ยงหลายแบบ:

ประเภทความเสี่ยง ถ้าพลาดจะเกิดอะไร
Revenue Risk ผู้ใช้จ่ายเงินไม่ได้, coupon ใช้ผิด, ยอดรวมคำนวณผิด
Data Risk ข้อมูลหาย, ข้อมูลคนหนึ่งหลุดไปอีกคน, export ผิด
Security / Privacy Risk สิทธิ์เข้าถึงผิด, token รั่ว, data leak
Operational Risk ระบบล่มในช่วงสำคัญ, queue ค้าง, notification ไม่ส่ง
Reputation Risk หน้าแรกพัง, flow หลักช้า, ลูกค้าใช้แล้วงงมาก
Compliance Risk เก็บข้อมูลไม่ตรงกฎ, audit trail ไม่ครบ, consent ผิด

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

4 · กรอบคิดง่าย ๆ สำหรับประเมินฟีเจอร์

ใช้ 5 คำถามนี้ก่อนเริ่มลงมือ

เวลามีฟีเจอร์ใหม่เข้ามา ลองถาม 5 ข้อนี้:

  1. ถ้าฟีเจอร์นี้พัง ผู้ใช้หรือธุรกิจจะเจ็บแค่ไหน?
  2. ส่วนนี้ถูกแก้เยอะไหม หรือมี logic/business rule ซับซ้อนไหม?
  3. มี integration กับระบบอื่นหรือ third-party ไหม?
  4. เป็น flow ที่คนใช้บ่อยหรือสำคัญมากไหม?
  5. ถ้าพังแล้วทีมจะรู้เร็วไหม หรือมีโอกาสหลุดเงียบ ๆ ?

ยิ่งตอบ “ใช่” หลายข้อ ก็ยิ่งควรทดสอบหนักขึ้น

ตัวอย่าง

ฟีเจอร์ ภาพรวมความเสี่ยง ควรทดสอบประมาณไหน
Checkout / Payment กระทบเงินโดยตรง, integration เยอะ, ผู้ใช้ใช้บ่อย ลึกมาก: happy path, negative, edge, regression, retry, duplicate
Reset Password กระทบ account access และ security ลึก: token, expiry, rate limit, invalid flow
Profile Picture Upload กระทบประสบการณ์ผู้ใช้ แต่ไม่ใช่รายได้หลัก กลาง: format, size, permission, browser/device สำคัญ
Change Theme Color กระทบ usability แต่ impact ธุรกิจต่ำ เบากว่า: smoke + visual sanity บางจุด
5 · วิธีทำ Risk Assessment แบบไม่ซับซ้อนเกินไป

ไม่ต้องมี spreadsheet 12 คอลัมน์เสมอไป

ในทีมเล็กหรือ sprint เร็ว คุณสามารถเริ่มจากตารางง่าย ๆ แบบนี้ได้:

รายการ Impact Likelihood เหตุผลสั้น ๆ ระดับรวม
Checkout สูง สูง กระทบเงินและเพิ่งเปลี่ยน payment callback สูงมาก
Login สูง กลาง flow หลักแต่ logic ไม่ได้เปลี่ยนเยอะ สูง
Search Filter กลาง สูง เพิ่ง refactor และมี combination เยอะ สูง
Profile Theme ต่ำ ต่ำ เปลี่ยน UI เฉพาะบางหน้า ต่ำ

สิ่งสำคัญไม่ใช่ให้คะแนนสวยที่สุด แต่คือให้ทีมเห็น “เหตุผล” ว่าทำไมบางส่วนควรได้ความสนใจมากกว่า

6 · ตัวอย่างเต็ม: ประเมิน risk ของฟีเจอร์ Checkout

ดูให้เห็นว่าความเสี่ยงไม่ได้มาจากปุ่มเดียว

สมมติ requirement คือ:

“ลูกค้าสามารถ checkout สินค้า เลือกที่อยู่ เลือกวิธีชำระเงิน และได้รับเลข order เมื่อสำเร็จ”

ถ้าแตกเป็น risk ย่อย คุณอาจเห็นแบบนี้:

ส่วนย่อย ตัวอย่างความเสี่ยง ระดับ
Cart Summary ยอดรวมผิด, ส่วนลดไม่ตรง สูง
Shipping Address ที่อยู่ผิด, province mapping ผิด กลาง
Payment ชำระสำเร็จแต่ order ไม่ถูกสร้าง, หักเงินซ้ำ สูงมาก
Order Creation เลข order ซ้ำ, status ไม่ตรง สูงมาก
Confirmation ผู้ใช้ไม่เห็นผลลัพธ์ชัด, email ไม่ส่ง กลาง

สังเกตว่า “checkout” ไม่ได้เป็น risk ก้อนเดียว แต่เป็นหลาย risk ที่ควรแบ่งน้ำหนักการทดสอบไม่เท่ากัน

7 · ข้อผิดพลาดที่พบบ่อยเวลา assess risk

หลายทีมคิดเรื่อง risk แต่ยังใช้มันไม่เป็น

1. ให้ทุกอย่างเป็น high หมด

ถ้าทุกอย่างคือ high เท่ากับไม่มีอะไร high จริง และทีมก็ยังไม่รู้ว่าจะเริ่มตรงไหน

2. ประเมินจากความยากในการทดสอบ แทนความเสี่ยงทางธุรกิจ

ฟีเจอร์ที่เทสต์ยาก ไม่ได้แปลว่าเสี่ยงที่สุดเสมอไป บางอย่างยากเพราะ environment แย่ แต่ impact ต่ำ

3. มองเฉพาะ happy path

ความเสี่ยงจำนวนมากซ่อนอยู่ใน:

  • retry
  • timeout
  • duplicate action
  • permission
  • data mismatch
  • callback จากระบบภายนอก

4. ประเมินครั้งเดียวแล้วไม่อัปเดต

risk เปลี่ยนได้เมื่อ:

  • code ถูกแก้
  • architecture เปลี่ยน
  • deadline เข้าใกล้
  • release scope ขยาย

Risk assessment ที่ดีจึงเป็นสิ่งที่ “ทบทวนได้” ไม่ใช่เอกสารครั้งเดียวแล้วจบ

Practice

แบบฝึก: มองฟีเจอร์ด้วยสายตาแบบ risk-based

  1. ฟีเจอร์ “เปลี่ยนรหัสผ่าน” กับฟีเจอร์ “เปลี่ยนรูปโปรไฟล์” อันไหนควรได้เวลาทดสอบมากกว่า และเพราะอะไร

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

    โดยทั่วไป “เปลี่ยนรหัสผ่าน” ควรได้เวลาทดสอบมากกว่า เพราะกระทบ security และ account access โดยตรง ต้องมองเรื่อง current password, password policy, session invalidation, rate limit, error handling และ audit trail ส่วน “เปลี่ยนรูปโปรไฟล์” ก็ยังต้องเทสต์ แต่ impact ทางธุรกิจและความปลอดภัยมักต่ำกว่า

  2. ทีมเพิ่ง refactor ระบบ coupon ทั้งก้อน แต่ PM บอกว่าฟีเจอร์นี้ไม่ได้ใช้บ่อยเท่า checkout คุณจะให้ความเสี่ยงอย่างไร

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

    ถึง frequency อาจไม่สูงเท่า checkout แต่ likelihood สูงขึ้นเพราะเพิ่ง refactor และ business rule ของ coupon มักซับซ้อน จึงอาจจัดเป็นความเสี่ยงระดับสูงได้ โดยเฉพาะถ้าผิดแล้วกระทบยอดเงินหรือโปรโมชันของแคมเปญ

  3. ฟีเจอร์ export report ไม่ได้ใช้ทุกวัน แต่ถ้า export ผิด ฝ่ายการเงินส่งรายงานผู้บริหารผิด คุณจะมอง risk อย่างไร

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

    frequency ไม่สูง แต่ impact สูงเพราะข้อมูลผิดอาจพาไปสู่การตัดสินใจผิดและเสียความน่าเชื่อถือ นี่คือตัวอย่างที่ช่วยเตือนว่า risk ไม่ได้วัดจาก “คนใช้บ่อยแค่ไหน” อย่างเดียว ต้องมองผลกระทบด้วย

  4. ถ้าทีมมีเวลาเทสต์เหลือแค่ครึ่งวันก่อน release คุณจะเอา risk assessment ไปใช้ยังไง

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

    ใช้มันเพื่อตัดสินใจว่าอะไรต้องรันก่อนแน่ ๆ เช่น login, checkout, order creation, critical integrations และส่วนที่เพิ่งแก้ จากนั้นค่อยตัดรายการที่ impact ต่ำหรือมีความมั่นใจสูงออกก่อน ไม่ใช่สุ่มหยิบ test case ตามลำดับเอกสาร

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

  • การทดสอบที่ดีไม่ได้พยายามให้ทุกอย่างสำคัญเท่ากัน แต่ให้เวลากับจุดที่พลาดแล้วเจ็บที่สุด
  • Risk มักมองผ่านอย่างน้อย 3 มุมคือ impact, likelihood และบางครั้ง detectability
  • ฟีเจอร์เดียวกันสามารถแตกเป็นความเสี่ยงย่อยหลายก้อนได้ และควรทดสอบหนักไม่เท่ากัน
  • Risk assessment มีค่าเมื่อช่วยให้ทีมตัดสินใจเรื่องเวลาและลำดับความสำคัญได้จริง
  • QA ที่โตขึ้นจะไม่ได้แค่ “เขียน test case เยอะขึ้น” แต่จะ “เลือกให้ถูกว่าควรเทสต์อะไรหนักที่สุด”
← บทเรียนก่อนหน้า บทเรียนถัดไป →