Menü

3 En Kötü Hata Raporlama Alışkanlıkları ve Bunlardan Nasıl Kurtulunur

3 worst defect reporting habits

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

Kusurlar ciddi işlerdir ve küçük hatalar pahalı olabilir.

Bir kusur bulduğunuzda ne yapacağınızı biliyorsunuz. Sen rapor et; ya da Kusur İzleyici / Kusur Yönetimi aracı veya bir Excel sayfasında. Her iki yöntem için de temel ilkeler aynıdır.

Hata Yönetimi araçları daha iyi raporlamayı garanti etmez. Günü kurtaran iyi uygulamalardır.

İyiyi takdir etmek için neyin olmadığını anlamalıyız.

Ne öğreneceksin:

3 En Kötü Hata Raporlama Alışkanlıkları ve Bunlardan Nasıl Kurtulunur

en kötü-kusur-raporlama-alışkanlıkları

İşte:

# 1) Tembellik

Elinizden gelenin en iyisini yapmak için zaman ayırmamak.

Bu kusur izleme süreci çoğu takımda takip edildi:

(Not- büyütülmüş görünüm için herhangi bir resme tıklayın)

kusur izleme

Gördüğünüz gibi, Test lideri hataları QA ekiplerine göndermeden önce gözden geçirir.

Bu inceleme aşağıdakilerin onaylanmasını içerir:

  • Geçerlilik - Bir hata mı?
  • Tamlık - Başlık, adımlar, veriler, ekran görüntüsü vb.
  • Yinelenenler
  • Tekrarlanabilir ya da değil… vb.

Bir QA liderinin% 100 eksiksiz olmasının imkansız olduğunu ilk elden biliyorum.

Dolayısıyla, “Sorunu istediğim şekilde rapor edeceğim. QA lideri yeniden kontrol edebilir. Kusurun geçerli / eksiksiz olup olmadığına o karar verebilir ”, QA ekibinizin sonu ve güvenilirliğinizdir.

Bazı müşterilerin kabul edilebilir geçersiz kusurların sayısı için bir SLA'ya sahip olduğunu biliyor muydunuz? Sayı aşıldığında, bildirilen her geçersiz kusur için yüklenicileri cezalandırmaya mı başlıyorlar?

Çözüm: Durum tespiti yapın ve çıktılarınızdan sorumlu olun. Yetersiz bilgi veya hata olmadığı için bir kusur mu geldi? Her zaman geliştirme ekibinin hatası olmayabilir. Uygulamadaki sorunların sahibi olmak istemedikleri için değil. Gerçek bir QA ekibi karışıklığı olabilir. Bunun olmasına izin vermeyin.

# 2) Acele

Bunu bir ile yapalımmisal.

Aşağıda bir ekran görüntüsü var OpenEMR’ler hasta oluştur ekranı. Açık kaynak kodlu bir hastane yönetim sistemidir.

Bu ekran, kullanıcının bir takvim özelliği aracılığıyla hastanın doğum tarihini girmesini sağlar. Yapmadığı şey, girişi takvimden seçim yapmakla sınırlamaktır. Demek istediğim, DOB'u takvimden “31-Mart-1983” olarak seçebilirsiniz. Daha sonra bunu '31 Şubat 1983' olarak değiştirin.

open-emr-calendar-özelliği

open-emr-error-tahmin

Neden 31 Şubat? Uygulamaya hata tahmin etme ve sahada olumsuz bir veri deneyin; sınamanın amacı bu, değil mi?

Bittiğinde, 'Hasta Oluştur' a tıklıyorum. Tarih geçersiz olduğu için sistemin bir hata görüntülemesini ve hastayı yaratmamasını bekliyorum. Ama bu olmaz. Hastayı aşağıdaki gibi oluşturur.

Aşağıdaki ekranda Yaş ve Doğum Tarihi alanlarına dikkat edin:

openemr-test-tester

Test ederken, bunu birkaç kez deneyebilir ve şuna karar verebilirsiniz:

  • Bu bir böcek.
  • Tekrarlanabilir.
  • Kopya değil (Onaylamak için ekibinize danışın)
  • Sorunun tam tanımını biliyorsunuz
  • Ayrıca, bunu gerçekleştiren kesin adımları da biliyorsunuz.

Artık ham maddeye sahip olduğunuza göre, gitmekte fayda var.

Bildirmeye başlıyorsun. Kusur önem derecesini atamak zorunlu bir adımdır ve ekibiniz şuna benzer bir şey kullanıyor olabilir: referans için aşağıdaki tablo:

Önem Etki
1 (Kritik) • Bu hata sistemi çökertecek, dosya bozulmasına neden olacak veya olası veri kaybına neden olacak kadar kritiktir
• İşletim sistemine anormal bir geri dönüşe neden olur (çökme veya bir sistem hatası mesajı görüntülenir).
• Uygulamanın askıda kalmasına neden olur ve sistemin yeniden başlatılmasını gerektirir.
2 (Yüksek) • Geçici çözüm ile hayati program işlevselliğinin eksikliğine neden olur.
3 (Orta) • Bu Hata Sistemin kalitesini düşürecektir. Bununla birlikte, istenen işlevselliği elde etmek için akıllı bir çözüm vardır - örneğin başka bir ekran aracılığıyla.
• Bu hata, ürünün diğer alanlarının test edilmesini engeller. Ancak diğer alanlar bağımsız olarak test edilebilir.
4 (Düşük) • Ürün kullanımı üzerinde minimum etkisi olan yetersiz veya net olmayan bir hata mesajı var.
5 (Kozmetik) • Ürün kullanımını etkilemeyen yetersiz veya net olmayan bir hata mesajı var.

