-
Alamat asli: Mengapa bug tidak diperbaiki
Penulis: Alan Page, Direktur Keunggulan dalam Teknik Pengujian di Microsoft, salah satu penulis buku Bagaimana Kami Menguji Perangkat Lunak di Microsoft (diterjemahkan dalam bahasa Mandarin sebagai "Cara Pengujian Perangkat Lunak Microsoft").
Terjemahan: Lu Yueli, Lu Mengyan, Wang Hong
Akhir-akhir ini saya menemui semakin banyak orang yang terkejut bahwa kami akan merilis produk buggy. Yang mengejutkan saya adalah banyak dari orang-orang ini adalah penguji perangkat lunak, dan saya pikir mereka pasti sudah mengetahui hal ini. Saya sarankan Anda membaca artikel Eric Sink sebelumnya (tapi bagus sekali) terlebih dahulu. Saya tidak yakin seberapa banyak lagi yang dapat saya sumbangkan pada topik ini, namun saya ingin mencobanya.
Banyak bug yang tidak layak diperbaiki. "Apakah Anda seorang penguji?", Anda akan berteriak kepada saya, "Penguji adalah penjaga kualitas produk." Saya bisa mengulanginya lagi (bila perlu) banyak bug yang tidak layak diperbaiki. "Izinkan saya memberi tahu Anda alasannya. Dalam kebanyakan kasus, memperbaiki bug memerlukan perubahan kode. Dan mengubah kode memerlukan investasi sumber daya (waktu) dan menimbulkan risiko. Itu menyebalkan, tetapi itu benar. Terkadang, jika Risiko dan investasi jauh lebih besar daripada manfaat memperbaiki bug, jadi kami tidak akan memperbaikinya.
Keputusan kami mengenai apakah akan memperbaiki bug tidak, dan tidak seharusnya, berdasarkan pada "perasaan". Saya suka menggunakan konsep “kesakitan pengguna” untuk membantu saya mengambil keputusan. Saya menggunakan tiga faktor utama untuk mempertimbangkan dan mengidentifikasi "kesakitan pengguna":
1. Tingkat Keparahan - Apa dampak bug ini - apakah seluruh program akan crash? Apakah ini akan menyebabkan informasi pengguna hilang? Atau tidak terlalu serius? Apakah ada solusi yang lebih mudah? Atau itu hanya masalah yang tidak relevan?
2. Frekuensi - Apakah pengguna sering mengalami masalah ini? Apakah ini bagian dari alur kerja utama program? Ataukah tersembunyi pada fitur yang tidak umum digunakan? Masalah-masalah kecil yang ada pada bagian-bagian program yang paling sering digunakan mungkin perlu diperbaiki, sementara beberapa masalah besar yang ada pada bagian-bagian program yang jarang digunakan mungkin harus dikesampingkan.
3. Dampak terhadap pelanggan – Jika Anda telah melakukan pekerjaan rumah Anda dengan baik, Anda seharusnya sudah mengetahui siapa pelanggan Anda dan berapa banyak (atau berapa banyak yang Anda harapkan) pengguna di setiap kelompok pelanggan Anda. Kemudian Anda perlu menilai apakah masalah ini akan mempengaruhi setiap pengguna, atau hanya beberapa orang. Jika Anda dapat melacak bagaimana pelanggan menggunakan produk Anda, Anda bisa mendapatkan data yang lebih akurat.
Ketiga faktor di atas merupakan sebuah rumus. Tetapkan rentang nilai untuk masing-masing faktor di atas dan lakukan beberapa penghitungan - Anda dapat langsung menjumlahkan, mengalikan, atau menambah bobot berdasarkan aplikasi dan faktor pasar Anda. Misalnya, kita hanya perlu melakukan penjumlahan dan menetapkan rentang numerik 10 poin untuk setiap bug.
Bug #1: Misalnya, ini adalah bug yang membuat program crash (10 poin), ada di sebagian besar program (10 poin), dan mempengaruhi 80% pelanggan (8 poin), jadi bug ini menyebabkan "kesakitan pengguna" "Volumenya 28 poin dan kami yakin kami akan memperbaikinya.
Bug #2: Ini hanya bug pengaturan (2 poin), muncul di jendela sekunder (2 poin), dan bagian program di mana bug berada hanya akan digunakan di versi yang lebih lama (2 poin). Oleh karena itu, nilai "kesakitan pengguna" dari bug ini adalah 6 poin, dan kami mungkin tidak akan memperbaikinya.
Sayangnya, banyak situasi yang tidak sesederhana di atas. Bug #3 adalah masalah kehilangan data (10 poin) yang ada di sebagian besar aplikasi tetapi hanya gagal dalam keadaan tertentu (5 poin) (omong-omong, datanya subjektif). Riset pelanggan membuktikan jarang digunakan (2 poin). Oleh karena itu, nilai "kesakitan pengguna" adalah 17 poin. Ini adalah data yang ambigu, yang dapat diubah atau tidak. Di satu sisi, investasi yang diperlukan untuk memperbaikinya mungkin tidak sepadan, namun selama masalahnya dipahami dan tidak ada titik buta, mengabaikan bug mungkin merupakan pendekatan yang tepat.
Di sisi lain, Anda harus mempertimbangkannya dengan bug lain di sistem. Kami menerapkan efek "Jendela Rusak" di sini - jika ada terlalu banyak bug ambang menengah dalam aplikasi, kualitas produk (atau setidaknya, persepsi kualitas) akan sangat terpengaruh. Ketika Anda mempertimbangkan setiap bug dalam sistem, Anda juga harus mempertimbangkan bug lain (yang diketahui) dalam sistem, dan menggunakannya untuk menganalisis dan memutuskan bug mana yang perlu diperbaiki dan mana yang tidak layak diperbaiki.
Memang merupakan hal yang sangat buruk jika terdapat bug pada perangkat lunak yang dirilis secara resmi - namun berdasarkan alat pengembangan dan bahasa pengembangan yang ada, kami belum menemukan solusi yang lebih masuk akal.
Mengisi kembali:
Saat saya menulis ini, saya rasa saya melewatkan faktor keempat dalam rumusnya: tanggal rilis. Faktor ini juga memainkan peran penting dalam keputusan untuk memperbaiki/tidak memperbaiki bug seiring dengan semakin dekatnya tanggal rilis. Namun, saya tidak yakin apakah itu faktor keempat, atau berapa ambang batas jumlah "kesakitan pengguna" yang diperlukan untuk memperbaiki bug menjelang rilis.