Çevik Yöntemlerde Test Yönetimi

Test kavramı, yetenekleri, bilgi, beceri ve kabiliyetleri ölçme veya sınama olarak tanımlanıyor ve hepimizin aşina olduğu bir konu. Hem günlük hayatımızda hem de profesyonel iş hayatımızda çeşitli sebeplerle kendimiz veya ürettiklerimiz teste tabi tutuluyor. Matematik testi, zeka testi, kişilik testi, dayanaklılık testi, zemin testi, kandaki şeker testi, bakteri üreme testi, araç çarpışma testi, birim test, sistem testi, stres testi, regresyon (türkçesi bağlanım olarak geçiyor, kullanımı yaygın değil) testi, kullanıcı kabul testi vb. Hepsinde bir ölçme veya sınama söz konusu.

Test yapmazsak ne olur? Fatura öderiz. En temel örnek otomobil üreticilerinin bir hata tespit edip bazen yüzbinlerce aracını geri çağırmaları ve hem prestij hem de para kaybetmeleri. Bunu genişletmek mümkün: yıkılan yapılar, çalışmayan makineler, hatalı çalışan kodlar, sağlık sorunları, zararlı yiyecek/içecekler vb.

Testin esas amacı durumu anlama veya önlem alma veya düzeltme/iyileştirme olabiliyor. Tüm yazılım projelerinde olduğu gibi çevik yöntemlerde (ilgili makaleler: Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde İş Analizi, Çevik Yöntemleri Uygulayabilmek) de testin önemi büyük. Bu önem de hatadan mümkün olduğunca arındırılmış kod üretebilmek ve bu sayede kullanım esnasında sorunsuz çalışmasını sağlayabilmekten ileri geliyor.

İster yazılım olsun ister başka bir endüstri test yönetiminde iki prensip çok işe yarıyor:

• İlki testi mümkün olduğu kadar erken aşamada yapmak veya başlatmak. Çünkü hata ne kadar erken fark edilirse düzeltme maliyeti o kadar düşük olacaktır. 
• İkincisi testi mümkün olan en geniş kapsam sağlayacak şekilde planlamak. Çünkü atlanan bir bölümde ortaya çıkacak bir hata, o kısmın test edilmesine ayrılacak maliyetten kat be kat yüksek olacaktır.

Yazılım projelerinde bu prensiplerden yola çıkılarak kod geliştirirken birim test; bileşenleri birleştirirken entegrasyon testi; birleştirilmiş ürünün çalışmasını görmek için sistem testi; son kullanıcıya göstermek için kabul testi; hataların düzeltilmesi esnasında farklı yerlerin etkilenip etkilenmediğini görmek için regresyon testi; performans beklentisinin karşılanıp karşılanmadığını görmek için performans testi planlanır. Bunların bazıları projeye ve ihtiyaca göre yapılmayabilir.

En kıymetli ve en az maliyetli test adımı olan birim testler maalesef genelde çok hafif geçilir veya atlanır. Çevik yöntemlerde tam da bu soruna bir çözüm öneriliyor Test Güdümlü Geliştirme (ingilizcesi Test Driven Development, Test Kontrollü Geliştirme de kullanılıyor). Burada amaç test durumlarına göre geliştirmeyi yapmak ve kodun testi geçecek kadar geliştirilmesini zorunlu kılmak. Temel adımları:

• Düşün (Think): Kodun ne yapması gerektiğini düşünüp bunları listeleyin.
• Kırmızı Çizgi (Red Bar): Testi listedeki fonksiyonlardan bir veya birkaçı için yazın. Mümkünse 5 satır veya daha az olsun.  
• Yeşil Çizgi (Green Bar): Testi geçecek kadar kod yazın ve testi geçin. 
• Kod Düzenleme (Refactor): Testi geçen kodu fonksiyonalitesini bozmadan iyileştirin. Fonksiyonun bozulup bozulmadığını gerekli yerlerde bir önceki adıma dönüp testi tekrarlayarak kontrol edin.
• Tekrar (Repeat): İyileştirilmiş koda ulaşınca, yeni bir fonksiyonalite için başa dönüp döngüye devam edin. Döngüden çıkış koşulu, listelenen fonksiyonalitelerin bitmesi.

Yukarıdaki yaklaşım ile önce testi sonra bu testi geçecek kodu yazarak önemli bir sıra değişikliği yapılıyor. Bu sayede henüz kodlama aşamasında bir çok hata tespit edilerek ortadan kaldırılıyor. İlk başlarda kodlama hızını düşürdüğü düşünülse de toplamda projeye hız katacaktır. Ayrıca buna alışan yazılımcıların hızlarının arttığı gözlenmektedir.

Test Güdümlü Geliştirme yanında kullanıcı hikayesi (ilgili makale: Çevik Yöntemlerde İş Analizi) yazılırken bunların arkasına testinin nasıl yapılacağının da yazılması gereklidir. Bu sayede geliştirilirken hangi durumlarda kullanılacağı ve nasıl test edileceği de biliniyor olacaktır. Hatta geliştirme aşamasında bunlar yukarıdaki döngüde Kırmızı Çizgi aşamasına da dahil edilebilecektir.