Bu kusur sistemi çökertmediğinden veya hayati bir işlevselliği engellemediğinden veya uygulamanın diğer alanlarının test edilmesini engellemediğinden, 'Düşük' diyebiliriz.

Doğru görünüyor?

YANLIŞ. Hastanın verilerinden, tüm aşılamaların ve diğer hatırlatıcıların gecikmiş olması. Bu doğru olabilir veya olmayabilir. Ayrıca, bir hasta için yaşı, bir çocuk doktoru mu yoksa genel bir hekim mi, vb. Görüneceğini belirler.

İlaçların dozajlarını ve bilmediğimiz birçok diğer tedavi alanını etkiler.

açık-emr-klinik-hatırlatıcı

Bu yüzden, 'Yüksek' ile gideceğim. Hastane personelinin bir hastanın DOB'una yanlış girme ihtimalinin düşük olduğuna katılıyorum. Ancak bu, sorunun ne zaman çözüleceğinin önceliğini etkileyen bir faktör olsun.

Bir test uzmanı olarak işim, sorunun ciddiyetini elimden geldiğince en iyi şekilde ilettiğimden emin olmaktır.

Çözüm: Rapor etmek için acele etmeyin. Sorunların etkisini birçok açıdan anladığınızdan% 100 emin olun. Test uzmanlarının sağlayabileceği en iyi katma değerdir. Sadece 'Bir şey çalışmıyor' demiyoruz. Ayrıca, 'Bu işe yaramazsa ne olacak' diyoruz. Tonlarca fark, değil mi?

# 3) Yaratıcılık Eksikliği

Test Uzmanları, yazılımı geliştirmek için önerilerde bulunmak için harika bir fırsata sahiptir.

Senin içinde Hata Yönetimi aracı ayrıca, 'Geliştirme Önerisi' türünde bir kusur da gönderebilirsiniz. Burası yaratıcı olabileceğiniz yerdir.

Çözüm: At gözlüklerini çıkar. Belirli bir özelliğin 'Vay be' faktörünün eksik olduğunu düşünüyorsanız ve onu nasıl hayata geçireceğinizi biliyorsanız, fikri öne sürün. En kötü ihtimalle reddedilebilir ve sorun değil. Önemli olan şey denemektir.

Ayrıca, bu süper gücü dikkatli kullanın. 'Afişin renginden nefret ediyorum, lütfen değiştirin' gibi yorumlar yapmamaya çalışın.

İşte iyimisalkarşılaştığım bir geliştirme önerisi: Bir araba bayi sitesinde 'Bayiye e-posta gönder' seçeneğini 'Bayi ile sohbet et' seçeneğiyle değiştirmek. Daha fazla trafiği satışa çevireceği tahmin edilmektedir.

Keşke o kadar yaratıcı olsaydım! Ama belki hepimiz bunun için çalışabiliriz.

İşte bir bonus. Bu kötü alışkanlıklardan kurtulmak için bir kontrol listesi:

1. Başlığım sorunu net ve kısaca aktarıyor mu?
Örneğin:'Yarat hasta çalışmıyor' iyi bir başlık değil. 'Tüm giriş alanları doğru değerleri içerse bile hasta oluşturma başarısız' dır.

iki. Tekrarlanabilirlik oranı nedir?
Başka bir deyişle, her zaman olur mu? Sorunu tekrar edecek adımların tam sırasını biliyor muyum?

3. Bu sorun platforma mı, tarayıcıya mı yoksa kullanıcıya özel mi?

Dört. Adımlar tamamlandı ve sizi sorununuza götürüyor mu?

5 . Ekte bir ekran görüntüsü var mı?

6. Belirli alanları vurgulamak için ekran görüntüme açıklama eklemem gerekir mi?

7. Eklenen görüntü dosyasının adı açıklayıcı mı?
'Adsız.jpg' gibi bir şey kullanmayın. Açıklayıcı bir isim verin.

8. Test verilerini ekledim mi?
Örneğin:Yetkilendirme kimlik bilgilerine ihtiyaç duyan bir Yönetici modülündeki kusur için bunları ekleyin. Geliştirme ekibinin QA ortamına erişimi olabilir veya olmayabilir. Bu kadar basit bir şeyi ertelemek ve takip etmek istemezsiniz.

9. Kusurumu güçlendirmek için başka ayrıntılar verebilir miyim?
(Misal:FRD'ye bir referans veya müşteri ile bir konuşma vb.)

10. Farklı bakış açılarından sorunun ne kadar ciddi olduğunu anlıyor muyum?

on bir. Sorunun temel nedenini biliyor muyum? Varsa, kanıtım var mı (belki günlük dosyaları) ve bunu ekleyebilir miyim? Lütfen bunu her zaman bilmeyebileceğinizi veya bunu bilmeniz gerekebileceğini unutmayın. Ama yaparsanız, onu dahil etmenin zararı olmaz.

12. Kusur raporu dil bilgisi, biçim, yazım ve noktalama sorunları içermiyor mu?

kalite güvencesi ve kalite kontrol arasındaki fark nedir

13. Ürünü iyileştirmenin bir yolunu biliyor muyum?

Bunun zaman alıcı olduğunu mu düşünüyorsunuz? Şey, bir alışkanlık haline geldiğinde, artık olmayacak.

Daha iyisi için köklenme kusur bildirimi rutinler!

Yazar hakkında: Bu makale STH ekip üyesi Swati tarafından yazılmıştır.

Sorularınızı / yorumlarınızı aşağıya göndermekten çekinmeyin.

Önerilen Kaynaklar

^