Müşteriyi Hissederek Geliştirme Hayaline BDD İle Çözüm

Yeni bir yazılım projesine başlıyorsunuz, ekiplerde heyecan dorukta, gayet hızlı bir başlangıç yapılıyor ve çıktılar alınmaya başlanıyor, herkes mutlu. Fakat bir süre bakıyorsunuz ki hızlı giriş sonrası bir duraklama dönemi başlıyor, test ve müşteri ortamlarından hatalar dönmeye başlıyor, aslında ihtiyaçların karşılanmadığı ortaya çıkıyor. Bu süreci yaşamamış bir yazılım ürettiyseniz gerçekten şanslısınız çünkü ilk grafikteki gibi çalışmamışsınız demektir. Bu yazımızda müşteriyi hissederek geliştirme hayaline BDD ile çözüm geliştirmeyi anlatıyoruz.

Biz de bulut üzerinde çalışacak olan SaaS modeline uygun yeni nesil ürünler için geliştirmelere başlama kararı aldığımızda kullanıcı deneyiminin ön planda olacağı, testlerin elle yapılması yanında otomatik testlerin ürün geliştirme kapsamında baş rolde olacağı bir yapıya merhaba demiş olduk. Yıllardır piyasada yoğun olarak kullanılan Logo ürünlerinin müşterilerimize sağladığı işlevler yeniden tasarlanırken işlevlerin gereksinimleri tam olarak karşıladığından emin olarak ilerlememiz gerekiyordu. Gereksinimlerinin sadece geleneksel analiz dokümanları ile değil, bilgisayar ile insan dilinin ortaklaştığı bir yöntem ile tanımlanmasının doğru bir yol olduğu konusunda hemfikir olarak yola çıktık. İkinci grafiğe uygun yani zamana bağlı olarak geliştirme hızının dengeli arttığı ve bir doygunluğa ulaştığı bir çalışma düzeni için test odaklı geliştirmeyi (Test Driven Development – TDD) düşünmek gerekiyor. Projelerin sonunda olan test baskısını yazılım geliştirme sürecinin her safhasında göz önünde bulundurmak, daha kaliteli üretim yapmayı, müşterilerin önüne daha güvenilir ve tutarlı uygulamaları sunmayı beraberinde getiriyor.

