Menü

Canlı Proje Hata İzleme, Test Metrikleri ve Test Sonlandırma - Ücretsiz QA Eğitimi 6. Gün

  • Ana
  • Hata Kusur Takibi
  • Canlı Proje Hata İzleme, Test Metrikleri ve Test Sonlandırma - Ücretsiz QA Eğitimi 6. Gün

live project bug tracking

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

Bu, ' Canlı bir projede Yazılım Testi eğitimi ' dizi.

Hatalar hakkında olacak ve ayrıca STLC'nin Test Yürütme aşamasının tamamlandığını işaret edecek kalan birkaç konu olacak.

İçinde önceki makale Test Yürütme devam ederken, test senaryosunun beklenen sonucunun karşılanmadığı bir durumla karşılaştık. Ayrıca, Keşif Testi sırasında bazı beklenmedik davranışlar belirledik.

Canlı Proje Hata İzleme, Test Metrikleri ve Test Sonlandırma

Bu sapmalarla karşılaştığımızda ne olur?

Açıkçası onları kaydetmeli ve bu sapmaların AVU'ya göre düzeltildiğinden emin olmak için takip etmeliyiz.

# 1) Bu sapmalara Kusurlar / hatalar / sorunlar / olaylar / hatalar / hatalar denir.

#iki) Aşağıdaki tüm durumlar kusur olarak kaydedilebilir

  • Eksik gereksinimler
  • Yanlış çalışma gereksinimleri
  • Ekstra gereksinimler
  • Referans belge tutarsızlıkları
  • Çevre ile ilgili sorunlar
  • Geliştirme önerileri

# 3) Hata kaydı çoğunlukla Excel sayfalarında veya bir Hata Yönetimi yazılımı / aracı kullanılarak yapılır. Araçlarla kusurların nasıl ele alınacağı hakkında bilgi için aşağıdaki bağlantıları kullanmayı deneyin:

Ne öğreneceksin:

Kusurlar Nasıl Etkili Bir Şekilde Kaydedilir

Şimdi bir önceki makalede karşılaştığımız hataları bir excel sayfasında nasıl kaydedeceğimizi görmeye çalışacağız. Her zaman olduğu gibi, standart bir format veya şablon seçmek önemlidir.

tutulmada yeni bir proje nasıl oluşturulur

Tipik olarak, aşağıdaki sütunlar Kusur Raporunun bir parçasıdır:

  • Kusur Kimliği: Benzersiz kimlik için.
  • Kusur Tanımı: Bu, sorunu kısaca açıklamak için bir başlık gibidir.
  • AUT modülü / bölümü: Bu isteğe bağlıdır, sadece AUT'nin problemle karşılaşılan alanını belirtmek için daha fazla netlik eklemek için.
  • Yeniden Oluşturma Adımları: Hatayı yeniden oluşturmak için AUT üzerinde gerçekleştirilecek işlemlerin tam sırası burada listelenecektir. Ayrıca, herhangi bir girdi verisi soruna özgü ise, bu bilgi de girilecektir.
  • Önem: Sorunun yoğunluğunu ve nihayetinde bunun AVE'nin işleyişi üzerindeki etkisini belirtmek için. Bu alanda nasıl atanacağına ve hangi değerlerin atanacağına ilişkin yönergeler test planı belgesinde bulunabilir. Bu nedenle, lütfen 3. maddeden Test Planı belgesi .
  • Durum: Makalede daha fazla tartışılacaktır.
  • Ekran görüntüsü: Hata oluştuğunda hatayı göstermek için uygulamanın anlık görüntüsü.

Bunlar, 'sahip olunması gereken' alanlardan bazılarıdır. Bu şablon genişletilebilir (Örn. Sorunu bildiren test kullananın adını içerecek şekilde) veya sözleşmeli ( Örneğin, modül adı kaldırıldı).

Yukarıdaki yönergeleri izleyerek ve yukarıdaki şablonu kullanarak, örnek bir Kusur günlüğü / Raporu aşağıdaki gibi görünebilir:

OrangeHRM Live projesi için Örnek Kusur Raporu:

OrangeHRM Hata Raporu

=> Canlı proje Kusur Raporunu indirmek için buraya tıklayın

Aşağıda, qTest Test Yönetimi aracında oluşturulan örnek Kusur Raporu bulunmaktadır: (Büyütmek için resmin üzerine tıklayın)

Örnek Kusur Raporu

Hataları kaydedip kendimize sakladığımızda kusurlar işe yaramaz. İlgili ekiplerin onlara göre hareket etmesi için onları doğru sırada görevlendirmemiz gerekecek. Süreç - kimin atanacağı veya hangi sıranın izleneceği de test planı belgesinde bulunabilir. Çoğunlukla benzer (Büyütmek için resmin üzerine tıklayın)

Kusur Döngüsü:

Kusur yaşam döngüsü 1

