Hata Yönetimi: Yaşam Döngüsü, Error / Defect / Failure Ayrımı ve TDD ile BDD Yaklaşımları

i Hata Yönetimi Nedir?

Hata yönetimi (Defect Management), bir yazılım ürününde tespit edilen hataların kaydedilmesinden, sınıflandırılmasından, öncelik/önem derecesinin belirlenmesinden, çözülmesinden ve doğrulanmasından sorumlu olan sistematik süreçtir. Amaç yalnızca hatayı “kapatmak” değil; hatanın kök nedenini anlamak, tekrarını önlemek ve yazılım kalitesini sürekli iyileştirmektir.

Bu sürecin sağlıklı işleyebilmesi için önce temel bir ayrımı netleştirmek gerekir: bir insan hatasının (error), kod içindeki kusurdan (defect) ve kullanıcının gözlemlediği arızadan (failure) farklı olduğunu bilmek. Ayrıca hataların doğumundan kapatılmasına kadar geçtiği standart bir yaşam döngüsünü anlamak gerekir. Aşağıdaki bölümlerde bu iki temel konuyu, ardından hataları en baştan azaltmayı hedefleyen TDD ve BDD yaklaşımlarını detaylı olarak ele alıyoruz.

1 Hata Yaşam Döngüsü (Bug / Defect Life Cycle)

Bir hata, test sürecinde tespit edildiği andan itibaren belirli durumlardan (status) geçerek kapanışa ulaşır. Bu döngü, ekipten ekibe küçük farklılıklar gösterse de genel akış aşağıdaki gibidir:

Yaşam Döngüsündeki Rollerin Özeti

2 Error / Defect / Failure Ayrımı

Yazılım testinde en sık karıştırılan üç terim Error, Defect (Bug) ve Failure‘dır. Bunlar aslında aynı sorunun farklı aşamalardaki halleridir:

3 Test Driven Development (TDD)

Test Güdümlü Geliştirme (TDD), kodu yazmadan önce o kodun testini yazma prensibine dayanan bir yazılım geliştirme yaklaşımıdır. Amaç, hataları en erken aşamada, kod daha yazılmadan önce tanımlanan beklentilerle sınırlandırmaktır. TDD, ünlü “Kırmızı – Yeşil – Refactor” döngüsü ile çalışır.

1. Red: Henüz yazılmamış bir fonksiyonalite için önce başarısız olacak bir test yazılır.
2. Green: Testi geçirecek en basit/minimum kod yazılır — mükemmellik hedeflenmez, sadece testin geçmesi önemlidir.
3. Refactor: Test yeşil kalırken kod kalitesi, okunabilirliği ve performansı iyileştirilir.

Basit TDD Örneği (Python — pytest)

# 1. ADIM - RED: Önce test yazılır (henüz "hesapla_indirim" fonksiyonu yok)
def test_hesapla_indirim():
    assert hesapla_indirim(100, 10) == 90

# 2. ADIM - GREEN: Testi geçirecek minimum kod yazılır
def hesapla_indirim(tutar, yuzde):
    return tutar - (tutar * yuzde / 100)

# 3. ADIM - REFACTOR: Kod iyileştirilir, testler yeşil kalmaya devam eder
def hesapla_indirim(tutar: float, yuzde: float) -> float:
    if not (0 <= yuzde <= 100):
        raise ValueError("Yüzde 0-100 aralığında olmalıdır")
    return round(tutar * (1 - yuzde / 100), 2)

4 Behavior Driven Development (BDD)

Davranış Güdümlü Geliştirme (BDD), TDD’nin bir uzantısı olarak doğmuştur. Farkı, testlerin/senaryoların teknik dilde değil, iş birimi (business), test mühendisi ve geliştiricinin ortak anlayabileceği doğal dile yakın bir dilde (genellikle Gherkin sözdizimi ile Given – When – Then yapısında) yazılmasıdır. Böylece gereksinimler doğrudan çalıştırılabilir test senaryolarına dönüşür.

Gherkin Sözdizimi ile Örnek Senaryo

Özellik: Sepette İndirim Uygulama

  Senaryo: Geçerli kupon kodu ile indirim uygulanması
    Given kullanıcının sepetinde 100 TL tutarında ürün var
    And "INDIRIM10" adında geçerli bir kupon kodu mevcut
    When kullanıcı kupon kodunu sepete uygular
    Then sepet toplamı 90 TL olarak güncellenmelidir
    And ekranda "Kupon başarıyla uygulandı" mesajı gösterilmelidir

Bu senaryo, otomasyon araçlarıyla (örn. Cucumber, SpecFlow, Behave) doğrudan kod adımlarına bağlanıp çalıştırılabilir hale getirilir:

# step_definitions.py (Python + behave)
from behave import given, when, then

@given('kullanıcının sepetinde {tutar} TL tutarında ürün var')
def step_sepet_olustur(context, tutar):
    context.sepet = Sepet(tutar=float(tutar))

@when('kullanıcı kupon kodunu sepete uygular')
def step_kupon_uygula(context):
    context.sepet.kupon_uygula("INDIRIM10")

@then('sepet toplamı {beklenen} TL olarak güncellenmelidir')
def step_toplam_kontrol(context, beklenen):
    assert context.sepet.toplam == float(beklenen)

5 TDD ve BDD Karşılaştırması

TDD ve BDD birbirini dışlayan değil, birbirini tamamlayan yaklaşımlardır. Pratikte pek çok ekip her ikisini bir arada kullanır: BDD ile üst seviye kabul kriterleri, TDD ile birim (unit) seviyesinde teknik detaylar doğrulanır.

✓ Sonuç ve Öneriler

Etkili bir hata yönetimi stratejisi, sadece hataları kaydetmekle kalmaz; onların nereden geldiğini (Error), nasıl koda yansıdığını (Defect) ve nasıl gözlemlendiğini (Failure) anlayarak kök nedene inmeyi hedefler. Bunun yanında hataların standart bir yaşam döngüsü içinde izlenmesi, ekipler arası şeffaflığı ve hesap verebilirliği artırır.

En güçlü strateji ise hatayı bulmak değil, en baştan önlemektir. Bu noktada TDD geliştiricilere kod seviyesinde erken geri bildirim sağlarken, BDD iş birimi ile teknik ekip arasındaki anlaşma farklılıklarından (Error’ın en yaygın kaynağı) doğan hataları en başından engeller. İkisinin birlikte kullanılması, hem teknik olarak sağlam hem de iş ihtiyaçlarını doğru karşılayan yazılımlar üretmenin en etkili yollarından biridir.