Saya berbicara dengan puluhan insinyur QA dari perusahaan yang berbeda dan masing-masing dari mereka berbicara tentang fakta bahwa mereka menggunakan sistem dan alat yang berbeda untuk pelacakan bug. Kami juga mencoba beberapa dari mereka, dan saya memutuskan untuk membagikan solusi yang kami dapatkan.
Intro
Saya akan dangkal. Kesalahan muncul dan terdeteksi pada berbagai tahap proses pengembangan. Oleh karena itu, Anda dapat membagi bug ke dalam kategori, tergantung pada waktu mereka terdeteksi:
- Kekurangan . Ini adalah kesalahan yang dilakukan pengembang saat menggergaji fungsi baru. Kesalahan semacam itu ditemukan selama penelitian atau pengujian penerimaan fitur baru di tribun pengembangan tim.
- Bug dalam regresi . Ini adalah cacat yang menemukan tes regresi manual atau UI dan tes API otomatis pada berdiri untuk integrasi kode.
- Bug dengan penjualan . Ini adalah masalah yang ditemukan oleh karyawan atau pelanggan dan menghubungi dukungan teknis.
Di mana kita mulai, atau Jira
Dua tahun lalu, kami memiliki tim penguji khusus yang menguji produk secara manual setelah mengintegrasikan kode semua tim. Hingga saat ini, kode tersebut telah diuji oleh pengembang di tribun pengembang. Kesalahan yang ditemukan oleh penguji dicatat dalam jaminan simpanan di Jira. Bug disimpan dalam backlog umum dan dipindahkan dari sprint ke sprint dengan tugas lain. Setiap sprint mendapat dua atau tiga bug dan memperbaikinya, tetapi sebagian besar tetap di bagian bawah tumpukan:
- Salah satu alasan mengapa bug terakumulasi dalam jaminan adalah bahwa bug tidak mengganggu pengguna. Bug semacam itu memiliki prioritas rendah dan tidak akan diperbaiki.
- Juga, jika perusahaan tidak memiliki aturan yang jelas dan dapat dipahami untuk membuat bug, penguji dapat menambahkan masalah yang sama beberapa kali karena mereka tidak dapat menemukan laporan bug yang sudah ditambahkan dalam daftar ini.
- Alasan lain mungkin karena penguji yang tidak berpengalaman terlibat dalam proyek ini. Merupakan kesalahan bagi penguji pemula untuk masuk dalam pelacakan bug semua bug yang ditemukan selama operasi. Penguji yang tidak berpengalaman menganggap tujuan pengujian adalah untuk mencari bug, daripada memberikan informasi tentang kualitas produk dan mencegah munculnya cacat.
Saya akan memberikan contoh sederhana. Saat membuat laporan di bidang input tanggal, tanggal diganti secara default. Saat mengubah tanggal dalam sembulan, Anda dapat kembali memilih hari ini dan bidang input tanggal akan dihapus.
Saya memiliki kecurigaan bahwa sepanjang hidup jaringan kami, tidak ada seorang pun kecuali penguji yang tidak mereproduksi kesalahan ini. Kesalahan semacam itu merupakan sebagian besar bug yang tidak diperbaiki.
Dengan pendekatan ini, ketika semua bug yang ditemukan dimasukkan, beberapa dari mereka digandakan dan sebagian besar bug ini tidak diperbaiki.
- Penguji didemotivasi, karena kesalahan yang mereka temukan tidak diperbaiki oleh pengembang. Seseorang mendapat perasaan bahwa pekerjaan itu tidak masuk akal.
- Sulit bagi pemilik produk untuk mengelola jaminan dengan banyak bug.
Selamat tinggal Jira, Hidup Kaiten
Pada musim semi 2018, kami meninggalkan Jira dan pindah ke Kaiten. Perubahan alat disebabkan oleh alasan yang ditulis Andrei Arefiev dalam artikel
"Mengapa Dodo Pizza mulai menggunakan Kaiten daripada sekelompok Trello dan Jira". Setelah pindah ke Kaiten, pendekatan kami untuk bekerja dengan bug tidak berubah:
- Ketidaksempurnaan dicatat di papan perintah dan pengembang memutuskan untuk memperbaikinya atau tidak.
- Bug yang ditemukan dalam regresi (dilakukan oleh tim penguji khusus) diperbaiki di cabang rilis dan tidak merilis kode sampai semua masalah diperbaiki. Kami memutuskan bahwa akan lebih logis untuk menyimpan dan mengumpulkan informasi tentang masalah ini di saluran penguji di Slack. Penguji menulis pesan yang berisi legenda, daftar bug dengan log dan nama-nama pengembang yang mengambil tugas untuk bekerja. Dengan bantuan emoji, mereka mengubah status, dan dalam perdagangan mereka mendiskusikan, menerapkan tangkapan layar, disinkronkan. Format ini cocok untuk penguji. Beberapa pengembang tidak menyukai metode ini, karena dalam obrolan ada korespondensi lain secara paralel dan pesan ini naik dan tidak terlihat. Kami memperbaikinya, tetapi itu tidak menyederhanakan kehidupan.
- Bug yang ditemukan pada prod dicatat dalam jaminan, Pemilik Produk, diprioritaskan dan dipilih yang akan kami perbaiki.
Waktu percobaan atau tidak
Kami memutuskan untuk bereksperimen dengan format dan membuat papan terpisah di Kaiten, tempat kami menyimpan bug dan mengubah status. Kami menyederhanakan pembuatan laporan bug untuk menghabiskan lebih sedikit waktu. Saat menambahkan kartu ke Kaiten, penguji menandai pengembang. Pemberitahuan telah dikirim ke email mereka tentang ini. Kami menempatkan papan ini pada monitor yang tergantung di lorong dekat tempat kerja kami, sehingga pengembang dapat melihat kemajuan dan proses pengujian menjadi transparan. Praktik ini juga tidak berakar, karena saluran komunikasi utama adalah Slack. Pengembang kami tidak sering memeriksa email. Oleh karena itu, solusi ini dengan cepat berhenti bekerja dan kami kembali ke Slack.
Bawa semut kembali
Setelah percobaan papan yang gagal di Kaiten, beberapa pengembang masih menentang format pesan di Slack. Dan kami mulai berpikir bagaimana melacak bug di slack dan memecahkan masalah yang mencegah pengembang. Sebagai hasil dari pencarian, saya menemukan sebuah aplikasi untuk Slack, Workast, yang membantu mengatur pekerjaan dengan balita tepat di messenger. Kami berpikir bahwa aplikasi ini akan memungkinkan Anda untuk mengelola proses bekerja dengan bug secara lebih fleksibel. Aplikasi ini memiliki kelebihan: perubahan status dan penugasan kepada pengembang hanya dengan mengklik tombol, tugas yang sudah selesai disembunyikan dan pesan tidak bertambah besar.
Jadi masalah yang diselesaikan terlihat dalam aplikasi Todo dan meminta untuk mengembalikan "semut". Setelah masa uji coba aplikasi Workast berakhir, kami memutuskan untuk mengabaikannya. Karena menggunakan aplikasi ini, kami sampai pada hal yang sama seperti ketika kami menggunakan Jira. Ada beberapa bug yang berjalan dari regresi ke regresi dalam daftar ini. Dan dengan setiap iterasi, ada lebih banyak lagi. Mungkin layak untuk menyelesaikan proses bekerja dengan ekstensi ini, membelinya dan menggunakannya, tetapi kami tidak melakukannya.
Cara sempurna kami untuk menangani bug sekarang
Pada akhir 2018 - awal 2019, sejumlah perubahan terjadi di perusahaan kami yang memengaruhi proses bekerja dengan bug.
Pertama, kami tidak memiliki tim penguji yang berdedikasi. Semua penguji tersebar ke tim pengembangan, untuk memperkuat kompetensi tim penguji. Berkat ini, kami mulai menemukan kesalahan sebelumnya, sebelum integrasi kode perintah.
Kedua, kami meninggalkan pengujian regresi manual demi otomatis.
Ketiga, kami mengadopsi "kebijakan bug nol". Dalam artikel "
#zerobugpolicy atau bagaimana kami memperbaiki bug ",
bevzuk merinci bagaimana kami memilih bug yang kami perbaiki.
Saat ini proses bekerja dengan bug adalah sebagai berikut:
- Kekurangan . Penguji melaporkan masalahnya kepada analis atau manajer produk. Mereka berjalan, menunjukkan, mereproduksi, menjelaskan bagaimana pengaruhnya terhadap pelanggan dan memutuskan apakah perlu diperbaiki sebelum dirilis, atau dapat diperbaiki nanti, atau mungkin tidak layak diperbaiki sama sekali.
- Bug dalam regresi yang ditemukan oleh tes otomatis diperbaiki oleh tim yang menyentuh bagian sistem ini dan kami tidak akan merilis kode ini sampai kami menyelesaikan masalah. Penguji memperbaiki bug ini dalam format sewenang-wenang di saluran rilis di Slack.
- Bug dengan penjualan . Bug semacam itu langsung pergi ke pemilik tugas. Analis menjalankan kesalahan pada Matriks Prioritas bug dan menambahkannya ke dalam backlog atau memperbaikinya sendiri, mengumpulkan statistik hit pada masalah ini.
Ringkasan
Singkatnya, kami pada dasarnya meninggalkan sistem pelacakan bug . Menggunakan pendekatan ini untuk bekerja dengan bug, kami memecahkan beberapa rasa sakit:
- Penguji tidak kecewa karena kesalahan yang mereka temukan dan picu dalam pelacakan bug tidak diperbaiki.
- Penguji tidak menghabiskan waktu di institusi dan deskripsi lengkap bug yang bahkan tidak akan dibaca oleh siapa pun.
- PO lebih mudah untuk mengelola backlog di mana tidak ada beban mati.
Saya tidak ingin mengatakan bahwa pelacakan bug tidak berguna. Bug yang kami bawa untuk bekerja dilacak seperti tugas lainnya. Tetapi sistem pelacakan bug bukanlah atribut pengujian yang diperlukan. Itu tidak perlu digunakan hanya karena sebagian besar perusahaan menggunakannya dan itu adalah kebiasaan di industri. Anda perlu "berpikir dengan kepala Anda" dan mencoba alat untuk proses dan kebutuhan Anda. Sangat ideal bagi kami untuk bekerja tanpa sistem pelacakan kutu sekarang. Selama setengah tahun pekerjaan seperti itu, kami tidak pernah berpikir untuk kembali ke sana dan mendapatkan semua bug di sana.
Dan bagaimana proses penanganan bug diatur di perusahaan Anda?