Download as PDF, PPTX
Uploaded byRiswan
Risk Based Testing
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.
Softwareâ—¦
Risk Based Testing
- 1. Internal #4 Risk Based Testing(RBT) Approach
- 2. Internal Durasi Tesing yang SingkatBudget & 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 RiskBased 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.