Haruskah QA menemukan skenario yang dapat direproduksi?


10

Terkadang tim QA saya melaporkan bug, tetapi baik saya maupun mereka tidak punya ide tentang cara mereproduksi mereka. Ini mengarah ke sesi debugging yang sangat panjang dan membuat frustasi yang terkadang bahkan tidak membuahkan hasil.

Perangkat lunak saya sangat terkait dengan perangkat keras berpemilik sehingga bug dapat datang dari berbagai arah sekaligus.

Haruskah saya mengharapkan lebih dari mereka daripada "perangkat lunak Anda macet ketika saya menekan tombol" atau haruskah saya membayangkan sendiri apa yang terjadi?

EDIT:

Salah satu rekan kerja saya menunjukkan bahwa kita mungkin semua pengembang di sini sehingga hasilnya mungkin sedikit bias


1
Ini sebenarnya bukan jawaban tetapi perlu menunjukkan bahwa dengan menempatkan (lebih banyak) masuk ke dalam aplikasi Anda, Anda dapat mengurangi masalah ini. Mungkin test build Anda dapat diatur ke mode logging verbose yang akan memberi Anda langkah-langkah reproduksi yang samar untuk membantu Anda dalam sesi debugging?
ChrisFletcher

Tidak juga, Pengujian harus melakukan itu. QA harus melakukan QA.
mattnz

1
Pertimbangkan untuk menambahkan logika ke produk Anda yang membantu Anda menelusuri kembali langkah-langkah yang diambil oleh pengguna, dan memiliki tombol QA yang memungkinkan reporter bug untuk dengan mudah mengekstraksi informasi dari produk Anda dan menambahkannya ke laporan bug.

Setidaknya tangkapan layar dari situasi aktual akan membantu sebagian besar waktu untuk mereproduksi kesalahan. (lihat komentar logging di atas). Usersnap adalah alat untuk pelaporan bug yang lebih baik dan menghemat waktu komunikasi.
Gregor

Jawaban:


31

QA harus selalu mencoba dan membuat bug semudah Anda mereproduksi mungkin dan deskripsi bug harus berisi langkah-langkah yang diambil.

Namun, jika mereka tidak dapat dengan mudah mereproduksi bug, mereka harus tetap masuk ke dalam database bug dengan judul / judul yang sesuai dan deskripsi lengkap tentang apa yang mereka lakukan untuk menyebabkan bug. Deskripsi bug harus dengan jelas menyatakan bahwa mereka tidak dapat mereproduksi bug (mungkin dengan beberapa komentar di sepanjang baris "mencobanya lima kali, itu terjadi sekali"). Dengan cara ini, jika orang lain melihat bug yang sama, mereka dapat menambahkan ke database bug dengan temuan mereka dan Anda juga mendapatkan informasi sebanyak mungkin yang selanjutnya akan membantu Anda menghemat waktu untuk melacak masalah.

Selain itu, Anda dapat memfilter informasi - mungkin ada banyak bug dalam sistem yang berbeda yang Anda tahu semuanya ditautkan ke (misalnya) satu area kode - jika QA tidak melaporkan apa pun (karena mereka tidak dapat mereproduksi mereka ) maka informasi ini tidak sampai kepada Anda.


... a full description of what they did to cause the bug. Apa bedanya dengan repo?
Steven Evers

13
@SnOrfus: Repo, menurut definisi, dapat direproduksi. Jika Anda menemukan bug tetapi tidak dapat mereproduksinya nanti, masih sangat membantu untuk mengetahui apa yang Anda lakukan saat itu, untuk membantu melacak apa yang menyebabkannya.
BlueRaja - Danny Pflughoeft

3
@SnOrfus: The software crashedvs The software crashed editing foowidgetsvs The software crashes when viewing a foowidget and toggling the frobulator 10 times followed by pressing this key sequence (stack trace attached). Detail terakhir mungkin tidak jelas, tetapi memiliki deskripsi kedua dan bukan yang pertama tentu saja membantu.
Daenyth

@ Ketidaksamaan: Cukup adil. Mungkin saya terlalu jauh ke dalam semantik deskripsi lengkap .
Steven Evers

Pastikan "Ditutup Tidak / Tidak Dapat Bereproduksi" tersedia (ada dan dapat diterima) untuk digunakan dalam pelacak cacat Anda.
mattnz

13

Sepertinya departemen QA Anda melakukan terlalu banyak pengujian eksplorasi (mis. Mereka tidak memiliki rencana pengujian yang baik).

Pengujian eksplorasi adalah baik, dan mengidentifikasi area masalah, tetapi dari sana mereka harus mendefinisikan uji kasus yang dapat direproduksi (mis. Rencana pengujian) untuk melakukan yang akan mengungkapkan bug tertentu.

