Bug Nedir? Yazılım Hatalarını Anlama ve Ayıklama Rehberi

Beklenen davranış ile gerçek sonuç arasındaki fark bug'ı nasıl tanımlar?

Bug, bir bilgisayar programının veya donanımın tasarımcıları tarafından beklenen şekilde çalışmasını engelleyen kusur, hata ya da arıza olarak tanımlanır. Yazılım açısından ölçüt, programın çalışıp çalışmamasından çok, belirlenen davranışla gerçekleşen davranışın uyuşup uyuşmadığıdır.

Örneğin bir uygulamanın görevi kullanıcı tarafından girilen bilgiyi kaydetmekse, uygulamanın kapanmadan açılması tek başına yeterli değildir. Bilgi yanlış kaydediliyor, eksik kaydediliyor veya işlem tamamlandı mesajına rağmen veri görünmüyorsa beklenen sonuçla gerçek sonuç arasında fark vardır. Bu fark bug belirtisidir.

Bir bug şu biçimlerde ortaya çıkabilir:

• Program hiç açılmayabilir veya işlem sırasında kapanabilir.
• Program çalışmaya devam ederken yanlış sonuç üretebilir.
• Yalnızca belirli bir işletim sistemi, cihaz, veri biçimi veya kullanım sırası altında hata verebilir.
• İşlev tamamen bozulmasa da yavaşlama, donma veya gereksiz kaynak kullanımı oluşturabilir.
• Görsel bir öğe yanlış yerde görünebilir ya da oyun içindeki bir nesne beklenmeyen biçimde davranabilir.

Burada önemli ayrım şudur: Kullanıcının hoşlanmadığı her özellik bug değildir. Bir davranış tasarımda özellikle seçilmişse, kullanıcı bunu gereksiz bulsa bile teknik anlamda hata olmayabilir. Bug diyebilmek için tasarlanan veya beklenen davranışla gerçekleşen davranış arasında temellendirilebilir bir uyumsuzluk bulunmalıdır.

Sözdizimi hatası, mantık kusuru ve tasarım yanlışı nasıl ayrılır?

Bug'ların kaynağı aynı değildir. Bu ayrım, hatayı bulma yöntemini ve düzeltmenin kapsamını anlamayı kolaylaştırır.

Sözdizimi kaynaklı hatalar: Programlama dilinin yazım kurallarına uymayan kod parçalarıdır. Eksik bir işaret, yanlış yazılmış bir komut veya dilin kabul etmediği bir kullanım programın derlenmesini ya da çalıştırılmasını engelleyebilir. Bu tür hatalarda sistem çoğunlukla sorunun bulunduğu satıra ilişkin bir uyarı verir; ancak uyarının gösterdiği yer, hatanın düşünsel kaynağıyla aynı olmayabilir.

Mantık hataları: Kod teknik olarak çalışır, fakat yanlış işlemi yapar. Örneğin bir döngünün bitmesi gereken koşul yanlış kurulmuşsa program sonsuz döngüye girebilir. Sıfıra bölme girişimi de belirli çalışma koşullarında hata oluşmasına neden olabilir. Mantık hatası, sonuç üretildiği için sözdizimi hatasından daha zor fark edilebilir.

Tasarım veya mimari hataları: Sorun tek bir satırın yazımından değil, bileşenlerin nasıl planlandığından kaynaklanır. Bir modülün diğer modülden beklediği veri biçimi baştan yanlış belirlenmişse, sonradan yapılan küçük kod değişiklikleri sorunu tamamen çözmeyebilir.

Uyumluluk hataları: Yazılımın farklı işletim sistemi, donanım veya başka yazılımlarla etkileşiminde görülebilir. Bir uygulamanın eski bir işletim sistemi sürümünde çalışıp yeni bir sürümde beklenmedik davranması bu gruba örnek olabilir. Burada yalnızca uygulama kodu değil, uygulamanın çalıştığı çevre de incelenmelidir.

Eksik testten kalan hatalar: Bir işlev yalnızca normal koşullarda denenmiş, sınır veya beklenmeyen girişler test edilmemiş olabilir. Böyle bir bug, geliştiricinin bilgisayarında görülmeyip son kullanıcıda ortaya çıkabilir. Bu nedenle 'benim cihazımda çalışıyor' ifadesi tek başına yazılımın hatasız olduğunu göstermez.

Bir bug'ın etkisi nasıl değerlendirilir?

Bug'ın önemini yalnızca ne kadar sık görüldüğüne bakarak belirlemek doğru değildir. Etkiyi değerlendirirken en az üç soru sorulmalıdır: Hangi işlev bozuluyor, kaç kullanıcı veya işlem etkileniyor ve veri ya da güvenlik açısından sonuç ne kadar ciddi?

