Aynı konuda / bilette birkaç hata gönderilmesi neden önerilmiyor?

Aşağıdaki kavramsal soruyu soracağınız yerin bu olup olmadığından emin değilim (Stackoverflow kesinlikle değildir).

Bu soruyu ISTQB sınavlarına benzer şekilde çoktan seçmeli bir sınavda (tek cevap) gördüm :

Aynı konuda / bilette birkaç kusurun bildirilmesi neden önerilmiyor?

a. Raporun kısa ve net kalması için.

b. Çünkü geliştiriciler yalnızca bir hatayı düzeltebilir.

c. Çünkü test grubu test cihazları, buldukları hata miktarına göre derecelendirilmiştir.

d. Hata yönetimi sistemleri, çoklu hataların bu özelliğini desteklemez.

Tek fikrim adoğru cevap budur.

b- Düzeltme-geri bildirim-çözüldü-kapandı , bu durumda kaçınması gerektiği için olamaz . c- Belli ki yanlış.

d - Redmine / Trac eklentileri birden fazla alanı destekliyor.

Cevap kağıdına göre cevap b.

Birisi nedenini açıklayabilir mi? Cevaplarla ilgili düşünceleri olan yorumlar açıktır.

Stack Overflow'un bir kılavuzu olup olmadığını bir düşünün: bir soru sormak yerine, aklınıza ne gelirse gelsin, son iki hafta boyunca sahip olduğunuz tüm sorunları soruyorsunuz. Olumlu ve olumsuz olmanın anlamı ne? Soruların başlıkları ne olurdu? En iyi cevabı nasıl kabul edebilirim? Soru nasıl etiketlenir?

Hata izleme sistemi ... böcekleri izlemek için yapılır. Bir hatanın izlenmesi şu anlama gelir:

1. Bir hatanın olabileceğini söyleyen bir kayıt oluşturarak, nasıl çoğaltılacağına dair bilgiler içeren

2. Gerçekten de, böceklerin var olduğunu ve bir böcek olduğunu, tasarım gereği değil

3. Hatanın şimdi çözüldüğünü iddia ederek,

4. Hatanın çözüldüğünü onaylayın.

Çok basit bir modelde, müşteri tarafından 1 ve 4 ve geliştirici tarafından 2 ve 3 yapılacaktır.

Aşağıdaki günlüğü hayal edin:

• 1. Gün [Müşteri] “Ürün detayları” penceresinde “Kaldır” butonuna basıldığında uygulama kilitleniyor. Uygulamayı yeniden başlatmak, ürünün kaldırılmadığını gösterir. Beklenen davranış, ürünü kaldırmaktır.

• 4. Gün [Geliştirici] <Sayı çoğaltıldı>

• 5. Gün [Geliştirici] <Sorun 5031 revizyonunda çözüldü>

• 12. Gün [Müşteri] <Bilet kapatıldı: sorun çözüldü>

Günlük basit ve açık . Ne olduğunu ve ne zaman , hangi revizyonun hangi hatanın çözüldüğünü vb. Kolayca takip edebilirsiniz . Örneğin, eğer hata izleme sistemi sürüm kontrolü ile entegre edilmişse, belirli bir revizyonu görüntülediğinizde, hangi hataların çözüldüğünü kontrol edebilirsiniz.

Bilgi bulmak kolaydır . Durumunu görmek kolaydır (çoğaltılır mı? Bilet kapatıldıysa neden?). Biletleri filtrelemek kolaydır (yalnızca eklentilerin kullanıcı arayüzünü ilgilendiren biletleri göstermek istiyorum, yalnızca açık, bir haftadan daha eski ve etkileşim tasarımcısının bana verdiği ve orta veya yüksek önceliğe sahip olan biletleri istediğim için).

Bir bileti yeniden atamak ya da başlangıçta hatadan sorumlu olan kişinin hangisi olduğunu belirlemek kolaydır.

Şimdi aşağıdaki günlüğü hayal edin:

• 1. Gün [Müşteri] “Ürün detayları” penceresinde “Kaldır” düğmesine bastığımda uygulama kilitleniyor. Ayrıca, sol panelin arka plan rengi koyu mavi iken, mor renkte olmalıdır. Ayrıca “Ürün detayları” penceresinin metninin Almanca'ya iyi çevrilmediğini de not ettim; bekleniyor mu Nihai çeviri ne zaman hazır olacak? BTW, “Ürün yayınla” işlemi için gönderdiğim yeni simgeyi aldınız mı? “Veri senkronize et” penceresinde görmüyorum.

• 6. Gün [Geliştirici] Rengi mor olarak değiştirdim.

• 7. Gün [Geliştirici] Evet, Almanca'ya çevirinin eksik olması normaldir.

• 8. Gün [Müşteri] Almanca için uygun. Peki ya İtalyan? Lucia size XML dosyasını iki gün önce gönderdi.

