TDD ve BDD Nedir? Aralarındaki Farklar ve QA Dünyasındaki Rolleri

Yazılım test süreçlerinde kaliteyi artırmak ve hataları daha kod yazılmadan yakalamak için kullanılan en popüler iki metodoloji TDD (Test-Driven Development) ve BDD (Behavior-Driven Development) yaklaşımlarıdır. Test dünyasında sıkça karşılaştırılan ve bazen birbirinin alternatifi gibi görülen bu iki kavram, aslında projenin farklı kaslarını güçlendirir.

Bu yazıda, TDD ve BDD’nin ne olduğunu, aralarındaki farkları ve bir test mühendisi olarak bu süreçlerin neresinde yer almamız gerektiğini inceleyeceğiz.

1. Test Odaklı Geliştirme (TDD) Nedir?

TDD, yazılım geliştirme sürecinde kodun testten sonra yazılmasını savunan teknik bir yaklaşımdır. Geliştirilecek olan özelliğin kodunu yazmadan önce o kodun nasıl çalışması gerektiğini belirleyen küçük bir birim test (Unit Test) yazar. TDD süreci, literatürde "Red-Green-Refactor" döngüsü olarak bilinen şu adımlarla işler:

1. Red (Kırmızı): Yapılacak işlev için bir test yazılır. Kod henüz var olmadığı için bu test doğal olarak başarısız olur (kırmızı hata verir).

2. Green (Yeşil): Testi geçirecek kadar, yani sadece işi görecek minimum kod yazılır ve testin başarıyla geçmesi (yeşil yanması) sağlanır.

3. Refactoring (Temizleme): Kodun işlevselliği bozulmadan mimarisi temizlenir, optimize edilir ve yinelenen kodlar ortadan kaldırılır.

Odak Noktası: TDD tamamen "Kod teknik olarak doğru ve hatasız yazıldı mı?" sorusuna cevap arar.

2. Davranış Odaklı Geliştirme (BDD) Nedir?

BDD, TDD'nin teknik sınırlarını aşarak sürece iş gereksinimlerini ve kullanıcı davranışlarını dahil eden bir yaklaşımdır. BDD'nin temel amacı; ürün yöneticisi (PO), iş analisti, yazılımcı ve test ekibinin aynı dilde konuşmasını sağlamaktır.

BDD süreçlerinde senaryolar, herkesin anlayabileceği ortak bir format olan Gherkin dili (Given-When-Then) ile yazılır.

Odak Noktası: BDD tamamen "Yazılım, kullanıcının beklediği davranışı ve iş ihtiyacını doğru karşılıyor mu?" sorusuna odaklanır.

Örnek Bir BDD Senaryosu:

Senaryo: Sepette Yetersiz Bakiye ile Ödeme Yapılması

• Given (Koşul): Kullanıcı sepetine 500 TL'lik bir ürün eklemiş ve ödeme sayfasına gelmiş olsun.

• When (Aksiyon): Kullanıcı, içinde sadece 100 TL limit olan bir kredi kartı bilgisi girip "Öde" butonuna bastığında,

• Then (Sonuç): Sistem bankadan dönen hatayı algılamalı ve kullanıcıya "Kartınızın limiti yetersizdir" uyarısını göstermelidir.

TDD ve BDD Arasındaki Temel Farklar

Bir QA / Test Mühendisi Bu Süreçlerin Neresindedir?

"TDD ve BDD yazılımcıların kod yazma şeklidir" algısı tamamen yanlıştır. Özellikle BDD süreçleri, bir QA mühendisinin projedeki gücünü en çok gösterdiği alandır.

• Three Amigos (Üç Silahşörler) Toplantıları: BDD projelerinde kod yazılmadan önce PO, Developer ve QA bir araya gelir. QA mühendisi, daha kod yazılmadan önce "Given-When-Then" senaryolarını çıkartarak edge case'leri (sınır durumları) masaya yatırır. Bu sayede hata daha analiz aşamasında engellenir.

• Manuel Testten Otomasyona Köprü: Yazılan bu BDD senaryoları, manuel testçiler için harika birer adım adım test case oluştururken; otomasyon mühendisleri için de Cucumber gibi araçlarla doğrudan otomasyon koduna dönüştürülebilir yapı taşları sağlar.

Sonuç: Hangisini Seçmeliyiz?

TDD ve BDD birbirinin düşmanı değil, tam aksine birbirini tamamlayan iki metodolojidir. Teknik detayların, algoritmaların ve veritabanı hesaplamalarının yoğun olduğu alt yapı işlerinde TDD ile kod kalitesini güvenceye alabilirsiniz. Kullanıcı deneyiminin, ekran geçişlerinin ve iş kurallarının ön planda olduğu ön yüz akışlarında ise BDD ile tüm ekibin aynı sayfada kalmasını sağlayabilirsiniz. En ideal senaryoda, altyapıyı TDD ile örüp, kullanıcı akışlarını BDD ile test etmek projeyi hatasız bir mükemmelliğe ulaştırır.