Küçük bir görsel hizalama sorunu kullanıcı deneyimini azaltabilir; fakat işlem yapılmasını engellemeyebilir. Buna karşılık bir bankacılık uygulamasında işlemin tamamlanmaması, yanlış görünmesi veya işlem geçmişinin eksik gösterilmesi daha ciddi bir güven ve veri sorunu oluşturabilir. Kaynak metinde de bug'ların kullanıcı deneyimi, güven, veri kaybı, güvenlik, maliyet ve performans üzerinde etkili olabileceği belirtilmektedir.

Etkileri şu başlıklarda düşünmek yararlıdır:

• İşlev kaybı: Kullanıcı bir işlemi tamamlayamıyorsa bug doğrudan iş akışını keser.
• Yanlış sonuç: Program çalışıyor görünse de hatalı bilgi üretiyorsa kararlar yanlış verilebilir.
• Veri kaybı: Girilen veya daha önce kaydedilen bilgiler görünmez hale gelebilir. Bu riski azaltmak için önemli verilerin düzenli yedeklenmesi gerekir.
• Güvenlik riski: Bir kusur, kötü niyetli kişilerin sisteme veya verilere erişmesine imkân tanıyabilir. Ancak bir bug'ın güvenlik açığı olup olmadığı ayrıca teknik inceleme gerektirir; her hata güvenlik açığı değildir.
• Performans etkisi: Program yavaşlayabilir, sistem kaynaklarını gereksiz kullanabilir veya mobil cihazlarda pil tüketimini artırabilir.
• Maddi ve zamansal kayıp: Sorunun bulunması, düzeltilmesi ve kullanıcılara yeni bir güncelleme sunulması kaynak gerektirir.

Bu değerlendirme, 'bug var mı?' sorusunu 'önemsiz mi, tehlikeli mi?' sorusundan ayırır. Etkiyi anlayabilmek için sorunun tekrarlanma koşulları ve ortaya çıkardığı sonuç birlikte kaydedilmelidir.

Kullanıcıdan geliştiriciye: Bug raporu nasıl hazırlanır?

Bir hatanın düzeltilmesi, çoğu zaman hatanın ne kadar açık tarif edildiğine bağlıdır. 'Uygulama bozuk' ifadesi geliştiriciye yeterli bilgi vermez. İyi bir bug raporu, sorunu yeniden üretmeye yardımcı olacak somut ayrıntılar içermelidir.

Adım adım raporlama yaklaşımı şöyledir:

1. Beklenen sonucu yazın: İşlem doğru çalışsaydı ne olması gerekiyordu?
2. Gerçek sonucu yazın: Bunun yerine ne oldu? Uygulama kapandı mı, yanlış değer mi gösterdi, işlem mi kayboldu?
3. Adımları sıralayın: Soruna ulaşmak için hangi düğmelere, hangi sırayla basıldı?
4. Koşulları belirtin: Hata hangi cihazda, işletim sistemi sürümünde, uygulama sürümünde veya ağ koşulunda görüldü?
5. Tekrarlanabilirliği kontrol edin: Aynı adımlar tekrarlandığında sorun yeniden oluşuyor mu? Her denemede görülmüyorsa bu da rapora yazılmalıdır.
6. Kanıt ekleyin: Uygunsa hata mesajı, ekran görüntüsü veya işlem zamanı paylaşılabilir; ancak kişisel ve finansal bilgiler rapora eklenmemelidir.

Örneğin 'ödeme çalışmıyor' yerine 'Ürün sepete eklendi, ödeme ekranında kart bilgileri girildi ve onay düğmesine basıldı; işlem tamamlandı mesajı görünmesine rağmen siparişlerim bölümünde kayıt oluşmadı' ifadesi daha değerlidir. Bu açıklama, geliştiricinin hangi adımda beklenen durumdan sapma olduğunu araştırmasına yardım eder.

Sorun bulut tabanlı bir hizmette yaşanıyorsa, istemci uygulaması ile sunucu arasındaki iletişim veya veri eşitlemesi de araştırılabilir. Bu tür durumlarda sorunun cihazda mı, ağda mı, yoksa hizmetin sunucu tarafında mı oluştuğu ayrıştırılmalıdır. Bulut kavramı bu ayrımı anlamak için ilgili bir başlıktır.

Debug sürecinde kök nedene ulaşmak neden tek düzeltmeden fazlasıdır?

Bug'ı bulma ve düzeltme sürecine debug denir. Debug, yalnızca hatalı görünen satırı değiştirmek anlamına gelmez; sorunun hangi koşulda oluştuğunu belirlemek, kök nedeni izole etmek ve düzeltmenin işe yaradığını doğrulamak gerekir. Ayrıntılı bağlantı için debug nedir yazısına bakılabilir.

Pratik bir debug akışı şu şekilde kurulabilir:

