developen

Bir süre önce, projelerimizden birinde kullandığımız Silk Cenral Test Manager uygulaması ile ilgili garip davranışlar görmeye başladık. Örneğin olur olmadık zamanlarda uygulama sunucusu yazılımı (AppServ) donup kalıyor ve gerek web kullanıcılarına, gerekse de takvimlenmiş otomatik testlere sistem yanıt veremiyordu.

Malımızı bilsek de disiplini elden bırakmayarak sırasıyla uygulama sunucusu, veri tabanı katmanı, test çiftliği iletişimi (ExecServ yada Silk Central SilkTest entegrasyon noktaları) ile ilgili profil çıkardık. Sonunda farkettik ki SilkTest yüklü istemci sunucu ile bağlantısı kopup yeniden bağlanmaya kalkığında sunucu 100MB’a yakın ek bir hafızaya ihtiyaç duyuyordu.

Anlaşılan münferit kopmalar sorun yaratmıyordu lakin bir şekilde bizim sahip olduğumuz 35 SilkTest yüklü cihaz bir şekilde toptan gidip geldiğinde sunucumuz buna dayanamıyordu.

Yapılacak basitti, JVM Heap Size’ı yükseltmek. Windows Registry’de Silk Central’in alışık olduğumuz kayıtlarında -Xms değerini 512′den 1024′e çıkardık ve artık kısa vadeli bir çözümümüz vardı.

Daha sonra bu sıkıntının sebebini araştırdığımızda sunucumuzun önündeki ağ aygıtlarından birinde bir düzensizlik farkettik. Görünen oydu ki cihazdaki düzensizlik, bağlantının ender de olsa kopmasına sebep oluyordu.

(DEVAM EDIYOR)

Bu güne kadar kendimce benimsediğim düsturumu tek cümleyle sunayım sizlere:

İşimle ilgili tek kuralım, müşterime eldeki imkanların elverdiği en iyi test hizmetini sunmaktır.

Bu cümlede "müşteri" kelimesi yerine geliştirme ekibi, proje finansörü, son kullanıcılar… vb. rollerden istediğinizi koyabilirsiniz.

Hiçbir zaman test edilmesi gereken bir yazılımı, eksik dökümantasyon, net olmayan isterler yada test aktivitelerinin ekip içerisinde hor görülmesi gibi sebepler öne sürerek reddetmedim ve bu tavrımı da -ne yalan söyleyeyim- çok doğru buluyorum.

Tabii ki proje sonunda "eğer elimde şu kaynaklar olsaydı sizlere böyle daha iyi hizmet verebilirdim" diye bir sonuç raporunu da proje kapanışı dokümanlarına ekleyerek. Bu raporları hazırlarken de tüm ölçümlerimi evrensel iş metriği saydığım "PARA" birimine çevirmeyi de ihmal etmiyorum.

Kullanabildiğiniz heryerde metrik olarak PARA’yı kullanın! PARA bizim gibi teknik insanların ve ayrıca da teknik olmayan yöneticilerin bile aynı biçimde algıladıkları bir birimdir. Sizi temin ederim, genel müdürünüzle test mühendisliği üzerine bir konu tartışırken defects_per_KLOC yerine USD daha iyi bir metrik olacaktır!

Ama gün geliyor ki kodlama safhası uzuyor ve proje takvimi test süresi içerisinden kullanılan zaman ile bitiriliyor. Yazılım, 5 aylık geliştirmenin ardından ofisi terketmesi gereken günün öğleden sonrasında, işini bitirmenin keyfiyle kocaman gülümseyen bir geliştiricinin ellerinde masanıza geliyor ve size "Şunu bir test et…" deniyor. Ama bekleyin, daha da ilginçleşebilir bu durum.

Bu yazılımı ilk defa görüyor olabilirsiniz!!

Bugün başıma gelen işte tam buydu ve hayatımda ilk kez bir yazılımı test etmeyi reddettim. Bir tarafta yıllardır benimsediklerim ve doğru addettiklerim, diğer tarafta ise mesleğime ve yaptığım işe duyduğum saygım.

"Bişeyler yap da aktivite raporunu imzala, yazılımın bugün çıkması gerek."

İpleri koparan cümle bu oldu bugün.

"Bişeyler" ne demek? Yani ne yaptığımın önemi yok muydu?

İmza? Rapora attığım imzanın yazılımın test edilmesi ile doğrudan bir bağlantısı bile yoktu ki. O imzanın atılma amacı test aktivitelerini bitirdiğimi kayıt altına almaktı, ötesi değil…

