Süreç
Okunan
Yazılım Sınama
2

Yazılım Sınama

by Özgür Eralp24 Haziran 2006

Hatırlayanlarınız mutlaka olacaktır 2004 senesinin ortalarında, ülkemizde çevik/atik yazılım geliştirme yaklaşımları yeni yeni popüler olma yolunda adımlarını atar iken, TurkTech e-grubunda yaklaşım pratiklerinden birinin isminin Türkçe karşılığının bulunması amacı ile yoğun bir fikir alışverişi yaşanmıştı. Bu pratiğin orijinal ismi ‘Test Driven Development – TDD’. Sonuç olarak herkesin üzerinde uzlaştığı bir karşılık belirleyememiştik. Öne çıkan adaylar ise; ‘Test Tarafından Yönlendirilen’, ‘Teste Yönelik’, ‘Test Odaklı’, ‘Test Güdümlü’ idi. Birde, ‘test’ kelimesinin yerine ‘sınama’ kullanılması kabul görmüştü. O zamanda oyumu kullandığım seçeneği bugünde destekliyorum, ‘Sınamaya Yönelik Geliştirme’. 2007 yılının yaz günlerini yaşamaya başladığımız bugünlerde, bu konuda karar verebildik mi?

Belki bu yazı vesilesi ile bu yaklaşımlar üzerindeki fikir alışverişi tekrar alevlenir. O günlerde bu konudaki tartışmalar, pratiklerin uygulanabilirlikleri, uçuk oldukları, sonuçların belirsizlikleri üzerineydi. Geçen 3 sene sonunda, ‘Sınamaya Yönelik Geliştirme’ pratiğinin yararları ve gerekliliği hakkında ikna olmuş durumdayım. Özellikle yazılımların kritik işlevlerinin geliştirilmesi safhasında mutlaka uygulanmalı diye düşünüyorum. Tespit ettiğim önemli noktalardan bir tanesi ise, özellikle algoritma geliştirilmesi esnasında zaten bu pratiğe benzerlikleri fazlaca olan metotların birçok organizasyonda uygulanıyor olmasıdır. Fakat, bu metotların revize edilerek belirli bir sistematiğe yerleştirilmesine; organizasyonun sahip olduğu veya benimsediği yazılım geliştirme süreci içerisinde ayrı bir süreç olarak, aşama, faaliyet ve adımlarının tanımlanmasına ihtiyaç duyulmaktadır.

Bu pratiğin, son müşteriye etkisini gösterebildiği alan ‘ürünün kalitesi’dir. Teorikte, geliştirme süreci sonunda ortaya çıkan ürünün tüm işlevsel özellikleri test edilmiş olacaktır. Kısacası, son ürünün tüm işlevsel gerekleri karşıladığından veya karşılama oranınından emin olunabilecektir. Müşterilerin belkide duymaktan en çok mutluluk duyacakları böyle bir bilgi olacaktır. Bu pratik işleyişinde özellikle yazılım modüllerinin en küçük birim testlerine kadar inceleme yapılabilmektedir. Birçok yazılımcı tarafından halen üzerinde eleştirilerin devam ettiği nokta, geliştirme esnasında odaklanılan nokta birim testlerinin başarısıdır. Önemli olan, tüm testlerin sorunsuz ve hatasız tamamlanmasıdır.

Günümüzde halen birçok yazılım organizasyonunun bu konularda çekinceleri sürmektedir. Danışmanlık firmaları ise tüm bu kaygıları ortadan kaldırmak için çeşitli seminerler, çalıştaylar düzenliyorlar. Bazı şirketler ise kendi içlerinde pilot projelerde bu türden pratikleri hayata geçirip, sonuçlarını gözlemlemeye çalışıyorlar.

Bu pratikleri uygulayan firmalarda ülkemizde gittikçe çoğalıyor. Yazılanları takip ettiğimde farkediyorum ki; bu organizasyonlar, veritabanı uygulamaları geliştirenlerden gömülü sistemlere kadar çok geniş yelpazade yer alıyorlar. Benim gömülü sistemlerdeki tecrübelerimden rahatlıkla söyleyebilirim ki, özellikle uygulama ve çekirdek katmanlarında eğer nesneye dayalı bir programlama dili kullanıyorsanız rahatlıkla uygulanabilmektedir. Ansi C dilinde geliştirilen donanım arayüz modüllerinde dahi biraz zorlanarak uygulandığına tanıklık ettim. Bu aslında bize gösteriyor ki, pratiğin özünde yatan faaliyetleri, geliştirdiğiniz üründen ve kullandığınız geliştirme metotlarından bağımsız olarak her yerde uygulayabilirsiniz.

2001 senesinde yayınlanan bir manifesto ile hayat bulan, atik/çevik yaklaşımların ortaya çıkışını kısaca anımsayalım. 11-13 Şubat tarihleri arasında Utah’ta yazılım mühendisliği alanında ciddi çalışmalarda yer alan 17 uzmanın buluşmasının sonucunda ortaya çıkan bir metin tüm dünyaya internet üzerinden yayınlandı. Bu metini kısaca özetlersek; yazılım geliştirmenin daha iyi yollarını bulmak için yaptıkları çalışmaların ortak alanında temel sayılacak bazı değerlere ulaştıklarını belirttiler.

Bireyler ve iletişime, süreçler ve araçlardan; çalışan yazılım ürününe, kapsamlı yapılmış dokümantasyondan; müşteri işbirliğine, sözleşme görüşmelerinden; değişiklere verilecek tepkiye, plan takibinden daha fazla değer verdiklerini ilan ettiler. Ülkemizde en çok ilgiyi çeken yöntem olarak XP yani Çevik/Atik geliştirme yaklaşımını söyleyebiliriz. Bu yaklaşım, Kent Back tarafından 1980’lerin sonlarında tasarlanmaya başlanmış ve ilk ciddi deneyimini 1996 yılında kazanmıştır. Gelişimini hala devam ettiren bu yöntem, kullanıcılarından ve uygulamalardan gelen geri beslemeler ile geçtiğimiz yıllarda bir güncelleme yaşamıştır. Ülkemizde bu konuda fikir alışverişlerinin ve tartışmaların yapıldığı arenalardan birisi XP-TR e-left_articlesa grubudur.

Ülkemizde yazılım mühendisliği ve yönetimi alanındaki çalışmaların artması, tartışmaların sonuca dönüşmesi dileğiyle…

About The Author
Özgür Eralp
Özgür Eralp
2 Yorumlar
  • 17 Mart 2013 at 19:35

    Evet gere7ekten bir rfcya gere7ek oluyor. SN Threading başlangıe7 ie7in en uygun model oiaibllr. Yazılması daha kolay olacaktır diye fcmid ediyorum. Thread Safety ve Memory Synchronization gibi konuları dert etmeyede gerek kalmayacağından diğer modellere gf6re daha hızlı bile e7alışabilir. Belki ileride bir’den fazla see7eneğimiz de olur Thread tipleri gibi. Actionscript tarafında gerekecek değişiklikler ie7in yakında EcmaScript tarafından da gfczel haberler e7ıkar işallah.

    • 11 Haziran 2013 at 08:15

      Thanks for this post, and for the new collection of Hebrew words! Although the mosiac was discovered in Israel, I assume this belonged to a Roman rather than a Jew, since Jews did not normally do mosiacs showing animals, because this might be against the Ten Commandments not to make graven images.

Yanıt Bırak