1. Sorunu yeniden üretin: Hata her çalışmada mı, yoksa belirli girişlerde mi ortaya çıkıyor?
2. Beklenen ve gerçek çıktıyı karşılaştırın: Farkı ölçülebilir biçimde tanımlayın.
3. Kapsamı daraltın: Hatanın hangi modül, işlem veya veriyle ilişkili olduğunu ayırın.
4. Varsayımları kontrol edin: Değişkenin beklenen değeri taşıyıp taşımadığı, girişin geçerli olup olmadığı ve bileşenlerin aynı veri biçimini kullanıp kullanmadığı incelenir.
5. Düzeltmeyi uygulayın: Değişiklik, yalnızca belirtiyi gizlemek yerine mümkünse kök nedeni hedeflemelidir.
6. Tekrar test edin: İlk hata senaryosu yeniden denenir; ayrıca değişikliğin başka işlevleri bozup bozmadığı kontrol edilir.

Programlama dilleri, bilgisayarın yürüttüğü talimatlara dönüşür; bu talimatların sonunda ikili kod biçiminde işlenmesi, insanın yazdığı kod ile makinenin uyguladığı işlemler arasında bir katman bulunduğunu gösterir. Bununla birlikte ikili kodun varlığı, her bug'ın doğrudan ikili koddan kaynaklandığı anlamına gelmez. Hata; gereksinim, tasarım, kaynak kod, veri veya çalışma ortamının farklı katmanlarında bulunabilir.

Bir düzeltme kullanıcılara çoğunlukla güncelleme, yama veya yeni bir sürüm olarak ulaştırılır. Bu nedenle kullanıcı açısından 'güncelleme geldi' bilgisi, belirli hataların giderilmiş olabileceğini gösterir; fakat her güncellemenin tüm bug'ları çözdüğü sonucu çıkarılamaz.

Çözümlü örnekler: beklenmeyen sonucu adım adım ayırmak

Örnek 1: Bir döngünün sonlanmaması

Verilenler: Bir programın belirli bir işlemi birkaç kez tekrarlaması bekleniyor. Ancak uygulama donuyor ve işlem tamamlanmıyor. Kaynak metindeki örneğe göre olası nedenlerden biri, döngünün bitiş koşulunun yanlış kurulmasıdır.

Çözüm adımları:

1. Beklenen davranış belirlenir: Döngü, koşul artık sağlanmadığında durmalıdır.
2. Gerçek davranış gözlenir: Program durmadığı için koşulun hiç yanlış hale gelmediği düşünülür.
3. Döngü koşulu ve koşulu değiştiren değişken birlikte incelenir. Değişkenin her adımda beklenen yönde değişip değişmediği kontrol edilir.
4. Koşulun sınır değerde ne yaptığı test edilir. Örneğin sayaç artması gerekirken değişmiyorsa, program aynı durumu tekrar tekrar işler.
5. Düzeltmeden sonra aynı girişle test yapılır; ardından döngünün bir kez, birkaç kez ve sınır durumda çalışması denenir.

Sonuç: Programın donması tek başına 'bilgisayar yavaş' anlamına gelmez. Döngünün durma koşulu veya bu koşulu etkileyen değişken incelenerek mantık bug'ının kaynağı aranır.

Örnek 2: Kaydedildiği söylenen verinin görünmemesi

Verilenler: Bir kullanıcı bir uygulamada işlem yapıyor. Uygulama kapanmıyor ve tamamlandı mesajı gösteriyor; ancak uygulama yeniden açıldığında işlem geçmişinde kayıt görünmüyor.

Çözüm adımları:

1. Beklenen sonuç yazılır: İşlem tamamlandıktan sonra kayıt, işlem geçmişinde görünmelidir.
2. Gerçek sonuç yazılır: Tamamlandı mesajı vardır, fakat kayıt listede yoktur.
3. Sorunun yalnızca görüntüleme katmanında mı, yoksa kayıt işleminde mi olduğu ayrıştırılır. Aynı kayıt başka bir ekranda veya cihazda görünüyorsa listeleme ya da eşitleme sorunu düşünülebilir.
4. Uygulamanın sürümü, bağlantı durumu ve işlemin gerçekleştiği zaman not edilir. Farklı bir sürüm veya ağ koşulunda sonuç değişiyor mu kontrol edilir.
5. Kullanıcı, işlemin gerçekten tamamlandığını varsayarak aynı işlemi art arda tekrarlamamalıdır. Özellikle finansal işlemlerde destek kaydı ve işlem bilgileri korunmalıdır.
6. Geliştirici tarafında kayıt isteğinin gönderilip gönderilmediği, sunucudan yanıt alınıp alınmadığı ve uygulamanın veriyi doğru eşitleyip eşitlemediği incelenir.

Sonuç: Bu senaryoda tek bir neden kesin olarak seçilemez. İstemci arayüzü, veri kaydı, sunucu iletişimi veya eşitleme katmanlarından biri sorunun kaynağı olabilir. İyi rapor, bu olasılıkları birbirinden ayıracak verileri sağlar.