Yaptığımız işin, test aktivite raporlarını imzalamaya indirgenmesi mi, yoksa test yapılmadığı için aslında anlamı da bulunmayan bir aktivite raporu yüzünden proje ekibine dahil edilmemiz mi daha fazla yaraladı bilemiyorum.

Bunu da buraya not almış olalım. Kim bilir belki ileride bir gün okur, okuduğumuzu anlar, anladığımızdan da dersler çıkarırız.

İyi Testler!

Uzunca bir aradan sonra tekrar selamlar, yaklaşık iki haftadır hayatımı düzene soktuğumu ve tekrar yazmaya başlamanın iyi bir fikir olduğunu düşünüyordum. Sevinçliyim ki bu aranın ardından sizlere güzel bir haber vermek için tekrar klavye başına oturdum.

Bugün aşağıdaki mesajı posta kutumda gördüm ve sizlerle de paylaşmak istedim.  Böyle etkinliklere aktif katılım konusunda geçen senelerde sektörümüzde belirgin bir isteksizlik mevcuttu. Bu isteksizliğimizi bir kenara atıp, özel sektörün deneyimlerini de böyle bir organizasyon içerisine taşımak herkes için büyük bir kazanım olacaktır. Bu konuda Havelsan ve MilSoft’u da kutlamak isterim.

Aldığım elektronik postanın içeriği aşağıdaki gibiydi;

Sayın Özay Civelek

Gelen talepler doğrultusunda Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu – YKGS’2008
bildiri teslim tarihi 20 Mayıs 2008 Salı gününe kadar uzatılmıştır.

Sempozyum ile ilgili detaylı bilgiler için http://www.cse.iku.edu.tr/ykgs2008/  web sayfasını,

Çevrimiçi bildiri gönderme için http://www.easychair.org/conferences/?conf=ykgs2008  web sayfasını kullanabilirsiniz.

Saygılarımla,

Yrd.Doç.Dr.Güray YILMAZ
Hava Mühendis Binbaşı
Hava Harp Okulu
Bilgisayar Mühendisliği Bölüm Başkanı

Umarım kalan 13 gün içerisinde birçok bildiri web tabanlı sistem aracılığıyla YKGS ilgililerine ulaştırılır ve umarım hayalini kurduğumuz ulusal çaptaki bu etkinlik tüm katılımcıların yüzünü güldürür.

İyi testler

Birkaç ay önce QualiTest bünyesindeki görevime Hollanda şubesinde devam etmem konusunda aldığımız kararı uygulamaya başladık ve 5 haftadır Türkiye’den uzak yaşamaktayım. Bu süre zarfında hayatımdaki değişikliklere adapte olmak tüm enerjimi tüketmekte ve yazacak entellektüel gücü kendimde bulmakta zorlanıyorum.

Lakin ne olursa olsun, Michael Bolton‘ın 13 Ocak tarihli blog yazısında anlattığı tartışmayı buraya taşımamak gerçekten ayıp olacaktı. Bu tartışma, yazılım hatalarının saptanması konusunda Epistemoloji’nin kullanımına mükemmel bir örnekti.

Tartışma şu şekilde; 11 Eylül olaylarında Dünya Ticaret Merkezi’nin iki kulesine, iki ayrı uçak çarptı(rıldı). Bu iki ayrı uçağın çarpması tek bir olay mıdır, yoksa iki ayrı olay mı? Kimileri bunu tek bir olay olarak görebilir, zira tüm eylem tek bir eylem planının eseriydi ve tek bir grup tarafından organize edildiler. Diğer taraftan, iki ayrı olay olarak kabul edenler de haklı olabilir çünkü iki farklı bina, iki farklı grup tarafından kaçırılan iki alakasız uçak söz konusu.

"Kimin umurunda?" diyebilirsiniz, "her koşulda binden fazla insan hayatını kaybetti, bunları düşünmek o insanları geri getirmez!" de denebilir. Böyle bir tartışmanın ne kadar değeri olabilir ki?

Sanırım yukarıdaki sorunun yanıtının değeri 3.5 milyar amerikan doları. WTC’yi kiralayan  Lerry Silverstein, her bir yıkıcı olay başına 3.5 milyar USD limitli bir sigorta poliçesine sahipmiş. Yukarıdaki soru ile ilgili çeşitli mahkemeler ve juriler farklı sonuçlara varmışlar. Yukarıdaki formüle göre de, Michael Bolton’ın da dediği gibi, "üç aşağı beş yukarı çarpan uçaklardan birinin yarısı(?) ayrı bir olay olarak değerlendirilmiş" ve 5 milyar dolar ödenmiş.

(DEVAM EDIYOR)