Talentra İşin Uzmanına Soruyor: "Test Mühendisliği"
6 dk okuma
Okuma Süresi: 9 dakika
Türkiye’de SoftTech, BKM, Saha Bilgi Teknolojileri şirketlerinde Test Mühendisliği alanlarında çalıştıktan sonra Almanya’da Finleap ve devamında Delivery Hero’da Senior Test Automation Engineer ve Domain Level QA olarak çalışan Tunç Kavaklıoğlu, Test Mühendisliği uzmanlığı hakkındaki sorularımızı yanıtladı.
Mesleğe girişimin enteresan bir hikayesi var. 2010 yılında mezun olduktan sonra; 7-8 ay ufak bir firmada mezuniyet projemizi hayata geçirmek için uğraştım. Sonrasında, orta ölçekli bir firmada, yazılım analisti pozisyonuna geçiş yaptım. Ancak, firma yaşam mücadelesi veriyordu, ve gerçek anlamda çıkar kümemiz kesişmiyordu. Bir gün, üniversitemizdeki bölüm hocalarımızdan birine yazılım alanında mı, yoksa analiz alanında mı ilerlemeliyim sorusuna cevap almak üzere ziyarete gittim. Kendisi hiçbiri diyerek cevap verdi. Her iki alanda da yeteneğin var, neden yazılım test bölümüne giriş yapmıyorsun? yanıtını verdi. Hiç beklemiyordum bu cevabı. Düşündüm, hocamızın altını çizdiği çok değerli bir nokta vardı. Test mühendisliği / uzmanlığı konusu, projenin tümünü görmenizi sağlıyor. Uçtan uca hakim olmanız gerekiyor. İşimin beni çeken en önemli özelliğinin bu olduğunu düşünüyorum. Ben hayatım boyunca bir konu, eşya, film, spor, v.b. ne olursa olsun en tepeden bakıp; bağlantıları, ilişkileri, eksi ve artıları görmeyi çok sevdim. Şu an iş hayatında da sürekli olarak, amacımız ne? Bu amaç doğrultusunda hangi aktiviteleri yapacağız? Ne tarz risklerimiz var? Hangi metotlar ile bu risklere karşı önlem alacağız sorularına yanıt arıyoruz.
Lisede tarih öğretmenimiz demişti ki; tarih alanında başarılı olmak istiyorsanız, bol bol kitap okuyun, film izleyin. Ana hikayeyi ve karakterlerin davranışları arasında bağlantı kurmaya çalışın. Göreceksiniz ki derste tarihin akışını daha rahat anlayacaksınız. Haklıydı.
Gençler için kısaca bir yaşanmışlık paylaşmak istiyorum aslında. Öğretmenlerinizin kıymetini iyi bilin. Lise hayatımda da üniversite hayatımda da öğretmenlerim hayatıma çok önemli dokunuşlarda bulundular. Öğretmenlerinize yakın olmak size derste bire bir başarı getirmeyebilir, lakin onların objektif görüşleri hayatınıza derslere kıyasla daha önemli öğretiler getirebilir.
Sektör ile bu konuda biraz ayrışıyoruz. Benim görüşümde ikisi temelde ayrılmamalı. Şu şekilde düşünelim. Herhangi bir markadan, bir bilgisayar aldınız. Bilgisayar size geldi ve fark ettiniz ki paketlemesinde bir problem var. Bu durum şikayetçi olmanıza neden oldu. Şimdi bu bilgisayarı aldığınız firmanın yöneticisi konumunda olduğunuzu düşünün. Toplamda bir kalite problemi olduğu mu düşünmeli yoksa sadece kutulama aşamasında mı problem olduğunu düşünmeli? Günün sonunda, müşteri şikayeti oluştu. Bunun yanı sıra, konu paketleme olarak görülse bile; paketlemeye gelene kadar oluşan problemlerden dolayı bu sorun paketlemede yaşanıyor olabilir. Siz paketlemedeki sorunu gidererek, belki de günün sonunda daha büyük bir kalite problemini çözebilirsiniz..
Özetle anlatmak istediğim. Yazılım kalitesi bütün bir konudur. Test mühendisliği, kalite güvence, test otomasyon mühendisliği, v.b. tüm ünvanlar kaliteye hizmet eden tek bir birim şeklinde hareket etmek durumundadır.
Yine de özetleyecek olursak, test mühendisi, bir yazılım fonksiyonlarının bozulmasına, çalışmamasına sebebiyet verecek riskleri hesap etmeye çalışır. Buna karşılık bu risklerin savuşturulması için gerekli aksiyonları alır. Kalite güvence üzerine çalışan kişiler ise, yazılımın, yazılımın çalıştığı sektördeki, ve / veya yazılımın üretim sürecindeki standartlara uygun olarak üretilip; üretilmediğini onaylamak, takip etmek veya soruşturmak üzere çalışır. Bu roller arasında geçiş, teknik bilgi eksiğinin kapatılması ile tabii ki mümkündür. Lakin kişilik özelliği olarak farklı yetkinliklerin geliştirilmesi, teknik bilgi eksiğinden daha fazla süre isteyebilir.
Bu konuda ISTQB adlı standardın bir bölümü var aslında. Bir test mühendisinin nasıl davranması gerektiği hakkında açıklamalarda bulunuyor. Ancak, muhalif kişiliğim ne yazık ki bunu da yeterli görmüyor. Aslında bu tavırdan da belli olacağı üzere, kişinin önermeleri kabul etmeyen sorgulayan birisi olması gerekiyor. Zira, şeytan her zaman detayda gizli oluyor. Buna bağlı olarak da yapılan açıklamaları hızla kabul etmek ve varsayım yapmak her zaman kaliteye zarar veren kavramlar oluyor.
Buna ek olarak, biraz araştırmacı olmak gerekiyor. Biraz da test edilen uygulamanın sektörüne ilgi duymak gerekiyor. Zira kaliteye giden yol hiçbir zaman sadece teknik kaliteden geçmiyor. Daha evvelki sorularda bahsettiğim, büyük pencereden ürününüzü izlemek, sektör hakkında bilgi sahibi olmak; kişiyi daha başarılı bir kalite ve test çalışanı haline getirecektir.
Bunların haricinde avrupa deneyiminin bana katmış olduğu bir düşünce ise; kişi gerçekten istediği zaman, planlayarak dilediği yeteneği kendine katabilir. Tek yapması gereken düzenli bir program dahilinde çalışmak. Bu söylediğim şey aslında prensip olarak kalitenin merkezinde de var. Yazılım üretim hattınızı, hatalarından, düzenli olarak öğrenen bir yapıya getirdiğiniz zaman; kalite, yazılım üretim hattınızın ister istemez bir parçası oluyor.
Yazılım test pazarı en son okuduğum rapora göre 2020 yılı itibariyle 40 milyar dolara ulaştı. 2017’de okuduğum bir rapor 2021 yılına ait veri için 23 milyar dolar seviyesini öngörüyordu. 40 milyar dolar seviyesini ölçen güncel rapor 2027 yılına kadar sektörün 60 milyar dolar seviyesini göreceğini söylüyor.
Yine internette yaptığım hızlı bir arama ile takip ettiğim bir kaynaktan gördüğüm enteresan bir hesap şu şekilde.
Kısacası geçmiş 20 yılda yazılan kod miktarı: 2.8 trilyon satır oluyor. İşin ilginç tarafı da bu satırların her yıl artması. Yani 92,700,000,000 rakamı her sene daha da artıyor.
Avrupa kısmına gelirsek; şu anda özellikle test otomasyon mühendisi tarafında çok fazla açık var. Lakin ben buna da muhalefet ediyorum. Zira, kalite tek başına test otomasyonu ile yakalanamaz. Yazılımlar da öğrenen varlıklar, ve onlar da insanlar gibi; bir sürece bağlı olarak öğrenebiliyorlar.
Test mühendisliğine bakış konusunda her iki kültür arasında çok fark yok. Piyasada, danışmanlık firmaları, ve kısa günün karı bakışlı patronlar sağolsun; otomasyon çok hızlı pazarlanabiliyor. Patronlar da otomasyon ile iş gücünden kısabileceğini düşünüyor. Daha sonrasında daha çok insan almak zorunda kaldıklarında şaşırıp kalıyorlar. Bu yaklaşımı burada da gördüm maalesef. Türkiye pazarı ve Avrupa pazarı konusunda gördüğüm en büyük fark; insanların düşüncelerine saygı duyulması ve düşüncelerin dinlenmesi için platform oluşturulması. Bu sebeple şanslıyım ki, şu anda farklı bir stratejiye yönelebilen bir şirket kültürü oluşturma çabasına girdik.
Danışmanlık tarafında çalıştığım günlerde eğitim alanında da çokça varlık gösterdim. Açıkça söyleyeceğim. Çok çeşitli geçmişlerden gelen kişilerle çalıştım. Bu işi kafasına koyan herkes bir şekilde şu an piyasada çeşitli pozisyonlarda çalışıyor. Burada benim en önemli gördüğüm iki şey var. Sorgulayan bir birey olmak. Sunulan açıklamaları bile en ince detayına kadar araştırmak. İkincisi ise yabancı dil bilmek. Geri kalanı kişinin öğrenme isteğine kalıyor. Harici olarak benden illa ki bir üniversite disiplini öğrenmek istiyorsanız; bence İşletme Enformatiği bölümü gerçekten biçilmiş kaftan. Hem teknik ihtiyaçları, hem iş tarafındaki ihtiyaçları görebileceğiniz; ikisi arasında bağ kurmanızı sağlayacak bir disiplin.
Martin fowler, Michael Bolton (testing şeklinde aratın lütfen. Aynı isimli bir şarkıcı var)
James Bach, Cem Kaner, David Evans, Dorothy Graham, Valentin Despa
Konferanslar için: testbash grubu (ministry of testing)
Bir de varsa meraklılarına, yakında ben ve Berk Kibarer bir podcast ve webinar serisine baslayacağız. Bizleri çeşitli mecralardan takip edebilirler.
