Hata Günlüğü

Bir cümlelik özet

Hata günlüğü, projede bulduğun her hatayı tarihi, belirtisi, nedeni, çözümü ve durumuyla birlikte kayıt altına aldığın bir tablodur; böylece hiçbir hatayı unutmaz ve her hatadan bir şey öğrenirsin.

Neden önemli?

Test senaryolarını çalıştırdığında er geç bir hatayla karşılaşırsın. İlk anda “Tamam, bunu aklımda tutarım” dersin. Ama yarım saat sonra üç hata daha bulursun ve ilkini unutursun. Sonra sunum gününe gelirsin, aynı hata tekrar çıkar ve “Bunu daha önce çözmüştüm galiba?” diye düşünürsün.

Hata günlüğü tam da bunu engeller. Aklına güvenmek yerine bir kayda güvenirsin. Bu kaydın üç faydası var:

• Unutmazsın. Bulunan her hata yazılı olduğu için hiçbiri kaybolmaz.
• Öğrenirsin. Aynı türden hataları yan yana görünce bir örüntü fark edersin. “Bağlantı hatalarımın çoğu gevşek kabloymuş” gibi.
• Gösterebilirsin. Bir yetişkine ya da takım arkadaşına “Şu ana kadar neler oldu?” sorusuna tek bir tabloyla cevap verirsin.

Profesyonel yazılım ve mühendislik ekipleri de aynısını yapar. Onlar buna “hata takip sistemi” (bug tracker) der. Senin yapacağın şey de küçük ölçekte tam olarak budur.

Hata günlüğünde ne bulunur?

Hata Ayıklama dersinde bir hatayı *bulup düzeltmeyi* öğrenmiştik. Hata günlüğü ise o işi *kayıt altına almanı* sağlar. İkisi birlikte çalışır: önce hatayı ayıklarsın, sonra ne yaptığını günlüğe yazarsın.

İyi bir hata günlüğünde her satır bir hatayı anlatır ve şu bilgileri içerir:

Kimlik ve tarih

Her hataya küçük bir numara ver (H1, H2, H3…) ve bulduğun tarihi yaz. Numara sayesinde hatalar hakkında konuşmak kolaylaşır: “H2 hâlâ açık mı?” demek, uzun uzun anlatmaktan hızlıdır.

Belirti

Belirti, senin gözlemlediğin şeydir; yani neyin yanlış göründüğüdür. Burada henüz nedeni tahmin etmeye çalışma, sadece gerçekte ne olduğunu yaz. “Gece lambası karanlıkta yanmıyor” bir belirtidir. “Sensör bozuk” değildir, çünkü bunu henüz bilmiyorsun.

Neden

Neden, hatayı araştırdıktan sonra bulduğun asıl kaynaktır. Bunu genellikle hemen yazamazsın; önce hata ayıklama yaparsın, sonra doldurursun. “Işık eşiği çok düşük ayarlanmış” bir nedendir.

Çözüm

Nedeni bulunca ne yaptığını yaz. “Eşik değerini 300’den 600’e çıkardım” gibi somut ol. “Düzelttim” yazmak yeterli değildir; ileride aynı hata çıkarsa ne yaptığını hatırlaman gerekir.

Durum

Her hatanın bir durumu vardır. Üç basit durum yeter:

• Açık: Hata var, henüz çözülmedi.
• Çözülüyor: Üzerinde çalışıyorsun.
• Kapalı: Çözüldü ve test senaryosuyla doğrulandı.

Bir hatayı ancak tekrar test edip düzeldiğini gördükten sonra “Kapalı” yaparsın. Test etmeden kapatmak, en sık yapılan yanlışlardan biridir.

Örnek: Otomatik gece lambası günlüğü

Önceki modüllerden hatırladığın otomatik gece lambası projesini düşünelim: karanlık olunca LED yanacak, aydınlık olunca sönecek. Test senaryolarını çalıştırdın ve bazı hatalar buldun. İşte günlüğün şöyle görünebilir:

Bu tablo sana çok şey anlatır. H1 ve H2 kapandı, yani proje ilerliyor. H3 açık ve nedeni henüz bilinmiyor; sıradaki hata ayıklama işin bu. H4 üzerinde çalışıyorsun ama emin değilsin, o yüzden “Deneniyor” yazdın ve durumu “Çözülüyor” bıraktın.

Dikkat et: H3’ün nedeni ve çözümü boş. Bu tamamen normaldir. Günlük eksiksiz doğmaz; sen hata ayıkladıkça satırlar dolar.