Ada sejumlah alasan mengapa repro yang benar diperlukan (tidak hanya bagus, tetapi perlu):

  1. Anda harus mengulang sehingga Anda dapat men-debug / melacak penyebabnya.
  2. QA harus dapat memverifikasi perbaikan setelah Anda selesai.
  3. Tes lulus lebih lanjut perlu dilakukan regresi pada bug sebelumnya.
  4. Bug yang dikenal dapat dibuang jika eksposur terlalu kecil atau repro terlalu kecil kemungkinannya.

Jadi, seperti yang dicatat SteveCzetty: Tutup tanpa repro dan kembali bekerja.


3
Masalah dengan langkah-langkah untuk mereproduksi adalah bahwa biasanya dengan bug Crash mereka tidak diantisipasi atau dicari dan mereka biasanya terjadi di tengah-tengah rencana pengujian. Mereka harus mencoba mereproduksi tetapi banyak kali ini tidak sempurna. Untuk pengujian manual, perangkat lunak perekaman layar desktop yang baik selama kasus pengujian dapat menangkap setiap langkah dan stempel waktu yang menyebabkan kecelakaan serta menangkap kesalahan sederhana atau detail yang tampaknya tidak penting yang mungkin terlewatkan oleh orang QA dalam langkah-langkah mereka untuk mereproduksi. Dengan ini dan log pengujian pengembang harus memiliki gambaran yang lebih jelas.
maple_shaft

3
@maple_shaft Ini memang benar - Saya tidak berharap setiap bug dari QA 100% dapat direproduksi. Rekaman layar adalah pilihan yang menarik dan tentunya lebih banyak pertimbangan, karena memungkinkan lebih banyak fleksibilitas tanpa melepaskan kesempatan untuk mengawasi bahu penguji.
Michael K

2
@maple_shaft: Saya setuju, dan MTM memiliki built-in itu. Namun dalam kasus ini, ada perbedaan yang signifikan antara apa yang didapatkan Eric ("Terjadi kecelakaan") dan apa skenario kasus terbaiknya (Log Kejadian + Log Aplikasi + Video + Rekaman Tindakan + Intellitrace + Itemized Repro). Pekerjaan IMO / E QA tidak berakhir ketika layar biru terjadi - dan repro adalah hal pertama yang harus mereka coba untuk hasilkan, meskipun itu tidak selalu layak.
Steven Evers

@SnOrfus Saya hanya bisa bermimpi bekerja dengan tim QA yang sangat profesional. Di sebagian besar organisasi saya telah bekerja mereka adalah ampas yang terlalu kompeten atau malas untuk memotongnya sebagai pengembang perangkat lunak. Ternyata tim QA terbaik yang pernah bekerja sama dengan saya benar-benar tidak cocok, mungkin karena mereka sebenarnya ingin melakukan pengujian QA.
maple_shaft

@maple_shaft: Di mana saya bekerja, sebelum saya pindah dari QA ke Dev, kami sudah melakukan sebagian besar itu (video membutuhkan ruang HDD yang besar saat Anda memiliki 400.000 kasus uji).
Steven Evers

7

Jika bug tidak dapat direproduksi secara konsisten, bagaimana QA akan tahu apakah itu diperbaiki?


Ya ini adalah masalah lain yang tidak saya sebutkan tetapi banyak berjalan. Saya mendapatkan laporan bug, melakukan perubahan lalu menutup bug. QA kemudian menyetujui penutupan. Beberapa minggu kemudian, masalah ini dibuka kembali karena tidak diperbaiki. Saya juga memiliki banyak masalah saat "peranti lunaknya mogok", yang menjadi peleburan besar setiap kemungkinan bug
Eric

6

Ya, Anda harus mengharapkan lebih dari mereka. Mereka harus bisa mengatakan:

1. Memulai program baru
2. Saya menekan tombol A
3. Masukkan "tes teks" ke dalam bidang TEST NAME pada Formulir # 1
4. Tekan tombol B
5. Mengamati bahwa program macet dengan pesan ini (lihat tangkapan layar terlampir).

Jika yang mereka katakan adalah "macet", itu tidak terlalu baik. Bahkan jika langkah-langkah di atas tidak 100% dapat direproduksi, sampel crash yang cukup besar dapat membantu mempersempit penyebabnya, begitu sebuah pola terdeteksi.


5

Saran saya adalah membaca bug itu dan memberi mereka pemikiran lama yang bagus. Jika Anda tidak dapat menemukan penyebab potensial, lupakan saja untuk saat ini.

