Menü

Hata Yönetimi Süreci: Bir Kusur Etkili Bir Şekilde Nasıl Yönetilir

  • Ana
  • Diğer
  • Hata Yönetimi Süreci: Bir Kusur Etkili Bir Şekilde Nasıl Yönetilir

defect management process

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

Hata Yönetimi Sürecine Giriş:

Daha odaklı süreç ve test, pazarda daha az hatalı yazılıma izin verecektir.

Kusur Önleme hata sayısını azaltmada çok daha verimli ve etkilidir ve ayrıca yazılım sürecinin erken aşamasında bulunan hataları düzeltmek için çok uygun maliyetlidir. Kuruluşların çoğu yürütür Kusur Keşfi , Kusur Giderme ve daha sonra Süreç geliştirme toplu olarak bir Hata Yönetimi Süreci .

Hata Yönetimi Süreci

dvd'yi mp4'e kopyalamak için ücretsiz yazılım

Ne öğreneceksin:

Hata Yönetimi Sürecinin (DMP) Hedefleri

Aşağıda bu sürecin çeşitli hedefleri verilmektedir:

  • Kusuru Önleyin
  • Erken teşhis
  • Etkiyi en aza indirin
  • Kusurun Çözümü
  • Süreç geliştirme

Hata Yönetimi Sürecini keşfetmeden önce, önce anlayalım aslında bir kusur veya hata nedir?

Hata Yönetimi Yaşam Döngüsü

Bir sistem, fiili iş gerekliliğinden farklı bir çıktı verdiğinde, yani fiili veya orijinal iş gereksiniminden bir sapma olduğunda, sistemde / yazılımda bir kusur olduğunu söyleyebiliriz.

Test ekibi test senaryolarını yürüttüğünde, gerçek test sonucunun beklenen sonuçtan farklı olduğu bir durumla karşılaşırlar. Bu varyasyon, Kusur .

Temel olarak, bir Yazılım Hatası, yazılım gereksinimini karşılamayan bir durumdur. Kusur, sistemde beklenmedik veya yanlış bir davranışa neden olan bir hata veya kusurdur.

Projeleri uygun şekilde ele almak için, geliştirme ve yayınlama ile nasıl başa çıkacağınızı bilmeniz gerekir, ancak bununla birlikte kusurları nasıl ele alacağınızı da bilmeniz gerekir.

Bir hayal edin, test ekibi hataları sözlü olarak bildirirse ve geliştirme ekibi de kusurun durumunu sözlü olarak güncellerse ne olur? Bu kusurlar, aslında düzeltilen ve beklendiği gibi çalışan, düzeltilen ancak hala çalışmayan, reddedilen, ertelenen ve süreç devam eden gibi tüm kusurları içerdiğinden süreç daha karmaşık olacaktır.

Yukarıdaki durumda, kusurların sayısı arttıkça ve iletişim sözlü olarak yapıldıkça, durum yakında çok kötüye gidecek. Kusuru etkili bir şekilde kontrol etmek ve ele almak için uygun Kusur Yaşam Döngüsüne ihtiyacınız vardır.

Kusur Yaşam Döngüsü, sürecin tek tip ve standartlaştırılmış olmasını sağlar. Bir kusur, yaşam döngüsü içinde farklı durumlara ulaşır. Bir kusur bulunduktan sonra, ömrü boyunca çeşitli aşamalardan geçer ve genellikle Kusur Yaşam Döngüsü .

Genel olarak, Kusur yaşam döngüsü, kusurun test ekibi tarafından bulunduğu veya ortaya çıktığı aşamadan başlar ve bir kusurun tekrarlanamadığından veya bir geliştirme ekibi tarafından reddedilmediğinden emin olarak kapatıldığında sona erer. Bir kusurun geçtiği durumların sayısı projeden projeye değişir.

Daha fazla okuma:

Yazılım Testinde Hata / Hata Yaşam Döngüsü Nedir? Kusur Yaşam Döngüsü Eğitimi