İkinci örnek: Çizgi izleyen robot günlüğü

Aynı yöntem donanımı daha karmaşık bir projede de işe yarar. Çizgi izleyen robotunu test ederken karşılaşabileceğin hatalar:

R2’ye bak: belirti “geri geri gidiyor”, neden ise “kablolar ters”. Belirti ile nedeni ayrı yazdığın için, ileride başka bir robotta aynı belirtiyi görürsen ilk bakacağın yeri bilirsin. İşte günlüğün öğreten yanı budur.

Mini uygulama

Kendi projelerinden birini (ya da hayalindeki bir projeyi) seç ve boş bir hata günlüğü şablonu hazırla. Aşağıdaki şablonu kopyalayabilirsin:

PROJE: ____________________
BAŞLANGIÇ TARİHİ: __________

No | Tarih | Belirti | Neden | Çözüm | Durum
---|-------|---------|-------|-------|------
H1 |       |         |       |       | Açık
H2 |       |         |       |       | Açık
H3 |       |         |       |       | Açık

DURUM SEÇENEKLERİ: Açık / Çözülüyor / Kapalı
KURAL: Bir hatayı ancak yeniden test edip düzeldiğini görünce "Kapalı" yap.

Sonra şunu dene: bir sonraki testinde bulduğun ilk hatayı bu tabloya işle. Sadece belirtiyi yaz, nedeni ve çözümü boş bırak. Hata ayıkladıkça diğer sütunları doldur. Böylece günlüğün canlı bir kayda dönüşür.

Uygulama laboratuvarı: Hata Günlüğü

Hata Günlüğü konusunu kalıcı hâle getirmenin en iyi yolu, kavramı küçük ve ölçülebilir bir göreve dönüştürmektir. Bu çalışmada Hata günlüğünde ne bulunur? ile Belirti arasındaki ilişkiyi kullanarak sorun tanımı, gereksinim listesi, prototip, test kaydı ve kısa sunum hazırlayacaksın. Amaç yalnız sonucun çalışması değil; hangi kararı neden verdiğini, neyi test ettiğini ve hangi durumda tasarımı değiştireceğini açıklayabilmektir.

Görev senaryosu

Şu senaryoyu ele al: evde enerji veya su kullanımını görünür kılan basit sistem. Dersin ana hedefi “Bulduğun hataları tarih, belirti, neden ve çözümüyle kaydedip düzenli takip etmeyi öğren” olduğuna göre önce problemi tek cümleyle tanımla. Ardından sistemin alacağı girdiyi, uygulayacağı işlemi ve üreteceği çıktıyı ayrı ayrı yaz. Bilmediğin bir ayrıntı varsa onu varsayım olarak işaretle; varsayımı gerçek bilgi gibi kullanma.

1. Planla: Başlangıç durumunu, beklenen sonucu ve kullanacağın kavramları yaz.
2. En küçük sürümü kur: Yalnız temel davranışı çalıştır; süsleme ve ek özellikleri sonraya bırak.
3. Üç test hazırla: Normal bir durum, sınırda bir durum ve hatalı ya da beklenmeyen bir durum seç.
4. Sonucu kaydet: Beklenen ile gerçekleşeni yan yana yaz; fark varsa olası nedeni belirt.
5. Tek değişiklik yap: Aynı anda birçok şeyi değiştirmek yerine bir kararı düzeltip testi yeniden çalıştır.

Başarı ölçütleri

• Sorun ve kullanıcı tek cümlede tanımlı mı?
• Gereksinimler ölçülebilir mi?
• Prototip en riskli varsayımı gerçekten deniyor mu?
• Test sonucu tarih ve koşulla kaydedildi mi?
• Sunumda çalışmayan noktalar da dürüstçe açıklanıyor mu?

“Hata Günlüğü” çalışmasını bitirdiğinde ürünü bir arkadaşına yalnız bölüm başlıklarıyla anlat. Arkadaşın evde enerji veya su kullanımını görünür kılan basit sistem senaryosundaki adımları ve karar nedenlerini takip edebiliyorsa anlatım yeterince açıktır. Anlaşılmayan noktayı daha fazla terim ekleyerek değil, Hata günlüğünde ne bulunur? ve Belirti ilişkisini daha küçük adımlara bölerek düzelt.

Sık yapılan hatalar

Belirti ile nedeni karıştırmak