QA harus mendokumentasikan setiap masalah yang mereka temukan, bahkan jika mereka tidak tahu bagaimana itu terjadi. Adalah tugas QA untuk mencoba dan mereproduksi masalah, tetapi secara realistis ini tidak selalu mungkin. Terkadang itu tidak ada hubungannya dengan apa yang mereka lakukan dalam 10 menit terakhir. Sesuatu masuk ke keadaan tidak valid sehari yang lalu, dan itu menjadi jelas karena salah satu dari 10 langkah terakhir.

Dengan bug "1 dalam 1000" ini, QA harus mencoba mereproduksi mereka sedikit. Jika mereka tidak berhasil, mereka harus mendokumentasikan bug, lalu coba lagi.

Alasan mengapa mereka harus memasukkan bug cukup awal adalah bahwa programmer mengetahui kode jauh lebih baik daripada QA, dan mungkin segera tahu masalahnya. Mungkin kode yang mereka refactored. Bisa jadi fungsi yang setengah mereka implementasikan lalu lupakan. Mereka mungkin tidak tahu, tetapi tidak ada gunanya dalam penguji menghabiskan beberapa jam mencoba mereproduksi masalah yang jelas bagi orang yang mengkodekannya. Penguji selalu dapat menambahkan rincian lebih lanjut ke bug nanti.

Bug harus menyertakan informasi sebanyak mungkin. Apa pun yang dapat diingat oleh penguji tentang penyebab masalah ini harus ditulis dengan sangat rinci. Log Crash, snapshot basis data, atau tangkapan layar yang relevan juga harus dilampirkan.

Jika bug tidak pernah direproduksi, hebat! Tidak ada salahnya menyimpannya di database. Jika program ini dirilis dan pengguna melaporkan bug yang sama nanti, Anda dapat membandingkan pengalaman mereka dengan apa yang ada di laporan dan mencari kesamaan.

Dalam pengalaman saya, bug yang paling baru tidak ditemukan dari mengikuti rencana pengujian. Kadang-kadang Anda harus membiarkan hal-hal rebus selama beberapa minggu agar bulan dan bintang sejajar yang menyebabkan bug jahat. Jika QA dapat melakukan beberapa pekerjaan detektif dan menemukan beberapa kemungkinan penyebabnya, beri tepukan pada mereka. Namun terkadang, siapa yang tahu apa yang terjadi?


+1 untuk "Tidak ada ruginya dalam database"
PhillC

4

Banyak bug tidak dapat direproduksi sampai Anda tahu cara memperbaikinya. Itu tidak berarti mereka tidak perlu diperbaiki. Saya memperbaiki bug tahun lalu yang masih belum bisa saya reproduksi. Dibutuhkan beberapa kombinasi aneh dari kesalahan transmisi tepat waktu bersama-sama dengan data sampah yang sangat spesifik di lokasi memori tertentu pada stack. Sayangnya, salah satu pelanggan kami "cukup beruntung" untuk memasuki kondisi itu setiap saat.

Jadi, tentu saja dorong QA untuk memasukkan langkah-langkah reproduksibilitas jika memungkinkan, tetapi jangan salahkan mereka jika mereka tidak bisa. Terkadang ini akan membantu Anda tahu di mana menambahkan logging. Terkadang yang dilakukan adalah memberi tahu Anda apa yang tidak menyebabkan bug, tetapi laporan bug selalu bermanfaat.


2

Jika Anda maksudnya harus QA menyertakan langkah-langkah untuk mereproduksi bug jika mereka bisa, maka jawabannya adalah ya. Jika yang Anda maksud adalah mereka hanya merekam bug yang dapat diperbanyak, maka sama sekali tidak. Bug adalah bug, apakah itu hanya terjadi pada tengah malam di bulan purnama, atau setiap kali Anda melihatnya. Beberapa bug bersifat non-deterministik (contoh klasik adalah variabel tidak diinisialisasi, di mana nilai yang diambil adalah semi-acak), itu tidak berarti mereka tidak boleh direkam, diselidiki, dan jika mungkin diperbaiki.

Bug yang tidak dapat direproduksi umumnya harus memiliki prioritas rendah, tetapi bug itu harus direkam.


1

IMO, kamu harus. QA tidak melakukan pekerjaan mereka jika mereka tidak dapat memberikan Anda langkah-langkah reproduksi. Jangan buang waktu Anda mencoba mereproduksi sesuatu yang Anda tidak bisa, tutup saja sebagai "Tidak dapat mereproduksi" dan lanjutkan.

Waktu Anda jauh lebih berharga dari itu.


1

Laporan bug harus berisi:

  • Langkah-langkah mereproduksi
  • Perilaku yang sebenarnya
  • Perilaku yang diharapkan

