Bugs Introduction

    Error adalah kesalahan manusia. Error muncul bukan hanya karena kesalahan logika pada kode yang dibuat oleh developer. Siapa pun dalam tim dapat membuat kesalahan selama fase pengembangan perangkat lunak yang berbeda. Contohnya:

  • Business Analyst mungkin salah menafsirkan atau salah memahami persyaratan.
  • Pelanggan dapat memberikan informasi yang tidak memadai atau salah.
  • Arsitek dapat menyebabkan cacat dalam desain perangkat lunak.
  • Tim juga dapat melakukan kesalahan karena persyaratan yang tidak mencukupi, tekanan waktu, atau alasan lainnya

    Bug/Defect adalah perbedaan antara hasil yang diharapkan dan hasil yang sebenarnya. Kesalahan yang ditemukan penguji dikenal sebagai Bug. Bug pada software mencerminkan ketidakmampuan atau ketidakefisienannya untuk memenuhi persyaratan dan kriteria yang ditentukan dan selanjutnya dapat mencegah aplikasi software melakukan pekerjaan yang diharapkan. Bug ini juga dikenal sebagai Defect atau Fault.

    Failure adalah konsekuensi dari Bug/Defect. Failure adalah kesalahan perilaku sistem yang dapat diamati, terjadi ketika software gagal untuk perform di real environment (production). Dengan kata lain, setelah pembuatan & eksekusi kode perangkat lunak, jika sistem tidak berfungsi seperti yang diharapkan, karena terjadinya bug/defeect, maka itu disebut sebagai Failure. Tidak semua bug menghasilkan failure, beberapa kasus mungkin kita tidak pernah menyadarinya. 

    Failure juga terjadi karena alasan berikut:

  • Kerusakan fisik atau panas berlebih pada perangkat keras dapat menyebabkan seluruh sistem fail.
  • Jika perangkat lunak tidak kompatibel dengan perangkat keras, maka sistem juga dapat bekerja secara tidak terduga.
  • Failure juga dapat terjadi oleh kondisi lingkungan seperti ledakan radiasi, medan magnet yang kuat, medan elektronik, atau polusi yang dapat menyebabkan failure pada perangkat keras atau perangkat lunak.

    Kali ini kita akan membahas lebih dalam tentang Bug/Defect/Fault karena merupakan bagian terpenting dari proses kerja Quality Assurance.

Bug Life Cycle


  • New : Saat bug dicatat dan diposting untuk pertama kalinya. Default status nya adalah 'New' (baru)
  • Open : Pada keadaan ini developer mulai menganalisa bug yang dilaporkan.
  • Assigned : Lead dev menugaskan bug tersebut ke developer. Status bug akan diubah menjadi 'Assigned'. Pada tahap ini juga dilakukan verifikasi apakah bug yang dilaporkan adalah benar merupakan kesalahan penulisan kode.
  • Fixed : Ketika developer membuat perubahan kode (code changes) yang diperlukan dan memverifikasi perubahan, maka developer dapat membuat status bug sebagai 'Fixed' dan bug diteruskan ke tim QA.
  • Test/To be Verified : Pada tahap ini, QA mulai melakukan pengujian terhadap perbaikan yang dilakukan oleh developer.
  • Reopen : Jika bug masih ada bahkan setelah bug diperbaiki oleh developer, QA mengubah status menjadi 'Reopen' ditugaskan ke developer lagi. Sekali lagi bug melewati siklus hidup. Namun ada perusahaan yang menerapkan siklus hidup dimana bug yang reopen akan langsung di fix oleh developer yang sebelumnya ditugaskan untuk memperbaiki bug tersebut. Jadi tidak perlu mengulang siklus dari awal.
  • Retest : Pada tahap ini QA melakukan pengujian ulang terhadap perbaikan dari developer.
  • Verified/Resolved : QA menguji kasus bug setelah diperbaiki oleh developer. Jika bug tidak ditemukan dalam perangkat lunak, QA menyetujui bahwa bug telah diperbaiki dan mengubah status menjadi 'Verified/Resolved'.
  • Closed : Setelah bug diperbaiki dan lolos uji oleh QA. Status bug akan diubah menjadi 'Closed', perubahan status terakhir ini bisa dilakukan oleh PO. Dev, ataupun QA. Status ini berarti bahwa bug telah diperbaiki, diuji, dan divalidasi.
Diluar siklus hidup dari bug yang sudah disebutkan di atas, ada beberapa hal lagi yang perlu dipahami
  • Rejected : Jika setelah dianalisa dan disimpulkan bahwa bug tersebut tidak dianggap sebagai bug yang sebenarnya, maka itu ditandai sebagai 'Rejected'. Analisa bug biasanya dapat dilakukan oleh seluruh anggota tim development.
  • Duplicate : Jika ditemukan bug yang sama dengan bug lainnya atau jika konsep bug cocok dengan bug lain, maka status bug diubah menjadi 'Duplicate'.
  • Deferred : Jika tim merasa bahwa bug tersebut bukanlah prioritas yang sangat penting dan dapat diperbaiki pada rilis berikutnya atau lebih dalam kasus seperti itu, status bug tersebut dapat diubah menjadi 'Deferred' (ditangguhkan).
  • Not a Bug : Jika bug tidak berdampak pada fungsionalitas aplikasi, maka status cacat akan diubah menjadi 'Not a Bug'.

