Risk Based Testing (RBT) digunakan untuk memprioritaskan test case berdasarkan risiko kegagalan berdasarkan kemungkinan dan dampak kegagalan, sehingga test kritis dapat diselesaikan tepat waktu dengan sumber daya terbatas. RBT memetakan skor risiko setiap test case untuk mengurangi jumlah test yang dijalankan tanpa mengurangi kualitas pengujian.

1. Internal
#4
Risk Based Testing (RBT) Approach

2. Internal
Durasi Tesing
yang Singkat Budget &
Resource
yang
Terbatas
Tuntutan
Qualitas yang
Tinggi
Dalam melakukan testing, sering kali kita dihadapkan pada kondisi dimana kita harus menyelesaikan suatu testing
dalam waktu yang sangat singkat, sedangkan jumlah test case yang harus ditest sangat banyak, tuntutan qualitas testing
yang tinggi, serta resource tester dan budget kita terbatas.
Jumlah
Test Case
yang Sangat
Banyak

3. Internal
Durasi Tesing
yang Singkat
Budget &
Resource yang
Terbatas
Tuntutan
Qualitas yang
Tinggi
Dalam melakukan testing, sering kali kita dihadapkan pada kondisi dimana kita harus menyelesaikan suatu testing dalam waktu
yang sangat singkat, sedangkan jumlah test case yang harus ditest sangat banyak, tuntutan qualitas testing yang tinggi, serta
resource tester dan budget kita terbatas.
Jumlah Test
Case yang
Sangat Banyak
Risk Based Testing (RBT) Approach
Salah satu hal yang dapat kita lakukan untuk bisa deal dengan kondisi ini adalah dengan melakukan

4. Internal
Risk Based Testing (RBT) adalah metode untuk memprioritaskan test case-test case yang akan dieksekusi berdasarkan
tingkat resiko apabila terjadi failure/error terkait suatu test case pada production environment, dimana prioritas ini
ditentukan dengan menentukan nilai LoF (Likelihood of Failure) dan IoF (Impact of Failure) dari tiap-tiap test case.
Ouput dari RBT approach ini adalah list test case yang sudah difilter berdasarkan prioritasnya yang bila test case tersebut
dieksekusi maka akan dapat selesai dalam waktu yang diharapkan dengan tetap menjaga kualitas hasil testing yang dilakukan.

5. Internal
Likelihood of Failure (LoF) adalah kondisi yang menunjukan besarnya
kemungkinan terjadinya suatu failure/error/defect pada suatu test case,
dimana nilainya adalah Likely, Quite Likely, atau Unlikely.
Kriteria-kriteria di bawah ini adalah salah satu CONTOH kriteria yang bisa
digunakan untuk menentukan nilai nilai LoF.
▪ Likely :
▪ category test case nya complex dan dalam 3 sprint sebelumnya selalu
terjadi failure/defect, atau
▪ Category test case nya complex dan di dalam 1 bulan terakhir di
production environment terjadi error/incident terkait denagn test
case tersebut.
▪ Quite Likely :
▪ Category test case nya complex dan test case tidak masuk dalam
scope SIT, atau
▪ Category test case nya complex atau medium, dan defect penetration
rate di SIT lebih dari 30%.
▪ Unlikely :
▪ Category test case simple dan tidak pernah terjadi failure/defect pada
3 sprint sebelumnya, atau
▪ Category test case simple dan total defect penetration di SIT lebih
kecil dari 2%.

6. Internal
Impact of Failure (IoF) adalah kondisi yang menunjukan besarnya impact
dari failure/defect yang terjadi pada suatu test case bila failure/defect
tersebut terjadi di production environment, dimana impact ini dilihat dari
point of view bisnis.
Di bawah ini adalah salah satu CONTOH kriteria impact yang bisa digunakan
sebagai acuan untuk menentukan nilai nilai IoF.
▪ Minor :
▪ Failure/error hanya menyebabkan terganggunya feature-feature yang
cosmetic, seperti menu help tidak dapat ditampilkan sedangkan fungsi
utama aplikasi masih dapat digunakan
▪ tidak berimpact ke revenue sama sekali.
▪ Visible :
▪ Failure/error menyebabkan terganggunya sebagian fungsi utama
aplikasi yang berimpact pada revenue, misalnya fungsi pembelian
pulsa bisa dilakukan tapi hanya untuk 1 jenis product saja.
▪ Failure/error sangat berimpact pada customer experience pengguna,
tapi aplikasi masih bisa digunakan.
▪ Interruption :
▪ Failure/error menyebabkan terhentinya lebih dari 80% fungsi utama
aplikasi.
▪ Failure/error menyebabkan semua fungsi pembelian pada aplikasi
tidak dapat berfungsi dengan baik sehingga memiliki impact revenue
yang sangat besar.

7. Internal
CONTOH Penggunaan Risk Based Testing
Dari total 341 Test Case yang ada, setelah dilakukan mapping
LoF dan IoF nya maka hasilnya adalah sebagai berikut :
▪ Test case dengan Prioritas 1 (P1) = 50 TC
▪ Test case dengan Prioritas 2 (P2) = 95 TC
▪ Test case dengan Prioritas 3 (P3) = 45 TC
▪ Test case dengan Prioritas 4 (P4) = 110 TC
▪ Test case dengan Prioritas 5 (P5) = 41 TC
Secara normal, dengan resource yang ada, maka testing untuk
341 TC ini akan selesai dalam 6 hari.
Agar dapat menyelesaikan testing dalam 5 hari, maka kita harus
mengurangi jumlah test case dengan cara mendrop test case
yang failure/defectnya paling jarang terjadi dan impact
failurenya paling kecil, dalam case ini adalah TC dengan Priority
5 (P5).
Dengan mendrop TC dengan Priority 5 (P5), maka total jumlah
TC yang akan dieksekusi menjadi 300 (341-41) dan dengan
resource yang ada maka 300 TC ini akan dapat diselesaikan
dalam 5 hari ( 2 (tester) x 30 (TC/tester/day) x 5 (hari) = 300).
Testing suatu project dengan jumlah test case 341 TC harus
dapat diselesaikan dalam waktu tidak lebih dari 5 hari
dengan hanya menggunakan 2 orang tester, dimana
Productivity Rate (PR) tester adalah 30TC/tester/day.