Tipik bir yazılımcı kendisine verilen bir işi görevlere (task) böler ve kod yazmaya başlar. Çoğu zaman bir işi parçalara bölme ve görevler oluşturma işlemi ekip içinde de yapılır. Bir işin parçası olan görevler ekip içinde paylaştırıldıktan sonra, herkes üzerinde düşeni yapmaya başlar.
Bir işi parçalara bölmek ve bu şekilde bir işi tamamlamaya çalışmak seçilebilecek en verimsiz yöntemlerden bir tanesidir. Bunun neden böyle olduğu bu yazımda açıklamaya çalışacağım.
Programcı olarak bize şöyle bir iş verilmiş olsun:
[css]
Kullanıcı e-posta ve şifresini kullanarak login yapabilir.
[/css]
Şimdi bu işten hangi görevlerin çıkabileceğine bir göz atalım:
- Kullanıcı e-posta ve şifresini bir form aracılığı ile edin.
- Kullanıcının girmiş olduğu şifreyi MD5 yöntemi ile dönüştür, çünkü veri tabanında şifreler MD5 yönetimi kullanılarak tutuluyor.
- Kullanıcının IP adresini session isimli veri tablosunda tut.
- Bu tablo yoksa, tabloyu oluştur.
- Kullanıcının hatalı girişlerini login_failed tablosunda tut.
- Kullanıcı üç kez hatalı giriş yaptı ise, hesabını dondur.
Yazılımcılar böl ve yönet prensibi ile büyük problemleri parçalarına bölüp, parça çözümlerini bir araya getirerek, problemin genel çözümüne ulaşabileceklerini bilirler. Bunun yanı sıra yazılımcılar bir işi görevlere bölmeye eğilimlidirler, çünkü ne yapmaları gerektiğini hemen anlamak ve bilmek isterler. Bu görev listesine baktığımızda ne yapmamız gerektiğini hemen görebiliyoruz değil mi?
Lakin göremediğimiz bazı noktalar bulunmaktadır. Bunlar:
- Bu görev listesi bize işi bitirme konusunda ne kadar ilerleme kaydettiğimizi söyleyebilme kabiliyetine sahip mi?
- Görev listesine bakarak, müşterimizin bizden ne istediğini tam olarak anladığımızı söyleyebilir miyiz?
- Müşterimiz görev listesine baktığında, sahip olduğu gereksinimin bizim tarafımızdan doğru anlaşıldığını tespit edebilir mi?
- Bu görevleri tamamladığımızda ne oranda müşterimizin sahip olduğu gereksinimi tatmin ettiğimizi kestirebilir miyiz?
Görev listesine göz attığımızda, “şu veri tabanı tablosunu oluştur” gibi görev tanımlamalarının çok teknik şeyleri ifade ettiğini görmekteyiz. Bu görev listesi bize işin nasıl yapılacağı konusunda fikir verebilmektedir. Lakin bir görevi tamamladığımızda, genel anlamda ne kadar ilerleme kaydettiğimizi kestirmemiz çok zordur. Görev listesinde yer alan görevlerin tamamlanma oranlarından yola çıkarak, ne kadar işimizin daha kaldığını söylememiz mümkün değildir, çünkü görev tanımlamaları bu bilgiyi yansıtma yetisine sahip değildirler. Yazılımcı olarak görev bazında çalıştığımızda, işin neresinde olduğumuzu ve daha ne kadar zamana ihtiyacımız olduğunu kestirmemiz mümkün olmayacaktır.
Bir müşteri gereksinimini tatmin edecek kodu yazmaya başlamadan önce bu gereksinimin ne olduğunu birçok yönüyle anlamış olmamız gerekmektedir. Yukarıda yer alan görev listesi, müşterinin sahip olduğu gereksinimi ne oranda anladığımızı yansıtmaktan acizdir. Görev listesi çok teknik bilgi ihtiva etmektedir. Oysaki müşterinin dile getirdiği gereksinimler, oluşturulmak istenen uygulamaya en tepeden bakar yapıdadırlar. Müşteri için önemli olan bir görevin nasıl yerine getirildiği değil, uygulamanın sergilediği davranış biçimlerinin sahip olduğu gereksinimleriyle ne oranda örtüştüğüdür. Bu yüzden müşterimiz bu görev listesine baktığında, bizim onu ne kadar iyi anladığımızı kestirmesi mümkün değildir. Aynı şey bizim için de geçerlidir. Görev listesine bakarak, müşteriyi ne kadar iyi anladığımızı kestiremeyiz, çünkü görevler bir takım teknik işlevleri ifade etmektedirler ve müşterinin ne istediğine dair bilgiden bihaberdirler.
Bir müşteri gereksinimini koda dönüştürmeden önce, onun ne istediğini ve bizim programcı olarak ne anladığımızı gösteren bir araca ihtiyaç duymaktayız. Bu aracın ismi onay/kabul (acceptance testing) testleridir.
Şimdi müsteri gereksinimini tekrar hatırlayalım ve görev listesi oluşturmak yerine onay/kabul test listesi oluşturalım ve aradaki farkı inceleyelim.
Bize verilen görev şu şekilde idi:
[css]
Kullanıcı e-posta ve şifresini kullanarak login yapabilir.
[/css]
Şimdi bu gereksinimden yola çıkarak, onay/kabul testleri oluşturalım. Benim aklıma ilk etapta gelen testler şu şekildedir:
- Kullanıcı e-posta ve şifresini girmeden login butonuna tıklar. Bu durumda uygulama Kullanıcıya “Lütfen e-posta ve şifrenizi giriniz” hatasını gösterir.
- Kullanıcı sadece e-posta adresini girer ve login butonuna tıklar. Bu durumda uygulama kullanıcıya “Lütfen şifrenizi giriniz” hatasını gösterir.
- Kullanıcı e-posta ve şifresini girer ve login butonuna tıklar. Geçersiz bir e-posta adresi olması durumunda, kullanıcıya “Lütfen geçerli bir e-posta adresi giriniz” hata mesajı gösterilir.
- Kullanıcı e-posta ve şifresini girer ve login butonuna tıklar. Şifrenin geçersiz olması durumunda, Kullanıcıya “Giriş işlemi hatalı” hata mesajı gösterilir.
- Kullanıcı e-posta ve şifresini girer ve login butonuna tıklar. E-posta adresi ve şifre geçerlidir. Login işlemi gerçekleşir ve Kullanıcı ana sayfaya yönlendilir.
Bu listeye baktığımızda hemen dikkatimizi çeken birkaç nokta bulunuyor. Bunlar:
- Görevler teknik bazda değil, daha ziyada uygulama kullanıcısı gözünden bakılarak oluşturulmuş.
- Hem programcı hem de müşteri bu listeye bakarak, ne yapılması gerektiğini anlayabilir.
- Çalışır hale getirdiğimiz her onay/kabul testi ile ne kadar ilerleme kaydettiğimizi görebiliriz. Bunun yani sıra ne kadar işimizin kaldığını kestirmemiz de kolaylaşmaktadır.
Biz programcılar ne yazık ki bize verilen görevleri teknik açıdan analiz etme eğilimi gösteriyoruz. Bir programcıya bir ev yap deseniz, programcı ev sahibi için önemli olan yaşam sahasının kalitesi ve genişliği gibi konularla ilgilenmek yerine, kullanılan betonun kaç derecede daha iyi kuruduğunu, kapı paspasının nereye konması gerektiği konularına öncelik verecektir. Burada programcı olarak gözden kaçırdığımız bir durum mevcut:
“Yaptığımız işle müşteriye sağladığımız katma değer nedir?”
Programcı olarak yaptığımız her işte, her daim bu sorunun cevabını aramalıyız. Bu sorunun cevabını bulmanın en kolay yolu, onay/kabul testleri oluşturmak ve kodu bu testler eşliğinde şekillendirmektir. Eğer bir müşteri gereksinimini koda dönüştürmeden önce görev listesi oluşturmak yerine onay/kabul test listesi oluşturursak, her iki tarafın da ne yapılması gerektiği ve ne yapıldığı konusunda fikir sahibi olmaları kolaylaşacaktır.
Onay/kabul testlerine nasıl tanımlanır sorusu aklınıza gelmiş olabilir. Onay/kabul testlerine gelmeden önce onay/kabul kriterlerinin tanımlanmış olması gerekmektedir. Onay/kabul kriterleri müşteri tarafından tanımlanırlar ve müşterinin uygulamadan olan beklentilerini ihtiva ederler. Normal şartlar altında uygulamanın nasıl bir davranış sergilemesi gerektiğini en iyi bilebilecek olan şahıs müşteridir. Bu yüzden onay/kabul kriterlerinin müşteri tarafından tanımlanması, yapılması gereken çalışmanın çerçevesini oluşturacaktır. Bu kriterlerden yola çıkarak, onay/kabul testlerini tanımlayabilir ve uygulamayı bu testler doğrultusunda şekillendirebiliriz.
Tanımlamış olduğumuz onay/kabul testlerini test güdümlü yazılım yapmak için kullanabiliriz. Bu tür test güdümlü yazılıma ATDD (Acceptance Test Driven Development) ismi verilmektedir.
Nasıl tasarım şablonları (design patterns) programcılar arasında ortak bir kelime hazinesi oluşturma özelliğine sahip ise, onay/kabul testleri de müşteri ile programcı arasında ortak bir dilin oluşmasını sağlama özelliğine sahiptirler. Ben şahsen onay/kabul testleri olmadan bir uygulama geliştirmeye çalışmanın harikiriden farksız olduğunu düşünüyorum. Onay/kabul testlerini müşterinin vizyonu olarak düşünmeliyiz. Yaptığımız işte takip edebileceğimiz bir vizyon olmadığı taktirde, rotamızın nereye doğru gittiği konusunda bir fikir sahibi olamayız. Rotası belli olmaya bir geminin de hangi limana gittiğini kestirmek mümkün değildir. Düşündüğünüz limana gitmeyeceğinden emin olabilirsiniz.
EOF (End Of Fun)
Özcan Acar