Penyebab terjadinya bug

  1. Buruknya komunikasi
  2. Deadline yang mepet
  3. Software yang kompleks (banyak modul)
  4. Perubahan kode yang tidak didokumentasikan dengan baik
  5. Proses testing yang bermasalah (QA tidak bekerja dengan baik atau alat testing yang kurang lengkap atau prosedur testing yang tidak sesuai standar)

Cara menghindari bug

  1. Bangun komunikasi yang baik (daily meeting, membahas dengan menghadirkan produk owner)
  2. Gunakan tools kolaborasi yang efektif (misal Trello atau JIRA)
  3. Jangan mengerjakan dengan terburu-buru
  4. Uji kode secara rutin (untuk developer)
  5. QA melakukan pengujian dengan baik dan menyeluruh

Bug yang sering dijumpai pada UI testing

1. Cross browser adaptability bugs

Contoh: Tidak responsif atau hanya bisa di buka di Chrome

2. Form validation bugs

Contoh: Validasi error message saat salah password

3. Usability bugs

Fungsi yang tidak mudah digunakan. Contoh: Mau delete satu data saja namun terlalu banyak tahapan

4. Inconsistent in page layout across devices

Contoh: berbeda header tiap halaman, situs tidak responsif di perangkat lain

5. Broken UI Elements leading to misbehavior.

Contoh: tombol 'Perbarui Profil' di setelan profil mungkin tidak berfungsi, dan klik berulang dapat membuat aplikasi crash.

Bug Severity

    Bug Severity adalah ukuran dampak suatu bug pada pengembangan atau fungsi fitur aplikasi saat sedang digunakan. Itu tergantung pada efek bug pada sistem. Bergantung pada seberapa besar ancaman yang dapat ditimbulkan bug terhadap perangkat lunak

1. Low (Bug tidak akan mengakibatkan kerusakan sistem)

2. Minor (Menghasilkan beberapa perilaku yang tidak diharapkan atau tidak diinginkan, tetapi tidak cukup untuk mengganggu fungsi sistem)

3. Medium (penilaian sebuah bug masuk kategori medium ini tergolong subjektif. Yang menjadi pembeda bug medium dengan bug minor tentu dampaknya terhadap sistem yang memang satu tingkat lebih tinggi. Bug ini masuk dalam kategori yang perlu dibenahi karena efeknya cukup mengganggu pada alur kerja sistem.)

4. Major (Bug yang mampu meruntuhkan sebagian besar sistem)

5. Critical (Tingkat tertinggi, sistem benar-benar tidak bisa digunakan sama sekali)

Bug Priority

  1. Low (Bug dapat diperbaiki di kemudian hari. Bug lain yang lebih serius diprioritaskan)
  2. Medium (Bug dapat diperbaiki dalam proses pengembangan dan pengujian normal)
  3. High (Bug harus diselesaikan paling awal karena berdampak buruk pada sistem dan membuatnya tidak dapat digunakan)

Bug Severity vs Bug Priority

Bug Severity

  • Mengacu pada ukuran dampak bug pada fungsi perangkat lunak
  • Didorong oleh kinerja fungsi perangkat lunak
  • Nilai subjektif yang mungkin berubah selama pengembangan atau sehubungan dengan resolusi bug lain.

Bug Priority

  • Mengacu pada urutan di mana pengembang harus memperbaiki bug
  • Didorong oleh nilai bisnis dan waktu rilis
  • Nilai objektif yang kemungkinan besar tidak akan berubah secara signifikan dalam proses pengembangan perangkat lunak

    Tingkat keparahan tinggi dan status prioritas rendah berarti bahwa bug dapat menyebabkan kerusakan yang signifikan, tetapi dapat diperbaiki di kemudian hari Prioritas tinggi dan status keparahan rendah berarti bahwa bug harus segera diperbaiki tetapi tidak terlalu mempengaruhi perangkat lunak\

Cara mengklasifikasikan bug severity dan priority?

  1. Identifikasi seberapa sering bug terjadi (Walaupun bug minor, tapi akan menjadi masalah apabila sering terjadi)
  2. Ketika bug sudah ditemukan, dapat dilakukan pengujian untuk menentukan tingkat severity dan priority

High severity dan Low priority

    Sebuah situs web di render dengan banyak kekurangan di beberapa browser lawas. Logo tidak muncul, teks mengacak, gambar terlalu berpiksel. Karena ini merupakan gangguan terhadap fungsionalitas produk serta pengalaman pengguna, tingkat keparahan bug menjadi tinggi. Namun, karena masalah hanya terjadi pada browser lawas, itu tidak akan memengaruhi banyak pengguna. Oleh karena itu, prioritas bug rendah.

