Yazılım Testinde Hata Yönetimi Süreci
Thomas Hamilton
⚡ Akıllı Özet
Yazılım testinde hata yönetimi süreci, hataların tanımlanması, sınıflandırılması, çözülmesi, doğrulanması, kapatılması ve raporlanması için yapılandırılmış bir çerçevedir. Test uzmanları ve geliştiriciler arasında öngörülebilir iletişimi sağlar, sürüm kalitesini artırır ve proje yaşam döngüsü boyunca üretim seviyesindeki hataları azaltır.
Kusur Yönetim Süreci Nedir?
MKS Kusur Yönetim Süreci Yazılım testinde, yazılım piyasaya sürülmeden önce hataları belirlemek, sınıflandırmak, düzeltmek ve doğrulamak için kullanılan sistematik bir yaklaşımdır. Yaşam döngüsü altı temel aşamayı içerir: 1) Hatanın keşfi, 2) Kategorilendirme, 3) Geliştiriciler tarafından çözüm, 4) Test uzmanları tarafından doğrulama, 5) Kapanış ve 6) Projenin sonunda hata raporlaması.
Bu makale, Hata Yönetimi Sürecinin nasıl uygulanacağını açıklamaktadır. Guru99 Bank web sitesi örneği, böylece yeni başlayanlar ve orta düzey test uzmanları her adımı gerçek bir proje bağlamında anlayabilirler.
Neden Kusur Yönetim Sürecine ihtiyacınız var?
Diyelim ki ekibiniz test sırasında birkaç hata buldu. Guru99 Bankacılık projesi. Yapılandırılmış bir süreç olmadan, test uzmanları ve geliştiriciler arasındaki iletişim sözlü olarak veya dağınık mesajlar aracılığıyla gerçekleşir.
Bir hafta sonra, geliştirici konuya ilişkin farklı bir anlayışla yanıt veriyor.
Ertesi hafta, test görevlisi tekrar yanıt vererek daha da fazla kafa karışıklığına yol açıyor.
Hata bildirimleri sözlü veya gayri resmi olarak yapıldığında, işler çok hızlı bir şekilde karmaşık hale gelir. Hataları kontrol etmek ve etkili bir şekilde yönetmek için, ekiplerin raporlama şeklini standartlaştıran tanımlanmış bir hata yaşam döngüsüne ihtiyacınız vardır. track ve sorunları kapatmak.
Adım 1) Keşif
içinde Keşif Bu aşamada, proje ekibi son müşteriyle karşılaşmadan önce mümkün olduğunca çok hatayı tespit etmelidir. Bir hata, geliştirme ekibi tarafından kabul edilip onaylandığında "keşfedilmiş" olarak kabul edilir ve bu noktada durumu değişir. Kabul edilen.
Örnek senaryoda, test uzmanları sistemde 84 hata tespit etti. Guru99 Bank web sitesi.
Ancak test uzmanları ve geliştiriciler her zaman aynı fikirde olmuyor. Aşağıdaki örneğe bakalım; test ekibi şu konularda sorunlar tespit ediyor: Guru99 Bank'ın internet sitesinde bu durumlar raporlanıyor, ancak geliştirme ekibi bunların kusur olup olmadığı konusunda itirazda bulunuyor:
Böyle bir durumda, Test Yöneticisi olarak ne yapmalısınız?
A) Test ekibiyle bunun bir hata olduğu konusunda hemfikirim.
B) Hakim rolünü üstlenin ve sorunun bir kusur olup olmadığına karar verin.
C) Geliştirme ekibiyle bunun bir hata olmadığı konusunda hemfikirim.
Doğru yaklaşım B seçeneğidir. Çatışmayı çözmek için bir çözüm süreci uygulanmalı ve Test Yöneticisi, sorunun bir hata olarak nitelendirilip nitelendirilmediğine karar vermeden önce konuyu tarafsız bir şekilde değerlendirmelidir.
Adım 2) Sınıflandırma
Hata sınıflandırması, geliştiricilerin işlerini önceliklendirmelerine ve en kritik iş sorunlarının önce çözülmesine yardımcı olur. Sınıflandırma genellikle Test Yöneticisi tarafından yapılır ve ciddiyet ve iş etkisi esasına dayanır.
Arızalar genellikle dört öncelik seviyesine göre gruplandırılır: Kritik, Yüksek, Orta ve DüşükLütfen aşağıdaki hataların her birine doğru önceliği atamayı deneyin:
- Web sitesinin performansı çok yavaş.
- Web sitesinin giriş yapma işlevi düzgün çalışmıyor.
- Web sitesinin grafik kullanıcı arayüzü (GUI) doğru şekilde görüntülenmiyor. hareketli cihazlar.
- Web sitesi kullanıcının oturum açma işlemini hatırlayamıyor.
- Bazı bağlantılar çalışmıyor.
İşte önerilen yanıtlar:
| Hayır. | Açıklama | Öncelik | açıklama |
|---|---|---|---|
| 1 | Web sitesi performansı çok yavaş | Yüksek | Performans sorunları son kullanıcılara büyük rahatsızlık vermektedir. |
| 2 | Giriş yapma işlevi düzgün çalışmıyor. | Kritik | Giriş işlemi, bir bankacılık web sitesinin temel işlevidir. Giriş işlemi başarısız olursa, tüm kullanıcı deneyimi engellenir. |
| 3 | Kullanıcı arayüzü mobil cihazlarda doğru şekilde görüntülenmiyor. | Orta | Bu hata, internet sitesini akıllı telefonlarından görüntüleyen kullanıcıları etkiliyor. |
| 4 | Web sitesi kullanıcının oturum açma işlemini hatırlayamıyor. | Yüksek | Kullanıcılar giriş yapabilirler ancak başka herhangi bir işlem gerçekleştiremezler. |
| 5 | Bazı bağlantılar çalışmıyor | Düşük | Geliştiriciler için kolay bir çözüm ve kullanıcılar sitenin geri kalanına erişmeye devam edebilirler. |
Adım 3) Kusur Çözümü
Kusur Çözümü Yazılım testinde, hataların giderilmesi adım adım ilerleyen bir süreçtir. Çözüm süreci, hataların geliştiricilere atanmasıyla başlar; geliştiriciler daha sonra önceliğe göre düzeltmeleri planlar, düzeltmeleri uygular ve son olarak Test Yöneticisine bir çözüm raporu gönderir. Bu sıra, hataların giderilmesini sağlar. tracKral şeffaf ve hesap verebilir.
Bir hatayı düzeltmek için şu adımları izleyebilirsiniz:
- Görev: Hata bir geliştiriciye veya teknisyene atanır ve durumu değişir. tepki vermek.
- Zamanlama düzeltmesi: Geliştirme ekibi devreye girer ve hata önceliğine göre bir düzeltme programı oluşturur.
- Hatayı düzeltin: Geliştiriciler hataları düzeltirken, Test Yöneticisi devreye girer. tracks'nin planlanan programa göre ilerlemesi.
- Kararı bildirin: Geliştiriciler, hangi hataların giderildiğini ve nasıl giderildiğini doğrulayan bir rapor gönderirler.
Adım 4) Doğrulama
Geliştirme ekibinin ardından sabit hem de rapor kusurlar, test ekibi doğrular Sorunların çözüldüğü bildirildi.
Örneğin, geliştirme ekibi 61 hatanın giderildiğini bildirdiğinde, test ekibi düzeltmelerin orijinal hataya neden olan aynı koşullar altında doğru çalışıp çalışmadığını doğrulamak için her birini yeniden test eder.
Adım 5) Kapatma
Bir hata giderilip doğrulandıktan sonra, durumu değiştirilir. KapalıDoğrulama sırasında hata düzgün bir şekilde giderilmezse, yeniden incelenmesi için geliştirme ekibine bir bildirim göndermeniz gerekir. Kapatma, hatanın sistemde artık aktif olmadığını gösterir.
Adım 6) Kusur Raporlaması
Kusur Raporlaması Yazılım testinde hata raporlaması, Test Yöneticilerinin hata durumunu hazırlayıp yönetim ekibiyle paylaşması sürecidir. Yönetim ekibi raporu inceler ve gerekirse geri bildirim veya ek destek sağlar. Hata raporlaması iletişimi geliştirir. tracKral ve kusurlar etrafındaki görünürlük.
Yönetimin, projeyi etkili bir şekilde desteklemek için hata durumunu anlama hakkı vardır. Bu nedenle, rehberlik ve kaynak sağlayabilmeleri için mevcut hata durumu hakkında düzenli olarak rapor vermelisiniz.
Önemli Kusur Metrikleri
Orijinal senaryoya dönecek olursak, geliştirici ve test ekipleri hataları birlikte inceler. Birleştirilmiş sonuçlar aşağıda gösterilmiştir.
Test yürütme kalitesini nasıl ölçebilir ve değerlendirebilirsiniz?
Bu, her açıdan kritik bir sorudur. Test Yöneticisi Cevap vermek istiyor. Genellikle iki temel parametre kullanılır:
Yukarıdaki senaryoda, Hata Reddetme Oranı (DRR) 20/84 = 0.238 (%23.8) olarak hesaplanmıştır.
Başka bir örnek olarak, varsayalım ki... Guru99 Bank web sitesinde toplam şu kadar bilgi bulunmaktadır: 64 kusurlar var, ancak test ekibi yalnızca bunları tespit ediyor. 44 - Anlam 20 Hatalar gözden kaçtı. Kusur Sızıntı Oranı (DLR) 20/64 = 0.312 (%31.2) olarak hesaplanmıştır.
Özetle, test yürütme kalitesi aşağıdaki iki parametre kullanılarak değerlendirilir:
DRR ve DLR değerleri ne kadar küçükse, test yürütme kalitesi o kadar iyidir. Kabul edilebilir aralık genellikle proje hedefleri tarafından tanımlanır veya benzer projelerle karşılaştırılarak belirlenir. Bu örnekte, önerilen kabul edilebilir aralık şöyledir: 5% 10% içinMevcut uygulama bu aralığın dışında kalmaktadır; bu da test kalitesinin aşağıdaki önlemlerle iyileştirilmesi gerektiğini göstermektedir:
- Iyileştirmek Takım üyelerinin test becerileri.
- Daha fazla zaman harca Özellikle test yürütme sonuçlarını incelerken, test yürütme sırasında.
Etkin Hata Yönetimi için En İyi Uygulamalar
Yapılandırılmış en iyi uygulamaları takip etmek, olgun bir hata yönetimi sürecini kaotik bir süreçten ayıran şeydir. Amaç sadece hataları düzeltmek değil, aynı zamanda bunların üretime sızmasını önleyen ve test uzmanları ile geliştiriciler arasındaki iletişim kopukluklarını en aza indiren bir sistem oluşturmaktır.
İşte başlangıç ve orta seviye test uzmanlarının hemen benimsemesi gereken en iyi uygulamalar:
- Hata şablonunu standartlaştırın: Hata Kimliği gibi alanlar içeren, düzeltilmiş bir hata raporu şablonu kullanın. DescriptHata ayıklama adımları, ciddiyet düzeyi, öncelik, ortam ve ekler gibi unsurları içeren tutarlılık, test uzmanları ve geliştiriciler arasındaki karşılıklı iletişimi azaltır.
- Atama yapmadan önce önceliklendirin: Hataları geliştiricilere göndermeden önce her zaman ciddiyet ve önceliğe göre sınıflandırın. Bu, kritik sorunların kozmetik sorunların arkasında kalmamasını sağlar.
- Raporlamadan önce yeniden üretin: Hatayı bildirmeden önce, temiz bir ortamda en az iki kez yeniden oluşturun. Yeniden oluşturulabilen hatalar daha hızlı giderilir ve ret oranını düşürür.
- Bir kusuru benimseyin tracKralın aleti: gibi araçlar kullanın JİRA, Bugzillaya da Peygamber devesi merkezileştirmek tracKral, tarih ve gazetecilik.
- Önceliklendirme toplantıları düzenleyin: Kalite güvence, geliştirme ve ürün ekipleri arasındaki öncelikleri uyumlu hale getirmek için kısa ve odaklı hata ayıklama toplantıları düzenleyin.
- Sızıntı ve reddetme oranlarını ölçün: Track DLR ve DRR her sprint veya döngüde. Artan sızıntı oranı, test kapsamının eksik olduğuna dair erken bir uyarıdır.
- Kök neden analizi gerçekleştirin: Tekrarlayan veya yüksek önem derecesine sahip hatalar için, aynı hata türünün gelecekteki sürümlerde tekrar ortaya çıkmaması için kök neden analizi yapın.
- Raporlama ile süreci tamamlayın: Sorunların görünür ve çözüme kavuşturulabilir kalması için haftalık hata raporlarını paydaşlarla paylaşın.
Bu uygulamalar tutarlı bir şekilde uygulandığında, hata yaşam döngüsünü istikrara kavuşturur ve her sürümün genel kalitesini yükseltir.
Kaynaklar:
Örnek bir Kusur Raporlama Şablonu indirin
