developen

1950′lerin ortasında ALGOL programlama dilini geliştiren Alan Perlis‘in çok güzel bir sözü var; “Aptallar karmaşıklığı yoksayar, pragmatistler karmaşanın derdini çeker, dahiler karmaşayı ortadan kaldırır.”

Eğer işiniz, birbirine naif ve verimsiz iletişim kanalları ile bağlı bir ekibin, bir arada ortaya koyduğu bir ürünün kalite seviyesini ortaya koymak ise “Ekibin aptal, pragmatik yada dahi elemanı mı olmalı?”  sorusunun yanıtı bellidir.

Durumumuzun fotoğrafını çekelim; Dünyanın en soyut ve en karmaşık işlerinden birini yapıyorsunuz ve zamanınız kısıtlı. Böyle bir karmaşa içerisinde işimizi layıkıyla yapabilmek o kadar kolay değil elbette. Yazılımın doğasını önümüzdeki 30 yıl değiştiremeyeceğimizi öngörerek, işimizdeki karmaşadan kurtulabilmek alet çantamızın isviçre çakısı olacağını söylersek yanılmayız umarım.

Karmaşanın azaltılması ile ilgili bir çok disiplin içerisinde pratikler geliştirilmiştir. Biz ana konumuz olan yazılım geliştirme hususunda ortaya konmuş ve kanıtlanmış pratiklere bir bakalım.

Karmaşanın azaltılmasının geleneksel olarak üç temel prensibi mevcuttur;

• Bölümleme
• Hiyerarşi oluşturma
• Bağımsızlığın tesisi

Bölümleme, işimizi ne şekilde parçalara ayıracağımıza dair prensiplerdir. Bu prensip bize yazılımları test ederken, aynı anda duruma etkiyen faktörlerin sayısını sınırlayarak daha kontrollü bir test süreci geçirebileceğimizi salık verir. Bir ekranda bağımsız olan fonksiyonların ayrı ayrı test konusu edilmesi karmaşayı düşürecektir.

Ayrıca bölümleme ile test altındaki fonksiyonumuzun sınır değerlerini (İng: Boundary Conditions) tanımlayarak aynı anda odaklanmamız gereken konuları da sınırlandırmış oluruz.

Bölümleme, bu karakteristikleri ile birçok formal test tasarım tekniğinin temelini oluşturmaktadır.

Hiyerarşi oluşturma, odak noktamızı test altındaki yazılım üzerinde kanalize etmemize yardımcı olur. Fonksiyonel kırılım, yada genel tabiri ile fonksiyon hiyerarşisi ile uygulamanın fonksiyonlarını sınıflandırabiliriz. Hiyerarşimizin her dalına tekabül eden fonksiyon sınıflarımızı da uygulama içerisindeki özgün durumları dahilinde ele alıp test ederiz.

Bir uygulamada muhasebe sınıfındaki fonksiyonlar ile kullanıcı yönetimi sınıfındaki fonksiyonların tabii ki içerdikleri riskler birbirinden farklı olacaktır. Bu farklılıkların test süreçlerinde de tesisini sağlamak için hiyerarşik yapılar üzerinde tanımlamalar yapmak, birçok formal test stratejisi pratiğinin çıkış noktasıdır.

Bağımsızlığın tesisi, yazılımların tasarımından geliştirilmesine kadar olan süreçte ne kadar önemli ise yazılımların test süreçlerinde de önem arzeder. Bizler uygulamayı birbirinden bağımsız mümkün olan en küçük parçalarına bölerek test etmek isteriz. Böylece daha basit yapılar üzerine odaklanarak testlerimizi gerçekleştirebiliriz.

Lakin her zaman ayırdığımız uygulama bileşenleri birbirinden tam bağımsız olamazlar. Bu durum Newton hareket denklemleri gibi belirli boyutlarda kaçınılmaz olmakla beraber bir noktadan sonra uygulamanın test edilebilirliği, sürdürülebilirliği, değiştirilebilirliği gibi noktalarda dar boğazlar yaratmaktadır.

Tam bağımsızlığın yakalanamadığı durumlarda bileşenler arasındaki bağların iyi tanımlanması ileride alt sistem testlerini yaparken süprizlerle karşılaşmamamızı sağlayacaktır. Bağımlılık matrislerini hazırlamamamızın da yegane sebebi budur.

Karmaşanın azaltılması diye başladığımız bu konunun yazılım testi pratiklerinin bir yazılımı yada sistemi ele alış biçiminin temellerine dönüşmesi size de ilginç gelmedi mi?

Belki de bu konuyu irdeleyerek yazılım testinin ilk olarak kontrol altına alması gereken faktörün altını çizebilmiş olduk – ki bu karmaşadır.

Arada bir vites değiştirip artık beyinciğimizden yaptığımız şeylerin sebeplerine, amaçlarına inmekte büyük fayda görüyorum. Bu yaklaşım bizi dogmalardan uzaklaştırıp neyi niye bu şekilde yaptığımızı tekrar tekrar değerlendirme fırsatı veriyor bize.

Daha emekleme aşamasında olan bir alanda çalışıyorsanız kendinizin en büyük düşmanı yine kendinizsinizdir. Arada bir vites değiştirin ve kullandığınız pratikleri sorgulayın. Sorgulayın, çünkü size “onlar” bunları anlatmayacaklar ve bilmek istediğinizde size daha başka şeyler satmaya çalışacaklar. Size ezberletecekler ve ürettirmeyecekler. Bunların tümünü yaparken de sizi cesaretlendirip gözünüzü boyayacaklar.

“Onlara” inat kendiniz ve mesleğiniz ile barışın. Düşünün ve irdeleyin çünkü testçi ile test mühendisinin arasındaki temel fark işte budur.

İyi testler!