Departemen Quality Assurance (QA) mencari bug dalam perangkat lunak. Metode bervariasi dari perusahaan ke perusahaan, tetapi ini biasanya dilakukan oleh karyawan yang terbiasa dengan perangkat lunak. Mereka menggunakannya dengan berbagai cara dan mencoba menemukan bug yang telah dilewatkan oleh pengembang.
Istilah QA dapat merujuk pada proses itu sendiri, ke organisasi, serta ke penguji individu dalam organisasi ini. Biasanya, penguji dalam organisasi penjaminan mutu disebut "QA". Dalam artikel ini, untuk konsistensi, kami akan menggunakan QA singkatan umum dan bukan "penguji kualitas" yang lebih tepat.
Perusahaan yang berbeda memiliki tanggung jawab QA yang berbeda untuk kualitas produk secara keseluruhan. Kadang-kadang istilah "jaminan kualitas" tidak sepenuhnya berlaku untuk departemen ini jika hanya mencari bug dan menghitung jumlahnya.
Berikut ini adalah individu yang bermasalah di departemen QA:
Selang kebakaran
Penguji yang melaporkan begitu banyak laporan bug dengan sangat cepat sehingga tim pengembang tidak akan pernah selesai.
- Dapat bermutasi menjadi alarmis
- Berbahaya jika dikombinasikan dengan manajer proyek seperti statistik
- Probabilitas koreksi: tinggi
- Bahaya untuk proyek: tinggi
Masalah
Jika bug ditemukan, penting untuk membuat laporan yang jelas dan segera menugaskannya ke pengembang yang sesuai. Namun, beberapa penguji dapat menemukan bug lebih cepat daripada tim pengembang memperbaikinya. Karena itu, daftar bug terus bertambah, dan semuanya tidak pernah bisa ditutup.
Sekilas, mungkin terlihat ada masalah dengan kualitas produk, tetapi ini tidak selalu terjadi. Tidak seperti tester konvensional, yang bekerja dengan program yang sangat buggy, selang kebakaran menghasilkan longsoran laporan dengan satu atau beberapa sifat karakteristik:
- Laporan mereka kurang terperinci, yang memungkinkan pelaporan kesalahan yang lebih cepat.
- Banyak bug adalah duplikat dari yang lain, karena mereka hanya variasi dari satu alasan utama.
- Tidak ada waktu untuk mereproduksi kesalahan, karena cukup melihatnya sekali untuk menulis laporan.
Penguji selang kebakaran sering kali muncul di bawah tekanan langsung atau tidak langsung perusahaan:
semakin banyak kesalahan yang Anda temukan, semakin baik Anda melakukan pekerjaan Anda . Ini mengarah pada fakta bahwa penguji QA, yang dengan hati-hati memonitor akar penyebab kesalahan dan melaporkannya dengan jelas dan ringkas, dianggap kurang produktif daripada selang kebakaran yang mengeluarkan jumlah laporan maksimum per unit waktu.
Kegiatan penguji tersebut dapat menyebabkan kepanikan pada proyek, karena tampaknya produk tersebut berkualitas buruk, dan proyek sekarang terlambat. Pengaruh mereka terhadap moral bisa langsung dan dramatis: tim pengembangan berdoa untuk mengganggu aliran laporan bug.
Solusi
Sebelum memasang selang kebakaran, penting untuk mengidentifikasi secara akurat dan tidak membingungkannya dengan QA efektif yang bertabrakan dengan sistem yang sangat bermasalah. Bukti paling jelas datang dari keluhan pengembang:
- Sebagian besar kesalahan adalah duplikat.
- Banyak bug memiliki akar penyebab yang sama, sehingga mereka dapat dilaporkan sebagai satu bug.
- Pesan kesalahan tidak mengandung detail.
Untuk memperbaiki situasi, selang kebakaran harus dijelaskan bahwa tidak ada insentif untuk melaporkan sejumlah besar kesalahan, dan tujuannya adalah untuk meningkatkan kualitas sistem dan membantu pengembang. Setelah itu, kualitas produk harus meningkat pada kecepatan yang sama (atau lebih baik), tetapi tanpa panik.
Jaksa penuntut
QA, yang setelah setiap bug ditemukan menuduh pengembang tidak menguji program mereka.
- Dapat bermutasi menjadi alarmis
- Berbahaya jika dikombinasikan dengan manajer proyek seperti statistik
- Probabilitas koreksi: tinggi
- Bahaya untuk proyek: rendah
Masalah
Secara teoritis, pengembang dapat menemukan dan memperbaiki bug apa pun sebelum mentransfer produk ke departemen QA. Oleh karena itu, beberapa penguji menganggap setiap kesalahan yang ditemukan sebagai bukti lain bahwa pengembang tidak menguji pekerjaan mereka dengan cukup baik. Argumen yang tak terbantahkan ini memungkinkan jaksa untuk bahkan lebih keras menyatakan pendapat yang menolak tentang tim pengembangan.
Jaksa penuntut menggerogoti moral tim Alih-alih membantu meningkatkan kualitas produk, ia mencoba membuktikan bahwa tim pengembangan tidak melakukan pekerjaan. Setiap kesalahan ditambahkan ke tumpukan bukti bahwa pengembang terlalu mengandalkan QA daripada mengidentifikasi bug sendiri.
Sayangnya, jaksa diciptakan sebagai hasil dari proses yang khas dan cukup dapat diprediksi:
- Kesalahan kritis telah terdeteksi dalam produksi.
- Penguji dituduh kehilangan bug ini.
Ini terjadi terlalu sering, dan karena itu QA secara alami membela diri dengan menggunakan argumen yang tak terbantahkan.
Solusi
Sebelum mengoreksi seorang penuduh, suatu organisasi harus terlebih dahulu berhenti menyalahkan QA untuk bug produksi. Mereka yang melakukan ini perlu dilatih dalam metode yang lebih produktif untuk meningkatkan kualitas perangkat lunak.
Ketika organisasi berhenti menyalahkan QA untuk bug dalam produksi, Anda dapat memperbaiki penuduh-tester dengan mengundangnya untuk mengubah pikiran dan sikapnya.
Perlu disampaikan kepadanya bahwa pengembangnya hanya manusia biasa, dan semua orang cenderung membuat kesalahan. Departemen QA harus memberikan kompensasi untuk properti manusiawi pengembang ini, bertindak sebagai perlindungan terhadap kesalahan yang memengaruhi pelanggan. Selain itu, karena proses pengkodean yang menjemukan dan menjemukan, sangat mudah bagi pengembang untuk tidak melihat hutan di balik pepohonan: ia begitu fokus dalam memecahkan masalah tertentu sehingga ia lupa memeriksa hal-hal yang tampaknya jelas.
Perubahan sikap: kita harus ingat bahwa kita semua bekerja dalam sebuah tim, kawan seharusnya tidak saling menyalahkan karena melakukan kesalahan, tetapi harus membantu untuk memperbaikinya demi kebaikan tim. Sangat penting bagi QA untuk menjalin kemitraan dengan tim pengembangan demi proyek, dan proses yang tidak terputus untuk mendeteksi bug, pelaporan, dan siklus perbaikannya sangat penting untuk kualitas produk.
Alarmis
QA, yang menyatakan bahwa seluruh produk memiliki tingkat kualitas yang tidak dapat diterima, sementara pendapatnya hanya didasarkan pada kesan yang dangkal.
- Dapat bermutasi pada penuduh atau selang kebakaran
- Berbahaya dalam kombinasi dengan manajer proyek seperti pesimis
- Probabilitas koreksi: tinggi
- Bahaya untuk proyek: tinggi
Masalah
Pada intinya, fitur aplikasi yang berbeda memiliki kualitas yang berbeda. Beberapa mungkin relatif sederhana atau dikembangkan oleh pengembang yang sangat terampil, dan karena itu ada sedikit atau tidak ada kesalahan. Lainnya relatif canggih atau dikembangkan oleh pengembang yang kurang berpengalaman - dan karena itu penuh dengan bug. Alarmist tidak beruntung untuk segera menemukan area dengan kualitas buruk - dan
tanpa investigasi lebih lanjut, dia mengumumkan bahwa seluruh produk tidak cocok .
Anda dapat berbicara banyak tentang bagaimana pengembang ban QA dan membuang-buang waktu mereka (lihat tester dari jenis
menyesatkan ), tetapi ini adalah situasi dua kali lipat. Bahkan, terlalu sering, pengembang secara sadar memberikan QA perangkat lunak yang tidak diuji untuk mendapatkan hadiah untuk pekerjaan yang dilakukan atau untuk mengklaim bahwa ia memenuhi tenggat waktu. Ketika QA mulai menguji sistem seperti itu, ia segera menemui banyak kesalahan yang seharusnya dilihat pengembang. Oleh karena itu, jelas bahwa ia memperkirakan apa yang dilihatnya untuk seluruh produk dan mengklaim kualitas yang sangat rendah.
Seorang alarmis biasanya memiliki otoritas di departemen QA, dan pendapatnya dihormati. Semakin tinggi tingkat otoritasnya, semakin merusak dampaknya pada proyek. Skenario khas adalah sebagai berikut:
- Produk ditransfer ke QA.
- Seorang alarmis mulai menguji area dengan kualitas mengerikan.
- Alarmist menghentikan semua pengujian dan memberi tahu pihak berwenang tentang masalah serius dengan kualitas produk.
Ini adalah kasus klasik melempar anak dengan air. Terkadang QA membuat pilihan yang tepat, terutama ketika tim pengembangan memiliki reputasi untuk mentransfer perangkat lunak yang tidak diverifikasi ke QA. Tetapi kebetulan alarm dinaikkan karena satu pengembang lemah, yang kodenya adalah yang pertama kali datang ke pembuat panik.
Solusi
Seorang penguji menjadi alarmis jika dia dikecewakan berulang kali oleh tim pengembang. Jika dia selalu menyediakan perangkat lunak berkualitas tinggi, tidak akan ada alasan untuk curiga. Tetapi jika tester menjadi alarmis, akan sulit bagi tim pengembangan untuk mendapatkan kembali kepercayaan diri, terutama jika tim benar-benar memiliki pengembang
gajah di toko Cina dan
tidak kompeten .
Biasanya, dalam tim pengembangan besar, kode berkualitas rendah muncul dari pengembang individu, bukan seluruh tim. Oleh karena itu, sangat penting bahwa pekerjaan pengembang yang kurang kompeten diuji terakhir, atau tidak termasuk dalam alarm. Namun, ini menyembunyikan masalah sebenarnya bahwa ada
pengembang di tim
yang secara negatif mempengaruhi proyek .
Ilmuwan
Seorang penguji yang menghabiskan sebagian besar waktunya untuk mendokumentasikan bug, tidak menemukan bug baru.
- Dapat bermutasi pada yang tertindas
- Berbahaya bila dikombinasikan dengan manajer produk seperti penulis paten
- Probabilitas koreksi: tinggi
- Bahaya untuk proyek: rendah
Masalah
Menemukan masalah dalam sistem bisa sama menariknya dengan berburu harta karun. Dan ketika Anda menemukan harta ini, tidak kalah menarik untuk memecahkan teka-teki. Dapat dikatakan bahwa penguji yang menganggap proses menemukan kesalahan dengan cara ini sangat ideal. Tetapi masalah muncul jika dia berusaha untuk mendokumentasikan perjalanannya yang menakjubkan. Alih-alih berfokus pada masalah utama, pengembang terpaksa membaca cerita panjang dengan banyak detail yang tidak membantu, mencoba memilih informasi yang relevan.
Ilmuwan secara harfiah memahami persyaratan untuk "mendokumentasikan serangga dengan hati-hati." Dia menggambarkan mereka dalam bentuk sejarah teks, dan bukan deskripsi singkat dengan urutan langkah-langkah reproduksi yang jelas. Membaca laporan semacam itu membutuhkan banyak waktu, dan pada akhirnya masih belum jelas apa sebenarnya masalahnya. Biasanya, deskripsi seperti itu mencakup beberapa bug, sambil merujuk ke area luas dari sistem, dan bukan ke masalah tertentu.
Keluhan utama dari pengembang saat menerima pesan kesalahan dari para ilmuwan adalah rasio signal-to-noise terlalu rendah. Mereka menghabiskan waktu menyaring aliran kesadaran, mencari detail spesifik. Ini buang-buang waktu untuk pengembang dan penguji.
Solusi
Seorang ilmuwan QA mudah dikoreksi dengan mengajarinya cara menulis laporan yang benar. Seringkali, koreksi terjadi secara instan begitu mereka menjelaskan apa yang diminta darinya. Cara paling efektif untuk mengajarkan gaya yang tepat adalah menulis ulang satu atau lebih laporan dalam format yang benar, yang akan berfungsi sebagai model untuk masa depan. Akibatnya, penguji yang antusias akan menulis laporan kesalahan yang jelas dan ringkas yang tidak dapat dibuat lebih ideal.
Menyesatkan
Sebuah QA, yang sering melaporkan kesalahan secara tidak akurat, menyebabkan pengembang salah ketika ia mencoba mereproduksi dan memperbaiki masalah.
- Dapat bermutasi menjadi alarmis
- Berbahaya jika dikombinasikan dengan manajer proyek seperti statistik
- Probabilitas koreksi: tinggi
- Bahaya untuk proyek: tinggi
Masalah
Laporan kesalahan harus mencakup yang berikut:
- Kemampuan menentukan bahwa sebenarnya ada kesalahan
- Kemampuan untuk menentukan langkah-langkah untuk memainkan bug
- Deskripsi lengkap kesalahan, seringkali dengan akar penyebab
- Hapus langkah-langkah untuk memainkan bug
Pada salah satu tahap ini, laporan dapat menyesatkan pengembang, sehingga ia akan membuang waktu:
- Jika tidak ada kesalahan, pengembang menghabiskan waktu mencari masalah yang tidak ada
- Jika kesalahan tidak dapat direproduksi, pengembang menghabiskan waktu pada reproduksinya
- Jika kesalahan tidak dijelaskan dengan benar, pengembang menghabiskan waktu mencari penyebab root yang terlalu spesifik atau terlalu luas
- Jika langkah-langkah untuk mereproduksi tidak akurat, pengembang menghabiskan waktu mencoba menafsirkannya atau mungkin tidak menyatakan bug, meskipun ia melakukannya.
Terkadang pengembang bingung karena kesalahan pengetesan sederhana. Tetapi penguji menyesatkan sering menghasilkan laporan seperti itu, menyebabkan ketidakpuasan yang cukup besar di antara pengembang. Jika situasinya berlanjut, penguji pada akhirnya akan kehilangan kepercayaan pengembang, dan mereka akan berhenti memperbaiki bahkan bug nyata, menolak laporan kesalahan tersebut.
Solusi
QA yang menyesatkan seringkali baik dalam menemukan bug, hanya mendokumentasikannya dengan buruk. Karena itu, ada baiknya upaya untuk melatihnya.
Salah satu metode yang paling efektif adalah memantau pengembang, yang, berdasarkan laporannya, mencoba mengidentifikasi masalah. Cukup duduk di sebelah pengembang yang menerima salah satu laporannya dan dengan tenang mengamati (tanpa campur tangan) bagaimana pengembang mencoba mencari tahu. Biasanya ini akan mengarah pada percakapan yang sehat tentang cara terbaik melaporkan bug, yang akan menguntungkan pengembang dan QA.
Tertindas
QA, yang dipukuli oleh pengembang sedemikian rupa sehingga tidak mungkin melaporkan kesalahan, takut ditindas di pihak mereka.
Masalah
Mungkin tidak ada manifestasi kemanjaan yang lebih besar daripada sikap khas pengembang terhadap QA. Selain itu, orang sering dapat melihat bahwa pengembang agresif secara terbuka mengintimidasi tester, bahkan jika ia melaporkan kesalahan alami dalam kode mereka. Untuk mengatasi ini, QA yang sukses ketika bekerja dengan pengembang agresif harus memiliki karakteristik berikut:
- Sudah memenangkan kepercayaan besar dari para pengembang, sehingga bug-nya selalu dianggap serius.
- Mampu menunjukkan tidak kurang dari agresi dan ketekunan dalam perselisihan dengan pengembang yang tidak mengenali bug.
Sayangnya, tidak banyak penguji yang memiliki karakteristik seperti itu, sehingga pengembang sering kali mengelapnya dan terutama menuduh QA mendeteksi bug baru. Tidak peduli seberapa tidak logis kelihatannya, ini adalah gambaran umum dalam kondisi berikut:
- Pengembang memiliki rasa percaya diri yang tinggi (lihat pengembang seperti primadona )
- Pengembang percaya bahwa ia tahu lebih baik daripada penguji bagaimana sistem bekerja (lihat pengembang seperti penyandera )
Setelah QA dipukuli secara menyeluruh dari waktu ke waktu, biasanya menghindari konfrontasi dengan pengembang yang bermusuhan untuk mengurangi stres. Akibatnya, bug dari pengembang spesifik ini jarang dilaporkan, meskipun mungkin ada. Sebagai aturan, situasi terdeteksi hanya ketika masalah muncul dalam produksi dan penyelidikan dimulai mengapa departemen pengujian tidak mendeteksi bug. Penguji yang tertekan akan memberikan penjelasan berikut:
- Dia berbicara dengan pengembang, dan dia mengatakan bahwa ini bukan kesalahan.
- Dia mengajukan laporan bug, tetapi pengembang menolaknya.
- Dia menemukan kesalahan, tetapi "tidak menganggapnya cukup penting."
Karakter pasif seringkali menyulitkan untuk mengenali QA yang tertindas. Kuncinya adalah menganalisis para pengembang QA ini bekerja dengan - mencari tanda-tanda permusuhan yang jelas.
Solusi
Pengembang sangat sering secara langsung mengejek penguji. Dengan demikian, mereka harus diperlakukan seperti penjahat lainnya:
- Menuntut untuk segera menghentikan mengejek QA dan menahan diri dari perilaku agresif.
- Latih komunikasi profesional.
- Singkirkan jika pengembang tidak dapat memperbaiki perilakunya.
Dalam kasus-kasus yang sangat parah, departemen personalia harus turun tangan, terutama jika situasinya telah berubah menjadi permusuhan terbuka.
Sangat menyedihkan bahwa situasi ini adalah norma daripada pengecualian. Satu-satunya perbedaan adalah tingkat permusuhan.
Clicker acak
QA yang mencari kesalahan dengan metode klik acak.
- Dapat bermutasi dalam selang api
- Berbahaya bila dikombinasikan dengan manajer produk seperti penulis paten
- Probabilitas Koreksi: Rendah
- Bahaya untuk proyek: rendah
Masalah
Pencarian bug dalam sistem dilakukan oleh dua metode utama:
- Menurut rencana pengujian dengan secara sistematis memproses daftar kasus uji.
- Berkeliaran secara acak di sekitar aplikasi dalam upaya untuk meniru tindakan pengguna.
Menulis rencana pengujian adalah tugas yang menghabiskan waktu, dan tidak ada jaminan bahwa pada saat tes dimulai, rencana tersebut akan tetap relevan setelah perubahan persyaratan. Ini dapat mengarah pada fakta bahwa tester benar-benar meninggalkan rencana pengujian, dan sebagai gantinya hanya berinteraksi dengan aplikasi dengan harapan menemukan bug.
Memang, interaksi yang tidak disengaja dengan aplikasi mengungkapkan kesalahan, terutama pada tahap awal pengembangan produk. Namun, seiring dengan bertambahnya usia produk, menemukan kesalahan dengan cara ini akan jauh lebih sulit, karena bug yang tersisa disembunyikan dalam kasus batas. Ini mengarah pada rasa aman yang salah, seolah-olah aplikasi tidak memiliki kesalahan, meskipun itu sama sekali belum diuji sebagaimana mestinya.
Penting untuk diingat bahwa interaksi acak dengan aplikasi tetap merupakan metodologi yang dapat diterima, karena dapat mengungkapkan situasi yang tidak didokumentasikan dalam rencana.
Tapi ini hanya tambahan rencana uji, bukan pengganti.Solusi
Clicker acak dapat muncul dalam satu dari dua kasus:- Dia tidak diajari cara menguji aplikasi dengan benar.
- Dia secara aktif menghindari menulis rencana tes.
Jika masalahnya adalah kurangnya pelatihan, maka Anda harus menyediakannya. Namun, dalam kasus ini, penguji masih bisa masuk ke dalam kategori kedua, tidak ingin membuat rencana pengujian, bahkan jika ia tahu bahwa ia harus melakukannya.Menulis rencana ujian yang baik membutuhkan tingkat organisasi, ketekunan, dan konsentrasi yang langka. Akibatnya, beberapa tipe orang menikmati pekerjaan semacam itu, tetapi kebanyakan tidak. Jika Anda sangat beruntung, clicker acak akan menemukan karakteristik yang diperlukan untuk menulis rencana pengujian yang baik, tetapi kemungkinannya kecil.Berani sekali
, -, .
Masalah
Melaporkan bug dengan benar adalah proses yang menghabiskan waktu dan sulit secara kognitif, dan beberapa QA tidak ingin melakukan upaya yang cukup. Sebagai aturan, ini adalah penguji dengan beberapa hak: mereka percaya bahwa mereka tidak harus mencoba dan memilih kata-kata. Mereka juga sering memandang remeh pada pengembang dan tidak berpikir bahwa itu layak menghabiskan waktu pada semacam analisis kesalahan: pernyataan umum cukup bagi pengembang untuk berani mencari tahu apa masalahnya.Laporan bug umum dari penguji yang ceroboh berisi frasa berikut:- "Itu tidak berhasil."
- "Rusak lagi."
- "Masalahnya akan jelas jika kamu benar-benar menggunakan fitur ini."
- "Aku tidak tahu mengapa mereka melewatkannya."
- "Periksa dengan cermat lain kali"
- "Saya tidak tahu mengapa kami tidak bisa menerapkannya dengan benar"
Jelas, pengembang tidak terlalu senang dengan laporan yang menggunakan frasa yang sama, bukan langkah-langkah untuk mereproduksi kesalahan. Ini jarang dilakukan oleh seorang analis QA profesional, tetapi sering ditemukan jika karyawan perusahaan lain yang diminta mencari bug melaporkan kesalahan. Ini biasanya terjadi ketika ada sedikit waktu yang tersisa sebelum rilis, dan tidak ada cukup penguji. Sebagai hasil dari "bantuan" seperti itu, kekacauan biasanya terjadi, karena laporan ditolak oleh pengembang, menyebabkan lebih banyak kontroversi dalam tim, yang semakin memperdalam kemarahan.Solusi
Secara umum, penguji profesional harus bertanggung jawab untuk menemukan bug. Sayangnya, ada pendapat di industri bahwa setiap orang dapat mencari bug, tetapi ini tidak benar. Lebih akurat untuk mengatakan bahwa siapa pun dapat mendeteksi kesalahan, tetapi sebagai aturan, hanya spesialis QA profesional yang dapat mengidentifikasi kesalahan penting yang tersembunyi dalam situasi batas dan melaporkannya sedemikian rupa sehingga pengembang dapat segera memahami, mereproduksi dan, oleh karena itu, memperbaiki bug ini.Seorang penguji yang bertindak ceroboh percaya bahwa ia memiliki hak atas laporan sembrono tersebut. Jika dia memasuki departemen QA, dia harus diperingatkan untuk memperbaiki perilaku kontraproduktifnya. Jika pencarian bug bukan tanggung jawab langsungnya, maka ia harus dilarang melaporkan kesalahan sampai ia belajar melakukannya secara profesional.Seringkali jauh lebih efisien untuk hanya menghapus tester berani yang sembarangan daripada mencoba memperbaikinya. Dengan tindakannya, ia jelas-jelas menegaskan bahwa ia tidak ingin terlibat dalam pengujian, jadi menghapusnya adalah demi kepentingan bersama.Lihat juga: