Menü

Hata Bildirme Sanatı: Hatalarınızı Nasıl Pazarlayabilir ve Düzeltebilirsiniz?

  • Ana
  • Hata Kusur Takibi
  • Hata Bildirme Sanatı: Hatalarınızı Nasıl Pazarlayabilir ve Düzeltebilirsiniz?

art bug reporting

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Neden Bir Bug Pazarlamaya İhtiyaç Var?

Bu makaleyi yazmaya başladığımda aklıma gelen ilk şeyler şu sözler. Cem Kaner - 'En iyi test kullanıcısı, en çok hatayı bulan veya çoğu programcıyı utandıran kişi değildir. En iyi test kullanıcısı, çoğu hatayı düzeltendir. '

Şimdi - arasındaki fark nedir çoğu hatayı bulmak ve çoğu hatanın düzeltilmesi ?

Herhangi bir hatanın giriş yaptığı açık değil mi? hata yönetim sistemi geliştirici tarafından düzeltilmelidir? Cevap Hayır. Ürünü pazarlama süresi, projeyi zamanında tamamlama süresi ve üzerinde çalışan geliştiriciler gibi faktörler pratik olmayan sıkı programlar vb. şirketleri, kullanıcıları büyük ölçüde etkilemeyecek birkaç hata ile piyasaya sürmeye zorlar.

Hata raporlama sanatı

(resim kaynak )

Üründe bulunan hataların müşterinin güvenini, güvenilirliğini ve paydaşların çıkarlarını etkilemeyeceğini söyleyen yönetime kim güven veriyor? - Test Mühendisi veya Test ekibi - ürün kalitesi üzerinde olumsuz etkisi olabilecek hataları düzeltmek her test mühendisinin görevidir.

Hatanın önceliği bence, büyük ölçüde bir sorunun test uzmanı tarafından geliştirme ve yönetim ekiplerine nasıl sunulduğuna bağlı.

Sorunun reklamını yapmak veya pazarlamak gibi düşünün - bu 2 adımdan oluşur:

  1. Yaz ya da hataları doğru şekilde rapor et
  2. Hatayla ilgili her şeyi öğrenin, böylece daha fazla ayrıntı daha iyi açıklanabilir

Ne öğreneceksin:

Hata Bildirme Sanatı

Evet, hata bildirme bir sanattır . Bir hatanın yazılma şekli, bir test mühendisinin teknik becerisini, alan uzmanlığını ve iletişim yeteneklerini gösterir.

Tipik olarak, bir hata aşağıdaki bilgileri içermelidir:

  • Hata Özeti
  • Yeniden üretme adımları
  • Ekler (Enstantane, Günlük dosyaları vb.)
  • Hata tekrarlanabilirliği
  • Hata Şiddeti
  • Yazılım Sürümü, Ortam Bilgileri
  • Organizasyonel gereksinimlere dayalı diğer bilgiler.

Önemli bir not: Sorunun temel nedenini bulmak ve rapor etmek için her zaman daha derine inin. Örneğin, doğru kullanıcı adı ve şifre kombinasyonuna sahip basit bir giriş hatası, aşağıdakiler gibi çeşitli nedenlerle ilgili olabilir:

  1. Giriş kimlik bilgileri hiç doğrulanmadı
  2. Uzaktan oturum açma durumunda ağ zaman aşımı sorunları
  3. Sistem tüm CAPS'leri CAPS olmayan olarak kabul edebilir.

Bu nedenle, bir Test Kullanıcısı olarak, hata özeti ifadelerini takip ederken farklılıkları deşifre edebilmelisiniz:

  • 'Doğru kullanıcı adı ve şifre ile giriş yapılamıyor'
  • 'Kullanıcı adı veya şifre CAPS ve CAPS olmayan alfabelerin bir karışımını içerdiğinde doğru kullanıcı adı ve şifreyle oturum açılamıyor.'

İkincisi, sorunun çok net bir açıklamasıdır ve belirsizdir. Bununla, yalnızca bir testçi olarak güvenilirliğinizi artırmakla kalmaz, aynı zamanda bir belirti yerine gerçek sorunu da bildirirsiniz.