Not: Aşağıdaki döngü organizasyondan organizasyona biraz farklılık gösterir.

Aşağıdaki kusur yaşam döngüsü olası tüm durumları kapsar:

Kusur Yaşam Döngüsü Akış Şeması

  • Test ekibi uygulamada bir kusur bulduğunda, sorunu ' YENİ ”.
  • Yeni bir kusur, bir QA sorumlusu tarafından incelendiğinde ve kusur geçerliyse, kusurun durumu ' Açık ”Ve geliştirme ekibine atanmaya hazır.
  • Bir KG sorumlusu, arızayı ilgili geliştiriciye atadığında, kusurun durumu ' Atanmış ”. Bir geliştirici, bu aşamada kusuru analiz etmeye ve düzeltmeye başlamalıdır.
  • Geliştirici, kusurun gerçek veya geçerli olmadığını hissettiğinde, kusurun reddedilmesi. Kusurun durumu ' Reddedildi 'Ve test ekibine geri atandı.
  • Günlüğe kaydedilen kusur iki kez tekrarlanırsa veya bildirilen kusurların her ikisi de benzer sonuçlara ve yeniden oluşturma adımlarına sahipse, bir kusur durumu ' Çiftleme ”.
  • Mevcut sürümde belirli bir hatayı düzeltmek için bazı sorunlar veya engeller varsa, kusur mevcut sürüm yerine gelecek sürümlerde alınacak ve ardından ' Ertelenmiş 'Veya' Ertelenen ”.
  • Bir geliştirici, test ekibi tarafından 'Yeniden Oluşturma Adımları' bölümünde belirtilen adımlarla kusuru yeniden oluşturamadığında, geliştirici, sorunu ' Tekrarlanamaz' . Bu aşamada, test ekibi bir geliştiriciye ayrıntılı çoğaltma adımları sağlamalıdır.
  • Geliştirici, kusuru yeniden oluşturmak için bir KG tarafından sağlanan yeniden üretme adımları konusunda net değilse, ' Daha fazla bilgiye ihtiyacınız var ”. Bu durumda, test ekibinin gerekli ayrıntıları geliştirme ekibine sağlaması gerekir.
  • Bir kusur zaten biliniyorsa ve şu anda üretim ortamında mevcutsa, kusur ' Bilinen kusur ”.
  • Bir geliştirici gerekli değişiklikleri yaptığında, kusur ' Sabit ”.
  • Geliştirici şimdi doğrulamak için kusuru test ekibine iletir, böylece geliştirici durumu ' Yeniden Test İçin Hazır ”.
  • Kusurun başka bir sorunu yoksa ve doğru bir şekilde doğrulanmışsa, test uzmanı arızayı ' Kapalı ”.
  • Kusur yeniden test edilirken, test eden kişi kusurun hala yeniden üretilebilir olduğunu veya kısmen düzeltildiğini tespit ederse, kusur ' Yeniden açıldı ”. Şimdi geliştiricinin bu kusuru tekrar araştırması gerekiyor.

İyi planlanmış ve kontrollü bir Kusur Yaşam Döngüsü, bir sürümde veya tüm sürümlerde bulunan toplam kusur sayısını verir. Bu standartlaştırılmış süreç, kodun nasıl yazıldığına, testin ne kadar düzgün yapıldığına, hatanın veya yazılımın nasıl piyasaya sürüldüğüne vb. Dair net bir resim verir. Bu, testteki kusurları bularak üretimdeki kusurların sayısını azaltacaktır. aşamanın kendisi.

Hata Yönetimi Süreci

Hata Yönetimi Süreci

Hata yönetimi süreci aşağıda ayrıntılı olarak açıklanmıştır.

# 1) Kusur Önleme:

