Yazılım sektörünün ülkemizde ne kadar büyük bir öneme sahip olduğunu her geçen gün daha fazla anlıyoruz. Bankacılık tarafı, e-ticaret uygulamaları, sosyal medya, haber uygulamaları her alanda büyük bir yer tutuyor ve geçmişten bugüne bütün alışkanlıklarımızı da sil baştan değiştiriyor. Her ne kadar bu yazılımların geliştirilmesinin yanı sıra test edilip son kullanıcıya sorunlarından olabildiğince arındırılmış biçimde ulaştırılması için yazılımın testinin gerçekleştirilmesi çok önemli. Bu makaleyi okuyorsanız teknik bilginin bu tarafta ne kadar değerli olduğunun siz de farkındasınızdır. Fakat teknik bilgi sizi bir yere kadar taşıyacaktır ve daha çok uzmanlaşmanız aslında bir noktada da iletişim ve ekip içindeki etkinliklerinizdir.
Yazılım geliştirme dünyasına dışarıdan bakan biri için test mühendisliği, kodun içinde hataları arayan, test maddeleri hazırlayan ve geliştiricilere “bunu düzelt” diyen yalnız bir savaşçının işi gibi görünebilir. Ben de aslında sektöre giriş yaptığım zaman genel olarak bu fikirdeydim. Fakat tecrübe kazandıkça yazılım testinin asıl gücünün projede köşemize çekilip testimizi yapıp Jira’dan taskı iletmek değil tüm ekip üyeleriyle kurulan sağlam iletişimden geçtiğini daha net anladım. Mid-level bir test mühendisi olarak, projenin başarısının bulduğumuz bug sayısıyla değil, bugları önemine göre etkisini ne kadar iyi ilettiğimizle ve kaliteyi bu noktada ekip olarak bir alışkanlık haline getirdiğimizle ölçüldüğünü daha net bir biçimde görüyorum.
“Biz Testçiler” ve “Onlar” Değil, Tek Bir Ekip : Analist-Geliştirici-Testçi İşbirliği
Projede en temel iletişim Analistler, Geliştiriciler ve Test Ekibi arasında kuruluyor. Fakat en zorlu iletimin bazı zamanlarda Test ve Geliştirme ekipleri arasında yaşandığı bir gerçektir. Klasik “biz bulduk, onlar düzeltsin” yaklaşımı, projeleri yavaşlatan, motivasyonu düşüren ve kalitesiz ürünlere yol açan zehirli bir döngüdür. Bunu kurumların projelerinde bizzat deneyimledim. Başarılı projelerdeki sır ise bu ilişkiyi yapıcı bir işbirliğine dönüştürmektir.
Bulduğumuz bir hatayı raporlarken amacımız birini suçlamak değil, ürünü hep birlikte daha iyi bir noktaya taşımaktır. Örnek olarak testini gerçekleştirdiğimiz bir web sitesinde bulunan butonun çalışmama bugını raporlarken “Buton çalışmıyor” demek yerine :
- Net Başlıklar: “Kullanıcı Profili Sayfasında ‘Kaydet’ Butonu API Hatası Nedeniyle Pasif Kalıyor”
- Tekrar Edilebilir Adımlar : Hatayı geliştiricinin kendi ekranında saniyeler içinde canlandırabilmesini sağlayan net adımlar.
- Beklenen&Mevcut Sonuç: Olması gereken ile mevcut durumun net bir karşılaştırması.
- Kanıtlar: Ekran görüntüsü, video kaydı, ilgili loglar (logcat, console vb.).
Bu adımları yapmak geliştiricinin sorunu anlamak için harcayacağı zamanı minimuma indirecektir ve kendi geliştirmesine daha iyi odaklanmasını sağlayacaktır. Aktarması zor bir hata söz konusu olduğu ise mesela Jira kartına direkt yorum yazmak yerine Teams üzerinden iletişim kurup 5 dakikalık hızlı bir ekran paylaşımı yapıp karşı tarafın çok hızlıca anlamasını sağlamak, saatler sürebilecek yanlış anlaşmaları ortadan kaldıracaktır.Buradaki odak noktamız bug fixlerin başarılı olmasının, test mühendisi ve yazılım geliştiricinin ortak bir zaferi olmasıdır.
Hataları Doğmadan Önce Engelleyebilmek: Analist ve Ürün Sahibiyle İletişim Kurmak
Kalite, kod yazıldıktan sonra eklenen bir katman değildir; projenin en başından itibaren işlenmesi gereken bir olgudur. Bu noktada test mühendisinin rolü, sprint planlama ve analiz toplantılarına aktif olarak katılmaktır.
Bir user story tartışılırken, analist ve ürün sahibine şu gibi soruları sormak bizim sorumluluğumuzdadır:
- “Bu özelliğin ‘happy path’ senaryosu bu, peki ya kullanıcı internet bağlantısını kaybederse ne olacak?”
- “Girilebilecek maksimum karakter sayısı nedir? Negatif bir değer girilirse sistem nasıl tepki verecek?”
- “Bu tasarım, mobil cihazların küçük ekranlarında okunabilir olacak mı veya kullanıcı mobil tarafta bu tasarımdan verim alabilecek mi?”
Bu “ya olursa?” soruları, potansiyel hataları ve mantıksal boşlukları daha tek bir satır kod yazılmadan ortaya çıkarır. Bu, “shift-left testing” yaklaşımının ta kendisidir ve projenin zaman ve maliyet verimliliği açısından paha biçilmezdir.
Büyük Resmi Görmek: DevOps, Tasarım ve Diğer Ekiplerle Koordinasyon
Yazılım sadece koddan ibaret değildir. Test ortamının sağlıklı çalışmasından son kullanıcının alacağı deneyime kadar geniş bir yelpazeyi kapsar.
- DevOps ile İletişim: Test ortamında bir sorun mu var? Yeni bir build mi gerekiyor? Bu konularda DevOps ekibiyle kurulan sağlıklı bir diyalog, test süreçlerindeki gereksiz beklemeleri ortadan kaldırır.
- UI/UX Tasarım ile İletişim: Bir özelliğin fonksiyonel olarak doğru çalışması yeterli değildir. Kullanıcı için sezgisel ve kolay kullanılabilir olmalı. Tasarım ekibine, test sırasında fark ettiğimiz kullanılabilirlik sorunlarını geri bildirmek, ürünün kullanıcı memnuniyetini doğrudan etkiler.
Sonuç: Test Mühendisi Bir Kalite Elçisidir
Yazılım Test tarafındaki teknik konuda yeteneklerimiz (otomasyon yazma, SQL sorguları, API test araçları vb.) bizim temel güçlerimizdir. Fakat bu güçleri ne kadar etkili kullanacağımızı belirleyen şey, iletişim becerilerimiz ve ekip içindeki duruşumuzdur. Mid-level bir test mühendisi olarak artık biliyorum ki, bizim işimiz sadece hata yakalamak değil; kalitenin tüm ekipteki bireyler tarafından anlaşıldığı ve sahiplenildiği bir kültür yaratılmasına liderlik etmektir. Yapıcı ve aktif bir iletişim kurarak, pasif bir “hata avcısı” olmaktan çıkıp, proaktif bir “kalite elçisi” haline geliriz. Projenin başarısı da tam olarak bu dönüşümde saklıdır.