Şimdi, bir hata raporunda yer alan her alana bir göz atalım ve her birinin önemli yönlerini tartışalım:

# 1. Hata Özeti

Bir hata özeti, sorunun tam olarak ne olduğuna dair hızlı bir anlık görüntü sağlamalıdır. Kesin ve iyi yönlendirilmiş olmalıdır.

Misal :

Teorinin dışında örneklerle açıklamaya çalışacağım.

Basit bir giriş modülünü varsayalım. Bir web sitesini ziyaret eden yeni bir kullanıcının varsayılan şifresiyle giriş yapamaması olarak sorunu varsayalım. Eğitimin ilk aşamasında eğittiğim birçok öğrenciye aynı senaryoyu sunduğumda, hata özeti olarak birkaç cevap vardı. Aşağıda, özetin nasıl göründüğüne dair birkaç örnek verilmiştir:

Windows'ta .mkv dosyaları nasıl oynatılır

' Yeni kullanıcı giriş yapamıyor ”

'Kullanıcı girişi beklendiği gibi çalışmıyor'

'Kullanıcı doğru şifre ile giriş yapamıyor'

hata özeti yanlış ve doğru

Yukarıdaki örneklerden sorunu gerçekten tanımlayan bir ifade seçebilir misiniz? Ben öyle düşünmüyorum. Özet, her zaman başarısız senaryo hakkında eksiksiz bilgi vermelidir.

Şu ifadeyi düşünün:

'Yeni kullanıcı, e-posta veya SMS yoluyla sağlanan varsayılan şifre ile oturum açamıyor'

Gördüğünüz gibi, yukarıdaki ifadeden bir geliştirici sorunun ne olduğunu ve sorunun nerede olduğunu açıkça anlayabilir.

Bu nedenle, bilgiyi doğrudan verecek olan özeti tanımlamak için doğru kelimeleri bulmaya çalışın. 'Düzgün çalışmıyor', 'beklendiği gibi çalışmıyor' gibi genel ifadelerden kaçınılmalıdır.

# 2. Yeniden Oluşturma Adımları ve Ekler

Tekrarlanamayan böcekler, önemli olsalar bile her zaman arka planda kalırlar. Bu nedenle, adımları doğru ve açıklayıcı bir şekilde yazmaya özen gösterin.

Adımlar doğru olmalı ve soruna yol açanlarla tam olarak aynı olmalıdır. İşlevsellikle ilgili hatalar için aşağıdaki örnek en iyi örnektir.

Misal :

Önceki bölümde belirtilen aynı konuyu düşünün.

  1. Ana sayfadaki Kaydol seçeneğini kullanarak yeni bir kullanıcı oluşturun. (Örnek Kullanıcı Adı: HelloUser)
  2. Varsayılan şifre ile bir e-posta ve bir SMS alınacaktır. Adım # 1'de kullanıcı oluşturulurken SMS için e-posta kimliği ve cep telefonu numarası verilir. (Örnek e-posta: HelloUser@hello.com Örnek Cep Telefonu Numarası: 444-222-1123)
  3. Ana sayfada Oturum Aç seçeneğini seçin.
  4. Kullanıcı adı metin alanına 1. Adımda sağlanan Örnek Kullanıcı Adını girin.
  5. Parola alanına, bir e-posta veya SMS yoluyla alınan varsayılan parolayı girin.
  6. Oturum Aç düğmesine tıklayın
  7. Beklenen Sonuç: Kullanıcı, sağlanan kullanıcı adı ve şifre ile giriş yapabilmeli ve Kullanıcı Hesabı Sayfasına gidebilmelidir.
  8. Gerçek sonuç: 'Geçersiz Kullanıcı Adı / Parola' mesajı görüntüleniyor.

kusur raporu adımları

Yukarıdaki örnekte herhangi bir bilgi verilmemişse, o zaman iletişim boşluklarına neden olmak ve geliştirici sorunu yeniden oluşturamaz. Adımlar, test sırasında kullandığınız örnek verilerle spesifik ve ayrıntılı olmalıdır.

