İyi Bir Hata Raporunun Anatomisi

Neredeyse bir buçuk yüzyıldır, mühendisler makinelerdeki küçük kusurları "böcek" olarak adlandırıyorlar. Günümüzde "buglar", bilgisayarlarda ve aygıtlarda hem donanım hem de yazılım sorunları için kullanılmaktadır. Bilgisayar hataları epeydir ortalıkta ve onlarla birlikte hata raporları da geldi.

İlk bilgisayar hata raporu 9 Eylül 1947'de Grace Murray Hopper tarafından belgelendi. Harvard Mark II bilgisayarındaki röle kontakları arasında gerçek bir güvenin sıkıştığını bildirdi. Hata, bilgisayar kayıt defterine kaydedildi.

İlk hata raporu hakkında daha fazla bilgiyi burada bulabilirsiniz.

O zamandan beri, hata raporları tüm QA sürecinin önemli bir parçası olmuştur. Programlama kodlarındaki hataları bildirmek için ana araç olarak kalırlar.

Bu makale, iyi bir hata raporuna nelerin dahil edilmesi gerektiğini kapsar. Ayrıca, her birinin kısa bir analizi de dahil olmak üzere iyi ve kötü hata raporları için birkaç örnek olacaktır.

Hata Raporu Nedir?

Web sitesi geliştirmede, belirli bir kod parçasının beklendiği gibi çalışmadığını belirtmek için kullanılan ana araç hata raporudur. Pek çok farklı "hata" örneği var, ancak bunlardan birkaçını saymak gerekirse:

• Çok fazla sistem kaynağı kullanıldığı için bir web sitesi çöküyor
• Görüntüler belirli tarayıcılarda veya cihazlarda tuhaf görünüyor
• Bir web mağazası, bazı ürünler için yanlış fiyatlar gösteriyor
• Müşteri gereksinimlerine göre bir özellik çalışmıyor

Bir hata raporunun temel amacı , geliştirme ekibinin QA ekibi tarafından bildirilen sorunu yeniden üretmesine izin vermektir. Hata ayıklama ve düzeltme sürecini kolaylaştırmak için gerekli tüm bilgilere sahip olmak önemlidir.

Hata raporları yalnızca sorunları bildirmek için değil, aynı zamanda yeni özellikler ve iyileştirmeler önermek için de kullanılır. Bu nedenle, iyi bir hata raporunun neleri içermesi gerektiğine ilişkin yönergelerin çoğu, öneriler için de geçerlidir.

İlgili Makale: WordPress Web Siteniz İçin Bir Kalite Güvence Planı Nasıl Geliştirilir

Bir Hata Raporu Neleri İçermelidir?

İyi bir hata raporu, meydana gelen sorunla ilgili kesin bilgiler içermelidir. Bunun gerçekleşmesi için, DevriX'te bizim tarafımızdan kullanılan şablonda olduğu gibi aşağıdaki öğelerin mevcut olması gerekir. Devrix'te, hata raporları için şablon bu öğelere dayanır. Karşılaşılan sorunlar hakkında yeterli bilgi sağladıkları kanıtlanmıştır.

• Başlık - Bu, sorunun ne olduğunun kısa bir özeti olarak hizmet etmelidir. Başlığın konunun doğası hakkında spesifik olması önemlidir. Bir geliştiricinin gördüğü ilk şey budur.
• Durum - Bu, hata raporunun hangi durumda olduğunun bir göstergesidir. Kullanılan yönetim yazılımına bağlı olarak (Jira, Asana, Trello, Mantis, vb.) Farklı heykel türleri olabilir. Bazı örnekler:
  • Görevlendirilecek - Rapordaki sorunları kimin araştıracağı henüz belirlenmediğinde.
  • Devam Ediyor - Bir geliştirici, bildirilen hatayı çözmeye çalışırken. Bu durum, şu anda test edilen bir güncelleme olduğunda da kullanılır.
  • Tamamlandı - Bildirilen hatanın çözüldüğüne dair bir işaret.
• Öncelik - Bu, bildirilen bir hatanın diğer görevler ve sorunlarla karşılaştırıldığında aciliyetini gösterir. Bir hatanın önceliği, test edilen sistem üzerindeki etkisini ölçtüğü için hatanın ciddiyetine bağlıdır. En yaygın öncelikler şunlardır:
  • Kritik - Diğer tüm faaliyetlerin durması gereken ve tüm çabanın durumu çözmek için yoğunlaştığı sorunlar için kullanılır. Bunun nedeni, bu tür sorunların rapor edildikleri proje üzerinde büyük bir etkiye sahip olması ve işletme için kayıplara neden olabilmesidir.
  • Yüksek - Daha sonra değil, daha erken çözülmesi gereken sorunlar için kullanılır. Çok büyük bir etkiye sahip değiller, ancak herhangi bir kritik sorun yoksa, en kısa zamanda çözülmeleri gerekir.
  • Orta - Temel işlevler üzerinde önemli bir etkisi olmayan sorunlar için kullanılır. Çözülmesi iyi olur. Bu tür sorunların öncelikli olanlardan sonra düzeltilmesi gerekir.
  • Düşük - Bildirilen hata önemsiz olduğunda ve temel işlev üzerinde bir etkisi olmadığında kullanılır. Bir blog gönderisindeki dil bilgisi hatası veya bir düğmenin yanlış rengi olabilir.
