Bazen KG ekibim hataları bildiriyor, ancak ne ben ne de onların nasıl çoğaltılacağı konusunda hiçbir fikrim yok. Bu, bazen sonuç bile vermeyen çok uzun ve sinir bozucu hata ayıklama oturumlarına yol açar.

Yazılımım, özel donanımlarla yoğun bir şekilde bağlanmıştır, böylece hatalar aynı anda birçok yönden gelebilir.

Onlardan "bir düğmeye bastığımda yazılımınız çöktü" den daha fazlasını mı beklemeliyim yoksa kendime ne olduğunu anlayabilmeli miyim?

DÜZENLE:

İş arkadaşımdan biri muhtemelen burada tüm geliştiriciler olduğumuza dikkat çekti, bu yüzden sonuçlar biraz önyargılı olabilir

KG her zaman mümkün olduğunca çoğaltmanız için hataları kolaylaştırmaya çalışmalı ve hata açıklaması atılan adımları içermelidir.

Ancak, hataları kolayca yeniden üretemezlerse, hata veritabanına uygun başlık / başlıklar ve hataya neden olmak için yaptıklarının tam bir açıklaması ile girilmeleri gerekir. Hata açıklaması, hatayı yeniden üretemeyeceğini açıkça belirtmelidir (belki de "beş kez denedi, bir kez oldu" satırları boyunca bazı yorumlarla). Bu şekilde, başka biri aynı hatayı görürse, bulguları ile hata veritabanına ekleyebilir ve aynı zamanda mümkün olduğunca fazla bilgi alırsınız, bu da hattı takip ederek zamandan tasarruf etmenizi sağlamak için hayati öneme sahip olabilir.

Ayrıca, bilgileri filtrelersiniz - farklı sistemlerde kodun bir alanına (ör.) Bağlı olduğunu bildiğiniz birçok hata olabilir - KG hiçbir şey raporlamazsa (bunları çoğaltamayacakları için) ) bu bilgi size ulaşmaz.

KG departmanınız çok fazla keşif testi yapıyor gibi görünüyor (yani iyi bir test planı yok).

Keşif testi iyidir ve sorunlu alanları belirler, ancak oradan belirli hataları ortaya çıkaracak tekrarlanabilir test senaryolarını (yani bir test planı) tanımlamaları gerekir.

Doğru bir repro'nun gerekli olmasının birkaç nedeni vardır (sadece iyi değil, aynı zamanda gerekli):

1. Nedenini ayıklamak / izlemek için çoğaltmanız gerekir.
2. QA, işlemi tamamladıktan sonra düzeltmeyi doğrulayabilmelidir.
3. Daha fazla test geçişinin önceki hatalarda gerileme yapması gerekecektir.
4. Pozlama çok küçükse veya repro olasılığı düşükse, bilinen hatalar atılabilir.

Yani, SteveCzetty'nin belirttiği gibi: Hiçbir repro olarak kapatın ve işe geri dönün.

Hata tutarlı bir şekilde çoğaltılamazsa KG, sorunun düzeltilip düzeltilmediğini nasıl bilecek?

Evet, onlardan daha fazlasını beklemelisiniz. Şunu söyleyebilmeliler:

1. Yeni program örneği başlatıldı
2. A düğmesine bastım
3. Form 1'deki TEST ADI alanına "test metni" girildi
4. B düğmesine basın
5. Programın bu mesajla çöktüğünü gözlemledi (ekteki ekran görüntüsüne bakın).

Eğer söyledikleri tek şey "çöktü" ise çok iyi değiller. Yukarıdaki adımlar% 100 tekrarlanamaz olsa bile, bu çökmelerden yeterince büyük bir örnek, bir desen algılandıktan sonra nedeni daraltmaya yardımcı olabilir.

Benim tavsiyem bu hataları okumak ve onlara eski güzel bir fikir vermek. Potansiyel bir neden bulamıyorsanız, şimdilik unutun.

KG, nasıl olduğunu bilmiyor olsalar bile buldukları her sorunu belgelemelidir. Sorunları yeniden üretmeye çalışmak QA'nın işi, ancak gerçekçi olarak bu her zaman mümkün olmayacak. Bazen son 10 dakikada yaptıklarıyla hiçbir ilgisi yoktur. Bir gün önce bir şey geçersiz bir duruma geldi ve son 10 adımdan biri nedeniyle ortaya çıktı.