Kusur Önleme Daha sonraki aşamada kusurları bulmak ve sonra düzeltmek yerine testin erken aşamasında hataları ortadan kaldırmak için en iyi yöntemdir. Testin erken aşamalarında bulunan kusurları gidermek için gereken maliyet çok düşük olduğundan, bu yöntem aynı zamanda uygun maliyetlidir.

Bununla birlikte, tüm kusurları ortadan kaldırmak mümkün değildir, ancak en azından kusurun etkisini ve onu düzeltmenin maliyetini en aza indirebilirsiniz.

Kusur Önlemede yer alan ana adımlar aşağıdaki gibidir:

  • Kritik Riski Tanımlayın : Test sırasında veya sonraki aşamada meydana gelirse, sistemdeki daha fazla etki yaratacak kritik riskleri belirleyin.
  • Beklenen Etkiyi Tahmin Et : Her kritik risk için, riskin gerçekten karşılaşması durumunda finansal etkinin ne kadar olacağını hesaplayın.
  • Beklenen etkiyi en aza indirin : Tüm kritik riskleri belirledikten sonra, karşılaşıldığında sisteme zarar verebilecek en yüksek riskleri alın ve riski en aza indirmeye veya ortadan kaldırmaya çalışın. Ortadan kaldırılamayan riskler için oluşma olasılığını ve finansal etkisini azaltır.

# 2) Verilebilir Referans:

Bir teslim edilebilir (sistem, ürün veya belge) önceden tanımlanmış dönüm noktasına ulaştığında, bir teslim edilebilir ürünün temel olduğunu söyleyebilirsiniz. Bu süreçte, ürün veya teslim edilebilir bir aşamadan diğerine geçer ve teslim edilebilir bir aşamadan diğerine geçerken, sistemdeki mevcut kusurlar da bir sonraki kilometre taşına veya aşamaya taşınır.

Örneğin, bir kodlama senaryosu, birim testi ve ardından sistem testi düşünün. Bir geliştirici kodlama ve birim testi gerçekleştirirse, test ekibi tarafından sistem testi gerçekleştirilir. Burada kodlama ve Birim Testi bir kilometre taşıdır ve Sistem Testi başka bir kilometre taşıdır.

Dolayısıyla, birim testi sırasında, geliştirici bazı sorunlar bulursa, bu sorunlar dönüm noktası son tarihinin karşılanmasından önce tanımlandığı için bir kusur olarak adlandırılmaz. Kodlama ve birim testi tamamlandıktan sonra, geliştirici, sistem testi için kodu verir ve ardından kodun 'Temelli' ve bir sonraki dönüm noktası için hazır, burada, bu durumda, 'sistem testi'.

Şimdi, sorunlar test sırasında belirlenirse, daha önceki dönüm noktasının, yani kodlama ve birim testinin tamamlanmasından sonra tanımlandığı şekliyle kusur olarak adlandırılır.

Temel olarak, teslim edilebilir ürünlerdeki değişiklikler sonuçlandırıldığında ve tüm olası kusurlar tanımlanıp düzeltildiğinde, teslim edilecekler temel alınır. Sonra aynı çıktı, üzerinde çalışacak bir sonraki gruba geçer.

# 3) Kusur Keşfi:

Sistemdeki tüm kusurları gidermek ve hatasız bir sistem yapmak neredeyse imkansızdır. Ancak, kusurları proje için daha maliyetli hale gelmeden önce tespit edebilirsiniz. Keşfedilen kusurun resmi olarak geliştirme ekibinin dikkatine sunulduğu anlamına geldiğini ve bunun analizinden sonra hata geliştirme ekibinin de kusur olarak kabul ettiğini söyleyebiliriz.

Hata Keşfi ile ilgili adımlar aşağıdaki gibidir:

  • Bir Kusur Bulun : Sistem için büyük bir sorun haline gelmeden önce kusurları belirleyin.
  • Kusuru Bildir : Test ekibi bir kusur bulur bulmaz, sorumlulukları, geliştirme ekibini, analiz edilmesi ve düzeltilmesi gereken bir sorun olduğunu tespit etmektir.
  • Kusuru Onaylayın : Test ekibi, kusuru geliştirme ekibine atadığında, kusurun kabul edilmesi ve geçerli bir kusursa düzeltmeye devam edilmesi geliştirme ekibinin sorumluluğundadır.

