Bedanya Severity dan Priority dalam Pengujian | Quality Assurance

 

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.

Continue reading Bedanya Severity dan Priority dalam Pengujian | Quality Assurance

Bagaimana cara mengidentifikasi bug dengan benar ?

Sumber: Pixabay.com

Ketika kamu sedang melakukan pengujian pada suatu aplikasi. Lalu tiba-tiba kamu menemukan sesuatu hal yang tidak bekerja sesuai dengan yang semestinya. Apa yang harus kamu lakukan ?

Jawaban yang biasa diberikan oleh beberapa QA adalah saya akan langsung memberitahukan ke developer bahwa ada sesuatu pada aplikasi yang saya test tidak bekerja dengan semestinya. Menurut saya jawaban tersebut sangat-sangat tidak direkomendasikan yah.. Dan beberapa QA lainnya menjawab Saya akan mencoba lagi dengan sample scenario lainnya dan juga saya akan menghapus cache sebelum saya mencobanya lagi. Menurut saya, pasti akan ada bermacam-macam metode yang bisa kita lalukan untuk mengulang supaya mendapatkan error yang sama. Jawaban tersebut bagi saya pun masih kurang bijak sebagai seorang QA.

Lantas bagaimana caranya agar kita bisa mengidentifikasi akar masalah dari error yang kita dapatkan sebelum kita memberitahu soal temuan ini ke tim developer ?

Ada 2 cara untuk melakukannya :

1. Perlihatkan bukti layar atau screenshot. Dimanakah letak fungsi yang tidak bekerja sesuai dengan yang semestinya itu.
2. Lakukan debugging secara mandiri. Cari tahu akar masalahnya melalui log yang tersimpan dan infokan kepada tim developer bahwa ditemukannya suatu error dengan melampirkan detail log yang terjadi.

Kira-kira seperti itu sebuah tim development mengharapkan seorang QA bekerja secara default ketika menemukan sebuah bugs pada aplikasi yang dilakukan testing.

Sedikit tips, dari saya…

Kalau teman-teman sedang melakuan pengujian pada website, temen-temen bisa manfaatkan Console log dan Network pada Insepect element di browser yang sedang teman-teman gunakan, untuk melihat apa saja yang missing. Agar ketika melaporkan suatu masalah ke developer, si developer juga bisa lebih cepat dalam menangani bug tersebut karna root cause nya sudah didapatkan.

Untuk membuat bug secara detail, formatnya sebagai berikut :

1. buat Repro Steps (Langkah-langkah untuk mengulang bug)
2. cantumkan sample data yang terkendala
3. Hasil yang diharapkan ketika step dilakukan
4. Hasil yang terjadi (error yang didapat)
5. Timestamp (Optional, untuk mempermudah tim dev utk mencari Log berdasarkan kurun waktu)
6. Screenshot

Continue reading Bagaimana cara mengidentifikasi bug dengan benar ?

Pekerjaan sebagai Quality Assurance yang sebenarnya bukan cuma ngetest

Seorang yang menjabat sebagai Leader QA dan seorang HR, untuk merekrut seorang QA yang benar-benar tahu posisinya sebagai QA memang tidak mudah dan terbilang sulit. Tidak jarang yang direkrut adalah orang-orang yang hanya dipercayakan bahwa dia bisa “nge-test” suatu aplikasi.. iya hanya itu..

Nah, Sebenarnya, QA yang benar itu sepertu apa ?

Berikut adalah beberapa point yang saya Highlight sebagai Software Quality Assurance dalam kurun waktu 3 tahun lebih.

QA dan developer mengerjakan proyek yang sama dengan “tujuan” yang sama. Untuk mendapatkan produk yang berkualitas

QA bukan musuh bagi programmer. QA tidak bertujuan untuk “Merusak Produk” lalu menggosok kedua tangan sembari tertawa jahat. QA tidak akan bersuka cita ketika menemukan masalah, bugs, cacat dan error!

QA akan mengeksplorasi aplikasi untuk mendapatkan status kualitas produk. Agar bermanfaat bagi proyek, QA harus bertindak seolah-olah sebagai Konsumen atau User. Kemudian, perihal Bug, Bug bukanlah produk yang dapat dirilis. Bug tidak membawa manfaat. Hanya kegiatan yang bertujuan untuk mencapai tujuan bersama untuk mendapatkan produk berkualitas yang membawa manfaat.

Dan untuk bisa mencapai hal itu, seorang QA harus dapat :

1. Mengerti tujuan pada proyek yang dikerjakan
2. Memperhitungkan kondisi eksternal (Prioritas, Tenggat waktu, Tujuan, Tugas yang memiliki kepentingan lebih tinggi)
3. Dapat mengetahui APA yang perlu dilakukan SEKARANG untuk dapat membantu pengerjaan proyek mencapai tujuannya.

