Bu makalede, hatanı kurallarımıza ve standartlarımıza uygun bir şekilde nasıl düzgün bir şekilde belgeleyeceğini öğreneceksin. Müşterilerin bir hatayı anlayabilmesi için yeterli bilgiye ve kaliteli belgelere ihtiyaçları var. Bu yazının her bölümünde kurallarımızla ilgili daha detaylı bilgiler bulacaksın, ancak işte hata raporu gereksinimlerinin hızlı bir özeti:

Doğru Özelliği seçerek başlamalısın. Eğer doğru özelliği açılır listede bulamazsan, test genel bakış sayfasına geri dön ve tüm özellik açıklamalarını oku ve bunları okundu olarak işaretle. Sonra hata raporu formuna geri döndüğünde, tüm özellikler açılır listede görünecektir.

Özelliği seçtikten sonra tüm hata formu karşına çıkacak. Örneğin, işlevsel hatalar için olan bir form şöyle görünür:
​

Her alanı kalite standartlarımıza uygun, doğru ve spesifik bilgilerle doldurmalısın. Her alanın gereksinimleri hakkında daha detaylı bilgileri aşağıda bulabilirsin.

Sadece işlevsel hatalar için ek bir Ciddiyet alanı göreceksin: Düşük, Yüksek ve/veya Kritik. Ciddiyet, raporunun aciliyetini belirler ve birçok faktöre bağlıdır. Farklı şiddet seviyeleri hakkında daha fazla bilgi almak için Fonksiyonel Hatalar makalesini ziyaret edebilirsin.

Ciddiyet alanı diğer hata türleri için görüntülenmeyecektir.

Hata raporu başlığı sorunu özetlemelidir, böylece okuyucu sadece hata başlığını okuyarak hata hakkında genel bir fikir edinebilir. Sorunun ne olduğunu anlamak için raporun tamamını okumak zorunda kalmamalıdırlar. Hata raporu başlığınız kesin olmalı ve aynı zamanda çok uzun olmamalıdır. Şu bilgileri içermelidir: hata nedir, hata nerede meydana geldi ve hata ne zaman tetiklendi? Dolayısıyla, hata raporunuz için bir başlık yazarken her zaman şunu unutmayın: Ne? Nerede? Ne zaman?

Bir hata başlığı yazarken, ne olmadığını değil ne olduğunu anlatın. Başlığınız asla bir şeyin çalışmadığını belirtmemelidir, aksi takdirde okuyucu gerçekte ne olduğu hakkında hiçbir fikre sahip olmaz.

Başlık gerçek sorunu yansıtmalı. Hata sadece belirli koşullarda oluyorsa, bu koşullar başlıkta belirtilmeli. Örneğin, bir bileti rezerve edemiyorsan ve bunun nedeni genç olduğunu belirtmense, bu bilgi başlıkta yer almalı.

Açıklayıcı bir başlık bulmak için, kendinizi web sitesini/uygulamayı hiç test etmemiş, hangi sayfada olduğunuzu, neye benzediğini ve ne yaptığınızı hayal edemeyen birinin yerine koyun. Hatayı anlayıp anlamayacağınızı görmek için başlığınızı o kişinin bakış açısından okuyun. Hata hakkında iyi bir fikir edinemezseniz, hata başlığını değiştirin ve işlemi tekrarlayın.

Yanlış: "Sepet sayfasında hata"

Doğru: "Kullanıcı 'Ödeme Yap' butonuna tıkladıktan sonra Sepet sayfasında '500 Hatası' görünüyor"

Yanlış: "Kullanıcı ürünü sepete ekleyemiyor"

Doğru: "Kullanıcı beden seçip 'Sepete Ekle' butonuna tıkladığında PDP sayfasında 'Beklenmeyen Hata' mesajı alınıyor."

Yukarıdaki örneklerde yanlış olan şey: çok soyut oldukları için bu başlıkların uyacağı pek çok olası senaryo vardır. Okuyucu hangi eylemleri gerçekleştirdiğinizi ve sistemin bunlara nasıl yanıt verdiğini bilmiyor. Bu nedenle, gözden geçiren kişi hatanın ne olduğunu anlamak için tüm raporu okumak zorunda kalır ve bu hatayı diğerlerinden kolayca ayırt edemez.