High severity dan High priority

    Situs web sedang diuji di Chrome dan berfungsi dengan baik. Tetapi ketika beralih ke Firefox, halaman harga menunjukkan kelemahan utama. Tombol beli untuk paket pembelian telah hilang, begitu pula teks yang menguraikan harga dan fitur terkait yang disertakan dalam setiap paket. Dalam hal ini, siapa pun yang menggunakan Firefox tidak dapat membeli produk, atau bahkan mengetahui detail produk yang ditawarkan. Karena fungsi utama jelas terpengaruh, tingkat keparahan bug tinggi. Karena fungsi yang rusak menghalangi fase utama dari perjalanan pengguna maka prioritas bug tinggi.

Low severity dan High priority

    Saat menguji fungsionalitas situs web, terlihat bahwa tombol sedikit tidak pada tempatnya saat situs dijalankan di Chrome. Mereka masih dapat diklik dengan mudah, dan melakukan apa yang mereka maksudkan. Ini berarti fungsionalitas tidak terpengaruh sehingga tingkat keparahan bug rendah. Namun, karena tombol yang tidak pada tempatnya tidak benar-benar membuat representasi visual yang menyenangkan dan situs web yang dirancang dengan buruk tentu akan membuat pengguna tudak nyaman, maka prioritas bug tinggi. Masalahnya perlu diperbaiki secepat mungkin.

Low severity dan Low priority

    Saat menguji situs web, beberapa teks ditemukan memiliki kesalahan ketik, dan font serta warna tidak sesuai dengan warna dan font desain utama situs web. Sekarang, ini pasti bug, tetapi ini jelas bukan masalah fungsionalitas yang sebenarnya. Oleh karena itu, tingkat keparahan bug rendah. Demikian pula, tidak perlu segera diperbaiki, dan karenanya prioritas bug rendah.

Materi QA: 

Komentar

Posting Komentar

Postingan populer dari blog ini

Software Testing Life Cycle

Gambar
     Pengujian adalah bagian mendasar dari setiap proses produksi. Apa pun produknya, selalu diuji kualitas dan cacatnya sebelum sampai ke pelanggan sehingga mereka menerima produk berkualitas yang berfungsi penuh. Hal yang sama berlaku untuk produk yang dikembangkan oleh perusahaan perangkat lunak juga. Dalam dunia perangkat lunak, proses pengujian secara resmi disebut Software Testing Life Cycle (STLC) .      Software Testing Life Cycle (STLC) merupakan tahapan proses pengujian yang dilaksanakan secara sistematis dan terencana. Dalam proses STLC, berbagai kegiatan dilakukan untuk meningkatkan kualitas produk. Semua fase STLC pada dasarnya mencakup daftar kegiatan yang perlu dilakukan dan memiliki entry criteria dan exit criteria yang ditetapkan. Entry Criteria dan Exit Criteria Entry Criteria merupakan suatu ketentuan yang harus kita penuhi sebelum pengujian dapat di mulai Exit Criteria merupakan ketentuan yang harus diselesaikan sebelum menyelesaikan pe...
Baca selengkapnya

Types of Testing

Gambar
     Ada banyak sekali tipe atau jenis jenis pengujian. Kali ini kita akan membahas beberapa tipe pengujian yang sering digunakan. UNIT TESTING      Unit Testing adalah jenis pengujian perangkat lunak yang dilakukan pada unit atau komponen individual. Biasanya, Unit Testing dilakukan oleh developer pada fase pengembangan aplikasi. Setiap unit dalam Unit Testing dapat dilihat sebagai metode, fungsi, prosedur, atau objek. Developer sering menggunakan automation tools seperti NUnit, Xunit, JUnit untuk mengeksekusi pengujian.\ WHITE BOX TESTING      White box testing adalah teknik pengujian di mana struktur internal atau kode aplikasi terlihat dan dapat diakses oleh QA. Dalam teknik ini, mudah untuk menemukan celah dalam desain aplikasi atau kesalahan dalam logika bisnis. Dalam melakukan verifikasi White Box Testing Ada beberapa hal yang dapat diuji: Security. apakah software ini memiliki sistem keamanan yang baik Broken or poorly structured Sp...
Baca selengkapnya

API Testing using Postman

Gambar
       Ketika membuat sebuah aplikasi berupa REST API atau GraphQL. Terdapat tools atau alat yang dapat digunakan untuk membantu dalam proses pengujian aplikasi yang telah dibuat. Salah satu tools tersebut adalah Postman.      Postman merupakan salah satu tools yang paling populer untuk melakukan pengujian API. Postman muncul pada tahun 2012 sebagai proyek sampingan oleh Abhinav Asthana untuk menyederhanakan alur kerja API dalam pengujian dan pengembangan. API memungkinkan aplikasi perangkat lunak untuk berkomunikasi satu sama lain melalui panggilan API. 1. Registrasi dan Login Jika belum memiliki akun, daftar melalui link berikut  https://identity.getpostman.com/signup . Setelah melakukan registrasi, silahkan langsung login menggunakan data yang sudah diregistrasikan Setelah Login, kita dapat mengganti Team Name dan Team Domain melalui  https://qabootcamp.postman.co/settings/team/general . 2. Instalasi      A...
Baca selengkapnya