• Önem - Rapor edilen hatanın test edilen sistem üzerindeki etki düzeyini göstermek için kullanılır. Bir hatanın ciddiyeti için en yaygın sınıflandırma şudur:
  • Kritik - Temel bir işlev çalışmıyor veya yazılımın tamamı çalışmıyor.
  • Büyük - Bir veya daha fazla temel işlev, hatadan etkilenir. Bu nedenle, test edilen yazılım istenen sonuçları vermiyor. Kritik öneme sahip hataların aksine, amaçlandığı gibi çalışan işlevler olacaktır.
  • Orta - Test edilen yazılımın temel işlevleri üzerinde hiçbir etkisi yoktur. Tutarsız davranışlara yol açan bir veya daha fazla bileşen etkilenir.
  • Küçük - Test edilen yazılım üzerindeki etki küçüktür.
  • Önemsiz - Bu önem derecesine sahip hatalar, yazılımın işlevselliğini etkilemez. Bunlar küçük görsel kusurlar, eksik çeviriler, çalışmayan bir onay mesajı vb. Olabilir.
• Hata Ayrıntıları - Ayrıntılar , bildirilen sorunla nerede karşılaşıldığı hakkında önemli bilgiler içerir. Aşağıdaki bilgiler dahil edilmelidir (farklı kuruluşlar farklı (hata) ayrıntılar gerektirse de):
  • Hatanın karşılaşıldığı tarayıcı (sürümü de dahil etmek en iyisidir)
  • İşletim Sistemi - Yalnızca Windows'ta görülen bir sorun olabilir. Buna Android, iOS ve PadOS gibi mobil işletim sistemleri de dahildir
  • Dal - Bu, yayınlanmamış güncellemeler içindir (bildirilen diğer hataları düzelten yeni özellikler veya güncellemeler). Şube, yalnızca bir özellikle ilgili belirli taahhütleri içerir. Bu, bir değişikliğin diğer insanların aynı projedeki çalışmalarına müdahale etmemesi için yapılır.
  • Sürüm - Test edilen yazılım bir masaüstü veya mobil uygulama ise. Hatanın bildirildiği sürümü dahil etmeniz önerilir.
• Hata Açıklaması - QA uzmanı, sorunu yeniden oluşturmak için gerekli adımlarla birlikte gözlemlenen sorunun doğru bir açıklamasını sağlamalıdır. Uzman ayrıca beklenen sonucun gerçekte ne olması gerektiğini de açıklamalıdır. Bunların tümü, geliştirme ekibinin sorunun ne olduğunu, yeniden üretmek için hangi eylemlerin yapılması gerektiğini ve doğru davranışın ne olması gerektiğini anlamasına yardımcı olmak için önemlidir.
• Ekler / Ekran Görüntüleri - Bir ek / ekran görüntüsü, uzmanın sorunun ne ve sıklıkla nerede olduğunu görmesini sağlar. Ayrıca, QA uzmanına sorunu tetiklemek için gerçekleştirilen adımları da sağlayabilir.
• Yorumlar - Yorumlar bölümü genellikle yeni bir hata raporu oluşturulduğunda kullanılmaz, ancak şuraya bir hata düzeltmesi gönderildiğinde geliştirici yorumlarına (ve sonraki yorumlara) dahil edilmesi gerekenler hakkında Test için QA ekibi. Geliştiriciler aşağıdaki öğeleri içermelidir:
  • Güncellemeyi içeren kaydetmeye bağlantı.
  • Güncellemenin ne yaptığını açıklayın.
  • Gerçekleştirilmesi gereken herhangi bir kurulum adımı varsa, bunları açıklamak önemlidir.
  • Güncellemeyi çalışırken gösteren tüm ekran görüntülerini / ekran videolarını ekleyin.
  • Güncellemeyi test ederken QA uzmanının dikkate alması gereken tüm notları ekleyin.

İlgili kaynaklar : Kalite güvence çalışması, her web sitesinde çalışmanın önemli bir parçasıdır. Bu nedenle, uzun ve ayrıntılı test aşamasından geçmek, hataları ve gerilemeleri düzeltmek ve lansman için platformu stabilize etmek, web sitesinin maliyetiyle ilgilidir.

Öneriler ve Yeni Özellikler için Görev Yazma

QA testleri çalıştırırken, deneyimli test uzmanları genellikle projede iyileştirmeler için fikirler üretir. Aynı şekilde, Proje Sahiplerinin ve Proje yöneticilerinin, geliştirme ekibiyle paylaşılması gereken müşteri isteklerini (özellikler, düzeltmeler, iyileştirmeler için) alması gerekir.