Bu "1000'de 1" hata ile KG bunları biraz çoğaltmaya çalışmalıdır. Eğer başarıları yoksa, hatayı belgelemeli, sonra biraz daha denemeliler.

Hatanın oldukça erken girmesinin nedeni, programcının kodu KG'den çok daha iyi bilmesi ve sorunu hemen bilmesi olabilir. Yeniden düzenledikleri kod olabilir. Yarısı uyguladıkları ve sonra unuttukları işlev olabilir. Hiçbir fikirleri olmayabilir, ancak test cihazında, kodlayan kişi için açık olan bir sorunu yeniden üretmeye çalışmak için birkaç saat harcamak mantıklı değildir. Test cihazı daha sonra hataya her zaman daha fazla ayrıntı ekleyebilir.

Hata, mümkün olduğunca fazla bilgi içermelidir. Test cihazının konuyla ilgili liderlik hakkında ne hatırlayabileceği her ne kadar acı verici bir şekilde yazılmalıdır. Ayrıca Crash günlükleri, veritabanı anlık görüntüleri veya ilgili ekran görüntüleri de eklenmelidir.

Hata asla çoğaltılmazsa, harika! Veritabanında olması acı vermez. Program yayınlanırsa ve bir kullanıcı daha sonra benzer bir hata rapor ederse, deneyimlerini rapordakilerle karşılaştırabilir ve benzerlikler arayabilirsiniz.

Deneyimlerime göre, en sulu hatalar aşağıdaki test planlarından bulunamıyor. Bazen ay ve yıldızların kötü bir hataya neden olması için birkaç hafta boyunca güveç etmesine izin vermelisiniz. KG bazı dedektiflik çalışmaları yapabilir ve bazı olası nedenler bulabilirse, onlara arkalarında bir pat verin. Ama bazen, ne olduğunu kim bilebilir?

Bir çok hata, bunları nasıl düzeltebileceğinizi bilinceye kadar çoğaltılamaz. Bu, düzeltilmeleri gerekmediği anlamına gelmez. Geçen yıl hala nasıl çoğaltılacağını bilmediğim bir hatayı düzelttim . Yığın üzerinde belirli bir bellek konumundaki çok özel çöp verileriyle birlikte kesin olarak zamanlanmış bir iletim hatasının bazı tuhaf kombinasyonlarını gerektirir. Ne yazık ki, müşterilerimizden biri bu duruma girmek için yeterince "şanslı".

Bu nedenle, KG'yi mümkün olduğunca tekrarlanabilirlik adımlarını dahil etmeye teşvik edin, ancak yapamazlarsa hata yapmayın. Bazen nereye günlük ekleyeceğinizi bilmenize yardımcı olur. Bazen tek yaptığı, hataya neyin neden olmadığını söylemek , ancak bir hata raporu her zaman yararlıdır.

KG, hatayı yapabildikleri takdirde yeniden oluşturma adımlarını içermelidirse, cevap evettir. Eğer sadece üreyebildikleri böcekleri kaydetmeleri gerekiyorsa, kesinlikle değil. Böcekler, sadece dolunayın gece yarısında veya her baktığınızda meydana gelen hatalardır. Bazı hatalar deterministik değildir (klasik örnek, alınan değerin yarı rastgele olduğu, başlatılmamış bir değişkendir), bu, kaydedilmemeleri, araştırılmaları ve mümkünse düzeltilmeleri gerektiği anlamına gelmez.

Tekrar üretilemeyen hatalar genellikle düşük önceliğe sahip olmalıdır, ancak kesinlikle kaydedilmelidir.

IMO, yapmalısın. KG size herhangi bir çoğaltma adımı alamazsa işini yapmıyor. Yapamayacağınız bir şeyi yeniden üretmek için zamanınızı boşa harcamayın, sadece "Yeniden üretilemiyor" olarak kapatın ve devam edin.

Zamanınız bundan çok daha değerlidir.

Bir hata raporu şunları içermelidir:

• Yeniden oluşturma adımları
• Gerçek davranış
• Beklenen davranış

Örneğin:

