BDD ve Bize Getirdikleri

Miray TOSUN yurtseven | ÜRÜN YÖNETİCİSİ

Günümüzde bir işin kalitesinin kanıtlanması için geliştirmeler bittikten hemen sonra test yapılması gerekmektedir. Testler, bir işin istenildiği gibi olup olmadığının en önemli kanıtlarından biridir. Bir diğeri ise iş birimleri (business) ile yapılan testlerdir. İş birimleri kendi kullanım alışkanlıklarına, talep ettikleri ürüne göre ve işleyişlerine göre test ederler. Yani kendi davranışsal testlerini yaparlar. İşte buradan yola çıkarak yeni bir test yaklaşımı da hayatımıza girmiştir.

Son dönemin popüler test yaklaşımı olarak sıklıkla duyduğumuz BDD (Behaviour Driven Development-Davranış Odaklı Geliştirme) aslında TDD’ye (Test Driven Development-Test Odaklı Geliştirme) alternatif olarak çıkmış bir kavramdır.

TDD ile yazılım geliştirme ve test otomasyon süreçlerinin maliyetli olduğu kabul edilmiş bir durum olmasıyla birlikte TDD yöntemiyle kaliteli yazılım yapıldığı gerçeği de göz ardı edilemez. Günümüz şartlarında müşteri taleplerinin hızlıca yapılabilmesi aynı zamanda hem BT (IT) hem de iş birimlerinin (business) ortak dili kullanması için BDD ortaya çıkmış ve iletişimi sağlamıştır.

Aslında tüm yaklaşımlarda olduğu gibi BDD’nin de üzerinde durduğu temel konu kaliteli kod üretiminin sağlanmasıdır.  Bu bağlamda birbirinin dilinden konuşamayan iki birim arasında iletişimi sağlamasının yanında kullanıcı davranışları üzerinden yapılan testler ile hataların daha hızlı bulunmasını sağlamıştır.

Temelinde iki çalışma söz konusudur; birincisi keşif atölyeleri(Sbe-specification by example), diğeri ise çalıştırılabilir özelliklerdir(TDD-test driven development). Keşif atölyesinde BT ve iş birimlerinin yazılımın nasıl davranması gerektiğine karar verdikleri kısa ve verimli toplantılar yaparlar. Bu toplantılar esnasında iş paydaşları ve BT temsilcileri (geliştiriciler ve test uzmanları) uygulamanın özelliklerini ve kullanıcı öykülerini tartışmak üzere toplanırlar. Temel amaç örneklerle sistemin nasıl davranması gerektiğine karar vermektir. İkincisi olan çalıştırılabilir özellikler ise yazılımın istenildiği gibi davrandığını yazılmış otomasyon kodları ile göstermeyi hedefler. Çalıştırılan otomasyon kodları sonrasında hızlıca test sonuçları gözlemlenir ve eksikler belirlenerek yine hızlıca aksiyon alınabilir.

BDD’nin çok kolay bir yazım yöntemi vardır. Verilen-Ne Zaman-Ardından (Given-When-Then) olarak üç başlıkta test senaryoları yazılır. Verilen(Given), belirlenen bir test senaryosu bu başlıkta yazılır. Ne Zaman (When), bir eylemin gerçekleştiği zaman anlatılır. Ardından (Then), belirlenen senaryo ve aksiyon sonrasında uygulamanın nasıl bir sonuç döneceğini anlatır. Örnek vermek gerekirse, herhangi bir uygulamaya giriş yapmak isteyen bir kullanıcı için bu adımları yazdığımızı düşünelim;

Given: Kullanıcı hatalı şifresini şifre alanına girer,

When: Giriş düğmesine basar,

Then: Kullanıcıya girişte yapmış olduğu hatalı şifre ile ilgili hata mesajı gösterilir.

Yine BDD’nin başka bir kolay yöntemi ise Rol-Özellik-Neden matrisi (Role-Feature-Reason matrix). Buna göre öncelikle Rol için “As a” ile başlanır, sonrasında Özellik için “I want” kullanılır ve son olarak ise Neden için “so that” kullanılır. Örnek vermek gerekirse;

As a: Bir perakende müşterisi olarak,

I want: Satın aldığım ürünleri 14 gün içerisinde iade etmek istiyorum,

So That: Böylece geri ödeme alabileceğim.

BDD’nin en önemli özellikleri yazılan test otomasyon kodlarının herkes tarafından okunabilen ve yazılabilen ortak dilin konuşulduğu platform sunmasıdır. Gerek yaklaşım gereği gerekse paydaşların ortak noktasını bulması sebebiyle son dönemde çok moda olmuş ve birçok sektörde kullanılmaya başlanmıştır.

Please follow and like us:

Bir Cevap Yazın