Yazılım Geliştirmede Testin Öneminin Yazılımın Kendisi Kadar Önemli Olması
Yazılım dünyasında her geçen gün yeni teknolojinin çıkması, yeni
trendlerin, patternlerin, methodların uygulanması dinamizmi
beraberinde getiriyor ve bu dinamikliğin içerisinde yazılımcılar mesleki
tatminini yüksek tutabiliyor. Diğer yandan yazılım geliştirme süreçleri içinde yer alan ancak sorumluluğu yazılım geliştirmek olmayan diğer birimlere olan bakışı yazılım geliştirene verdiği değerden daha düşük olabiliyor. Örneğin: Testi, tasarımı ya da diğerlerini küçümseyebiliyor.
Nasıl ki futbol ve basketbol bir takım oyunu ise oyunu takım olarak
oynayıp takım olarak hareket ediyorlarsa yazılım geliştiren bir ürün
ekibinin de takım oyunu oynaması gerekir ve her bir birimin işlevi
takımın başarılı bir sonuç elde etmesi için olmazsa olmaz bir kriterdir.
Kalecinin iyi bir kaleci, defansın iyi bir savunma, forvetin iyi bir golcü
olması gibi her bir birimin sorumluluğu farklı ancak her biri kendi
sorumluluğu ve pozisyonu gereği çok değerlidir.
İyi bir analizin yokluğu ya da iyi bir proje yönetiminin olmaması nasıl başarısız bir projenin oluşmasına sebebiyet verecekse iyi bir yazılımın olmaması da projenin başarısız olmasına sebebiyet verecektir. Dolayısı ile takım üyesinin birbirini iyi bir şekilde desteklemesi, takım bilincinin oluşması, başarılı bir sonuç elde etmek için olmazsa olmaz bir kriter olarak masada yerini alıyor.
Özellikle test tarafının önemini vurgulamak istiyorum. Geçen gün karşılaştığım Güneş Okan’ın kitabındaki şu prensipler değerli.
Yazılımın 7 Test Prensibi Nelerdir?
- Testler hataların varlığını gösterir.
- %100 test etmek imkansızdır.
- Testlere ne kadar erken başlanırsa o kadar zaman ve para tasarrufu sağlanması mümkündür.
- Hataların çoğu belirli yerlerde kümelenir.
- Zehirlenme paradoksu; aynı kişilerin aynı test case’leri baz alarak aynı testleri gerçekleştirmesi durumunda, kişilerin yaptığı testlerde hatalar çıkması farklı bir bakış açısıyla bakılmadan testlerin yapılması sebebiyle zorlaşır. Bu duruma “zehirlenme paradoksu” denir ki bunun sebebi de sinek ve böceklerin aynı zehirden zehirlenmelerine benzetilmesidir.(TDD’de benzer olduğu gibi kodu yazanla/testi yazan aynı olduğunda senaryoyu kaçırması.)
- Test içerikleri ve yaklaşımları bağımsızdır.
- Hatasızlık yanılgıdır.
Her yazılımın hata barındırdığı şüphesizdir. Özellikle geliştirme sürecinin içinde hatalar devamlı çıkar ve hatalar geliştirici ile testçi arasında gider, gelir. Yukarıdaki prensiplerden de biri olan ne kadar erken teste başlanırsa zaman ve para tasarrufu sağlamak o miktarda yüksek olacaktır. Bu sebeple geliştiricilerin geliştirme süreci içerisinde testçiler ile yan yana ve en kısa zamanda teste başlayarak ilerlemesi önemli bir kriterdir. Testçinin test için gerekli ortamı en kısa zamanda gerekirse geliştirme yapılarak sağlamaya çalışması süreçleri kısaltacaktır.
Bir projede yaşadığımız durumu örnek olarak verecek olursam. Lokasyon tabanlı bir proje geliştiriyoruz. Bu projede mobil cihazlarda uygulamaların ayakta çalışır şekilde kalması ve backend servisini düzenli lokasyon verisi ile beslemesi gerekiyor ancak mobil cihazda servis kapanırsa backend, mobil uygulamalara silent push atarak uygulamanın tekrar ayağa kalkmasını istiyor. Bunun testinin yapılması sürecini düşünecek olursak: cihazın kapatılma zamanı, silent push gönderip göndermediği, gelen silent push’a uygulamanın cevap verip arka planda lokasyon bilgisini gönderip göndermediği bunu ilk seferde yapamazsa tekrarlanan push gönderimlerinde ayağa kalkıp kalkmadığı gibi çok daha detaylanan testlerin sağlıklı test etmek için sadece manuel olarak gözle bakılarak yapılacak bir test yeterli olmayacaktır. Sağlıklı bir çıktı da vermeyecektir.
Temelde sıkıntı silent push gönderdin mi diye backend’e bunu sorup ondan cevap almaya çalışmak ile başlıyor ve mobil app’e silent push’un ulaşıp ulaşmadığını mobil app geliştiricisine sormak ile devam ediyor. Bunu ne sıklıkla sorabilirsiniz? Kaç test senaryosunu devamlı soru-cevap şeklinde kişilerden dönüş bekleyerek yapabilirsiniz. Kısıtlı sayıda, kişilerin sabırlarını sınayarak ve iletişimdeki gereksiz zaman kaybı ile yeterli sayıda test senaryosu denemeden testi sonuçlandırırsınız.
Bu sonuçtan kim memnun olur peki?
Testçi yeterli test senaryosu deneyemediği için mutsuz, diğer yandan geliştirici devamlı soru sorulup bölünmüş, mutsuz. Kendi düşüncesi ile angarya olarak değerlendiriyor. İşin çıktısını takip eden proje yöneticisi sağlıklı bir sonuç alamadığı için mutsuz. Ürün Yöneticisi test ederken farklı senaryolarda çıkan hatalarla karşılaştığı için mutsuz. Yani kimse mutlu değil.
Bu sebeple testçilerin test yapmadan önce test stratejisini belirlemesi projenin başarısı için çok önemli bir yer tutmakta. Kullanacakları test teknikleri ya da test çeşitlerini projenin ihtiyaçlarına göre belirleyip işe koyulmaları gerekir. Bunu biz yapıp işe koyulduk mu diye bir özeleştiri yapacak olursam, yeterince yapmadık.
Bu önemli çünkü yazılımın kendisinin sonuçlanması için testin sağlıklı sonuçlanması şart. Eğer yazılımı tamamladık diye düşünüp, testin çıktısında yavaş kalınırsa başarılı, istenen zamanda çıktı almanız mümkün değil. Dolayısı ile test stratejisi doğrultusunda testçi arkadaşların çalışacakları ortamın öncelikle hazırlanması, yazılım geliştirme süreçlerinde zaman ve para tasarrufu sağlayacağı şüphesiz.
İşin başında yapmadığımız bu stratejiyi işin ortasında değerlendirildiğinde testçi arkadaşlar için gerekli olan arayüzlerin elzem olduğunu aksi durumda testlerin sağlıklı yapılmasının mümkün olmayacağı fark edildi. Bu sebeple Grafana üzerinden projedeki ihtiyaçlara özel arayüzler ayarlandı ve bir çok ihtiyaç duyulan veriyi testçi arkadaşların görmesi sağlandı.
Grafana plugin’leri ile farklı birçok ürüne bağlantı sağlamanıza imkan veren harika bir araç. Bu araç yazılım geliştirme süreci içinde olan her bir kişi için çok kıymetli ve süreçleri takip etmek için ciddi hız ve zaman tasarrufu sağlıyor. Bu sebeple yazılımcı, testçi ve DevOps gibi ekiplerin elinin altında devamlı bulunması gereken bir panel.
Kapsamlı ve iyi yapılan loglamanın ciddi oranda geliştirme ve test süreçlerini kısaltacağına şüphe yok. Projelerin başından itibaren bunu göz önünde bulundurarak yazmak gerekir. Her açıdan pozitif olduğu gibi, kapalı kutunun içini görmenizi sağlaması, hem testin hem hataların tespitini kolaylaştırır. Loglama olmadan yapılmaya çalışan çözümler biraz da şöyle görünebiliyor :)
Test Ekibinin Yönetimine İlişkin OKR’lar
Test ekibinin OKR’ları ne olmalı noktasında bir kaç kelam edip yazımı tamamlayayım. Eğer bir OKR verilecek olsaydı:
- İlk iş güncel durumun fotoğrafını çekmek olabilirdi. TMMI denen test olgunluk seviyesini belirlemek ve bu olgunluk seviyesini iki ya da üç çeyrekte bir seviye artırıp TMMI 5 seviyesine çekmek olurdu.
- Test ekibindeki kişilerin uluslararası ISTQB sertifikası alma noktasında ekibin desteklenmesi. Her çeyrekte ekibin içinden belirli kişi adedinde bu sertifikanın alınmasının sağlanması. Hatta başarılı alınan sertifikanın ödemesinin şirket tarafından yapılmasının sağlanması üzerine çalışılabilir.
- Her çeyrekte belirlenen oranda test otomasyon kullanımının artırılması.
- İstatistiksel veri ile belirlenmiş hedefler verilmesi. Örneğin mobil için crash-free metriğinin belirlenen bir değerden aşağıya düşmemesi gibi.
- Her çeyrek içinde ekip içi eğitim organizasyonun adetinin belirlenmesi.
- Test kalitesini ölçecek metrikler belirleyip onların iyileştirilmesi için hedefler belirlenebilir.
Toparlayacak olursak başarılı, tanımlanmış, ölçülmüş, etkin ve verimli test yapabilmek yazılım geliştirme sürecinde iyi bir mimari, doğru teknoloji seçimi kadar önemli bir konudur. Bu sebeple yazılım ve test ekiplerinin koordineli çalışıp, gerekirse kendileri için gerekli olan simülatörleri, arayüzleri belirleyecekleri strateji çerçevesinde hazırlayıp/hazırlatıp, test süreçlerini mümkün olduğunca erken başlatması projenin istenen zamanda başarılı bir sonuca ulaşması için olmazsa olmaz bir konudur.
Yorum yazarak ya da Twitter veya LinkedIn üzerinen bana direk mesaj atarak ulaşabilirsiniz. Twitter üzerinde teknoloji odaklı paylaşımlar yapıyorum daha fazlası için twitter’dan beni takip edebilirsiniz.
Teşekkürler
Yukarda bahsettiğim proje içerisin yer alan, azimleri ve sabırları ile bana ilham kaynağı olmuş Gürkan Ateş, Ali Bilgiç, Görkem Manav’a özellikle teşekkür ederim. Yoğun bir çalışma temposu ile projenin sağlıklı olması için omuz omuza çalışma fırsatı bulduğum için minnettarım.
Her zaman pozitif ve güler yüzleri ile çalışmaktan mutluluk duyduğum Ayris Ayça ve Dinçer Demircioğlu’na editoryal destekleri için teşekkürler ederim.
