developen

Aktif geliştirme, ardından yürüttüğüm geliştirme ekibi yöneticiliği sonrasında başladığım test mühendisliği kariyerim, bende apayrı hisler uyandırmıştır. Bir anda kendimi psikoloji makaleleri okurken, insanın ne şekilde kavradığı konusunda uzun sohbetler içerisinde yada Nüfus Müdürlüğü’nün çalışma sisteminin hatalara ne kadar açık olduğunu düşünürken bulmak benim geek tarafımı gerçekten çok tatmin ediyor.

Ama her meslek gibi test mühendisliğinin de bazı garip tarafları mevcut… Birçok zaman, içine sürüklendiğim durumlardan çıkmak için, çalıştığım disiplin dışındaki bilgilerimden ve deneyimlerimden faydalanmak zorunda kalıyorum. Bu durum beni gerçekten çok sıkıyor. Bir test mühendisi, gerekli formasyona sahip ise, bu formasyonu ile yapması gerekeni yapıp evine mutlu ve mesut gidebilmelidir diye düşünüyorum.

Nedense geliştiriciler benim de onlar gibi korumalı mod assemly yazabildiğimi, tasarımcılar geçmişimde benim de onlar kadar karmaşık uygulamaları tasarladığımı, proje yöneticileri PERT hesabı yapabildiğimi gördükten sonra çözümcül davranmaya başlıyorlar. Kısacası, aslında görevim yazılım test etmek iken, görevim dışındaki bilgilerimi demonstre ederek ancak görevimi yerine getirebiliyorum. Günümüzde, korkarım, yazılım kalite güvencesi aktiviteleri yapabilmek için fizik doktorası gerekmekte.

Öncelikle, test mühendisi olarak, yeni katıldığım ekip içerisindeki insanların saygısını kazanmak karşılaştığım ilk ciddi sorundur. Sorunu çözebilmek için ancak ekip üyelerine gözle görülür faydalar sağlamak zorundasınız. Yani her durumda maça 1-0 yenik başlarsınız. Ne zaman ki Musa gibi Kızıldeniz’i ikiye yararsınız, o zaman işte ekibin diğer üyeleri ile eşit konuma gelirsiniz.

Tabii ki bunun belirli sebepleri mevcut.

Örneğin çıkan uygulamada sorun yok ise, sorun yoktur! Yazılımda sorun çıkması zaten beklenmez. Analistler mükemmel analizler yaptılar, tasarımcılar eşsiz tasarımlar ortaya koydu ve geliştiriciler mükemmel kodlar yazdılar. Bu durumda SQA ekibi ne yaptı? Yazılımda sorun çıkmış ise SQA ekibi işini yapmamış olur ve sorunu gideren geliştirici ekip yine de sorunu çözdükleri için prim yaparlar. Yoksa SQA ekiplerine gerek yok mu?

“Olmaz ya, elinizde isterler net olmadan yazılım geliştirmek durumundayız diyelim ;) Bu eksik isterleri biz geliştiricilere verdiler ve biz bir ürün ortaya çıkardık. Daha sonra test ekibi geldi ve durmadan sorular sormaya başladı. Onca işin arasında bunca soru soran ve hiçbirşeyi anlamayan yada anlamak istemeyen (test sistematik şüpheciliktir), üstüne üstlük de sürekli sorunlardan bahseden birilerini niye saygı ile karşılayalım? Bu adamların tek bildiği gelip gerekli gereksiz bir sürü hatadan bahsetmek, uygulamayı hiç kullanılmayacak şekillerde kullanmak ve kendi donanımlarına özel sorunları tüm ekibe bağırmaktan öte mi? Uygulama işini yapıyor ve benim sistemimde sorunsuz çalışıyor. Bu adamlara ne gerek var?”

Şaka bir yana, -aslında gerçek pek uzak değildir yukarıda anlatılanlara- yaşanan sorunlardan birisi de alınan sorumluluk ve verilen güç ile ilgili olan dengesizliktir. Geliştirilen yazılımın gerçekten “çalışıp çalışmadığını”, yada daha güzel bir ifade ile “yazılımın bitip bitmediğini” inceleyen test mühendisleri, kendi alanlarında bile ekip içerisinde yeterince güçlü değildirler.

Eh, buna bir de yazılım geliştirmenin tam olarak oturmamış ve halen kendi içerisinde bile çelişkilerle dolu bir iş olduğunu düşünürseniz… Mutlak doğruların olmadığı bir ortamda, yazılım için mutlak doğruları araştıran, işi şikayet etmek olan ve doğru olduğuna inandığı şeyler için ürün toplantılarında tartışmaktan çekinmeyen test mühendisleri, işte bu sebeplerle, son işe alınan ve bütçe ile ilgili sorun yaşandığında ilk işten çıkarılan insanlar oluveriyorlar.

Test mühendisliği ile ilgili canımı sıkan şey aslında tam da bu durumdur!