Test Otomasyonunu "Tool Fetişizmi"ne Kurban Etmek

Seri 2: Sahadan Hatalar – Bölüm 4

Teknoloji dünyasının çok tipik bir hastalığı var: Bir problemi çözmek yerine, o problemi çözmek için kullanılan araçlara aşık olmak.

Yazılım test ekipleri bu tuzağa belki de herkesten daha hızlı düşüyor. LinkedIn akışları, konferans başlıkları ve teknik bültenler sürekli "yeni nesil", "yapay zekâ destekli", "kodsuz", "ultra hızlı" araçların vaatleriyle dolu. Her birkaç yılda bir sektörün önüne yeni bir kurtarıcı atılıyor ve ekiplerde şu konuşma başlıyor:

"Artık X aracını bırakıp Y framework’üne geçmeliyiz. Bütün sorunlarımızı bu çözecek."

Ben bu döngüyü sahada defalarca gördüm. Selenium’dan Cypress’e, Cypress’ten Playwright’a ya da aradaki onlarca popüler kütüphaneye koşan ama günün sonunda aynı kararsız testlerle, aynı bakım maliyetleriyle ve aynı kırılgan mimariyle baş başa kalan onlarca takım…

Çünkü sorun hiçbir zaman kullanılan çekiçte değildi; çiviyi nereye ve nasıl çakacağını bilmemekteydi.

Araç Değiştirerek Süreç İyileşmez

Bir ekip test otomasyonunda başarısız oluyorsa, bunun sebebi yüzde doksan ihtimalle kullandığı framework’ün yetersizliği değildir.

Sebep çoğunlukla şunlardır:

• Test edilebilir olmayan (untestable) kötü bir ön yüz mimarisi,
• Doğru düzgün id veya veri özniteliği (data-testid) barındırmayan HTML yapıları,
• Asenkron çağrıları ve state yönetimini anlamadan körlemesine atılan bekleme (wait) süreleri,
• Test senaryolarının birbirine bağımlı yazılması,
• Ve en önemlisi; neyin neden test edildiğine dair stratejik bir aklın olmaması.

Siz bu temeli düzeltmeden sadece alttaki kütüphaneyi değiştirdiğinizde, yaşadığınız kaosu sadece yeni bir syntax ile yeniden yazmış olursunuz. İlk bir iki ay her şey harika görünür; yeni aracın kurulumu kolaydır, dokümantasyonu moderndir, ekip heveslidir.

Ama proje büyüyüp test sayısı yüzleri, binleri bulduğunda o eski tanıdık kabus aynen geri döner: Flaky testler, şişen pipeline süreleri ve güvenilmez raporlar.

"En Yeni Olan En İyisidir" Yanılgısı

Yazılım geliştiriciler ve test mühendisleri olarak hepimiz yeni teknolojileri denemeyi, CV’mize popüler araçları eklemeyi severiz. Bu çok insani bir motivasyon. Ancak bir mühendislik liderinin masasında duran en kritik sorumluluk, bu heves ile şirketin ve ürünün gerçek ihtiyaçları arasındaki dengeyi korumaktır.

Bir aracın popüler olması, sizin ekibiniz için doğru çözüm olduğu anlamına gelmez.

• Ekibinizin yetkinliği o dili veya paradigmayı ne kadar destekliyor?
• O aracın arkasındaki topluluk ne kadar güçlü, yarın bir tıkanıklık yaşadığınızda çözümü ne kadar hızlı bulabileceksiniz?
• CI/CD altyapınız o aracın paralel koşum maliyetlerini ve kaynak tüketimini kaldırabilecek mi?
• En önemlisi: Eski yapıyı çöpe atıp yeni araca geçmek için harcayacağınız aylar, gerçekten ürüne ölçülebilir bir kalite artışı getirecek mi?

Bu soruları sormadan sırf "trend" olduğu için araç değiştirmek, teknik borcu kapatmaz; sadece yeni bir ambalajla erteler.

Çekiç mi, Marangoz mu?

Çok sevdiğim bir benzetme vardır: Kötü bir marangoza dünyanın en pahalı Japon testeresini de verseniz, ortaya çıkardığı masa sallanır. Ama usta bir marangoz, elindeki mütevazı aletlerle bile sağlam, dengeli ve ömürlük bir iş üretir.

Test otomasyonunda da asıl zanaat;

• Sayfa nesne modellerini (Page Object Model veya benzeri mimarileri) ne kadar temiz kurguladığınızda,
• Test verisini ortamdan nasıl izole ettiğinizde,
• Hangi katmanda neyi ölçeceğinizi (UI vs. API vs. Unit) ne kadar doğru paylaştırdığınızda yatar.

Bunları doğru yapan bir ekip için kullandığı framework sadece bir uygulama detayından ibarettir. Selenium ile de kaya gibi sağlam bir altyapı kurabilirsiniz; en modern kütüphaneyle de içinden çıkılmaz bir spagetti yaratabilirsiniz.

Masadaki Duruş

Bir test lideri olarak ekibimden yeni bir araç önerisi geldiğinde ilk baktığım şey o aracın sunduğu cafcaflı özellikler değildir.

Şunu sorarım: "Bugün yaşadığımız hangi kök problemi çözemiyoruz da bu araca ihtiyaç duyuyoruz?"

Eğer cevap süreçteki bir tembelliği, mimarideki bir eksikliği ya da kötü yazılmış bir senaryo setini perdelemek için veriliyorsa, orada durmak gerekir. Çünkü hiçbir yazılım kütüphanesi, disiplinli bir mühendislik aklının ve iyi bir test tasarımının yerini tutamaz.

Araçlara değil, çözdüğünüz probleme odaklandığınız gün; test otomasyonu ekibin sırtındaki bir yük olmaktan çıkıp gerçekten güven veren bir güce dönüşür.

Böylece Seri 2: Sahadan Hatalar serisini de tamamladık.