Yukarıdaki süreçten, hataların tespit edilme sürecinde farklı kişilerden ve farklı kararlardan geçtiği not edilebilir. Belirli bir hatanın tam olarak hangi durumda olduğu konusunda şeffaflık sağlamak ve izlemek için, hata raporunda bir 'Durum' alanı kullanılır. Tüm süreç bir 'Hata yaşam döngüsü' olarak adlandırılır. Tüm durumlar ve anlamları hakkında daha fazla bilgi için lütfen buna bakın. Hata Yaşam Döngüsü öğreticisi .

Hata İzleme Sırasında Birkaç İşaret

  • Yaratıcı bir Ekip / Proje / AUT için yeni olduğumuzda, her zaman en iyisi karşılaştığımız sorunu tartışın bir kusuru gerçekten neyin yarattığına dair anlayışımızın doğru olup olmadığından emin olmak için bir meslektaşımızla.
  • İçin tüm bilgileri sağlayın bu sorunu yeniden oluşturmak için gereklidir. 'Yeterli bilgi yok' statüsü ile test ekibine geri dönen bir kusur, bize çok olumlu bir şekilde yansımaz. Bu gönderiye göz atın - Herhangi bir 'Geçersiz hata' etiketi olmadan tüm hatalarınızı nasıl çözebilirsiniz? .
  • Yeni bir sorun oluşturmadan önce benzer bir sorunun ortaya çıkıp çıkmadığını kontrol edin. 'Yinelenen' sorunlar QA ekibi için de kötü bir haber.
  • Rastgele ortaya çıkan bir sorun varsa ve sorunu yeniden oluşturabileceğimiz adımları / durumları tam olarak bilmiyorsak sorunu aynı şekilde dile getirin. Sorunun ayarlanması riski altında 'Tekrarlanamaz / yeterli bilgi yok' - olası tüm arızaları mümkün olan en iyi şekilde ele aldığımızdan emin olmalıyız.
  • Genel uygulama QA ekibinin her birinin kusurlarını bir gün boyunca bir excel sayfasında oluşturması ve günün sonunda bunu konsolide etmesidir.

Kusurlu Yaşam Döngüsü

Canlı projemiz için, kusur 1 için kusur yaşam döngüsünü takip edecek olsaydık,

varsayılan ağ geçidi Windows 10 wifi mevcut değil
  • Onu (test eden) oluşturduğumda, durumu 'Yeni”. Bunu QA ekibi liderine atadığımda, durum hala 'Yeni' ancak sahibi artık QA sorumlusu.
  • QA sorumlusu sorunu inceleyecek ve bunun geçerli bir sorun olduğunu belirledikten sonra sorun, Dev liderine atanacaktır. Bu aşamada durum şu şekildedir: 'Atanmış' ve sahibi Dev lideridir.
  • Geliştirme sorumlusu daha sonra bu sorunu, bu sorunu çözmek için çalışacak bir geliştiriciye atayacaktır. Durum şimdi olacak 'Devam Eden Çalışma' (veya bu etkiye benzer bir şey), sahibi geliştiricidir.
  • Hata 1 için, geliştirici hatayı yeniden oluşturamaz, bu nedenle hatayı QA ekibine geri atar ve durumu şu şekilde ayarlar: 'Çoğaltılamıyor”.
  • Alternatif olarak, geliştirici üzerinde çalışıp bir sorunu çözebildiyse, durum şu şekilde ayarlanacaktır: 'çözüldü' ve sorun QA ekibine geri verilecektir.
  • QA ekibi daha sonra sorunu alacak, sorunu yeniden test edecek ve sorun giderilirse durumu şu şekilde ayarlayacaktır: 'Kapalı' . Sorun devam ederse, durum şu şekilde ayarlanır: 'Yeniden aç' ve süreç devam ediyor.
  • Diğer durumlara bağlı olarak durum şu şekilde ayarlanabilir: 'Ertelenmiş' , 'Yeterli bilgi yok', 'Çiftleme' , 'Amaçlandığı gibi çalışmak' , vb. geliştirici tarafından.
  • Hataların kaydedilmesi, raporlanması ve atanması, yönetilmesi için bu yöntem, test yürütme aşamasında QA ekip üyeleri tarafından gerçekleştirilen başlıca faaliyetlerden biridir. Bu, belirli bir test döngüsü tamamlanana kadar günlük olarak yapılır.
  • 1. Döngü tamamlandıktan sonra, geliştirici ekibin tüm düzeltmeleri birleştirmesi ve kodu bir sonraki döngüde kullanılacak bir sonraki sürüme yeniden inşa etmesi bir veya iki gün sürecektir.
  • Aynı süreç 2. döngü için de devam eder. Döngünün sonunda, uygulamada hala bazı 'Açık' veya çözülmemiş sorunlar olma ihtimali vardır.
  • Bu aşamada - Döngü 3'e devam ediyor muyuz? Varsa, testi ne zaman durduracağız?

