SEVERITY
Pertama, kita harus mengerti terlebih dahulu apa itu Severity dan bagaimana cara memutuskannya. maksudnya, seberapa parah temuan dari cacat yang didapatkan.
Severity menentukan sejauh mana bug tertentu dapat membuat dampak pada aplikasi atau sistem. Severity adalah konsep untuk menunjukkan bug pada sistem seberapa kritiskah bug tersebut dan apa dampak bug tersebut pada fungsionalitas seluruh sistem. Tingkat keparahannya adalah parameter yang ditetapkan oleh tester saat ia membuka bug dan terutama dalam kendali tester.
1. Critical atau Stopper (S1)
Bug yang benar-benar menghambat atau menghalangi pengujian produk / fitur adalah bug kritis.
Misalnya: Di penyedia layanan email seperti Yahoo atau Gmail, setelah mengetik nama pengguna dan kata sandi yang benar, sistem crash atau muncul pesan kesalahan, bug ini diklasifikasikan sebagai critical karena bug ini membuat seluruh aplikasi tidak dapat digunakan.
2. Mayor atau Parah (S2)
Setiap fitur utama yang diterapkan yang tidak memenuhi persyaratan / kasus penggunaannya dan berperilaku berbeda dari yang diharapkan, fitur utama tersebut dapat diklasifikasikan sebagai Major Severity. Bug tersebut terjadi ketika fungsi berfungsi terlalu jauh dari harapan atau tidak melakukan apa yang seharusnya dilakukan. Sebagai contoh bug pada login.
Misalnya: Sebagai contoh akun sosmed seperti facebook dan twitter jika terdapat bug dengan perilaku user dapat login menggunakan password yang tidak valid.
Bug tersebut sangat fatal jika user mencoba login dengan akun user yang lain dan memiliki niat jahat.
3. Moderate atau Normal (S3)
Bug Moderate terjadi ketika produk atau aplikasi tidak memenuhi kriteria tertentu atau masih menunjukkan beberapa perilaku yang tidak wajar, namun fungsi secara keseluruhan tidak terpengaruh.
Misalnya: Di penyedia layanan email seperti Yahoo atau Gmail, ada opsi yang disebut “Syarat dan Ketentuan” dan dalam opsi itu akan ada banyak tautan mengenai syarat dan ketentuan situs web ketika satu di antara banyak tautan tidak berfungsi baik, itu disebut Severity Minor karena hanya mempengaruhi fungsi kecil aplikasi dan tidak memiliki dampak besar pada kegunaan aplikasi.
4. Low atau Kecil (S4)
Bug Minor terjadi ketika hampir tidak ada dampak pada fungsi, tetapi masih merupakan bug yang valid yang harus diperbaiki.
Misalnya: Di penyedia layanan email seperti Yahoo atau Gmail, Anda akan melihat “Halaman Lisensi” jika ada kesalahan ejaan atau ketidaksejajaran di halaman, bug ini diklasifikasikan sebagai low.
PRIORITY
Priority menentukan seberapa cepat waktu penyelesaian bug . Jika ada beberapa bug, Priority memutuskan bug mana yang harus diperbaiki dan diverifikasi segera.
Saat membuka bug, tim Tester umumnya menetapkan prioritas pada awalnya saat ia melihat produk dari perspektif pengguna akhir. Sejalan dengan ini, berikut adalah tingkatan yang berbeda:
1. Intermediate (P1)
Ini harus segera diperbaiki dalam waktu 24 jam. Ini umumnya terjadi dalam kasus ketika seluruh fungsionalitas diblokir dan tidak ada pengujian yang dapat dilanjutkan sebagai akibatnya. Atau dalam kasus lain tertentu jika ada kebocoran memori yang signifikan, maka umumnya bug diklasifikasikan sebagai prioritas -1 yang berarti program / fitur tidak dapat digunakan dalam keadaan saat ini.
2. High (P2)
Setelah bug immediate diperbaiki, bug yang memiliki prioritas ini adalah kandidat berikutnya yang harus diperbaiki untuk setiap kegiatan pengujian agar sesuai dengan kriteria “closed”. Biasanya ketika fitur tidak dapat digunakan sebagaimana mestinya karena bug program atau bahwa kode baru harus ditulis, bug mungkin memenuhi syarat untuk prioritas 2.
3. Medium (P3)
Bug dengan prioritas ini harus dipertimbangkan untuk diperbaiki karena dapat juga menangani masalah fungsi yang tidak sesuai harapan. Semisal ada kesalahan pada pesan error yang tampil tidak sesuai dengan yang semestinya, maka kategori priority ini dapat dikualifikasikan sebagai bug dengan tingkat medium (P3).
4. Low (P4)
Bug dengan prioritas rendah menunjukkan bahwa pasti ada masalah, tetapi tidak harus diperbaiki saat itu juga. Namun, ini harus diperbaiki sebelum proses deployement dilakukan. Biasanya, bug ini terjadi pada salah pengetikkan.
Berikut adalah table perbedaan singkat dari Severity dan Priority.
Cara cerdas untuk Test ulang ketika bug sudah diperbaiki/fixed
Ketika tim dev sudah berhasil memperbaiki Bug yang diterima dan bola sudah kembali kepada tim Tester, lalu yang harus dilakukan adalah tim Tester harus mengujinya kembali bug tersebut. Bagaimana caranya ?
Simpel nya, pasti tim QC akan menjawab, Ya… Kita akan ngetes ulang bahwa secara fungsionalitas bug tersebut sudah bekerja sesuai dengan yang semestinya atau belum. Mungkin jawabannya seperti itu, akan tetapi.. itu aja belum cukup menurut saya.
yang harus dilakukan sebagai seorang Tester adalah dengan menanyakan Scope mana perbaikan yang dilakukan oleh tim dev.. fungsi tersebut berkaitan atau berelasi dengan fitur yang mana aja, lalu kita test ulang secara menyeluruh (Regression Testing) pada fitur yang sekiranya berkaitan dengan bug tersebut.karena kita tidak tahu dampak nya yang terjadi pada Source code yang diimplementasikan oleh tim dev agar bug tersebut bisa solved. Sekiranya seperti itu..
Akhir kata,
Jika kamu berfikir bahwa artikel ini menarik dan cukup membantu, jangan lupa untuk share artikel ini ke teman-temanmu.
Referensi Artikel ini :
.png)
0 komentar:
Posting Komentar