Misalnya:

  • Saya menghapus semua pemasok dari basis data (menggunakan DELETE * FROM tSuppliers), membuka dialog pemasok, dan mengklik daftar drop-down Pemasok.
  • Daftar itu berisi pesan berikut: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Ketika saya mengklik pesan itu, aplikasi menghilang dari layar, dan Task Manager.
  • Saya berharap melihat daftar kosong atau (lebih disukai) pesan seperti "Tidak ada pemasok yang ditemukan". Mengklik daftar kosong atau pesan tidak akan berpengaruh. Aplikasi ini jelas tidak boleh hilang tanpa peringatan dalam kondisi apa pun.

Jadi, ya - harus berisi langkah-langkah untuk mereproduksi. Fakta bahwa mereka tidak merasa perlu untuk memasukkan ini tampaknya mengindikasikan bahwa mereka berpikir pekerjaan mereka adalah "merusak perangkat lunak", daripada mengidentifikasi kesalahan.


0

QA harus dapat mereproduksi bug berdasarkan langkah-langkah yang dimasukkan. Jika mereka berusaha keras, masih tidak dapat mereproduksi, mereka masih harus memasukkan bug dengan sebanyak yang mereka miliki dengan stempel waktu sehingga pengembang dapat melihat aplikasi dan men-debug log untuk detail lebih lanjut.


0

Uang dipertaruhkan di sini. Mengapa setiap anggota tim dapat membuat tugas yang tidak jelas, peluang rendah kesuksesan yang membebani pengembang (mudah-mudahan) berbayar tinggi?

Ini bukan tentang mematuk urutan, hierarki, kesombongan, kita vs. mereka, atau semacamnya. Ini hanya tentang berinvestasi dalam kegiatan yang menambah nilai pada produk.

Ketika masalah dapat didemonstrasikan untuk secara negatif dan terukur mempengaruhi nilai produk, maka itu harus diselidiki, direproduksi, dan diperbaiki. Perbaiki pipa cacat produk Anda untuk menyaring kebisingan.


-1

Tim QA Anda menyebalkan

Pergi ke mereka dan suruh mereka membaca dokumen yang harus dicetak oleh penguji profesional mana pun di dalam otak mereka (saya pernah menjadi penguji dan saya masih memilikinya di otak saya): Cara Melaporkan Bug dengan Efektif .

Terutama, arahkan mereka ke bagian "Tunjukkan saya cara menunjukkan diri" :

Ini adalah era Internet. Ini adalah era komunikasi di seluruh dunia. Ini adalah era di mana saya dapat mengirim perangkat lunak saya kepada seseorang di Rusia dengan satu sentuhan tombol, dan dia dapat mengirim saya komentar tentang hal itu dengan mudah. Tetapi jika dia memiliki masalah dengan program saya, dia tidak bisa membuat saya berdiri di depannya sementara itu gagal. "Tunjukkan padaku" itu bagus ketika kamu bisa, tetapi seringkali kamu tidak bisa.

Jika Anda harus melaporkan bug ke programmer yang tidak dapat hadir secara langsung, tujuan latihan ini adalah untuk memungkinkan mereka mereproduksi masalah. Anda ingin programmer menjalankan salinan programnya sendiri, melakukan hal yang sama dengannya, dan membuatnya gagal dengan cara yang sama. Ketika mereka dapat melihat masalah terjadi di depan mata mereka, maka mereka dapat mengatasinya ...


Jika mereka mulai berteriak pada Anda mengeluh bahwa "bug dapat datang dari berbagai arah sekaligus" , beri tahu mereka bahwa mereka mengisap lebih dari yang Anda pikirkan sebelumnya. Beri tahu mereka bahwa Testability adalah fitur yang harus mereka evaluasi di antara fitur-fitur proyek lainnya dan mereka harus menginvestasikan upaya untuk memperbaiki fitur ini.

  • Peningkatan kemampuan uji yang bisa didapat ketika ada tester profesional yang berfokus pada hal itu bisa seperti sulap. Saya belajar itu sendiri beberapa bulan yang lalu. Insinyur QA yang bekerja dengan tim kami memberi saya beberapa permintaan pengujian untuk dikembangkan untuk beberapa komponen dalam aplikasi kami. Hal-hal yang dia tanyakan kurang masuk akal bagi saya, tetapi saya hanya memberikannya dengan anggapan bahwa dia lebih tahu sebagai seorang profesional. Segera setelah saya selesai, dia datang dengan alat yang mengurangi upaya pengujian berdasarkan urutan besarnya . Dia mengatakan sebagian besar didasarkan pada permintaan rahasia yang saya laksanakan, lanjutkan.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.