Kullanıcıların düzgün ve kullanışlı hata raporları yazmalarını sağlama

Kullanıcıların yarı saygın (okuma: faydalı ) bir hata raporu yazmalarını sağlamanın iyi bir yolunu bilen var mı ?

Çoğu kullanıcı için anlamlı olacak bir şey ortaya koymak istedik (okuması ve anlaması kolay), ancak geliştiricilere de faydalı bilgiler verdik.

Mavi düğmeye tıkladığımda çalışmıyor! Ahhh, daha bir haftalık çalışmasını kaybettim ... çalışmasını sağla.

olduğu gibi çok kullanışlı değil.

Bir listeyi düzeltmeye başladım, ancak benzer bir yöntemin zaten mevcut olup olmadığını kontrol etmeyi düşünüyorum.

Kullanıcıların doğru ve yararlı hata raporları yazmalarını sağlamanın en etkili yolu

1. raporlarını çevrimiçi görmelerini sağlamak için ...
   ^{[Sistem] Bildirdiğiniz için teşekkür ederiz, isteğinizin durumunu burada bulabilirsiniz: ...}
2. ... değerlendirme ve atanmış mühendisin yorumlarıyla birlikte ...
   ^{[Mühendis] Reddedildi, aşağıdaki detaylar için eksik: ...}
3. ... raporlarını düzenleme / geliştirme seçeneği ile .
   ^{[Kullanıcı] İstenen ayrıntılar eklendi, lütfen tekrar değerlendirin: ...}

Bunun tek etkili yol olduğunu iddia etmek kadar ileri giderdim .

Kabul edelim, hata raporlarını etkin bir şekilde yazabilmek sadece tecrübe ile gelir. Kişinin deneyim kazanmayı öğrenmesi gerekiyor. Öğrenme, pratik yapmayı, geri bildirim almayı ve geliştirmeyi içerir.

Kullanıcı tarafından düzenlenebilir çevrimiçi hata raporları, kullanıcılara iyileştirmeyi öğretmenin en etkili yoludur .

• ^{Yukarıdaki seçeneklere alternatifler 1), kullanıcılarla yüz yüze öğrenme oturumları düzenlemek (evet, özellikle dünyaya yayılmış binlerce kişi olduğunda). Veya 2) bunları telefonla açıklayın ("yalnızca 225 satırında yazdığınız saçmalıkları görebiliyorsanız bakın ..."). Başka? Oh 3) e-posta ile, "iki ay önce bize gönderdiğiniz postada, bahsettiniz ... o e-postadan değil, bu gün bize beş e-posta gönderdiniz, bunlardan üçü Re: mavi düğme tıklamasıyla bakıyordu. ikincisi, ona bağlı 10 MB ekran görüntüsü olan ... ... ne? bulamıyor musunuz? "}

Bence daha önemli olan, hatayı kullanıcı ile temasa geçerken anlamlı kılmak için hatayı kullanmak. Hata raporlarını yazmak ve anlamak bir beceridir ve tavsiyem kullanıcının ilk temas kurmasını mümkün olduğunca kolaylaştırmak ve ardından gerektiğinde daha fazla değer vererek geri bildirimlerini yapmak olacaktır.

Örneğin, kullanıcının e-postasını almanız ve tamamlamaları için aşağıdaki metinle birlikte onlara düz metin alanı verin:

"I did _____ , and expected ______ to happen, but ______ happened instead."

E-postayı aldıktan sonra, hatayı gönderdiklerini, aldığınızı ve hatayı takip etmenin tamam olduğunu onaylamak için iki kez seçmek için otomatik yanıtlama yapın.

Bu konuda Mozilla ve Sun'dan bazı fikirler almayı düşünebilirsiniz:

• Hata yazma kuralları - Mozilla MDN makalesi
• Doğru Hata Nasıl Yazılır - Mozilla QMO makalesi
• Faydalı Bir Hata Raporu Nasıl Yazılır - Sun SDN makale

Özellikle (Mozilla "Doğru bir Hata Nasıl Yazılır" sayfasından):

Hata Raporunun Genel Taslağı

Özet : Hatayı 60 karakterden daha kısa sürede nasıl tarif edersiniz? Bir hata raporunu hızlı ve benzersiz bir şekilde tanımlamalı ve önerilen çözümünüzü değil, sorunu açıklamalıdır.

İyi : “Dosya Kopyalama iletişimini iptal etmek Dosya Yöneticisini çökertiyor”

Kötü : “Yazılım çöküyor”

Kötü : “Tarayıcı web sitemle çalışmalı”

Bileşen : Yazılımın hangi alt bölümünde var? Bu alan herhangi bir hata bildirimi göndermek için zorunludur. Her bir bileşenin açıklamasını görmek için “Bileşen” kelimesini tıklayın. Hiçbiri uygun görünmüyorsa, “Genel” bileşenini vurgulayın.

