Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Tek tek test vaka hatalarına öncelik verdikten sonra düzeltmeler uygulayabilir ve genel aracı performansında yine de çok az veya hiç iyileştirme göremeyebilirsiniz. Bu sonuç genellikle ilgili olmayan hatalardan oluşan bir koleksiyonu değil, sistemik bir sorunu gösterir.
Desen analizi, yinelenen sinyalleri ve paylaşılan kök nedenleri belirlemek için birden çok başarısız test çalışması arasında aramanıza yardımcı olur. Her hatayı yalıtarak düzeltmek yerine hata gruplarını aynı anda ele alan değişikliklere odaklanmak için desen analizini kullanın.
Önemli
Hata önceliklendirmesini tamamladıktan ve düzeltme değişiklikleri uyguladıktan sonra bu kılavuzu kullanın. En az beş arızayı öncelik sırasına koyduktan sonra arıza analizi en verimli şekilde yapılabilir.
Desen analizi ne zaman kullanılır?
Desen analizi en çok aşağıdaki koşullardan birini veya daha fazlasını gözlemlediğinizde yararlıdır:
- Aynı değerlendirme kümesinde birçok hata.
- Benzer belirtilerle tekrarlanan hatalar.
- Genel puanları değiştirmeyen tekil test vakalarına yapılan iyileştirmeler.
- Bir alandaki iyileştirmeler, başka bir alanda gerilemelere neden oluyor.
Bu gibi durumlarda hataları teker teker düzeltmek verimsizdir. Desen analizi, temel alınan nedeni ele almak için hangi hataların ortak olduğunu belirlemenize yardımcı olur.
Konsantrasyon analizi
Tek tek hataları sınıflandırdıktan sonra tüm kümedeki desenleri arayın.
| Desen | Neyi gösterir? | Önerilen eylem |
|---|---|---|
| 80% veya daha fazla hata değerlendirme kurulum sorunlarıdır | Değerlendirme paketinin kalibrasyona ihtiyacı var, madde değişikliklerine değil | Aracı yinelemesini duraklatın. Önce değerlendirme kalitesini denetle ve düzelt, ardından temiz sinyal almak için yeniden çalıştır. |
| 80% veya daha fazla hata, bir alandaki aracı yapılandırma sorunlarıdır (örneğin, tüm bilgilerle ilgili) | Sistemik ajanın yapılandırma boşluğu | Düzeltmeyi o alana odakla. Bu sorun genellikle bireysel test vakası düzeltmeleri değil, mimari bir sorundur (örneğin, bilgi kaynağı yapısı). |
| 80% veya daha fazla hata platform sınırlamalarıdır | Ajan, platform sınırlarına ulaşır. | Aracı kapsamını yeniden değerlendirin. Platform ekibine yükseltin. Eşikleri ayarlayın veya etkilenen öğeleri uygun yerlerde bilinen sınırlamalar olarak değerlendirin. |
| Hatalar, kök neden türlerine eşit olarak dağılıyor | Tek bir sistemik sorun yok | Düzeltme eşlemesini kullanarak vakaya göre düzeltmeye devam edin. |
Konsantrasyon analizi nasıl yapılır
Sınıflandırılmış hatalarınızı kök neden türüne göre not edin:
- Değerlendirme kurulum sorunları
- Aracı yapılandırma sorunları
- Platform sınırlamaları
- Sınıflandırılmamış
Her türün yüzdesini hesaplayın.
Tek bir tür 80% veya daha yüksekse (sistemik bir sorunu gösterir) tek tek durumları değil kategoriyi düzeltin.
Aracı yapılandırma sorunları tek bir kalite sinyalinde yoğunlaşıyorsa (örneğin, altı sinyalden beşi bilgi temellendirmeyle ilgiliyse), bu durum mimari kökenli bir soruna işaret eder.
Çapraz sinyal desenleri
Hatalar birden çok değerlendirme kümesine yayıldığında, genellikle paylaşılan bir kök nedene işaret eder. Aşağıdaki desenleri arayın:
| Desen | Büyük olasılıkla neyi gösterir? | Araştırılması gerekenler |
|---|---|---|
| Olgusal doğruluk ve bilgi zemini oluşturma her ikisi de başarısız oluyor | Bilgi kaynağı sorunu (yanlış, eksik, erişilemez veya eski) | Bilgi yapılandırması, dizin oluşturma durumu ve içerik güncelliği |
| Araç çağırma ve tetikleyici yönlendirmesi her ikisi de başarısız oluyor | Düzenleme yapılandırma sorunu; konular ve araçlar düzgün bağlanmadı | Konuların araçlara nasıl yönlendirilmiş olduğunu gözden geçirin. Bağlantısı kesilmiş veya yanlış yapılandırılmış akışları denetleyin. |
| Ton başarısız ama doğruluk yüksek | Temsilci doğru yanıtı alıyor ama kötü bir şekilde teslim ediyor | Komut stili yönergelerine odaklanın; doğruluk altyapısı sağlamdır. |
| Güvenlik başarılı, fakat doğruluk yetersiz kalıyor. | Etmen aşırı kısıtlanmış olabilir—çok ihtiyatlı davranıyor; gerektiğinde yanıt vermeyi reddediyor. | Yasal yanıtları engelleyen fazla kapsamlı kısıtlamalar için güvenlik yönergelerini gözden geçirin. |
| Uç durumlar hariç her şey geçer | Temel davranış sağlamdır | Kenar boşluklarında sağlamlığı genişletmeye odaklanın; bu desen iyiye işarettir. |
| Doğruluk iyileşiyor ama ton kötüleşiyor. | Talimat çelişkisi - Yeni doğruluk talimatları, üslup kılavuzunun yerini alabilir | Son istem değişikliklerini gözden geçirin ve "yönerge bütçesini" göz önünde bulundurun. |
| Birden fazla değerlendirme kümesi aynı anda bozuluyor | Tek bir kök nedenin, geniş çapta etkisi olması muhtemel | Son sistem istemi değişikliklerini, bilgi kaynağı güncelleştirmelerini veya platform modeli güncelleştirmelerini denetleyin. |
Çapraz sinyal desenleri ile ne yapmalı?
- Paylaşılan kök nedeni belirleme: İki sinyal birlikte başarısız olursa, büyük olasılıkla bilgi kaynağı, istem bölümü veya araç yapılandırması gibi bir bağımlılığı paylaşır.
- Paylaşılan bağımlılığı düzeltme: Her sinyali bağımsız olarak düzeltmeyin.
- Her iki değerlendirme kümesini de yeniden çalıştırın: Düzeltmeden sonra her iki kümenin de iyileştiğinden emin olun.
- Yalnızca biri iyileştirirse sinyaller aslında bir kök nedeni paylaşmaz. Kalan hataları bağımsız olarak değerlendirin ve önceliklendirin.
Yinelemeler arasında eğilim analizi
Düzeltme stratejinizin çalışıp çalışmadığını anlamak için puanların yineleme döngülerinizde nasıl değiştiğini izleyin.
| Eğilim | Yorumlama | Eylem |
|---|---|---|
| yinelemeler boyunca puanlar yükseliyor | İyileştirme çalışıyor | Eşikler karşılanıncaya kadar devam edin. |
| Değişikliklere rağmen puanlar değişmedi | Düzeltme gerçek kök nedeni hedeflemiyor | Yeniden değerlendirme; kök neden sınıflandırması yanlış olabilir. |
| Değişiklik sonrasında puanlar düşürüliyor | Regresyon— değişiklik bir şeyi kırdı | Değişikliği geri al. Neyin ve neden regresyona neden olduğunu araştırın. |
| Bir değerlendirme kümesi gelişirken, diğeri kötüleşiyor. | Ödünleşme—bir boyutu düzeltmek başka bir boyuta zarar verir | Genellikle yönerge çakışması nedeniyle oluşan eşleştirmeyi araştırın ( Bkz. Yolculuk 3). |
| Sonuçlar, testler arasında dalgalanıyor (+/- %10'dan fazla sapma) | Sınıflandırıcının kararsızlığı veya aracının belirsizliği | Öncelikle derecelendirici güvenilirliğini doğrulayın (Derecelendirici doğrulaması'na bakınız). Yineleme başına en az üç kez çalıştırın. |
Eğilim görünümü oluşturma
Her yinelemeden sonra şunları kaydedin:
- Tarih
- Değişiklik yapıldı
- Değerlendirme kümesi
- Önce puanla
- Sonraki sonuç
- Delta
Bu bilgiler size yardımcı olur.
- Eşiklere doğru yakınsamada olduğunuzu onaylayın
- Regresyonları hızla belirleme
- Platoları erken tespit edin (Yolculuk 2)
Belge hataları
Yapılandırılmış hata kayıtları, yineleme döngüleri arasında kurumsal bilgi oluşturur. Belgeler olmadan ekipler genellikle aynı araştırma çalışmalarını yineler.
Hataları belgelemeyi neden yapmalıyız?
- Gelecekteki önceliklendirmeyi hızlandır: Bilinen hata desenlerini hemen tanırsınız.
- Yönlendirme kanıtlarını oluşturun: Platform ekibine daha ikna edici argümanlar sunmak için platform sınırlamalarına ilişkin kayıtları biriktirin.
- Ekip öğrenmesini etkinleştirme: Günlük, aynı aracı üzerinde birden çok kişi çalıştığında yinelenen araştırmaların önlenmesine yardımcı olur.
- Bilinen eksiklikleri takip edin: "Düzeltilmeyecek" veya "bilinen sınırlama" olarak sınıflandırılan hataları takip etmeyi unutmayın.
Hata günlüğü şablonunu kullanma
Hataları ekip boyutuna ve süreç olgunluğuna bağlı olarak basit veya ayrıntılı bir biçimde yakalamak için hata günlüğü şablonunu kullanın.
Ne kaydedilecek?
Her bir önceliklendirilmiş arıza için en azından aşağıdaki bilgileri kaydedin:
- Hangi test çalışması başarısız oldu.
- Bunu hangi temel neden türüne göre sınıflandırdınız?
- Özellikle ne yanlış gitti .
- Ne değiştirdiniz onu düzeltmek için.
- Düzeltmenin çalışıp çalışmadığı.
Çözülmemiş hatalar için şunları da kaydedin:
- Şimdiye kadar denediğiniz şey.
- Neden hala çözülmediği.
- Yeniden değerlendirme zamanı (örneğin, "platform X güncelleştirmesinin ardından").
Sürekli iyileştirme iş akışı
Sonuçları ve sonraki adımları yakaladığınızı onaylamak için her önceliklendirme ve düzeltme döngüsünden sonra bu denetim listesini kullanın.
Yineleme sonrası denetim listesi
| Tamam mı? | Görev |
|---|---|
| ✓ | Tüm önceliklendirilmiş arızaları arıza günlüğüne kaydedin. |
| ✓ | Kök neden konsantrasyonlarını belirleyin ve not edin. |
| ✓ | Çapraz sinyal desenlerini denetleyin. |
| ✓ | Eğilim izleme için puanları kaydedin. |
| ✓ | Geçici çözümlerle bilinen sınırlamaları belgele. |
| ✓ | Kalan hatalara göre sonraki yineleme önceliklerini belirleyin. |
| ✓ | Yeniden çalıştırma zamanlamasını ayarlayın (hangi değerlendirme kümeleri, ne zaman). |
Yineleme ne zaman durdurulacak?
Şu durumlarda yinelemeyi durdurun:
- Tüm değerlendirme kümeleri eşiklerin üzerindedir.
- Bilinen boşlukları belgelediniz.
- Puanlar tutarlıdır (< 5% varyans).
- Engelleme sinyalleri için açık ajan yapılandırma sorunları yok.
Şu durumlarda yinelemeyi durdurmayın:
- Kalıcı hataları araştırmadınız.
- Eşikleri tutturmak için zor test vakalarını kaldırdınız.
- Platform sınırlamalarını belgelemediniz.
Yinelemenin ne zaman tamamlanmasını belirleme bölümünde daha fazla bilgi edinin.
Sonraki Adımlar
- Çerçeve katmanlarının gerçek dünya senaryolarında birlikte nasıl çalıştığını gösteren pratik örnekleri gözden geçirin.
- Bulgularınızı izlemek için hata günlüğü şablonunu kullanın.