Ana sayfada yanlış yazılmış bir şirket adı ve nadiren kullanılan bir dışa aktarma özelliğindeki çökme: Önce hangisini düzeltirsiniz? Bunun gibi argümanlar, test ekiplerinin önem derecesi ile önceliği ayırmasının nedenidir. Biri teknik hasarı, diğeri ise işin aciliyetini anlatıyor.

Bu ayrım olmazsa, her hata “kritik” olarak etiketlenir, etiketler anlamlarını kaybeder ve geliştiriciler bunlara güvenmeyi bırakır. Bu kılavuz size açık tanımlar ve örneklerin yanı sıra bu kararları vermenize yönelik basit bir süreç sunar. Örnekler açıklayıcıdır ve tam ölçekler ekipler ve araçlar arasında farklılık gösterir.

Kısa cevap

Önem düzeyi yanıtları: Bu hata ürünü ne kadar kötü etkiliyor? Bir çökme veya veri kaybı ciddi düzeydedir, ancak kozmetik bir aksaklık değildir.

Öncelik yanıtları: Sorunu ne kadar sürede düzeltmeliyiz? Bu, etkilenen müşterilere, son teslim tarihlerine, gelire, yasal görünürlüğe ve marka itibarına bağlıdır.

Bir hastane düşünün. Şiddet, hastanın durumunun ne kadar ciddi olduğudur. Öncelik, hastaların tedavi edilme sırasıdır ve bu aynı zamanda kimin güvenli bir şekilde bekleyebileceği ve hangi kaynakların ücretsiz olduğu gibi diğer faktörlere de bağlıdır.

Önem ve öncelik yan yana

Önem düzeyleri

Çoğu takım yaklaşık dört veya beş seviye kullanır. İşte ortak bir ölçek:

Öncelik seviyeleri

Her bir seviyenin ekibiniz için ne anlama geldiğini, ideal olarak her biri için bir hedef yanıt süresiyle birlikte yazın. “P1, birisinin bir saat içinde başlayacağı anlamına gelir”, “P1 çok önemli anlamına gelir” ifadesinden çok daha faydalıdır.

Örneklerle birlikte dört kombinasyon

Bunu anlamanın en net yolu her bir kombinasyona bakmaktır:

Yüksek önem derecesi, yüksek öncelik

Ödeme herkes için başarısız oluyor, işletme her dakika para kaybediyor ve bunun geçici bir çözümü yok. Bu bariz bir durumdur: Her şeyi bırakın ve düzeltin.

Yüksek önem derecesi, düşük öncelik

Uygulama eski bir formata aktarılırken çöküyor. Teknik olarak bu ciddi bir başarısızlıktır. Ancak kullanıcıların çok küçük bir kısmı bu özelliğe dokunursa ve modern format düzgün çalışıyorsa, planlı bir sürümü bekleyebilir.

Düşük önem derecesi, yüksek öncelik

Ana sayfada şirket adı yanlış yazılmış. Hiçbir şey bozulmaz ve hiçbir veri risk altında değildir. Ancak her ziyaretçi bunu görüyor, bu durum güveni zedeliyor ve yarın büyük bir lansman yapılacaksa bugün düzeltilmesi gerekiyor.

Düşük önem derecesi, düşük öncelik

Nadiren ziyaret edilen bir yardım makalesinde küçük bir yazım hatası. Uygun olduğunda düzeltin. Biriktirme listeniz bunlarla doluysa, bunları tek bir temizleme görevinde birleştirmeyi düşünün.

Bir hata, iki farklı öncelik

Aynı kusur, bağlama bağlı olarak farklı öncelikleri hak edebilir. Yanlış logoyla bir sipariş onayı e-postasının gönderildiğini varsayalım.

Sistem üzerindeki etki aynı olduğu için önem derecesi değişmedi. Ancak iş durumu öyle oldu. Zaman da bazı şeyleri değiştirebilir. Bugün P3 olan bir hata, büyük bir müşterinin devreye girmesinden bir hafta önce P1 haline gelebilir.

Ciddiyete ve önceliğe kim karar veriyor?

• Test uzmanları genellikle davranışı gördükleri ve sistem üzerindeki etkisini anladıkları için önem derecesini önerirler.
• Ürün sahipleri veya yöneticileri genellikle müşterileri, geliri ve yol haritasını tartarak önceliğe karar verir.
• Geliştiriciler bunun nedeni, düzeltme riski ve düzeltmenin ne kadar süreceği hakkında bilgi ekler.
• Destek ekipleri kaç müşterinin etkilendiğine ve bunun ne kadar kötü olduğuna dair kanıtlar getiriyor.

