Dönüşen dünyadaki IT trendlerine şöyle bir baktığımızda, ‘’Agile’’ rüzgarlarının tüm organizasyonlar üzerinde kuvvetle estiğini görmekteyiz. Piyasalardaki fırsatları çok daha hızlı yakalamak, yaşanılan problemleri bir an önce daha çevik atılımlarla çözmek isteyen firmalar bu dönüşüm rüzgarını arkalarına alarak ilerlemek istemektedirler. Tüm bu süreçlerde Waterfall’dan Scrum ve Kanban’a evrilen SDLC döngüsünü ve tasarım odaklı iş yapış şekillerini görmekte iken, bildiğimiz değişmeyen tek gerçek nokta iş analizi aktivitelerinin gerekliliği ve iş analistlerine olan ihtiyaç. Yeni nesil trendlerde en çok karşılaşılan sorulardan biri ‘’İş Analistlerine Olan İhtiyaç Azalıyor mu?’’ olduğu için sanıyorum yazımın en başında sizlerle bunu paylaşmak istedim. Benim yanıtım, elbette “Hayır”. Analiz aktivitelerini gerçekleştirme şekilleri, roller her ne kadar değişime uğrasa da, her metodolojide iş analistlerine olan ihtiyacın devam edeceği gerçeği yadsınamaz. Bu bakış açısı altında, hep birlikte Agile yapıyı bütünleştiren, bir adım daha ileri seviyeye taşıyan, SDLC döngüsündeki maliyetleri daha aşağı çeken BDD (Behaviour Driven Development) yaklaşımını gelin hep birlikte inceleyelim.

Agile içerisindeki temel proje döngüsünde en kritik noktanın işlerin doğru kırılımda katma değer sağlayacak en ufak, anlamlı parçalara bölünmesi olduğunu bilmekteyiz. Bu doğrultuda planlama-tasarım-geliştirme-test-canlıya alım döngüsü sprint bazlı devam etmekte olup, iş analistleri tarafından user story formatında ihtiyaçlar tariflenip, iş senaryoları ile desteklenmektedir.

User story formatları hem analizleri sadeleştirmekte, hem de kullanıcı ve değer odaklı düşünme sürecini desteklemektedir. Peki tüm bu senaryoları oluşturmadan önce test etmenin mümkün kılındığı bir IT dünyası oluşturulabilir mi? Planlama ve tasarım aşamasının ardından kodlama sürecine geçilmeden tüm senaryoların testini yazabiliyor olmak bize bu noktada ne sağlar? En doğru ve en net yanıt: ‘’Business Agility’’. Bir ürünün/servisin karar verilmiş ilk farklılaştırmaya hızla adapte olabilme yeteneği olarak tanımlayabiliriz bu kavramı. Nasıl ki organizasyonlarda IT içerisindeki takımların agile olmasının yetmediği, iş kollarının hem vizyon hem de talepleri olgunlaştırma süreçlerinde de agile’ı desteklemeleri gerekliliği gibi; BDD yaklaşımı ile uçtan uca agile döngüsünün tamamlanabileceği gerçeğini göz ardı etmemek gerekir.

“Agile metodolojisi ile iş yapıyorsanız ve uygulama testi için BDD kullanmıyorsanız kendinizle çelişiyorsunuzdur.” (Eric N. SHAPIRO, Co-founder of ArcTouch) sözü bu durumda kendini ispatlamış olmakta. Business Agility kavramını tam olarak anlayabilmek/uygulayabilmek için şirketler içlerindeki her halkanın (pazarlama, satış, ürün yönetimi & geliştirme, süreç iyileştirme, test) aynı çeviklikte ve aynı duyarlılıkta olabilmesi için yazılım süreçlerinde BDD yaklaşımının gerekliliği kaçınılmazdır.

BDD yaklaşımı test süreçlerini bir adım öne alır ve kodlama başlamadan test senaryolarının yazılmasını destekler. User story’ler üzerinden elde edilen senaryolar ile oluşturulacak bu test senaryoları sayesinde test maliyetleri ciddi derecede minimize edilebilir. Manuel test eforlarının oldukça azalmasını sağlayan bu yaklaşım IT dünyasında yadsınamayacak bir devrim yaratacaktır.