• Tüm tedarikçileri veritabanından sildim (kullanarak DELETE * FROM tSuppliers), tedarikçi iletişim kutusunu açtım ve Tedarikçi açılır listesine tıkladım.
• Liste şu mesajı içeriyordu: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Mesajı tıkladığımda, uygulama ekrandan ve Görev Yöneticisi'nden kayboldu.
• Boş bir liste veya (tercihen) "Tedarikçi bulunamadı" gibi bir mesaj görmeyi bekledim. Boş listeye veya mesaja tıklamanın bir etkisi olmamalıdır. Uygulama hiçbir koşulda uyarı vermeden kaybolmamalıdır.

Yani, evet - çoğaltma adımlarını içermelidir. Bunu dahil etme gereğini hissetmedikleri gerçeği, işlerinin hataları tanımlamaktan ziyade "yazılımı kırmak" olduğunu düşündüklerini göstermektedir.

KG, girilen adımlara göre hataları yeniden üretebilmelidir. Eğer çok çalıştılarsa, yine de çoğaltamazlarsa, geliştiricilerin uygulamaya bir göz atabilmeleri ve daha fazla ayrıntı için günlükleri hata ayıklayabilmeleri için zaman damgasıyla ilgili ayrıntılarla hatalarını girmeye devam etmelidirler.

Burada para tehlikede. Neden herhangi bir ekip üyesi (umarım) yüksek ücretli bir geliştiriciye yüklenen kötü tanımlanmış, düşük başarı şansı görevi yaratabilmeli?

Bu düzene, hiyerarşiye, kibire, bizlere karşı onları ya da bunun gibi şeyleri gagalamakla ilgili değil. Bu sadece ürüne değer katan faaliyetlere yatırım yapmakla ilgilidir.

Bir sorunun ürünün değerini olumsuz ve ölçülebilir şekilde etkilediği gösterilebiliyorsa, araştırılmalı, yeniden üretilmeli ve düzeltilmelidir. Gürültüyü filtrelemek için ürün kusur boru hattınızı düzeltin.

KG ekibiniz berbat

Onlara gidin ve herhangi bir profesyonel test cihazının beyninin içine yazdırması gereken bir belgeyi okumalarını söyleyin (bir kez test edildim ve hala orada, beynimde var): Hatalar Nasıl Bildirilir .

Özellikle, onları "Kendimi nasıl göstereceğimi göster" bölümüne yönlendirin :

İnternetin çağı bu. Bu dünya çapında iletişim çağıdır. Bu, bir düğmeye dokunarak yazılımımı Rusya'daki birisine gönderebileceğim bir dönem ve bana bu kadar kolay yorum gönderebilir. Ama programımla ilgili bir sorunu varsa, başarısız olduğunda beni onun önünde durduramaz. "Göster bana" yapabildiğiniz zaman iyidir, ama genellikle yapamazsınız.

Şahsen bulunamayan bir programcıya bir hata bildirmeniz gerekiyorsa, egzersizin amacı sorunu yeniden üretmelerini sağlamaktır . Programcının programın kendi kopyasını çalıştırmasını, aynı şeyleri yapmasını ve aynı şekilde başarısız olmasını istiyorsunuz. Sorunun gözlerinin önünde olduğunu gördüklerinde, bununla başa çıkabilirler ...

Eğer "böcekler aynı anda birçok yönden gelebilir" diye şikayet etmeye başlarlarsa , onlara daha önce düşündüğünüzden daha fazla emdiklerini söyleyin. Onlara, Test Edilebilirlik'in diğer proje özellikleri arasında değerlendirmeleri gereken bir özellik olduğunu ve bu özelliği doğru hale getirmek için çaba göstermeleri gerektiğini söyleyin .

• Profesyonel bir test cihazı olduğunda sihir gibi olabilen test edilebilirlik iyileştirmeleri. Bunu kendim birkaç ay önce öğrendim. Ekibimizle çalışan KG mühendisi , uygulamamızdaki bazı bileşenler için geliştirmem gereken bir avuç test edilebilirlik talebi verdi . Hakkında sorduğu şeyler bana çok az mantıklı geldi ama ben sadece profesyonel olarak daha iyi bildiğini varsayarak ona verdim. Bitirdikten kısa bir süre sonra, test çabalarını büyüklük sırasına göre azaltan bir araç buldu . Çoğunun uyguladığım bu şifreli taleplere dayandığını söyledi.