OrangeHRM Canlı Proje Testi için Çıkış Kriterleri

Burası 'Çıkış Kriterleri' dediğimiz şeyi kullandığımız yerdir. Bu, Test Planı belgesinde önceden tanımlanmıştır. Testi 2. döngüden sonra mı sonuçlandıracağımızı yoksa bir döngü daha mı devam edeceğimizi belirleyen basitçe kontrol listesi şeklindedir. OrangeHRM projesi ile ilgili aşağıdaki sorulara bazı varsayımsal cevaplar dikkate alınarak doldurulduğunda aşağıdaki gibi görünüyor:

Test Çıkış Kriterleri

Yukarıdaki kontrol listesine dikkatlice baktığımızda, burada daha önce tartışmadığımız ölçütler ve imzalar var. Şimdi onlar hakkında konuşalım.

Test Metrikleri

Test Yürütme aşamasında, diğer tüm proje ekibi üyelerine hakkında net bir fikir vermek için raporlar gönderildiğini tespit ettik. QA Yürütme aşamasında neler oluyor . Bu bilgiler, nihai ürünün genel kalitesinin doğrulanması için herkes için önemlidir.

10 test vakasının geçtiğini veya 100 test vakasının yürütüldüğünü bildirdiğimi hayal edin - bu rakamlar yalnızca ham verilerdir ve işlerin nasıl gittiği hakkında çok iyi bir bakış açısı sağlamaz.

Metrikler, bu boşluğu doldurmada hayati bir rol oynar. Metrikler basit kelimelerdir, test ekibinin topladığı ve koruduğu akıllı sayılar . Örneğin, Test vakalarının% 90'ının geçtiğini söylersem, 150 test vakası geçti demekten daha mantıklı. Değil mi?

Test yürütme aşamasında toplanan farklı Metrik türleri vardır. Hangi süreler boyunca tam olarak hangi ölçütlerin toplanıp muhafaza edileceği - bu bilgi test planı belgesinde bulunabilir.

Aşağıdakiler, çoğu proje için en sık toplanan test metrikleridir:

  • Test senaryolarının Geçme Yüzdesi
  • Kusur yoğunluğu
  • Kritik Kusur yüzdesi
  • Kusurlar, Önem derecesi

Kontrol et Bu makaleye ekli Durum Raporu bu ölçümlerin nasıl kullanıldığını görmek için.

Test Oturum Kapatma / Tamamlama Raporu

Tüm paydaşları testin başladığını bildirmemiz gerektiğinden, testin tamamlandığını herkese bildirmek ve sonuçları paylaşmak da QA ekibinin görevidir. Bu nedenle, genellikle QA ekibinden (genellikle Takım Lideri / QA Yöneticisi) bir e-posta gönderilir ve KG ekibinin test sonuçlarını ve açık / bilinen sorunların listesini ekleyerek ürünü imzaladığına dair bir gösterge verilir.

Örnek Test Oturum Kapatma E-postası:

Kime: Müşteri, Koruyucu Bakım, Geliştirme ekibi, DB ekibi, BA, QA ekibi, Çevre Ekibi (ve dahil edilmesi gereken diğer herkes)
E-posta: Merhaba takım,

Kalite güvencesi ekibi, web sitesinin 2 döngüsel işlevsel testini başarıyla tamamladıktan sonra OrangeHRM sürüm 3.0 yazılımını imzaladı.

Test senaryoları ve yürütme sonuçları e-postaya eklenir. (Veya bulundukları konumu belirtin. Veya test yönetimi yazılımı kullanıyorsanız, aynı şeyle ilgili ayrıntıları sağlayın.)

Bilinen sorunların listesi de e-postaya eklenmiştir. (Yine, anlamlı olan diğer referanslar eklenebilir.)

Teşekkürler,
QA ekip lideri.

Ekler: Nihai Yürütme Raporu, Son sorun / kusur raporu, Bilinen sorunlar listesi

Test imzalama e-postası QA ekibinden gönderildiğinde, STLC sürecini resmen tamamlamış oluruz. Bu, SDLC'nin 'Test' aşamasının tamamlandığını göstermez. Bunun olması için hala UAT testimiz var. Bul UAT testi hakkında daha fazla ayrıntı burada .

UAT tamamlandıktan sonra, SDLC, yayına girdiği ve müşterileri / son kullanıcıları tarafından tüketilmek üzere hazır olduğu dağıtım aşamasına geçer.

Bu kadar!

Bu, okuyucularımıza QA Projesi gibi en canlı deneyimi yaşatma çabamız oldu. Lütfen bu ücretsiz çevrimiçi Yazılım Testi QA eğitim serisiyle ilgili yorumlarınızı ve sorularınızı bize bildirin.

Önerilen Kaynaklar

^