Artikel ini lahir dari sebuah posting di forum internal kantor kami, sedikit diskusi, sedikit tambahan, dan kemudian saya memutuskan untuk meletakkannya di formulir akhir di sini untuk membuatnya lebih nyaman untuk ditautkan.
Ya, pos adalah kapten, ini adalah perilaku yang diharapkan :) Saya hanya ingin dikumpulkan, tertib, dan secara umum tersedia.
Pendahuluan: temukan kucing
Ada bug dalam produk yang kami kembangkan.
Kami terkadang menemukan mereka. Kadang-kadang kita bahkan menuliskannya.
Untuk membantu kolega kami membuat produk mereka lebih baik.
Dan kami sangat tersinggung ketika rekan-rekan kami menulis surat kepada kami - “Saya tidak mengerti nichrome”, “itu tidak cocok untuk saya”, “datang tunjukkan padaku”.
Terkadang saya mengatakan itu.
Karena seringkali bug terlihat seperti gambar “find a cat”.
Orang yang menulis bug tahu persis di mana kucing itu berada. Dia sudah menemukannya. Dia tidak bisa lagi melihatnya.
Dan saya harus duduk, menggali monitor dan mencari kucing sialan.
Seringkali video dilampirkan ke bug. Lagipula, video menunjukkan semuanya!
Semuanya sama di sana, hanya rumput yang masih berayun (mouse bergerak) dan gerbang terbuka (membuka dialog yang tidak relevan).
Pada titik ini, saya berbicara tentang aturan untuk merekam bug, yang saya coba ikuti sendiri, dan yang saya rekomendasikan kepada orang lain.
Aturan pribadi saya untuk merekam bug
1) Kata kunci di header bug
Sehingga Anda dapat dengan cepat memahami kompetensi milik bug.
2) Langkah-langkah untuk bermain
Dan itu sangat sangat penting. Dan ya, mengompilasinya membutuhkan waktu paling lama saat merekam.
Karena cukup sering, memulai, menuliskan langkah-langkah dan membuang yang "ekstra", Anda memahami bahwa bug tidak selalu direproduksi sama sekali.
3) " perilaku yang diharapkan " vs " perilaku yang diamati " pada langkah-langkah di mana, pada kenyataannya, bug.
Ini sangat penting. Karena tidak selalu apa yang diharapkan seseorang untuk dilihat, sesuai dengan bagaimana sebenarnya. Maka Anda dapat mencari kucing tanpa henti.
4) Screenshot bagus
Gambar memberikan konteks visual, menunjukkan bagian-bagian pengembang produk dengan masalah, dan ia segera memahami bidang pengetahuan yang diperlukan. Gambar dalam hal ini bekerja bersama dengan kata kunci (lihat paragraf 1)
5) Video bagus, tetapi hanya saat kami menunjukkan bug animasi
Dan - video itu adalah sesuatu yang pada dasarnya dapat Anda jalani ketika pembuat bug tidak dapat menulis langkah-langkah untuk pemutaran.
Atau kesalahannya adalah non-deterministik, dan bukti diperlukan.
Dalam kasus lain, videonya berlebihan.
Video untuk bug harus untuk bug. Panjang 10 detik, tanpa membuka jendela kiri.
6) Stack trace / console error dengan eksekusi eksplisit
Yah, hampir semua orang mengerti ini dan menerapkannya, saya menulis hanya untuk kelengkapan daftar.
7) Contoh untuk pemutaran .
Jika kita berbicara tentang semacam sistem desktop, maka kita perlu arsip tempat masalah tersebut direproduksi.
Di web lebih mudah - Anda sering dapat memberikan tautan ke demo online (atau ke lingkungan pementasan yang diperluas).
Itu semua dalam perkiraan pertama.
Saya berbagi ini dengan orang lain - dan sering mereka percaya padaku dan mulai melakukan hal yang sama.
Contoh lebih lanjut dan 20% dari detail, yang menempati 80% dari artikel :)
Contohnya
Contoh bug adalah bagaimana saya menulisnya, dan yang kurang lebih :)
dxTreeView membuat indikator pemuatan berlebihan dalam mode Virtual
Lebih banyak tiket (hanya beberapa pilihan acak dari daftar tiket publik yang direkam oleh tim kami) Filosofi dan detail kecil yang menentukan
Persiapan Screenshot
Gambar harus dengan panah merah besar atau bahkan dengan teks.
Tangkapan layar harus menjadi bagian dari tubuh bug, tepat di teks.
Jika bug dilaporkan di sebagian besar sistem modern, maka ini dilakukan hanya dengan menempelkan gambar dari clipboard dengan Ctrl + V
Mengapa Anda tidak bisa memberikan tautan ke gambar saja? Karena ada kehilangan konteks. Jika Anda melihat gambar, Anda tidak melihat teksnya. Jika Anda melihat teks, maka Anda tidak melihat gambar. Jika Anda melihat ini dan itu - probabilitas bahwa sesuatu mengklik di otak jauh lebih tinggi.
Satu menit deformasi profesional
Itulah mengapa dasbor sebagai fenomena analisis data menjadi populer :)
Ketika seseorang melihat data yang sama dalam format yang berbeda dan dari sudut yang berbeda, wawasan bisa datang kepadanya.
Lihat Steven Few dan penulis lain untuk detailnya.
Ukuran tangkapan layar selalu merupakan kompromi.
Ketika kecil, masalahnya lebih baik dilihat, dan hanya memakan sedikit ruang. Namun tidak selalu jelas dari mana karya ini berasal.
Mereka menangkap area layar sedikit lebih - rincian asing cocok. Layar tempat munculan dibuka, yang merupakan galat. Browser di mana kesalahannya. Tombol Start untuk Windows yang menjadi penyebab kesalahan. DPI monitor tempat kesalahan ... oh, tetapi kesalahan itu sendiri tidak lagi terlihat. Kucing itu menjadi dua pixel dan bahkan tidak dapat didefinisikan di dalam lingkaran merah.
Tempat berhenti memotong tangkapan layar selalu merupakan seni)
Contoh tangkapan layar, dari kecil ke besar:
laporan bug dalam KUHP, pagar rusak
Masalahnya jelas terlihat, tetapi konteksnya hilang. Jika tidak ada tulisan dalam kata-kata bahwa itu di dekat pintu masuk utama, tukang las akan berjalan di sekitar situs dengan topeng, akan mencari.
dalam komunikasi pribadi, pertanyaan tentang implementasi TreeView
Terlihat elemen mana yang ada dalam pikiran saya (tanda plus ... yah, terjemahkan tombol memperpanjang lebih baik :)), konteksnya terlihat (layar wisaya baru)
- Masalah dengan penskalaan demo dasbor di DPI = 125%
Dapat dilihat browser seperti apa dan URL situs
Tab tidak perlu buram, agar tidak mengalihkan perhatian. Sebuah artikel tersisa tentang Pembaruan Kreator Windows 10 (di mana 125% DPI menjadi default pada 15,6 ″ laptop) sehingga, melihat screenshot ini, saya akan mengingat ini dan dapat memamerkan dan membicarakannya.
Mari kita tekankan lagi. Dengan alat normal, waktu persiapan untuk masing-masing tangkapan layar ini adalah 5 hingga 30 detik.
Ini bukan buah dari karya seni yang panjang. Cepat dan efisien. Anda dapat berhenti dan membawa mereka masing-masing ke kesempurnaan ... tetapi sebagai aturan ini tidak diperlukan.
Program untuk mengambil tangkapan layar
- Yandex.Disk, saya sangat suka screenshot-nya . Nah, ini dia. Untuk beberapa alasan, ternyata itu yang terbaik dari apa yang saya coba buat panah, lingkaran dengan kotak kecil dan tambahkan tulisan yang dapat dibaca. Semua contoh dari artikel dibuat di atasnya.
- Monosnap (gratis, dengan paket berbayar). Pada prinsipnya, tidak ada apa-apa, tetapi (subjektivitas!) Panah itu jelek;
- ShareX (sepenuhnya gratis);
- Jing telah banyak digunakan oleh para insinyur dukungan teknis kami; perlahan-lahan pergi, karena dia menulis video dalam sekejap.
- Di Windows 10 - kombinasi bawaan Win + Shift + S # Komentar penulis: sangat bagus
- screenshoter bawaan di Mac # ,
- GreenShot - Menangkan # , #
- LightShot - Mac / Win #
- Pengambilan FastStone #
- FlameShot (Linux, di github mendiskusikan kemungkinan Windows)
- Snipping Tool - Dibangun di Windows #
- gooncam #
- PicPick (Windows) #
- Spectacle & KSnapshot (Linux) #
- Problem Steps Recorder - terintegrasi ke dalam Windows, diluncurkan melalui PSR dari baris perintah
Kami menuliskan masalahnya, bukan solusinya
Item ini muncul sebagai hasil dari diskusi internal. Sangat tak terduga, itu tidak jelas bagi semua orang, karena itu - sebuah contoh.
Misalnya, saya menguji desainer dasbor dan saya melihat hal seperti itu:
Dan saya menulis bug:
"Tidak ada gulir horizontal"
Saya bahkan bisa menulisnya dengan langkah-langkah dan hasil yang diharapkan: smiley:
Hasil yang Diharapkan : Nama aturan harus digulir secara horizontal.
hasil nyata : nama aturan tidak digulir
Bug ini dibingkai secara normal, tetapi ini tidak mencegah pengembang menganggap saya orang bodoh. Dan dia akan benar :)
Ada masalah: "teks tidak terlihat secara keseluruhan; teks ditumpangkan pada ikon"
Tetapi alih-alih merekam masalah ini, saya mencatat solusi saya untuk masalah ini. Satu dari banyak, dan tentu saja bukan yang terbaik.
Dan penggantian seperti itu tidak jarang terjadi. Bahkan saya sendiri, saya terkadang menangkap ini.
Lagi pula, saya tahu persis bagaimana cara memperbaikinya. Jadi, saya akan menulisnya!
(Yah, kadang-kadang saya benar-benar tahu. Dan saya mencoba menulis saran saya di tubuh bug, setelah benar-benar menggambarkan masalahnya. Tapi bukan sebagai satu-satunya solusi yang mungkin)
Contoh pro untuk pemutaran
Dalam pengembangan desktop, item ini masih bisa diperdebatkan. Di satu sisi, utilitas mengeksekusi kode contoh yang mereproduksi masalah jelas bagi semua orang.
Di sisi lain, membuat contoh sudah secara signifikan meningkatkan waktu yang diperlukan untuk menulis bug, hingga pesanan.
Secara umum, di kepala saya seperti ini: untuk kasus-kasus yang kompleks itu perlu, dalam kasus-kasus sederhana itu bisa berlebihan.
Saya diajari di universitas bahwa jika sistem keamanan menjadi terlalu rumit dan membawa bahaya dan ketidaknyamanan, maka mereka hanya berhenti menggunakannya.
Jika Anda mewajibkan contoh dibuat untuk setiap bug, maka dalam sebulan mereka akan mencetak bahkan contoh untuk bug kompleks)
Di sisi lain, pada bug sederhana Anda dapat melatih untuk membuat contoh ...
Singkatnya, masalah ini masih bisa diperdebatkan.
Saya akan menambahkan artikel CTO dari kantor kami ke celengan sepuluh tahun yang lalu, di mana dia menjelaskan mengapa kami meminta pelanggan kami untuk contoh.
Permintaan untuk program contoh sederhana 10 oleh Julian
Dan ada momen seperti itu dengan contoh sederhana, kutipan:
Contoh yang sangat sederhana tentu baik, tetapi juga buruk. Ada kasus berulang yang contoh sederhana:
- tidak mencakup semua skenario bug;
- tidak mencerminkan skenario nyata, yang dapat mengarah pada solusi yang tidak tepat.
Idealnya, lebih baik memiliki sampel yang disederhanakan dan asli.
Sekarang Anda tahu itu:
- menyiapkan contoh sangat berguna;
- itu sulit;
- yang utama adalah jangan berlebihan.
Waktu perekaman bug
Ternyata banyak surat. Ini mungkin tampak seperti prosedur birokrasi yang rumit, panjang dan membosankan.
Jadi, seharusnya tidak sulit dan panjang.
Median waktu perekaman bug yang memenuhi alas kaki persyaratan di atas adalah sekitar satu menit.
Ya, dalam kasus di mana ternyata langkah-langkahnya tidak mereproduksi bug; atau bahwa mereka tidak semuanya penting, dan ingin menghilangkan kelebihannya; atau langkah baru telah terungkap dalam proses - maka waktu meningkat.
Tetapi kemungkinan bug Anda akan diperbaiki dan tidak ditutup dengan komentar "tidak dapat direproduksi" tumbuh secara signifikan.
Oposisi
Apa yang mereka katakan ketika saya membagikan visi saya:
bug jelas
Jelas bagi seseorang yang sudah menemukan kucing.
Tanpa deskripsi dan langkah-langkah terperinci, semua orang harus mencarinya. Waktu non-deterministik.
Ya, istri saya dan VYudachev menemukan kucing itu dalam tiga detik pertama. Dua sampel saya.
Dan sisanya dari orang-orang (sekitar selusin atau lebih), yang monitor saya lihat, mencari kucing selama lima menit.
Namun secara umum, saya meludah dan segera membuka tebakan.
Dan dengan bug yang ditulis buruk hal yang sama.
videonya cukup, semuanya terlihat di sana
Pertama, bagi pembaca bug itu adalah waktu yang lama. Jauh lebih lama daripada membaca daftar langkah-langkah, merayapnya untuk kata kunci.
Kedua, untuk mengetahui detail terkecil, perlu untuk merevisinya berkali-kali, mencoba untuk berhenti, menangkap jeda tepat pada saat-saat kritis.
Ketiga, seringkali pada video yang tidak disiapkan dengan baik ada banyak detail tambahan. Dan Anda tidak tahu apa yang benar-benar berlebihan dari ini, dan apa yang tidak. Apakah perlu untuk menutup pemberitahuan dari VKontakte untuk reproducibilitas bug? .. Apakah ada interaksi dengan sistem operasi yang menyebabkan bug rendering? .. Dapatkah saya menggunakan telegram alih-alih VKontakte? ...
(Dalam keadilan, itu terjadi dalam praktik saya bahwa penulis fungsional menemukan bug lain di video terlampir)
tulis bug seperti ini untuk waktu yang sangat lama
Butuh waktu lebih lama untuk menulis bug dengan langkah-langkah, itu benar.
Seringkali karena, dengan menuliskan langkah-langkah yang tepat, Anda tanpa disadari mulai melakukan pekerjaan debugging.
Anda mencoba membuang beberapa langkah, atau itu penting.
Ya, Anda menghabiskan waktu dan menghemat orang lain.
Referensi
Daftar persyaratan untuk merekam bug lahir berdasarkan saya:
jika Anda membuang spesifik forum-maillist-open-source, maka hampir semuanya bernilai. Termasuk favorit saya "Jelaskan gejala masalahnya, bukan tebakan Anda" dan "Jelaskan pertanyaan Anda secara eksplisit";
Akhirnya
Saya membagikan pendapat ini tentang merekam bug dengan tim saya. Sekarang saya memutuskan untuk menjangkau audiens yang lebih luas.
Terima kasih sudah membaca.
Ini adalah petunjuk untuk gambar kucing ( diambil di sini ).
By the way, gambar itu bukan milikku, tapi siap - ada panah, dan ada peningkatan di daerah dengan sebuah bug kucing
UPD 06/28/2019
Cuplikan layar program dari komentar yang ditambahkan ke daftar umum
Kesalahan ketik diperbaiki, bahkan menyebabkan diskusi dalam komentar