Bu konuya özellikle ülkemizde gerekenden çok daha az önem verildiğini düşünüyorum. Manual testleri bırakıp otomatize edilmiş testlere geçmemiz, hem yazılımın hayata geçtikten sonra müşteri önünde ortaya çıkaracak sorunlarını azaltacak, hem değişiklik maliyetini, hemde tekrar kullanılabilirlik maliyetini artıracaktır. Bu konu ile ilgili yeterli bilgisi olan teknik personelin bulunmaması, yöneticilerin bu konunun önemini bilmemeleri ve zaman kaybı olarak görmeleri dolayısı ile çok nadir uygulanabilmiştir. Ancak, bu konunun anlaşılıp uygulanması ile kalitemizin çok ciddi şekilde artacağı ve karlılığımızın yükseleceği de ısrarla savunduğum fikirlerdir.
Yazılımsal testleri kullanan herhangi bir kişinin kolay kolay manuel test edilen ortamlara geri dönmek istememesinin sebebi bu yaklaşımın gerçekten işe yaramasıdır.
Yazılım projeleri tüm yaşam evresi süresince bir takım istenmeyenlerle boğuşup durur.
Yaılım hayata geçinceye kadar ve geçtikten sonra, bir sürü beklenmyen davranış sergiler. Sebebi tam bitirilmemiş fonksiyonalite olabileceği gibi, düşünülmeyen nedenlerden, değişiklikten, anlık davranışlardan ortaya çıkan sorunlar olabilir. Bunların toplamına bug diyebiliriz.
Sorun
- Bug terimi ilginç bir terim, bilgisayarların ilk yıllarından bize miras kalmış, o zamanlar oda büyüklüğünde bilgisayarla çalışan kişiler bazı problemlerin sebebinin uzun uğraşlar sonrasında devrelerin içerisine girmiş böceklerden kaynaklandığını bulmuşlar, işleme bug temizleme manasına gelen debugging adı vermişler ve terim bu şekilde günümüze kadar gelmiştir.
Bazı yazılımcılar tarafından küçümsense de, istatistiklere göre yazılım geliştirme sürecinin çok büyük bir bölümünü debug işlemi almaktadır. Sorun, sadece yazılım kullanılmaya başladıktan sonra çıkan sorunlar değil, yazılım esnasında ve yazılımın değiştirilmesi esnasında çok şekilde uzun debug süreçlerinden geçme ihtiyacının ortaya çıkması, ayrıca bu debug süreçlerine girilmesi için gerekli önkoşulun da yazılımda bir hata veya beklnemyen davranışla karşılaşılmış olmasıdır. Hata göze çarpmayan bir hata ise, gerçek ortamda ortaya çıkana kadar yazılımal beraber yaşar. Gerçek ortamda ortaya çıkan bir bug ise, hem müşterinin güvenini zedeler, hem yazılımın üzerinden zaman geçmiş olabileceği için unutma riskini artırır, hem de değişikliği esnasında sistemin diğer taraflarını bozarak başka bugları oluşturma sürecine girmesine sebep olur.
Orta veya büyük çaplı bir projede yer almış herhangi bir kişi, bu debug sürecini iyi bilir. Yazılımda bir hata vardır, bunun tespiti için uzun süre boyunca uğraşılır, daha sonra bu hata bulunup çözülür ancak bir süre sonra ortaya çıkarki bu hatanın düzeltilmesi başka bir yeri bozmuştur, o kısım düzeltilir ve bir durumda ilk düzeltilmiş hatanın tekrarlandığı gözükür.
Biraz uzun süredir üzerinde uğraşılıyor olan herhangi bir yazılım için bu durum genel bir durumdur. Yeni özellik ekleme esnasında bu problemlerin hepsi hem yazılım hem kullanım esnasında nükseder ve her seferinde üzerinde zaman harcanarak düzeltilmeye çalışılır.
Projenin toplam maliyetine eklenen bu süreler, yazılım büyüdükçe daha da uzar, o yüzden yeni bir özellik eklemenin yaratacağı problemlerden ürken bir ekip bu durumdan sonra yazılıma dokunmak istemez veya dokunduğu zaman çok uzun zamanlarda sorunlar çözüleceğinden yöneticiler yazılımın baştan yazılmasına karar verme durumuna gelir.
Bu durumun çözümü nasıldır ? Yazılımın gerçek ortama geçmeden önce her noktasının manuel test edilmesi belki yazılımın gerçek ortamda hata vermesini engelleyebilir, ki bu tür bir çalışmanını başarılı olması için her değişiklikten sonra bu testin tekrarlanması gerekir, bu yaklaşım debug süresini azaltmaya yardımcı olamaz.
Çözüm
Bu döngünün içerisinden çıkmamızı sağlayan yapı aslında sihir gibi bir yapı olabilir. Sistemin her tarafını test edecek, problemlerin yerini bizim yerimize tespit edip nerelere müdahele etmemiz gerektiğini söyleyecek bir yapı, bu kontrolü çok kısa zamanda yapabilecek, yazılımdaki her türlü sıkıntıyı oluşmadan bize haber verebilecek bir yapı lazımdır.
Edindiğimiz bilgi, bu tür bir sihirin ancak başka bir yazılım ile mümkün olduğu yönündedir. İnsan gibi davranabilecek, sistemin her yerine girecek çıkacak ve problemleri tespit edecek.
Eğer yazılımı yapan veya yapan ekipten birisi , yazılım esnasında yazılımın sağlaması gereken fonksiyonaliteleri bir kağıda değilde yazılıma dökerse ve bu yazılım çalışma anında kodu kontrol ederse, problemleri bulmuş oluruz. Ancak sorunlarımız sadece kullanıncının gördüğü fonklsiyonalite değil, yazılımın kendi içerisindeki işleyiştende kaynaklanıyor olabilir. Bu durumda, aynı şekilde, bir yazılımcı bu kısmında nasıl çalışması gerektiğini koda yazar ise, bu problemler de sorun olduğunda tespit edilebilir.
Software testingin doğuşu bu şekilde olmuştur, bunun faydasını gören yazılımcılar, testlerin yazılabileceği, hızlı, anında ve kolay anlaşılabilecek şekilde çalışabilmesi için frameworkler yazmıştır.
Bu şekilde test edilmiş bir sistem, değişikliklere karşı sağlamlaştırılmış bir sistem de olur. Eğer sistemin tüm noktalarına çalışma prensipleri kod olarak yazılır ve bu kontrolü yapar ise her ne değişiklik veya yeni fonksiyonalite olursa olsun, kod kolayca değiştirilip yeni fonksiyonalite eklenebilir. Ayrıca, kodu düzeltme, okunulurluğunu artırma, performans artırma veya refactoring gibi işlemlerde bu tür testler olmadan çok zor ve risklidir.
Konuyla ilgilenenler için unit testler bir giriş noktası olabilir. Unit testler, bir classın kendi içerisindeki işleyişini bilen ve buna göre kontrolü yapan testlerdir. Kontrol edecek bir test suite çalıştırıldığında, sınıfların tümü kontrol edilir ve problem var ise tespit edilir. jUnit bu suitelerden bir tanesi, java için olmakla beraber, yeni her dilde bununla ilgili bir yazılım mevcut.
Fonksiyonalite testlerini yapan başka yazılımlar da var, Fit bir örnek olabilir.
Ayrıca, takım olarak çalışan insanlar için, kodun tutulduğu ortak noktaya kodun iletilmesinden önce tanımlanan testlerin herbirini çalıştıran ve tümü olumlu sonuç vermezse kodun yerleştirilme işlemine izin vermeyen bazı yapılar da ekip çalışmasını kolaylaştırır. (crusie control)