Hata Raporlarının aksine, Öneriler ve Yeni Özellik görevlerinin amacı, projeyi iyileştirme potansiyeline sahip müşteri isteklerini veya iyileştirme fikirlerini açıklamaktır (bir performans güncellemesinin uygulanması, kullanıcılarla daha iyi etkileşime izin verecek bir özellik eklenmesi gibi) , vb).

Her iki durumda da uygulanması gereken özellik hakkında net bir açıklama sağlamak önemlidir:

• Müşteri tarafından talep edilen Yeni Özellikler - Proje Sahibi / Proje Yöneticisinin müşterinin neye ihtiyacı olduğunu anlaması, sağlanan modelleri incelemesi ve ek ayrıntıları tartışması önemlidir. Müşterinin ne istediği belli olduktan sonra, geliştirme ekibine ne yapmaları gerektiğini açıklamak daha kolaydır.
• Öneriler - Bir bütün olarak proje ve önerilen özelliğin onu nasıl iyileştireceği hakkında net bir vizyona sahip olmak önemlidir. Bu şekilde fikri ve getireceği faydaları açıklamak daha kolay olacaktır.

İyi ve Kötü Hata Raporları: Örnekler

Sorumluluk Reddi : Aşağıdaki örnekler, yazarın katıldığı bir QA kurs projesinden alınmıştır. Amaç, raporlarda yapılan hataları ve bunların nasıl önlenebileceğini analiz etmektir.

Örnek 1 :

İşte iyi yazılmış bir hata raporu örneği. Yukarıda tartışılan tüm nitelikleri içerir.

Bununla birlikte, bununla ilgili bir sorun var - başlığı, bildirilen sorun hakkında doğru bir fikir sağlamıyor. Eksik ürün resmi, test edilen web mağazasının herhangi bir yerinde olabilir.

Daha iyi bir başlık, "Bu ürünü alan kişiler de satın aldılar" bölümündeki eksik ürün resimleri "dir. Bu şekilde geliştirme ekibi, başlığın kendisinden raporun ne hakkında olduğu konusunda bir fikir sahibi olur.

Örnek 2 :

Bu, genel olarak kötü yazılmış bir hata raporu örneğidir. Bu örnekle ilgili ana sorunlar şunlardır:

• Başlık, eksik fiyatın tam olarak nerede olduğu konusunda spesifik değil
• Açıklama, sorunun tam olarak nerede gözlemlendiğini belirtmez.
• Beklenen Sonuç aslında doğru davranışın ne olduğunu açıklamıyor.

Kötü yazılmış hata raporları, geliştirme ekibini sorunun ne olduğunu ve bildirilen sorunun nerede olduğunu bulmak için gereksiz zaman harcamaya zorlar. Ekip sık sık hatayı bildiren QA Uzmanından eksik ayrıntıları açıklamasını istemeye başvurmalıdır ...

Örnek 3 :

Bu, düzgün yazılmış bir hata raporu için iyi bir örnektir. Geliştirme ekibine sorunun nerede olduğu ve nasıl yeniden üretilebileceği konusunda net bir fikir verir.

Bu raporla ilgili küçük bir sorun, bildirilen sorunun aslında test sürecini durdurmaması, yani atanan önem derecesi ve önceliğin yanlış olmasıdır. QA uzmanı sorunu daha iyi araştırırsa, bir geçici çözümün var olduğunu fark ederdi.

Bu geçici çözüm, Hesap Kaydı işleminin tamamlanmasına izin verirdi. Bir sorunu bildirilmeden önce araştırmak büyük önem taşır, böylece önemli ayrıntılar hariç tutulmaz ve doğru önem derecesi ve öncelik atanabilir.

Sonuç olarak

QA'lar tarafından iyi yazılmış bir hata raporu, geliştirme ekibinin sorunun ne olduğunu ve nasıl çözülmesi gerektiğini anlaması için çok önemlidir. Bunun olması için daima aşağıdakileri unutmayın:

• Hata raporu başlığı, bildirilen sorunu özetlemelidir.
• Doğru ayrıntılar sağlayın - sorunun gözlemlendiği platform, tarayıcı (web uygulamaları için), sorunun gözlemlendiği şube.
• Bildirilen sorunun ne olduğuna dair net bir açıklama sağlayın.
• Çoğaltma adımlarının doğru olduğundan emin olun.
• Rapor yaratılırken gerçekte gözlemlenenin aksine, beklenen davranışın ne olması gerektiğini yazın.
• Uygun görev önceliğini ve önem derecesini atamayı unutmayın.
• İlgili tüm dosyaları ekleyin - ekran görüntüleri, ekran kayıtları, günlükler vb.
• Geliştirme ekibinin sorunu çözmesine yardımcı olabilecek tüm ek bilgileri ekleyin.