İşletim Sistemi : Hangi işletim sisteminde (işletim sistemi) buldunuz? (örn. Linux, Windows XP, Mac OS X.) Örnek: “Eğer hatanın birden fazla işletim sisteminde meydana geldiğini biliyorsanız,“ Hepsi ”seçeneğini seçin. İşletim sisteminiz listede yoksa, “Diğer” i seçin.

Açıklama : Aşağıdakiler de dahil olmak üzere sorun raporunuzun ayrıntıları:

- Genel bakış : Bu, özetin daha ayrıntılı bir ifadesidir. Bir örnek şöyle olabilir: “Herhangi bir sayfayı sürükleyerek seçmek, NSGetFactory işlevinde Mac'in oluşturduğu çöküyor”.

- Yapı Kimliği : Bunu bulmak için ya konum çubuğu üzerinden “about:” sayfasına gidin ya da MozQA'nın Nightly Tester Tools uzantısına sahipseniz, Araçlar | Nightly Tester Tools ve build Id'nin çıktısını içeren seçeneği seçin. Şöyle bir şeye benzemelidir: “Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-ABD; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3 ″.

- Ek Yapılar ve Platformlar : Hatanın diğer platformlarda (veya varsa, tarayıcılarda) olup olmadığı. Şöyle bir şeye benzemelidir: “Mozilla / 5.0'da Meydana Gelmiyor (Macintosh; U; Intel Mac OS X 10.5; tr-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Yeniden Oluşturma Adımları : Hatayı tetikleyecek en aza indirgenmiş, takip etmesi kolay adımlar. Gerekirse, özel kurulum adımlarını eklediğinizden emin olun. Buna güzel bir örnek aşağıdaki gibi olacaktır: 1) Herhangi bir web sayfasını görüntüleyin. ( Http://www.google.com/ adresindeki varsayılan örnek sayfayı kullandım ). 2) Sayfayı sürükleyin. Özellikle, fare düğmesini basılı tutarken, fare işaretçisini tarayıcının içerik bölgesindeki herhangi bir noktadan tarayıcının içerik bölgesinin altına doğru aşağı sürükleyin.

Gerçek Sonuçlar : Yukarıdaki adımları uyguladıktan sonra uygulama ne yaptı? Bir örnek şöyle olurdu: Uygulama çöktü.

Beklenen Sonuçlar : Uygulamanın yapması gereken, böcek mevcut değildi. Bir örnek: Pencere aşağıya doğru kaydırılmalıdır. Kaydırılan içerik seçilmelidir. Veya, en azından, uygulama çökmemelidir.

Simon Tatham'ın Hatalarını Etkili Olarak Rapor Etme Var . Daha az deneyimli kullanıcılar için kolay anlaşılmasını sağlamak için işleri güzelce açıklar. Ancak olumsuz tarafı, biraz metin olmasıdır. Bir sorunu bildirmeye çalışan ancak açıklayamadığınız bir kullanıcı varsa, genellikle onu tüm bunları okumaya ikna edemezsiniz.

Yararlı raporlar beklemek için kullanıcılara soruları kolayca cevaplaması ve cevaplaması kolaydır.

Örneğin, "Bu hatadan önceki son işleminiz neydi?", "Bu hatadan hemen önce ... denediniz mi?".

Hiçbir kullanıcı aşağıdaki gibi bir hata raporu yazmaz: "Video sürücüm güncel değil. Grafik kitaplığınız eski grafik sürücüleri ile uyumlu olmayabilir."

Kullanıcı tabanını varsayarsanız, yazdığınız yazılımla sorunu olan son kullanıcılar ...

Uzman bir Yazılım Mühendisi veya Test uzmanı olmak sizin işiniz değil ve beklememelisiniz. Kullanıcılarınız, yazılımın “sadece çalışmasını” haklı olarak bekleyen ortalama kişilerdir. Olmadığında, dikkatinizi çekmek için neye dikkat ettiklerini düşündükleri her şeyi rapor edeceklerdir. Bunu değiştiremezsiniz ve denememelisiniz. Bir profesyonelin yapması beklenen rapor türleriyle ilgili ısrarcı herhangi bir girişimde bulunulması, hata raporunun kaybedilmesine ve müşterinin sonuçlanmasına neden olacaktır - “Bu yazılımla ilgili bir sorunum vardı, ancak bana yardım etmek yerine, hepsini doldurdular. hiçbir şey ifade etmeyen ve benim için hiçbir değeri olmayan işe yaramaz formlar. Gerçekten işe yarayan bir yazılım bulacağım. "

yani bu onların işi değil .....

İyi hata raporları istiyorsanız, hatalarınızı bulmak için profesyoneller kullanın. Bir yazılım geliştiricisi olarak müşterilerle uğraşmaktan rahatsız olamazsanız, yapabilen birini kullanın.