Bugüne kadar, çok tane yazılım projesinde bulundum. Projelerin doğumunu, büyümesini, olgunlaşmasını ve hatta maalesef ölümünü gördüm…

Konumuz, proje üretime (ya da en azından teste) girdikten sonra, hata raporlama (“bug report”) olarak bilinen şey.

Neredeyse her projede, bir veya bir kaç acemi hata bildirmeye çalışan insan bulunur. Bunlardan epey bir tane eğittim. Ama eğitmekle bitecek gibi değil, hata raporlama okulda öğretilmiyor ki!

Yazıdan, “hangi sistemi kullanalım” tarzı bir bilgi çıkmayacak. Dediğim, kullanılacak hata takip sisteminden bağımsız, hatta kullanılacak sistemden daha önemli… Olabilecek en kötü çözüm olan e-posta yoluyla hata raporluyor bile olsanız, şu diyeceklerime uygun davranırsanız, işleriniz yürür.

Ana prensip şöyle:

Hata raporu, yazılımcının hatayı en hızlı ve kolay şekilde üretebilmesini sağlar.

Eğer bunu gerçekten açık ve net olarak anladıysanız, bundan sonrasını okumanıza gerek olmayabilir. Bundan sonrası, bu durumun nasıl sağlanacağıyla ilgili.

1. Konu satırı, problemi genel hatlarıyla tarif etmelidir.

E-posta da olsa, en gelişmiş hata raporlama sistemi de olsa, hepsinin bir “konu satırı” vardır. Bu, bir sürü hatanın bir arada görüldüğü ekranlarda okunacak olan kısımdır. Eğer konuya bakınca, O hangi hata olduğunu yazılımcı anlayamıyorsa, gerektiğinde hatayı bulamayacaktır.

Şu anda üzerinde çalıştığımız proje gezisitesi.com olduğundan, örneği oradan alalım. Diyelim ki, siteye girdik. Otel araması yaptık. Otel listesi geldi. Bir otel seçtik, detay sayfasına gittik. Fiyat gelecek yerde, hata mesajı çıktı…

Örnek yanlış konu satırları:

• Site çalışmıyor!!!
• Otel arama çalışmıyor!!!
• Otel satın alamıyorum.
• Fiyatlar gelmiyor!
• Otel detay sayfası bozuk.
• Sayfada hata.

Dikkat ederseniz, bunların hiç biri, hatanın ne olduğunu düzgün anlatmıyor. Doğrusu (ya da doğrulardan bir tanesi) şöyle:

Otel detay sayfasında, fiyat gösterme alanında hata mesajı veriyor.

Yukarıdaki konu satırlarından farkı, nerede ne olup bittiğini, kısa ve net bir şekilde anlatıyor.

2. Rapor içeriğinde, hatayı üretme yolu, adım adım yazılmalıdır.

Bir hata, her durumda oluşuyorsa, sorun yok. Tek adımda oluyordur bu durum. Bunun böyle olduğunu kontrol etmeden, rapor etmemeniz gerekir. Eğer birden fazla adım gerektiğini tespit ederseniz, bunun adımlarını bildirmeniz gerekir.

Mesela, yukarıdaki örnekte, hata sadece önce Facebook ile login edip, sonra (olmaz ya) Antalya otellerini arayınca oluşuyorsa, bunu net olarak yazmanız çok önemlidir. Diğer durumda, yazılımcı hatayı yeniden üretmeye çalışınca, hata çıkmayacak, o da çaresiz kalıp, “bana göre çalışıyor” (“works for me”) deyip, hatayı olduğu gibi bırakacaktır.

3. Hata mesajını, size görünen tüm ayrıntısıyla yapıştırmanız iyidir!

Bazı durumlarda, ekranda size Çince gibi görünen uzun bir hata mesajı olur. Size Çince olmasına rağmen, yazılımcı için “o kadar da Çince” değildir bunlar. Tüm içeriği hata raporunun içine yapıştırmanızın sayısız faydaları vardır.

4. Eğer hata mesajı yoksa, “screenshot” dostunuzdur.

Derdinizi net anlatamadığınızı ya da anlatmanın zor olduğunu düşünüyorsanız, bir ekran görüntüsü alıp, rapora eklemeniz, mutluluk kaynağı olacaktır. Ancak, ekran görüntüsünü kırparken dikkatli oldun. URL satırı gibi şeyler görüntüye dahil olursa faydalıdır. Öte yandan, o anda kimlerle “chat” ettiğinizi ya da o kişilere ne yazdığınızı, hatta tarayıcınızda başka hangi sitelerin açık olduğunu bilmek istemiyoruz, ya da siz bilmemizi istemiyor olabilirsiniz.

Hata Raporlama Basit Bir İş Değildir!

Hata raporlama işini küçümsemeyin. Eğer hatayı doğru şekilde, yeniden üretilebilir şekilde raporlamayı başaramazsanız, raporlamış bile olmazsınız. “Yazılımcı gitsin denesin bulsun işte yaa” diye düşünüyorsanız, büyük yanılgı içindesiniz. Çünkü, bu sizin zaten bulduğunuz ve gördüğünüz durumu, sizin düzgün iletişmeniz yerine, yazılımcının ne aradığını da tam bilmeden yeniden üretmeye çalışması anlamına gelir. Yazılımcının, bunu yapmak yerine, direkt olarak problemi çözmek için çalışmaya başlamasını siz de istersiniz, çünkü eğer hata raporluyorsanız, yazılımcı ile aynı gemidesiniz.

Hata Varsa, Yazılım Üretilmiştir! Bunu Unutmayın!

Hata olması, yazılımcıların işini yapmadığını değil, aksine yaptığını gösterir. Hata raporu yazarken bunu hatırlayın. %99 doğru bir yazılım, maalesef çok basit bir hata yüzünden kullanılmaz halde olabilir. Hata rapor ederken, objektif olun. Ajitasyon cümleleri kullanmayın. Mesela “bunun yüzünden sistem çalışmıyor”  ya da “bunun yüzünden satışlar göçtü” falan demeyin. İnanmazsınız ama, yazılımcı, doğru yazılmış bir hata raporunu okurken, bunları sizden daha iyi biliyor ve algılıyordur zaten!

Önceliklendirmeyi Öğrenin!

Önceliklendirme sisteminiz yoksa, edinin. Önceliklendirmede, yüksek öncelikleri idareli kullanın. Her şeye acil demeyin. Hemen her zaman gereksiz olan, ünlem, yıldız, büyük harf falan kullanmayın…

Bundan ötesi için bir yazı dizisi gerek. Bugünlük ders bitmiştir, dağılabilirsiniz.