• 9. Gün [Geliştirici] Şimdi tamam.

• 10. Gün [Müşteri] “Kaldır” düğmesi için uygun mu? Garip, bilgisayarımda hala takılıyor.

• 11. Gün [Geliştirici] Hayır, İtalyanca çeviri için uygun olduğunu söylemek istedim.

• 12. Gün [Müşteri] Anlıyorum. Teşekkür ederim. Fakat rengin bir sorunu var. Koyu mor olarak değiştirdiniz, ancak ana penceredeki üst panel gibi açık mor renkte olması gerekir.

• 13. Gün [Geliştirici] Simgesini güncelledim.

• 14. Gün [Müşteri] Simge? Hangi simge?

• 15. Gün [Geliştirici] Güncellememi istediğiniz simge.

• 16. Gün [Müşteri] Sizden hiçbir simgeyi güncellemenizi istemedim.

• 17. Gün [Geliştirici] Tabii siz istediniz. Bu bileti gör. Yayınla ürün simgesinin güncellenmesi gerektiğini yazdınız. Yaptım.

  ⁞

• 100. Gün [Müşteri] Peki, günlükteki girişlerden ne haber?

• 101. Gün [Geliştirici] Ne hakkında konuştuğunuz hakkında hiçbir fikrim yok. Bu bilette bile değil, 6199'da. Bunu çözüldüğü gibi kapatıyorum. <Bilet kapalı: sorun çözüldü>

• 102. Gün [Müşteri] Yeniden açtığım için üzgünüm, fakat sorun çözülmedi. Günlükteki girişlerden bahsediyorum: Geçen hafta size unicode karakterler içerdiğinde metnin bazen geçersiz olduğunu söyledim. Hatırlıyor musun? <Bilet yeniden açıldı>

• 103. Gün [Geliştirici] Belli bir şeyi hatırlıyorum, ancak bu biletin son üç sayfasını aradıktan sonra hiçbir iz bulamıyorum. Sorunun ne olduğunu tekrar yazabilir misin?

  ⁞

• Gün 460 [Geliştirici] İki saatimi ağ üzerinden şifreli olarak gönderilen dosyalar hakkında söylediklerinizin izini aramaya harcadım. Kesin bir istek bulabileceğimden emin değilim.

• Gün 460 [Müşteri] Sizler gerçekten daha organize olmalısınız. Son iki hafta boyunca bu konuda dört kez bilgi verdim. Neden her şeyi unutuyorsun?

  ⁞

Bu kayıt ne hakkında? 43 kez çözüldü ve 43 kez tekrar açıldı. Geliştiricinin aynı sorunu 460 gün boyunca çözemediği kadar aptal olduğu anlamına mı geliyor? Ah, hayır, bekleyin, bu bilet bu arada 11 geliştiriciye verildi. Anlaşma ne? Belirli bir konu nasıl aranır? Aslında Vanessa'ya atanmış, ancak beş meslektaşı bu biletteki on bir sayıdan yedi tanesiyle de ilgileniyor. Bilet ne zaman kapanmalı? Sorunların yarısı çözüldüğü zaman mı? Ya da belki on birinden on?

Not: Bu tür kayıtların bulunmadığına inanabilirsiniz. İnan bana, bir kereden fazla olanları gördüm.

Sadece ifadenize yorum yapmak için:

düzeltme-geri bildirim-çözüldü-kapandı bu durumda kalmamalı

Bu, ortaya çıkan tüm böceklerin aynı anda sabitleneceğini varsayar. İki sorunlu ürünün v1'ine karşı bir biletin yükseltildiği bir senaryo düşünün:

1. Bir form sıfırlama düğmesi aslında değerleri silmek yerine formu gönderir
2. Düğmedeki yazı tipi boyutu% 115 olması gerektiğinde% 110'dur.