Bu kadar teste gerek var mı derseniz, yanıtım kesinlikle evet olacaktır. İyi test edilmemiş her iş faturasını er geç ödetir. Son söz olarak teste ayrılan zaman asla boşa gitmez, mutlaka bir faydası olacaktır, ya prestij ya para ya da emek kaybını önleyecektir.

Çevik Yöntemlerde Ekip Liderliği

Çevik yöntemlerle (ilgili makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi ) ilgili önemli başlıklardan birisi ekip yönetimidir. Kimi zaman çevik yöntemlerde ekibin kendi başına tüm işi yaptığı, kararlarını kendi içinde aldığı, lidere de ihtiyaç duymadığı düşünülse de çevik yöntemlerde liderlik bir ihtiyaçtır. Klasik yönetim tarzlarının başarılı olamadığı, ekibe direktif verici yaklaşımların uygulanamadığı, ekibin kendi içinde karar alabildiği çevik yaklaşımlarda ekip yönetimi da haliyle farklı olacaktır. Peki çevik ekiplerle çalışırken nasıl davranacağız, nasıl liderlik yapacağız? Bu sorunun yanıtı arayacağız.

Eğer proje yönetiminden geliyorsak ve çevik bir ekibe liderlik yapmamız bekleniyorsa işi planlayıp plana göre takip etme alışkanlığından vazgeçmemiz gerekiyor. Çevik yöntemlerin dinamik planlama yapısı içinde ekibin planlamaya aktif katılmasına müsaade etmemiz ve proje boyunca planı revize etmemiz gerekiyor. Hatta en hassas olduğumuz kapsam yönetimi ve değişiklik yönetimi konularında bildiklerimizi bir kenara bırakmamız ve kapsamın projenin sonuna kadar değişmesine izin vermemiz gerekiyor. Başarı ölçümüzü müşteriye katma değer sunan ve çalışan uygulamalar olarak değiştirmemiz gerekiyor.

Eğer teknik yöneticilikten geliyorsak, direktif verici ve sıkı kontrole dayanan yönetim tarzını bir kenara bırakmamız gerekiyor. Ekibe yöneticilik yapmaktan vazgeçmemiz, liderlik özelliklerimizi ön plana çıkarmamız gerekiyor.

Çevik yöntemlerde başarılı liderlerin diğer liderlerle birçok ortak noktası var (ilgili makaleler: Liderlikte Enerji, Takım Formasyonu ve Liderlik, Mükemmeliyetçilik ve Liderlik, İnsan Nasıl Yönetilir?) bu yazıda onlara değinmeyeceğiz. Çevik yöntemlere özel ve önemli beceriler neler diye baktığımızda, alttaki başlıkların öne çıktığını görüyoruz:

• Ekibe koçluk yapma: Ekip üyelerinin kendilerini ve değerlerini tanıyarak potansiyellerini ortaya çıkarmalarına yardımcı olmak. 
• Ekip içi işbirliğini teşvik etme: Çevik yöntemlerde ekibin bir arada olması, birlikte çalışması ve işin sorumluluğunu hep birlikte üstlenmeleri sebebiyle iş birliğini ve yardımlaşmayı öne çıkarmak ve de teşvik etmek.
• Problemleri ekiple birlikte çözme: Problemleri çözümleriyle beraber sunmak veya kendi başına çözmek yerine ekiple birlikte çözülmesi için ortak aklı harekete geçirmek.
• Yaptıkları ve davranışlarıyla örnek olma: Liderliğin olmazsa olmazı olan hem kişiliği hem de yaptıkları ile ekibe ilham vermek.
• Yapılan çalışmanın müşteriye katacağı değeri ön plana çıkarma: Esas üretimin çalışan yazılım ve bunun müşteriye katacağı değer olduğunun altını gerekli noktalarda çizmek.
• Bürokrasi ve engelleri kaldırma: Ekibin dış etkenlere en az maruz kalması ve işlere odaklanabilmeleri için kurum içi bürokrasi ve engelleri temizlemek ve ekibin önünü açmak.
• Her detaya karışmama: Ekibin ne yapılması gerektiğini bilen, iyi niyetli ve çalışkan bireylerden oluştuğunu kabul etmek. Ekibe hareket alanı bırakmak. Yapılan işlerin tüm detaylarına hakim olmaya çalışmamak.

Her alanda olduğu gibi çevik yöntemlerde de iyi liderlik için eğitim ve tecrübe gerekir. Eğitim, zaten konuyu öğrenmek için gerekli, bunu tartışmaya gerek yok. Tecrübe ile kastedilen işi yıllarca aynı şekilde yapma değil, değişikliklere, farklı ekiplere, farklı tekniklere duyarsız kalmadan değişerek gelişmedir. Çevik yöntemler doğası gereği dinamik bir ortam sunuyor, müşteriden gelen değişikliklere yeşil ışık yakılıyor. Haliyle ekip liderinin de değişime ve gelişime açık olmasını beklemek gerekiyor.