Hatanın oluştuğu sayfaya git ve tarayıcının URL alanından kopyaladığın bağlantıyı hata rapor formundaki URL alanına yapıştır.

URL geçerli bir bağlantı olmalı.

Hatalar tekrar üretilebilir olmalı ve bunun için adım adım bir rehber olmalı. Her adım ayrı bir işlemi anlatmalı.

İlk adım, eğer bir web sitesi test ediyorsanız, müşterinin Erişim bölümünde sağladığı açılış sayfasının URL'sini ya da bir mobil uygulama test ediyorsanız uygulama adını içermelidir. Diğer adımlar, ilk adımdan başlayarak hatanın meydana geldiği noktaya kadar gerçekleştirdiğiniz işlemleri açıklamalıdır – hangi düğmelere bastığınız, hangi bağlantıları izlediğiniz ve ne girdiğiniz. Son adım, hatayı tetikleyen işlemi tanımlamalıdır. "Gözlemlemek" bir kullanıcı tarafından yapılan işlem değildir.

Adımlarınız olabildiğince genel olmalıdır. Sadece hatanız belirli koşullar altında meydana geliyorsa, örneğin belirli bir ürün sayfası, belirli bir filtre veya belirli bir giriş gibi, bu koşulları adımlarınızda adlandırın. Örneğin, adımlarınızda belirli bir ürün sayfasına gittiğinizi ve sepete belirli bir ürünü eklediğinizi belirtmeyin, eğer sorun herhangi bir ürün için ortaya çıkıyorsa. Bu, okuyucunun hatanızın ne olduğunu anlamasına yardımcı olacaktır ve gereksiz ayrıntılarla dikkati dağılmayacaktır.

Son olarak, adımlarınızın mümkün olan en az sayıda işlem içermesine dikkat edin. Her adımı okuduktan sonra, hatanızı yeniden üretmek isteyen kişi web sitesi veya uygulamada bu adımları eksiksiz bir şekilde tamamlayabilmelidir. Aynı adımı hatırlamak için birkaç kez kontrol etmek zorunda kalmamalıdır.

Yukarıdaki örneklerde yanlış olan şey: İlk adım açılış sayfasına erişim göstergesi içermelidir, yalnızca URL değil. Üçüncü adım yeterince ayrıntılı değil ve çok fazla işlemi tek bir adımda içeriyor. İkinci ve dördüncü adımlar gereksiz ve hatayı anlamak için gerekli değil.

Gerçek sonuç, bir hata raporunun en önemli alanlarından biridir çünkü burada sorunun ne olduğunu ve hatanın anlaşılması için gerekli tüm detayları açıklarsınız.

Adım adım rehberinizi takip ettikten sonra gerçekte ne olduğunu olabildiğince net bir şekilde açıklayın. Olabildiğince kesin olmaya çalışın ve çok genel olmaktan kaçının, örneğin "Sıralama yöntemi X uygulandıktan sonra ürünlerin çoğu aynı sırada kalıyor" demek yerine, doğru sırada olmayan belirli ürün örneklerini tanımlayın. Bu alana hatayla ilgili olan tüm bilgileri ekleyin, örneğin örnekler, ek koşullar, istisnalar veya gerekliyse diğer önemli sonuçlar. Sadece bilgilerinizi, okuyucunun düşünme sürecinizi anlamasına yardımcı olacak şekilde yapılandırdığınızdan emin olun.

Aynı şekilde, gerçek sonuç raporun başlığıyla aynı olmamalıdır. Başlık sorunun bir özetidir, gerçek sonuç ise sorunun ayrıntılı bir açıklaması olmalı ve senaryo bilgileri, örnekler ve hatanın yeniden üretim adımları sırasında elde edilen sonuçlar gibi ek detaylar içermelidir.

Yanlış: "Checkout" butonuna tıklandıktan sonra Sepet sayfasında hata gösteriliyor.

Doğru: Kullanıcı sepete bir ürün ekleyip Checkout sayfasına geçmeye çalıştığında, bunu yapamayacağını fark eder. Sağdaki menüde "Checkout" butonuna tıklandığında "Hata 500 - İç Sunucu Hatası - Üzgünüz, bir şeyler yanlış gitti" hatası gösterilir.

Yanlış: Kullanıcı sepete ürün ekleyemiyor, bir hata gösteriliyor.