Her ikisi de, bir test cihazının yükselmesi için doğrudur, çünkü uygulamada her ikisi de hatalıdır. Ancak diyelim ki ürün sahibi, ilk alt görevin serbest bırakılması için bir engelleyici olduğuna karar verir (yani, ürün yayınlanmadan önce düzeltilmesi gerekir), ancak ikinci görev küçük bir konudur (yani v1'de sabitlenebilir). 1 sürüm).

Bu durumda, 2 numarayı kendi biletine bölmekten başka bir seçeneğimiz yok (ya da bunu unutma riski var). Bunu yapabilirsek, birbirlerinden bağımsız olarak uygulanabilecekleri, test edilebilecekleri ve konuşlandırılabilecekleri anlamına gelir, bu durumda başından itibaren bireysel sorunların olması mantıklıdır.

Kapsam:

Bu cevap (ve soru) yalnızca kaynak kodun spesifikasyona veya programcıların niyetlerine göre performans göstermediği durumlarda, kod hatalarının izlenmesi için uygulanabilir görünmektedir.

Aksine, her GUI biletinin etkin bir şekilde "yeniden tasarlanması" (tasarım hatası), "gözden geçirilmiş bir özellik" veya "özellik isteği" (eksik işlevsellik) olduğu için GUI kusur biletlerinin birden fazla spesifikasyon içermesi yaygındır.

Hata izlemenin önemli bir amacı, çoklu roller (programcılar, test uzmanları, müşteriler ve yöneticiler) arasında iletişim kurmak ve koordine etmektir.

Kod kalitesinin yüksek öneme sahip olduğu projelerde (örneğin kullanıcı dostu olma durumuna göre), hata izleme, biri kod hatalarının izlenmesine odaklanacak olan birden fazla yönden oluşabilir. donanım , geliştirmelerin izlenmesinden ve müşteri destek taleplerinden ayrı olarak .

Kod hatası izleme sisteminin amacı:

• Bağımsız olarak çoğaltılabilen bağımsız ve net bir şekilde takip edilmesini sağlamak kusurları ve
• Her defektin kök nedenine en iyi yaklaşımı (birebir yazışma) sağlamak.

Bunu yaparken, aşağıdaki istenen nitelikleri maksimize etmelidir:

• Kusur sayısı zamanla arttıkça verimli bir şekilde ölçeklendirin.
• Hareketli hedef sendromunu önleyin.

Feragatname: Bu cümle benim kişisel deneyimimdendir. Sertifika sınavı amacı için yetersiz veya yanlış olabilir.

Bağımsız ve net izleme, şu anlama gelir:

1. Her geçerli kusur, belirsizlik olmadan çözülebilir veya çözülemez .

   • Sebep 1: yönetimi kolaylaştırmak,
     • Örnek: "çözümlenmemiş bilet sayısı" nın metrik olarak kullanılmasını sağlar.
   • Sebep 2: işlem yapılabilir öğeye çevirmek
     • Örnek: çözülmezse, sorumluluk atanan programcının üzerindedir. Çözümlenir ancak kapanmazsa, sorumluluk atanan test cihazına aittir (doğrulayıcı).
   • Sonuç: Bu metodolojide, kısmen çözülmüş bir kusur birkaç bağımlı kusura ayrılmayı hak eder.

2. Bağımsız olarak yeniden üretilebilir kusurlar bağımsız olarak izlenmelidir.

   • "Bağımsız olarak yeniden üretilebilir", farklı durumlara sahip olabilecekleri anlamına gelir. Biri kırık kalırken biri sabit görünebilir.
   • Sebep: Hata izleme ve kök neden analizi arasındaki uyuşmazlığı en aza indirgemek.
     • Bir kod kusuruna kadar izlenebilecek her kök nedenin en az bir kod değişikliği gerektirdiğine inanılır.
     • İki hata bağımsız olarak yeniden üretilebiliyorsa, birden çok kod değişikliğine ihtiyaç duyulur.
     • Eğer iki hata bağımsız olarak tekrarlanabilirse, her ikisinin de test edilmesi (doğrulanması) gerekir, çünkü bir testin geçmesi diğer testin geçeceği anlamına gelmez.
   • Örnek 2: Eğer iki belirtinin başlangıçta aynı kök nedene sahip olduğuna inanılıyorsa ve böylece aynı bilete sınıflandırılmışlarsa ve daha sonra bağımsız olarak tekrarlanabilir oldukları gösterilmişse, iki bilete bölünmeleri gerekir.

Birkaç ay sonra ortaya çıkan sistemi kullanan birisinin perspektifinden bakın. Programda bir hata bulmuşlar. Etraflarında Google ve gördükleri sorunla eşleşen bir destek bileti olduğunu görüyorlar. Ve hey, kapalı! Müthiş! En son sürümde düzeltildi! Demek güncelleme yapıyorlar ve böcek hala orada mı? Bu aptal geliştiricilerin nesi var?

Hiçbir şey aslında. Hata raporunu gönderen kişiyle ilgili yanlış bir şeyler olduğu ortaya çıkıyor. Aynı bilette iki böcek gönderdiler. Biri tamir etmek kolaydı ve hızlı bir şekilde düzeldi, diğeri de değildi. Fix-feedback-resolved-closed gibi bir şey kullanıyor olsanız bile , özellikle dışarıdaki bir gözlemciye ne olup bittiğinden daha az olabilir.

Her böceğe kendi biletini vermek çok daha iyidir ve ilgili ancak görünüşte farklı olan birden fazla hatanız varsa, çoğu hata izleme sistemi bir hatayı diğerine bağlamanıza izin veren bir özelliğe sahiptir. (Ve eğer değilse, sadece rapora koyabilirsiniz. "Ayrıca bakınız # 12345.")