Davranışsal odaklı bu yazılım süreci en genel hali (planlama ve tasarım aşamaları ardından) ile aşağıdaki aşamalardan oluşur:

  1. Test edilecek olan kodun olası davranış şekilleri neredeyse düz metinsel halde kodlanabilir.
  2. Testi gerçekleştirecek birkaç adım tanımlaması (Step Definition) yapılır.
  3. Sprint içindeki kodlama gerçekleştirilir.
  4. Kodlanan test çalıştırılır.
  5. Testin fail ya da pass durumuna göre kod üzerinde review yapılır.
  6. Kodlanan test tekrar çalıştırılır.

Bu aşamalardan da anlaşıldığı üzere, her ne kadar organizasyonlar IT süreçlerinde test senaryolarını oluşturma ve test senaryolarını kodlama üzerine vakit ayırmaktan kaçınsalar da; manuel test etmenin oluşturabileceği kalite sıkıntısı, ürün release sürelerindeki manuellik ve proje maliyetini doğrudan artıran kalemlerdir.

Yukarıdaki şekilden de görüleceği üzere; tüm sprint döngüsünde “Sürekli Test (Continuous Testing)” mantığını oturtabilmek adına; yazılan birçok kod parçacığının tüm entegre sistemlere olan etkisini ölçme, release’lerin daha kontrollü, hatasız gerçekleşmesi BDD yaklaşımları ile gerçek kılınabilir.

BDD yaklaşımda feature ve senaryo (user story) bazlı aşağıdaki örnek üzerinden nasıl ilerleyebileceğine bir bakalım:

Feature: Mobil Bankacılık Kanalından Hesaptan Para Transferi Yapılması

Senaryo: Hesaptan EFT Yapılması

–Given I am on the page that all listed my account’s.

–When I choose ‘’an account’’

–Then I should see ‘’I want to transfer my money’’ button

–Then I should fill ‘’IBAN or Account’s Number’’

–Then I should fill ‘’Amount’’

–Then I should see ‘’Approving Page’’

–When I click ‘’Approve button’’ on the page, I should see ‘’Process Complete’’ message.

–Then I should return the page that all listed my account’s.

Given, when, then gibi komutlarla basit bir dil ile yazılabilecek bu BDD senaryo kodlaması sayesinde, çıkan defect’lerin çözümleri veya farklı sprintler de kodun üzerine inşa edilecek entegresyon noktaları için testlerin sürekli tekrarlanması çok daha kolay bir hal alacaktır. Yukarıdaki senaryo için mobil kanal üzerinden ileri tarihli bir para transfer işlem girişi talebi geldiğinde mevcut EFT sürecinin bundan ne derece etkilendiği hazır test senaryoları ile otomatize olarak test edilebilecek, böylece yeni taleplerin hayata geçirilmesinde istenen çevikliğe bir adım daha yaklaşılacaktır.    

Test senaryolarının development öncesi basit bir dille kodlanabilmesi; sistem davranışlarının test edilmesinin yanı sıra, unit test ve entegrasyon testlerinin eş zamanlı yapılabilir hale gelmesi sayesinde sprint içerisinde süreçlerin sürekliliği sağlanabilir.  Release’lerin otomasyonu ile de beklenen çevikliğe uyum sağlanması bu döngüyü kusursuzca tamamlayacaktır.

Gerçek anlamda Agile Olmak, yani “Business Agility” kavramını tüm organizasyona yayabilmek adına, müşteriden gelen talepler, bu taleplerin doğru kırılımlarda anlamlı parçalara ayrıştırılması, geliştirme takımı içerisindeki agile vizyonu ve canlıya çıkış süreçlerinin hatasız ve otomatize edilmesi bütünsel olarak ele alınmalıdır. Parçalardan birinin diğerine yetişmemesi o organizasyonun hantallığını engelleyemeyecektir. Sistem davranışlarının her durumda kontrol edilebildiği, geliştirilen her bir kodun tüm sisteme etkisinin otomatize olarak tespit edilebildiği ve her analistin deadline baskısı uğruna efor harcamaktan çekindiği test süreçleri için BDD yaklaşımı biz iş analistleri için de hayat kurtarıcı olacaktır.

Bir yöneticimin sözüyle bu yazının da sonuna gelmiş olalım, ‘’Değişim artık kapıda değil, dönüşüm tam olarak hayatımızda, bizimle, içimizde.’’ Kim bilir, belki de bu dönüşüm, bu yeni nesil yaklaşım yıllardır dilimize pelesenk olmuş “test” kavramını “davranış” olarak güncelleyecektir…

Bahattin Emre Özdemir
BA-Works