“Sensör bozuk” diye yazarsan bu bir tahmindir, gözlem değildir. Belki sensör sağlamdır ve sorun kablodadır. Önce gerçekte ne gördüğünü (belirti) yaz, nedeni araştırdıktan sonra ekle.

Çözümü belirsiz yazmak

“Düzelttim” yazmak işe yaramaz. Üç ay sonra aynı hata çıkarsa bu not sana hiçbir şey söylemez. “Eşiği 600 yaptım” gibi somut yaz.

Test etmeden kapatmak

Bir düzeltme yaptın diye hata çözülmüş sayılmaz. Yeniden test senaryosunu çalıştırıp düzeldiğini görmeden durumu “Kapalı” yapma.

Küçük hataları yazmaya üşenmek

“Bu çok küçük, yazmaya değmez” dersin ve o küçük hata sunum günü karşına çıkar. Küçük ya da büyük, her hatayı kaydet.

Günlüğü sonradan doldurmaya çalışmak

Hafızan hatanın yarısını unutur. Hatayı bulduğun an, en azından belirti sütununu doldur.

Güvenlik notu

Hata günlüğün genellikle sadece seni ilgilendiren teknik bir kayıttır. Yine de bu günlüğü bir başkasıyla (öğretmen, takım arkadaşı) paylaşırken ya da sunumda gösterirken içine kişisel bilgi yazmadığından emin ol: tam adın, ev adresin, okul adın ya da başkalarının bilgileri günlükte yer almamalı. Hata notların projeyle ilgili olsun, seninle ilgili değil. Ayrıca donanım hatalarını araştırırken sıcak yüzey, pil ve motor gibi parçalara dokunmadan önce bir yetişkinden yardım iste.

Ders özeti

• Hata günlüğü, bulunan her hatayı tarih, belirti, neden, çözüm ve durumla kaydeden bir tablodur.
• Belirti gözlemlediğin şeydir; neden ise araştırma sonucu bulduğun asıl kaynaktır — ikisini karıştırma.
• Her hatanın durumu vardır: Açık, Çözülüyor veya Kapalı.
• Bir hatayı ancak yeniden test edip düzeldiğini gördükten sonra kapatırsın.
• Günlük, hataları unutmamanı sağlar ve zamanla örüntüleri görüp öğrenmeni kolaylaştırır.

Kontrol soruları

1. Bir hata günlüğünde her satırda bulunması gereken beş bilgi nedir?
2. “Belirti” ile “neden” arasındaki fark nedir? Birer örnek ver.
3. Bir hatayı ne zaman “Kapalı” durumuna alabilirsin?
4. Çözüm sütununa “düzelttim” yazmak neden yeterli değildir?
5. Yeni bulunan bir hatanın neden ve çözüm sütunlarının boş olması bir sorun mudur? Neden?

Cevaplar

1. Kimlik/numara ve tarih, belirti, neden, çözüm ve durum. (Numara ve tarihi tek bilgi sayarsan: tarih, belirti, neden, çözüm, durum.)
2. Belirti, gözlemlediğin yanlış görünen şeydir (“Karanlıkta LED yanmıyor”). Neden, araştırınca bulduğun asıl kaynaktır (“Işık eşiği çok düşük ayarlanmış”). Belirti gözlem, neden ise açıklamadır.
3. Ancak bir düzeltme yaptıktan sonra ilgili test senaryosunu yeniden çalıştırıp hatanın gerçekten kaybolduğunu gördüğünde.
4. Çünkü ileride aynı hata çıkarsa “düzelttim” notu sana ne yaptığını hatırlatmaz. Somut çözüm (“eşiği 600 yaptım”) hem tekrar işine yarar hem de başkasına açıklanabilir.
5. Sorun değildir. Günlük hata ayıkladıkça dolar. Yeni bir hatada önce sadece belirtiyi yazarsın; nedeni ve çözümü araştırma bitince eklersin.

Kaynak ve doğrulama notu

“Hata Günlüğü” dersi için doğrulama odağı Hata günlüğünde ne bulunur? ile Belirti arasındaki ilişkinin örnekler üzerinde tutarlı çalışmasıdır. Proje sayfalarında sonuç iddiası ancak gerçek prototip, test kaydı veya gözlemle desteklendiğinde kullanılmalıdır. Maliyet, süre ve başarı oranı gibi sayılar tahminse açıkça “tahmin” olarak işaretlenmelidir.

Sonraki ders

İyileştirme: Hataları kapattıktan sonra projeyi sadece “çalışır” olmaktan “daha iyi” hale getirmek için hangi adımları izlersin?