Kaynaklar ve ekipler bu sorumluluklara göre farklılık gösterir ve küçük bir startup’ta bunların hepsini tek bir kişi yapabilir. Önemli olan herkesin son kararı kimin verdiğini bilmesidir, dolayısıyla anlaşmazlıklar bir kararla sona erer.

Bir hata nasıl değerlendirilir?

Emin olamadığınızda bu sorular üzerinde çalışın.

Ciddiyet açısından:

1. Verileri kaybediyor mu, bozuyor mu ya da özel bilgileri açığa çıkarıyor mu?
2. Bir ana fonksiyonun çalışmasını engelliyor mu?
3. Geçici bir çözüm var mı ve normal bir kullanıcı bunu bulabilir mi?
4. Özelliğin ne kadarı etkileniyor?

Öncelik için:

1. Kaç kullanıcı etkilendi ve hangileri?
2. Maliyeti var mı veya yasal ya da uyumluluk riski yaratıyor mu?
3. Bir sürüm, demo veya indirim yaklaşıyor mu?
4. Ne kadar görünür ve itibarınıza zarar verebilir mi?
5. Test etme gibi diğer işleri engelliyor mu?

Hata önceliklendirmesi çalıştırılıyor

Triyaj, bir ekibin yeni hataları incelediği ve bundan sonra ne olacağına karar verdiği düzenli toplantıdır. Basit bir format iyi çalışır:

1. Hazırlık yapın. Testi yapan kişi, her yeni hatanın açık adımlara, kanıtlara ve önerilen önem derecesine sahip olduğundan emin olur.
2. Onayla. Kopyalanabildiğini ve kopya olmadığını kontrol edin.
3. Karar verin. Önem derecesi üzerinde anlaşın, bir öncelik belirleyin ve bir sahip atayın.
4. Döngüyü kapatın. Her hatayı reddedin, erteleyin veya programlayın ve nedenini kaydedin.

Kısa ve sık tutun. Salıverilmeden önceki son günlerde günlük 15 dakikalık triyaj yaygındır. Önem derecesi ve öncelik aynı zamanda yayınlama kararınızı da besler; bu nedenle, çıkış kriterlerinizin bir parçası olarak “yayın sırasında açık S1 veya S2 hatası olmaması” gibi kurallar üzerinde önceden anlaşın.

Bir hata raporunda önem derecesi ve öncelik

Kısa ve net bir giriş herkesin iyi bir karar vermesine yardımcı olur:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Bu rakamlar örnektir. Gerçek bir raporda, günlüklerinizden ölçülen rakamları kullanın ve gerekçenizi açıklayın. Hata raporunun nasıl yazılacağına ilişkin kılavuzumuzdan daha fazla bilgi edinin. Ayrıca hata kodlarının ne anlama geldiğini bilmenize de yardımcı olur; bu nedenle HTTP durum kodları yardımcı sayfamızı el altında bulundurun.

Yaygın hatalar

• Bunlara aynı alanmış gibi davranılması. İkisi her zaman eşleşirse, yararlı bilgileri kaybedersiniz.
• Dikkat çekmek için ciddiyeti abartmak. Her şey kritik olduğunda hiçbir şey kritik değildir.
• Test uzmanlarının önceliği tek başına belirlemesine izin vermek. İş resminin tamamını nadiren görürler.
• Biriktirme listesini asla incelemeyin. Öncelikler eskir, bu nedenle eski hataları düzenli olarak yeniden kontrol edin.
• Yazılı tanımlar yoktur. Bunlar olmadan, insanlar etiketleri farklı şekilde uygular ve sonunda sözcükleri tartışırsınız.
• Düşük önemdeki yığılmaların göz ardı edilmesi. Elli küçük sorun, hiçbiri tek başına ciddi olmasa bile ürünün kırılmış gibi görünmesine neden olabilir.

Son sözler

İki soruyu ayrı tutun: Durum ne kadar kötü ve ne kadar sürede düzeltilmesi gerekiyor? Her seviye için yazılı tanımlar üzerinde anlaşın ve kimin karar vereceğini açıkça belirtin. Bir sonraki adım olarak takip cihazınızdaki en eski on hatayı alın ve yukarıdaki soruları kullanarak bunları yeniden derecelendirin. Muhtemelen hareket etmesi gereken birkaç tane ve kapatılması gereken birkaç tane bulacaksınız.

Sık sorulan sorular

Öğrenmeye devam et