Mümkünse veya uygun olan yerlerde, bir enstantane fotoğraf ekranda tam olarak gördüğünüz şey. Bu şekilde, yalnızca geliştiricilere sorunun iyi bir görünümünü sağlamakla kalmayacak, aynı zamanda test sonucunuzun bir kanıtı olacaktır.

işlevsel olmayan Stres, stabilite veya performans testi senaryoları gibi test durumları yukarıdaki detaylara ek olarak sisteme stres oluşturan senaryo hakkında bilgiler olduğu gibi raporlanabilmektedir. Ek olarak, gerçekleştirilen her işlem için günlükleri raporlayan birkaç sistem vardır. Günlükler, genellikle geliştiriciler tarafından kodlarında sağlanan yazdırma ifadeleridir. Bir modül yürütüldüğünde, ilgili günlükler yazdırılacak veya görüntülenecektir. Günlükler mevcut olduğunda, bu, geliştiricilere sorunu yeniden oluşturmada büyük ölçüde yardımcı olur.

# 3. Hata Tekrarlanabilirliği

Büyük veya küçük bir konu, tekrarlanabilirliğe göre önceliklendirilecektir. Her zaman, bazen, nadiren ve hatta sadece bir kez görülebilir. 'Her zaman' olarak yeniden üretilen bir sorun, diğerlerinden daha yüksek önceliklendirilecektir.

bir kusuru yeniden üretemez

Bu nedenle, her zaman yeniden üretilen sorun için senaryoyu tam olarak izlemek bir test mühendisinin görevidir. Bazen, bir test mühendisinin kontrolü dışında, bir sorunun yalnızca birkaç kez, ancak birden fazla denemeyle yeniden üretilmesine neden olabilecek birkaç sorun olabilir. Bu tür durumlarda, her zaman deneme sayısını belirtin, belirli bir senaryo, sorunun bu denemeler sırasında görülme sayısı ile birlikte yürütülür.

Bu da sizin belirttiğiniz hata raporuna güvenilirlik katacaktır. Yine, bu bir testçi olarak itibarınızı artıracaktır. Daha sonra size iyi bir itibara sahip olmanın nedenlerini anlatacağım.

# 4. Hata Şiddeti

Önem derecesi, hiç şüphesiz Böceği önceliklendirmek için en büyük etkileyicilerden biridir.

Aşağıdakiler farklı ciddiyet kategorileridir. Lütfen bunların genel örnekler olduğunu ve firmadan firmaya değiştiğini unutmayın.

  1. Önem Derecesi 1 - Durdurucuyu Göster - yıkıcı hatalar için, düzeltilmeden kullanıcı yazılımı kullanmaya devam edemez ve olası bir çözüm yoktur
  2. Önem Derecesi 2 - Yüksek - Önem Düzeyi 1'e benzer hatalar için, ancak bunun bir geçici çözümü var
  3. Önem Derecesi 3 - Orta
  4. Önem Derecesi 4 - Düşük
  5. Önem Derecesi 5 - Önemsiz.

Örneğin, iki benzer sorunu karşılaştıralım.

Alıcı kutularımızda, birkaç servis sağlayıcı, şu anda ayarlanmış olan hizmetin frekans bilgilerini sağlar. Frekansın 100.20 MHz yerine 100 MHz olarak görüntülendiğini varsayalım. Bu, kullanıcının hizmetleri görmesini etkilemeyebilir, ancak set üstü cihazların teşhisini izleme açısından etkileyebilir. Dolayısıyla bu, Önem Derecesi 3 sorunu olarak sunulabilir.

Bankacılık alanında benzer bir sorun olduğunu varsayarsak: Hesap bakiyeniz 100,20 ABD doları yerine 100 ABD doları olarak görüntüleniyorsa, sorunun etkisini bir düşünün. Bu Önem Derecesi -1 hatası olmalıdır. Her iki durumda da görebileceğiniz gibi, kullanıcı arayüzünün ondalık noktadan sonraki rakamları göstermemesi sorunu çok benzer. Ancak etki, ilgili alana göre değişir.

Yazılım Sürümü Kontrol Toplantılarına etkin katılım