Doğru: Kullanıcı "Test IO - Ürün 1" detay sayfasını açtıktan, Beden: 36'yı seçtikten ve "Sepete Ekle" butonuna tıkladıktan sonra, PDP'nin sağ üst köşesinde "Beklenmeyen Hata" hata mesajı belirir ve ürün sepete eklenmez.

Son adımı gerçekleştirdikten sonra ne olmasını beklediğinizi açıklayın. Her zaman olduğu gibi, detaylar önemlidir. Hata olmasaydı, her şey doğru çalıştığında ne olması gerektiğini düşünün.

Unutmayın, beklenen sonuç ile gerçek sonuç sadece küçük farklılıklar veya olumsuz kelimelerle aynı olmamalıdır, bunlar farklı alanlar olup son adım tamamlandığında ne olması gerektiğini açıklamak için tasarlanmıştır.

Yanlış: Kullanıcı Checkout sayfasına geçebilmelidir.

Doğru: Sepete ürün ekledikten sonra, kullanıcı "Checkout" butonuna tıkladığında, doğru bir şekilde Checkout sayfasına yönlendirilmelidir. Bu sayfada kullanıcı kargo ve ödeme bilgilerini ekleyebilmeli ve sipariş verebilmelidir.

Yanlış: Ürün sepete başarıyla eklenmelidir.

Doğru: "Test IO - Ürün 1" için Beden: 36 seçildikten ve "Sepete Ekle" butonuna tıklandıktan sonra, ürün başarıyla sepete eklenmelidir. Kullanıcı bu süreçte herhangi bir hata ile karşılaşmamalıdır.

Hatayla ilgili hangi eklerin eklenmesi gerektiğini ve hangi kuralların geçerli olduğunu öğrenmek için lütfen şu makaleyi ziyaret edin: Hata Raporu Ekleri İçin Gereksinimler.

Hata ile karşılaştığınızda hangi cihazı kullandığınızı bilmemiz ve müşterilerimizin bunu öğrenmesi önemlidir. Bir web sitesini test ederken, kullandığınız cihazın yanındaki tarayıcı simgesine tıklayın. Bir mobil uygulama test ederken, uygulamanın yüklü olduğu cihazı seçin.

Test için yalnızca bu bölümde listelenen cihazları kullanabilirsiniz. Ayrıca, hatayı raporlarken yalnızca bir cihaz veya tarayıcı seçmeli ve sadece bu cihaza ait ekleri yüklemelisiniz. Hatayı diğer cihazlarda veya tarayıcılarda da yeniden üretebiliyorsanız, bunu Gerçek Sonuç alanında belirtmelisiniz.

Hatanın oluştuğu doğru ortamı seçmek zorunludur. Raporunuzu gönderdiğinizde doğru ortamı seçtiğinizden emin olun. Yanlış ortamı yanlışlıkla seçerseniz, raporu gönderdikten sonra bunu düzeltebilirsiniz. Ortam seçiminizi, ekip lideri hata raporunu incelemeden önce değiştirebilirsiniz. Hata raporu yanlış ortamı içeriyorsa, ekip lideri hata raporu incelemesi sırasında onu reddedecektir.

Profilinizde mevcut cihazlar listesinde olmayan bir cihazla test yapmak mı istiyorsunuz? Destek sohbeti aracılığıyla bize bir istek gönderin, cihazınız müşterilerimiz için uygun olduğu sürece cihazınızı listenize ekleyelim.

Raporunuzu gönderdikten sonra, seçilen hata türü dışındaki tüm alanları düzenleyebilirsiniz. Her zaman gözden geçirilmeye hazır, eksiksiz hata raporları göndermelisiniz ve yalnızca küçük yazım hatalarını düzeltmek veya raporun kalitesini artırmak için düzenleme seçeneğini kullanmalısınız.

Hatanız yalnızca belirli bir girdiyle oluşuyorsa, hata raporu veya ekleri oluştururken gerçek kullanıcılar tarafından kullanılacak terimleri kullanın ve rastgele anahtar kelimeler girmeyin. Kötü bir örnek, müşteri arayüzünde bir hesap oluştururken "asdsdfkg_lajsdh" gibi bir kullanıcı adı kullanmaktır, çünkü bu, raporunuzu profesyonel olmayan bir şekilde gösterir.