# 4) Kusur Çözümü:

Yukarıdaki süreçte, test ekibi arızayı tespit etti ve geliştirme ekibine rapor etti. Şimdi burada geliştirme ekibinin kusurun çözümü için ilerlemesi gerekiyor.

Kusur çözümünde yer alan adımlar aşağıdaki gibidir:

  • Riski önceliklendirin : Geliştirme ekibi, hatayı analiz eder ve kusurun giderilmesine öncelik verir. Bir kusur sistem üzerinde daha fazla etkiye sahipse, kusurun düzeltilmesini yüksek bir öncelik haline getirir.
  • Kusuru düzeltin : Önceliğe bağlı olarak, geliştirme ekibi arızayı düzeltir, daha yüksek öncelikli kusurlar önce çözülür ve sonunda daha düşük öncelikli kusurlar giderilir.
  • Çözümü Bildir : Test ekibinin, kusurların ne zaman bir düzeltmeye gittiğini ve hatanın nasıl düzeltildiğini, yani yapılandırma dosyalarından birini değiştirerek veya bazı kod değişiklikleri yaparak haberdar olmasını sağlamak geliştirme ekibinin sorumluluğudur. Bu, test ekibinin hatanın nedenini anlamasına yardımcı olacaktır.

# 5) Süreç İyileştirme:

Hata çözme sürecinde hatalar önceliklendirilir ve sabitlenir, ancak süreç açısından bakıldığında bu, düşük öncelikli hataların önemli olmadığı ve sistemi fazla etkilemediği anlamına gelmez. Süreç iyileştirme açısından, tespit edilen tüm kusurlar kritik bir kusurla aynıdır.

Bu küçük kusurlar bile, sürecin nasıl iyileştirileceğini öğrenme ve gelecekte sistem arızasını etkileyebilecek herhangi bir kusur oluşumunu önleme fırsatı verir. Sistem üzerinde daha düşük bir etkiye sahip bir kusurun belirlenmesi çok önemli olmayabilir, ancak bu tür bir kusurun sistemin kendisinde meydana gelmesi çok önemlidir.

Süreç iyileştirme için, projedeki herkesin geriye bakması ve kusurun nereden kaynaklandığını kontrol etmesi gerekir. Buna bağlı olarak, daha ucuz olan ve sürecin erken aşamalarında hataları yakalayabilecek doğrulama sürecinde, temel astar belgesinde, gözden geçirme sürecinde değişiklikler yapabilirsiniz.

Sonuç

Hata Yönetimi Süreci, yalnızca belirli test veya geliştirme faaliyetleri için değil, genel yazılım geliştirme süreci boyunca izlenmelidir.

Test aşamasında bir kusur bulunursa, hata bu aşamada yakalanırsa, sistemde canlı olan ve ortaya çıkarsa ve henüz keşfedilmemişse sistem arızasına neden olabilecek diğer kusurlar hakkında bir soru sorulabilir.

Bu nedenle, gözden geçirme süreci, statik test, inceleme vb. Gibi tüm süreçlerin güçlendirilmesi gerekir ve projedeki herkes süreç konusunda ciddi olmalı ve gerektiğinde katkıda bulunmalıdır. Organizasyondaki üst yönetim de kusur yönetimi sürecini anlamalı ve desteklemelidir.

Test yaklaşımları, inceleme süreci vb. Proje hedefine veya organizasyon sürecine göre seçilmelidir.

Kusur Yönetim Süreci hakkındaki bu bilgilendirici makalenin size çok yardımcı olacağını umuyoruz.

jnlp dosyası nasıl açılır

Önerilen Kaynaklar

^