Genellikle, her kuruluşun hataları araştırmak ve önceliklendirmek için kendi süreci vardır. Genel olarak, proje sırasında belirli aralıklarla hataları tartışmak ve önceliklendirmek için bir toplantı yapılır.

Bu tür toplantılar sırasındaki süreç şu şekildedir:

  1. Hata yönetim sistemindeki hataların listesini önem derecesine göre sorgulayın.
  2. Özete bakın ve hatanın kullanıcının bir yazılım ürününü kullanma deneyimi üzerindeki etkisini tartışın.
  3. Risk ve etki değerlendirmesine göre önceliği belirleyin ve hatayı düzeltmek için uygun bir geliştiriciye atayın.

2. adımda, her test mühendisinin hatanın hak ettiği önceliği almaması durumunda hatanın kullanıcı deneyimi üzerindeki etkisini savunması zorunludur. Sonuçta, test senaryoları yazmak ve ürünü test etmek için bir kullanıcının bakış açısını dikkate alan test mühendisleriyiz.

Bir bankacılık alanında ondalık noktadan sonraki rakamları göstermeme örneğini ele alalım. Bir geliştiriciye göre daha az ciddi bir sorun gibi görünebilir. Değişkeni bir tamsayı olarak bildirmek yerine, bunu sorunu çözmek için bir kayan nokta ve dolayısıyla daha az şiddetli olarak ilan edeceğini iddia edebilir.

Ancak bir test uzmanı olarak rolünüz, müşterinin durumunu açıklamaktır. Sizin görüşünüz, kullanıcının bu senaryoda nasıl şikayet edeceği olmalıdır. Test eden kişi, müşterinin parasını kuruş olarak kaybetmesinin kullanıcılar arasında paniğe neden olacağını söylemelidir.

Bir hatayı doğru şekilde pazarlamamanın etkisi

Bir hata doğru şekilde pazarlanmazsa aşağıdaki gibi sorunlar yaratacaktır:

  • Yanlış kusur önceliği
  • Önemli sorunları çözmede gecikme
  • Ciddi kusurlu ürün çıkışı
  • Olumsuz müşteri geri bildirimi
  • Marka değerini düşürmek

Bir hatayı doğru şekilde pazarlamamanın etkisi

Yukarıda belirtilen tüm nedenlerin dışında, test mühendisi olarak itibar . Daha çok kendi kendinize bir marka değeri geliştirmeye benziyor.

Kariyerinizin ilk aşamasında, 'Yeniden Üretilemez' veya 'Daha Fazla Bilgiye İhtiyacınız Var' veya 'Geçerli Bir Hata Değil' sayınızı veya ciddiyetteki değişiklikleri olabildiğince düşük tutabilirseniz, bir aşamada hatalarınız incelenmeyecektir. tamamen ve düzeltilmesi için uygun geliştiriciye doğrudan atanırlar.

Böyle bir marka değeri geliştirmek ve ekibinizin ve geliştirme / veya yönetim ekiplerinin güvenini kazanmak için, test etme bilgisi, etki alanı ve iletişim becerileri açısından bazı teknik beceriler geliştirmelisiniz.

Sonuç

Büyük veya küçük herhangi bir ürün veya hizmet, uygun reklam olmadan her zaman başarısız olmaya mahkumdur. Bir marka kurulduktan sonra, herhangi bir küçük ürün, izleyiciler arasında süper bir hit olabilir.

Bunu söyledikten sonra, bir ürünün aşırı reklamı da itibarın zedelenmesine neden olabilir.

Bu nedenle, kapsamlı / ayrıntılı yazılım haritasında hatanın tam yerini vermesi için bir hata her zaman açık, kısa ve kesin bir şekilde yazılmalıdır. Bunun sadece yazılım kalitesini artırmakla kalmayıp aynı zamanda yazılımı test etme ve geliştirme maliyetini de büyük ölçüde düşürdüğünü yineliyorum.

Artık çok geç değil! Devam edelim ve hataları hemen düzeltelim!

Java'da başka bir yöntemden bir dizi nasıl çağırılır

Önerilen Kaynaklar

^