Behaviour Driven Development (BDD) Nedir? Türkiye'de Yanlış mı Anlaşıldı?

Behaviour Driven Development veya kısa adı ile BDD yaklaşımı BA (Business Analyst) tarafından oluşturulmuş hikayeler(story) üzerinden BDD senaryoları oluşturmak üzerine kurgulanmıştır. Özetle Test Case'lerin Analist tarafından yazılması beklenir. Analist kişinin de kodlama bilgisi olmadığı için metin dilinde veya cümle şeklinde Case’leri yazabilmesi için Cucumber, Gherkin Metin Dili (Syntax), Feature File, Given-When-Then gibi terimler veya teknolojiler kullanılır.

Analistin bu Use Case’leri kolaylıkla yazabilmesi için arkadaki fonksiyon kısmını ise Test otomasyon yazılımcısı yazar. Otomasyon yazılımcısı, Analistin kolay Use Case yazmasını sağlamak için stabil ve kullanılabilir bir ortam oluşturur.

Başta Türkiye olmak üzere kurumlarda BDD adı altında yanlış yapılan uygulama ise şudur; Test Otomasyon Yazılımcısı Excel veya Word ile Test Senaryolarını Manuel Testçi veya Analistden alıp Cucumber ve Given-When-Then kullanarak Test Otomasyon Scriptlerini yazıp bu yaptığının adına BDD demesidir.

Eğer Analist Use Case’leri Cucumber ortamında yazmayacak ise Test Otomasyon Yazılımcısı için Cucumber, Gherkin Dili, Given-When-Then'in hiçbir önemi yok. Junit ile de istenilen Test Scriptlerini hazırlayabilir. Çünkü burada Test Yazılımcısı testleri yazdığı için BDD anlayışı ve burada kullanılan teknolojilerin çokda bir anlamı kalmıyor.

Zaten kurumlardaki iş yoğunluğu, proje veya taleplerin yetiştirme süreleri, acele çıkılmak istenen Release paketleri derken SDLC sürecindeki klasik Analist-Developer-Tester üçlüsündeki Analisten ayrıca böyle bir çalışma yapmasını beklemek pek mümkün değildir.

Genelde kurumlar biz BDD yapıyoruz dediklerinde Use Case’leri Cucumber ile Test Otomasyon Yazılımcısının yazdığını görebilirsiniz. Ya da Analistin hazırladığı Word-Excel dokumanı BDD’ye çevirmesini pek beklemeyin derim. Kendi işlerini yetiştirmekten dolayı Cucumber ile Use Case yazmaya pek vakit bulamayacaktır.

Bir başka savunulan görüş ise Test Case’lerin daha spesifik ve anlaşılır olması denmektedir. Zaten doğru bir Framework kurgusu ile Test Otomasyoncu ister Cucumber, ister Junit, Nunit veya KDT olsun testi anlayacaktır. Analist test case yazmadığı sürece bu görüşün çok bir anlamı yoktur.

Sonuç olarak Analist, İş Analisti veya Test Analisti olan kişiler ilk bahsettiğim teknolojiler ile Story yazamıyor ise o kurumdan BDD ile Test Otomasyon pek beklemeyiniz. Sadece Test Otomasyon Yazılımcısı içinde BDD yapmak saçma bir hal alacaktır. İleri de kurum da analistlerin bu çalışma biçimine geçeceği varsayılırsa belki bu teknolojiye erken geçme söz konusu olabilir.

Behaviour Driven Development Terimleri;

Cucumber

Cucumber JVM

Gherkin Metin Dili (Syntax)

Feature File, Scenario

Given-When-Then (Türkçe'de Yapılabilir)

Burak AVCI