Agile Projelerde Test Kulturu Nasıl Farklı Olabilir?

Herkese merhaba 🙋‍♀️ Bu yazımda sizlere Agile Metodolojisinde test kültürünün geleneksel metodolojilere göre farklı yapısından bahsederek Agile Testing Manifesto kavramını aktarmak istedim.

Günümüzde Agile ile birlikte test kültürüne verilen önem günden güne artıyor. Şirketler test tarafına oldukça yatırım yaparak bu yöndeki kaslarını geliştirmeye çalışıyorlar. Bazıları tamamen bu yöntemleri olduğu gibi kendi organizasyonlarına aktarıp uygularken bazıları da içlerinden birkaç yöntemi seçerek kendi kültürleriyle birlikte harmanlıyorlar.

Agile Testing manifesto da geleneksel yöntemlere göre test yöntemlerini bize aktaran bir referans kitap şeklinde. Bu manifesto Karen Greaves ve Samantha Laing adlı Agile koçları tarafından derlenerek ortaya çıktı. Bu agile manifestosu 5 adımdan oluşuyor. Dilerseniz adımların her birine yakından bakalım.

Test bir faz değil bir geliştirme sürecidir yaklaşımı

Bugün şirketlerde birçok sanal veya fiziksel board’a baktığımızda her birinde bir test kolonu görüyoruz. Bu da test kolonunun yalnızca test uzmanlarına ait olduğu algısını yaratıyor.

Fakat yazılım geliştirme yaşam döngüsünde test geliştirme başında başlar ve sprint sonuna kadar devam eden bir süreçtir. Test geliştirme sürecinin tamamında vardır. Geleneksel yaklaşımda insanlar testi gelişimin sonunda gerçekleşen bir aşama olarak görürken aksine, çevik olarak, test bir aşama değil kodlama, dokümantasyon ve diğer her şeyle birlikte gerçekleşmesi gereken bir faaliyettir.

Metodolojiyi yayınlayan Karen Greaves ve Samantha Laing’e göre işleri yaparken Todo-In progress-done şeklinde bir yaklaşım öneriyorlar. Eğer başka bir kolon daha açma ihtiyacı duyulursa da bir review kolonu daha eklenerek farklı bir ekip üyeleri tarafından küçük bir parça şeklinde taskların done olmadan önce review edilmesini öneriyorlar.

Bug bulma yerine Bugları önleme yaklaşımı

Hataları önlemek hataları bulmaktan çok daha az zahmetli ve maliyetsizdir. Geleneksel kültürde özellikle de büyük projelerde işleri müşteriye teslim etmeden önce son birkaç ayda projeler test edilip bug-fix yapılırken şimdi ise işleri bugsız yazma ve önleme üzerine konuşuyoruz. Test uzmanlarının asıl görevi bug bulmak değil projede kaliteyi takıma benimseten kişi olmaktır.

Bugları önlemek için de işleri planladıktan sonra task ile ilişkin sorularla test caseleri yazarak takımla paylaşmak ve geliştirmek otomasyon süreçlerini de yazarak işleri ilerletmek gerekiyor. Geliştiricilerin ise unit testlerini en az %70 oranında yazarak kaliteye katkıda bulunması gerekiyor.

Geleneksel yöntemler bug bulma ve manuel test yoğunluğunun fazla olduğu sistemler iken şimdilerde ise unit testler ,entegrasyon testleri ,api tesleri , GUI testler yazarak yukarıda sağdaki modeldeki gibi manuel test yoğunluğunu ve bug oranını azaltan yapılar kurmak gerekiyor.

CheckListler Yerine Düşünme Odaklı Yaklaşım

Geleneksel yaklaşımda uzun uzun checklistler olup geçen veya geçmeyen maddeleri işaretleyen sistemler yerine Agile ile birlikte bunu nasıl test edebilirim gibi müşteri odaklı bir kavram ön plana çıktı. Test uzmanlarının müşterilerin ihtiyaçlarını anlayarak onların savunucuları olmaları ve müşterilerin gerçek ihtiyaçlarını karşılamaları üzerine düşünmeleri gerekiyor. Takım ile birlikte kabul kriterlerini bu yapı üzerine inşa etmeleri müşteri memnuniyeti için oldukça önemlidir.

Sistemi kırma yerine mümkün olan en iyi sistemi oluşturmaya yardımcı olma yaklaşımı

Waterfall projelerde test uzmanları geliştiricilerin açığını bulmaya çalışırken geliştiriciler ve test uzmanları arasında çoğu zaman problem yaşanabiliyordu. Şimdi ise sürecin zihniyeti değişerek takımla birlikle kendini takımın bir parçası olarak görüp sistem için en iyi yöntemleri takımla birlikte uygulamaya çalışan yapılar oluştu.

Kalite Tüm Takımın Sorumluluğunda Olan Bir Süreçtir Yaklaşımı

Son olarak bu yaklaşımla da birlikte kalitenin takımın sorumluluğunda olan bir süreç olduğunu vurguluyorlar. Geleneksel methodta bir problemde test uzmanlarında sorun ararken şimdilerde hataları tüm takım üstlenerek sistemi iyileştirmek için takım olarak çalışıyoruz. Bence yazılım geliştirme sürecinde en önemli konulardan biri takım olmayı başarabilmekte. Kaliteyi baştan sona tüm süreçlerde iyileştirerek kaliteden tüm takımın sorumlu olduğu sistemler geliştirmeye çalışıyoruz.

Hepimiz bir takımda yer alıyoruz, hataları ve başarıları hep birlikte sağlıyoruz. Günün sonunda 10 numarayı bir takım olarak giyiyoruz. Süreçleri geliştirmek ve kaliteden sorumlu olmak hepimizin görevi. Bunu başarabilenler gerçekten bir takım oluyor ve başarılı işlere imza atıyor.

Bu yazımda geleneksel metodolojiye göre agile metodolojisindeki test manifestosunu aktarmaya çalıştım. Bir sonraki yazılarımızda görüşmek dileğiyle 🙌🏻