Bu fikirle yola çıkarken TDD ilk akla gelen yöntem olabilirdi. TDD, veri tabanı ve hesaplama işlemleri yoğun bir iş uygulaması geliştirme süreci için tercih edildiğinde; kapsamı tekrarlı olan test metotları üretme olasılığı yüksek olmakta. Bu yöntem ile devam edildiğinde “code coverage” oranı yüksek ama proje sonunda çıkacak iş uygulamasının karşılamayı vaat ettiği gereksinimleri gerçek anlamda adreslemeyen bir ürüne sahip olunabilir. Bunun yerine gereksinimlerin karşılandığını teyit edebildiğimiz bir geliştirme süreci oluşturmak daha doğru bir yaklaşım haline dönüşmektedir. Bu noktada, yine testlerin önce oluşturulmasından vazgeçmeyen, ürün özelliklerini geliştirme esnasında sınamaya odaklanan bir geliştirme yöntemi tercih edilmesi doğru bir karar olarak görülüyor. BDD (Behavior Driven Development – Davranış Odaklo Geliştirme) yaygın kullanımı olarak kullanıcı kabul testleri için önerilen bir yöntem olarak kabul görmesine rağmen Logo olarak geliştirme safhalarında da davranış odaklı geliştirmeyi tercih ederek denemeye karar verdik.

  (tBDD, ürün geliştirme sürecindeki paydaşların iş birliğini arttıran ve ortak anlayışı oluşturmayı hedefleyen bir yaklaşımdır.  BDD’yi test odaklı geliştirmeden (TDD) ayıran en önemli özelliklerinden biri de budur, çünkü TDD daha çok kodlama tarafına odaklanmayı sağlamaktadır.

BDD ile Geliştirme Süreci

BDD ile geliştirme yapılırken insan diline yakın bir şekilde gereksinimlerin senaryolar şeklinde oluşturulması sağlanmaktadır. Her bir senaryo, geliştirilecek olan ürünün işlevlerinin girdilerini, yapılması beklenen işlemi ve çıktılarını tarif etmektedir.

Java ile geliştirmeler yapılmaya devam ettiği için BDD’nin Java dünyasındaki gerçekleştirimden biri olan Cucumber ile çalışmalara başlanmıştır. Cucumber, açık kaynak kodlu olması nedeni ile ve geliştirme ortamları tarafından desteklenmesi sayesinde geliştirme süreçlerimize rahat entegre olabileceği düşünülerek tercih edilmiştir.  Bu noktada, örnek bir senaryoya bakarsak, maaş bilgisi olmadan bir çalışanın eklenmesini engelleyen bir işlevin kontrolünü sağlayan senaryo Cucumber’ın script dili olan Gherkin ile aşağıdaki gibi yazılabilir.

  Scenario: Add an employee without salary info

    Given There is no employee with employee code “EMP_EMPCODE1”

    When I try to add an employee

      | name   | surname | country | startDate      | employeeCode     | branchCode |

      | İlknur  | Demir       | TR           | 07/08/2007 | EMP_EMPCODE1 | EMP_B01    |

    Then Employee addition is not successful

Örnek senaryoda yer alan;

• “Scenario” ile başlayan satır senaryonun adını,
• “Given” ile başlayan satır senaryonun ön kabullerini,
• “When” ile başlayan satır senaryonun hedeflediği işlevi ve senaryonun çalışması sırasında kullanılacak test verisini,
• “Then” ile başlayan satır ise senaryonun beklenen sonucunu

belirtmektedir.

Senaryoların tamamlanmasından sonra Cucumber kullanarak oluşturulan adım tanımları oluşturulur. Bu aşamadan sonra senaryoyu geliştiren iş analistlerinin görevi tamamlanmakta, geliştiricilerin ise görevleri yeni başlamaktadır.

    @Given(“^There is no employee with employee code \”(

*)\”$”)

    public void thereIsNoEmployeeWithEmployeeCode(String employeeCode) throws Throwable {

        try {

            String employeeByCode = myHelper.getMyEmployee().getEmployeeIdFromAssignByEmpCode(employeeCode);

            Assert.assertNull(employeeCode + ” çalışan mevcut”, employeeByCode);

        } catch (Exception e) {

            Assert.fail(e.getClass().getCanonicalName());

        }

    }

Geliştiriciler, senaryodaki gereksinimi yerine getiren iş servislerinin kodlamasını yapacaklardır. İş servislerinin geliştirilmesi sırasında kullanıcı ara yüzleri ile ilgili geliştirmeler henüz başlamamış durumdadır.  BDD senaryoları, ürün işlevlerine odaklanmakta ve bu işlevlerin düzgün çalışmasını garanti etmeyi hedeflemektedir. Burada senaryoların ve ürün kaynak kodlarının aynı proje kapsamında yer alması sürecin karmaşıklığını arttıran bir durum olarak karşımıza çıkmıştır. Çünkü aynı projede yer alma durumu senaryoları geliştiren iş analistinin ürünü derleyebilmesini gerektirmektedir, bu zorunluluğu ortadan kaldırmak için senaryolar ile kaynak kodlar ayrı projelere bölünmüş, senaryoların yer aldığı projenin kaynak kodların yer aldığı projeye bağımlı olarak çalışması sağlanmıştır. Bu yöntem, davranış odaklı geliştirmenin sadece kullanıcı kabul testi olarak değil, yaygın kullanımdan farklı olarak geliştirme sürecinin değişmez bir parçası olarak kullanılmasını beraberinde getirmiştir.

Senaryoların Çalıştırılması

Buraya kadar geldiğimiz noktada senaryolar, geliştirme ortamları üzerinden çalıştırılabilmektedir. Geliştirilen işlerin sürdürülebilir olması için “Continous Integration” kapsamında testleri çalıştırmak gerekmektedir. Bunun için; otomasyon sunucusu olarak kullanılan Jenkins yardımı ile ürün derlendikten sonra senaryolar entegrasyon testi olarak devreye girmekte ve son derlenen kaynak kodlar üzerinde koşarak beklendiği gibi çalışmayan senaryolar ortaya çıkmaktadır. 

Proje yönetim aracı (örnek durumda Maven) yardımıyla projeler yapılandırılarak senaryolara uygun şekilde geliştirilmiş iş servisleri ve senaryolar bir araya getirilmektedir. İş servislerinin senaryolara uygunluğu REST servisleri üzerinden veya “in-memory” olarak test edilebilir.

Jenkins üzerinde BDD senaryolarının koşturulması, tercihe göre her sürüm öncesinde çalışabileceği gibi dilenirse kaynak kod versiyon kontrol sistemine aktarılan her yeni geliştirme sonrasında da çalıştırılabilir. Böylelikle BDD ile geliştirme süreci DevOps süreçlerinin de bir parçası haline dönüşmekte ve süreçlerin oluşturulmasında önemli bir adım olarak yerini almaktadır. Bunun getirdiği bir diğer avantaj ise canlı kullanımda olan bir SaaS ürüne eklenen özelliklerin mevcut ürün özelliklerine olumsuz bir etkisi oluşacak ise yeni özellikler müşterilerin kullanımına açılmadan tespit edilebilmesidir. Yeni versiyonlarda oluşabilecek potansiyel hataların önene geçilerek bizim bakım maliyetlerimiz azalırken müşterilerimiz daha kaliteli ve tutarlı Logo ürünlerine sahip olacak ve memnuniyetleri giderek artacaktır.

Senaryoların Ölçümü

Senaryonun beklediği sonucu vermeyen durumların olmadığı ve senaryoların yazılan kaynak kodların ne kadarlık bir kısmını kapsadığını belirlemek buraya kadar anlatılan sürecin işlerliğini ortaya koyan en kritik parametrelerdir. Bu parametrelerin ilkini Jenkins üzerinde koşan testlerin sonucunu izleyerek elde edebiliriz. Testin kaynak kodların kapsadığı oranı ölçmek için ise Java Code Coverage (JaCoCo) kütüphanesi kullanılmıştır. JaCoCo’nun ürettiği sonuçlar ise statik kod analiz aracı Sonar’a aktarılmakta ve Sonar’ın kullanıcı ara yüzü üzerinden takip edilebilmektedir. Ayrıca Sonar üzerinde Logo’nun Java geliştirme ile ilgili oluşturmuş olduğu kural setlerine göre kod kalitesi ile ilgili metrikler de takip edilmektedir. Logo’nun mevcut ürünleri dahil olmak üzere “blocker” veya “critical” bir madde olmaması hedeflenmektedir. Bu bölümde bahsedilen işler, Jenkins otomasyon sunucusu üzerinde koşmakta ve DevOps sürecimizin kalite ile ilgili önemli bir parçası olarak görülmektedir.

BDD benimsenerek geliştirilmiş iş servisleri için %80 üzeri “code coverage” oranı elde edilmiştir. Örnek olarak çalışanın atamalarının yönetildiği iş servisi, veri erişim servisleri ve servisin kullandığı veri yapıları göz önüne alındığında aşağıdaki oranlar elde edilmiştir.

Sınıf İsmi	Coverage Oranı (%)
EmployeeAssignService	86,1
EmployeeAssignMapper	88,9
EmployeeAssign	100,0
EmployeeAssignDao	79,0
EmployeeAssignDTO	89,7
AssignmentDaoService	81,6

Yukarıdaki tabloda yer alan sınıfların statik kod analizleri sonucunda ise “blocker”, “critical” veya “majör” hata bulunmamaktadır.

BDD ile geliştirme sürecini sadece “code coverage” oranı ile ölçümlemek tam doğru bir sonuç üretmeyecektir. “Code coverage” oranı ile birlikte bu senaryoların beklendiği şekilde sonuç vermesi beklenmelidir. Bu iki ölçüm sonuçları birleştirildiğinde gereksinimlerin tam olarak karşılandığı konusunda net bir fikir sahibi olunabilir. Bu noktada örnek olarak verilen işlevler ile ilgili yazılmış senaryolar göz önünde bulundurulduğunda “fail” eden senaryo bulunmamaktadır.

LAPIS Sürecine Entegrasyon

Daha önceki blog yazılarında bahsedilen LAPIS sistemi, yeni geliştirilen SaaS ürünler için yine etkin olarak kullanılmaktadır. Yeni geliştirilen ürünlerde 2 haftalık Sprint’ler koşulmaktadır. Analizi belirlenmiş maddeler JIRA üzerinden mutabakat toplantısı öncesinde ürün sahibi tarafından belirlenmektedir. Mutabakat toplantısı öncesinde iş yükü tahminleri yapılmaktadır. Mutabakat toplantısında yapılmasına karar verilen maddelerin öncelikle BDD senaryoları oluşturulmakta, bu iş tamamlandıktan sonra kod geliştirilmesine geçilmektedir.

Sonuç

TDD test sorumluğunu yazılımcılara yüklerken, bizdeki kullanım biçimiyle BDD test sorumluluğunu analiste yükleyen test odaklı bir yazılım geliştirme sürecidir diyebiliriz. Bu şekilde, test süreci en baştan itibaren yazılım geliştirmenin her safhasına yayılmaktadır.

Yazılım geliştirme uzmanları açısından sürecin etkisine baktığımızda ise bizim kullandığımız yöntem sadece teknik odaklı bir geliştirmeyi hedeflememektedir. Müşterideki kullanım şeklinin ve beklentilerin farkında olarak bir geliştirme yapma olanağı sunmaktadır. Bu sayede yazılım geliştirme uzmanlarının ürünün ilgilendiği alana ait bilgi birikimi artmaktadır. Sonuç olarak; müşteriyi hissederek geliştirme yapmak için önemli bir adım atılmış olmaktadır.

Yazan: Nail Diker / Logo Yazılım – Yazılım Geliştirme Müdürü