Jika pengujian tidak efisien dan bug yang ditemukan terlambat, Maka akan ada semakin banyak bug yang akan ditemukan di lain waktu: lokalisasi bug yang buruk akan memperhambat pengerjaan dari developer apalagi kalau seorang QA tidak memberikan tingkat prioritas dan tingkat keparahan dari bug yang ditemukan.

Selain itu, umumnya seorang QA berpikir seperti :“Bagaimanapun aku harus bisa menemukan banyak bugs dan langsung melaporkan itu ke developer” , Jika QA yang benar-benar tahu bahwa dia seorang QA, maka ia akan berpikir: “Apa yang dibutuhkan proyek sekarang, dalam format apa dan dengan prioritas apa?”

Seorang QA harus tau bagaimana merancang Test Desain (Design Test)

Seorang QA harus mengetahui bagaimana merancang sebuah test desain. untuk melakukan ini, harus diketahui terlebih dahulu paling tidak analisis testnya. Tergantung pada kondisinya, pengujian dapat dilakukan secara eksploratif atau sesuai dengan Acceptance Criteria. Pengujian juga tidak boleh dilakukan tanpa berpikir “apa yang akan terjadi jika saya menekan tombol ini”, Tentunya harus sesuai dengan hasil analisis: apa yang perlu diuji, dalam prioritas apa dan bagaimana metode yang paling efisien dalam melakukan hal itu ?

Think First, Then Test!

Seorang QA harus Ahli dalam hal komunikasi 

Siapa lagi dong, kalo bukan QA yang harus menanggung kabar buruk kepada developer nya ? Hal terburuk yang dapat dilakukan oleh seorang QA adalah ketika menemukan sebuah bug dan memberi tahu kepada developer “Wah, Aplikasi nya rusak!”.

Seorang QA membutuhkan lebih dari sekedar menemukan bug. QA perlu melakukan segalanya agar sebisa mungkin dapat mempermudah developer serta dapat mempersingkat waktu bagi developer dalam memperbaikinya. Mungkin dengan menambahkan detail screenshot, waktu, sample data, detail device yang digunakan atau history log pada saat terjadinya bug. Setiap developer, dalam proses pengembangan software tidak luput dari yang namanya melakukan kesalahan. Maka dari itu, dengan adanya tim QA dalam proses pengujian, akan membantu sebuah proyek menjadi lebih baik dengan menemukan suatu kelemahan pada proyek yang dikerjakan. Seorang QA tidak bertujuan untuk menyinggung developer, mencari kesalahan developer ataupun menusuk hidungnya dengan 2 jari dan menyeret dia ke dalam bug yang kita temui.

Catatan : Terkadang ada situasi di mana developer tidak dapat memperbaiki bug yang kita temukan. Pada situasi ini, kamu bisa diskusikan case tersebut dengan Project Manager dan bersama-sama untuk mencari solusi terhadap bug tersebut.

Seorang QA harus mempunyai kemampuan analisis yang baik

Seorang QA engineers dengan latar belakang jurusan IT biasanya memiliki pemikiran analitis yang terlatih. Yang mungkin dimiliki atau tidak dimiliki oleh QA engineers dengan latar belakang yang lainnya.

Dalam hal keterampilan dan tools yang digunakan, seorang QA akan menggunakan tools serta keterampilannya sesuai dengan proyek apa yang sedang dikerjakan. Bagaimanapun, hal ini akan berguna jika kamu memahami prinsip dari client-server architecture, version control systems, serta punya pemahaman dengan database dan log. Penting sekali untuk memahami cara kerja aplikasi yang dikerjakan dan juga cara kerja API. Pengetahuan dasar mengenai SQL, HTML, serta kemampuan untuk membaca bahasa pemrograman dasar seperti Java, C atau Python. Pada awalnya, pengetahuan ini akan cukup secara efektif membantu kamu dalam melakukan pengujian serta menemukan akar penyebab bug. Ditambah lagi kalau kamu sudah bisa melakukan Automation Test menggunakan tools Automation.

Kesimpulan

Jadi, apakah kamu sudah siap menjadi seorang QA atau kamu adalah seorang lulusan baru yang sedang mempertimbangkan QA sebagai karir selanjutnya ?

Saya harap pemikiran saya dapat membantu kamu untuk bisa mengevaluasi diri sendiri dan memutuskan apakah bidang ini cocok untuk kamu.

Love your job, learn and you will become the leader in your field!

Jika kamu berfikir bahwa artikel ini menarik dan cukup membantu, jangan lupa untuk share artikel ini ke teman-temanmu.

Continue reading Pekerjaan sebagai Quality Assurance yang sebenarnya bukan cuma ngetest