Skip to content

Risk‐Based Testing

Jump to bottom
Somkiat Puisungnoen edited this page May 13, 2025 · 9 revisions

Example of Risk-Based Testing

  • Level 1 :: Business requirement
  • Level 2 :: Software architecture

1. Risk-Based Testing + Business Requirements

Teams

  • Business
  • Tester/QA
  • Developer

Business Requirements คือสิ่งที่ระบบจะต้องมีหรือทำเพื่อสนับสนุนเป้าหมายทางธุรกิจ เช่น

  • ผู้ใช้ต้องสามารถลงทะเบียนด้วยอีเมลได้
  • ข้อมูลผู้ใช้ต้องถูกเก็บอย่างปลอดภัยตาม PDPA

Risk-Based Testing จะเข้ามาช่วยวิเคราะห์ว่า

  • หาก feature เหล่านี้มีข้อผิดพลาด จะส่งผลอย่างไรต่อธุรกิจ ?
  • ความน่าจะเป็นที่ข้อผิดพลาดจะเกิดขึ้นคือเท่าใด ?
  • ควรทดสอบจุดไหนก่อนเป็นลำดับแรก ?

Step 1 :: ทำความเข้าใจ Business Requirements (BR)

ตัวอย่างเช่น ในระบบลงทะเบียน

  • BR1: ผู้ใช้งานใหม่ต้องลงทะเบียนด้วยอีเมลที่ถูกต้อง
  • BR2: อีเมลห้ามซ้ำกับผู้ใช้เดิม
  • BR3: รหัสผ่านต้องมีความปลอดภัย (อย่างน้อย 8 ตัว มีตัวเลข+อักษรพิเศษ)
  • BR4: ข้อมูลต้องเข้ารหัสก่อนบันทึก

Step 2 :: วิเคราะห์ความเสี่ยงของแต่ละ Requirement

Business Requirement ความเสี่ยง Impact Likelihood Risk Level
BR1 ระบบไม่ตรวจสอบรูปแบบอีเมล → สมัครไม่ได้ Medium High High
BR2 ระบบอนุญาตอีเมลซ้ำ → เกิดปัญหาข้อมูลซ้อนทับ High Medium High
BR3 รหัสผ่านไม่ผ่าน validation → เสี่ยงโดน brute-force Very High Medium Very High
BR4 ข้อมูลบันทึกแบบ plain text Critical Low Very High

Step 3 :: จัดลำดับความสำคัญของการทดสอบ (Test Prioritization)

  • เริ่มจาก Requirement ที่มีความเสี่ยงสูงสุด
  • ถ้าทรัพยากรจำกัด → ให้ทดสอบเฉพาะฟีเจอร์ที่มีความเสี่ยงระดับ High ขึ้นไปก่อน

Step 4 :: ออกแบบ Test Cases ตาม Business Risk

Test Case เชื่อมกับ BR ความเสี่ยง ประเภท
ตรวจสอบรูปแบบอีเมลที่ไม่ถูกต้อง BR1 High Functional
ตรวจสอบการสมัครด้วยอีเมลที่มีอยู่แล้ว BR2 High Business Rule
ตรวจสอบ validation ความซับซ้อนของรหัสผ่าน BR3 Very High Security
ตรวจสอบว่า DB เก็บรหัสผ่านในรูปแบบ Hash BR4 Very High Data Security

2. Risk-Based Testing + Software Architecture

Teams

  • Business
  • Architect
  • Tester/QA
  • Developer

Feature ที่ทดสอบ

  • ระบบลงทะเบียนผู้ใช้งาน (Register)

Architecture

  • Frontend: ฟอร์มลงทะเบียน (ชื่อ, อีเมล, รหัสผ่าน ฯลฯ)
  • Backend with REST API: รับข้อมูล ตรวจสอบ และบันทึกข้อมูลผู้ใช้
  • Database: จัดเก็บข้อมูลผู้ใช้ใหม่

Risk-Based Testing จะเข้ามาช่วยวิเคราะห์ว่า

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

Step 1 :: วิเคราะห์ความเสี่ยง (Risk Identification & Assessment)

แยก Component ใน Feature Register

  • Frontend: การป้อนข้อมูล (Input Validation)
  • Backend: REST API /register (Business Logic, Error Handling)
  • Database: การบันทึกข้อมูล, ความสอดคล้องของ schema

ระบุความเสี่ยงของแต่ละจุด เช่น

Component ความเสี่ยง Impact Likelihood Risk Score
Frontend ผู้ใช้กรอกอีเมลไม่ถูกต้อง แต่ระบบไม่แจ้งเตือน Medium High High
Backend API รับข้อมูลซ้ำซ้อน (Duplicate Email) High Medium High
Backend ไม่มีการเข้ารหัสรหัสผ่านก่อนเก็บ Very High Medium Very High
Database Schema ไม่ enforce unique constraint High Low Medium

Step 2 :: ใช้ Risk Matrix เพื่อวิเคราะห์ลำดับความสำคัญ

Step 3 :: ออกแบบ Test Cases ตามความเสี่ยง

  1. เขียน Test Case โดยเรียงตามความเสี่ยง
  2. กำหนดชนิดของการทดสอบ
    • Functional (เช่น กรอกข้อมูลผิด)
    • Security (รหัสผ่านไม่ได้เข้ารหัส)
    • Performance (API หน่วง)
    • Database Constraint (duplicate)

ตัวอย่าง Test Cases

Priority Test Case Component ประเภท
High กรอกอีเมลผิด format แล้วระบบไม่แจ้งเตือน Frontend Functional
Very High ตรวจสอบว่ารหัสผ่านถูกเข้ารหัสก่อนบันทึก Backend Security
High ตรวจสอบการป้องกันการใช้ email ซ้ำ Backend + DB Business Rule
Medium ส่งคำขอซ้ำแบบเร็ว ๆ เพื่อดูว่า API handle ได้หรือไม่ Backend Load/Robustness
Low กรอกชื่อที่มีความยาวเกิน 100 ตัวอักษร Frontend Edge Case

List of tools

Section Tools
Frontend Test Cypress, Playwright, Robot Framework
API Test Postman, REST Assured
Database Test SQL script, Database management tools, Data migration tools
Risk Mapping Google Sheets, Miro, Excel, Test management tools

Clone this wiki locally