Her Şeyi Otomatize Etmeye Çalışırken Kaybettiğimiz 6 Ay

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

Bir test ekibinin başına gelebilecek en tehlikeli şeylerden biri, kulağa son derece havalı gelen bir hedefin peşine kontrolsüzce takılmaktır. Bizim için o hedef, günün birinde toplantı odasında birinin tahtaya yazdığı şu cümleydi: "Manuel testi tamamen bitiriyoruz, her şeyi otomatize edeceğiz."

Dışarıdan bakıldığında vizyoner, modern ve tam bir mühendislik hedefi gibi duruyordu. Framework’ler seçildi, CI/CD pipeline’ları süslendi, sprint planlarına sayfalarca otomasyon task’ı eklendi. Ekip büyük bir iştahla kolları sıvadı.

Aradan geçen altı ayın sonunda elimizde ne vardı biliyor musunuz? Her sabah kırmızı yanan yüzlerce kararsız (flaky) test, o testleri ayağa kaldırmak için günün yarısını harcayan tükenmiş bir ekip ve prod ortamına kaçan, manuel bir gözün beş saniyede yakalayabileceği kadar bariz hatalar.

Kutsal Kâse Yanılgısı: Yüzde Yüz Otomasyon

Yazılım dünyasında bazı kavramlar adeta bir fetişe dönüşüyor. Test otomasyonu da bunlardan biri. Sanki bir ekip ne kadar çok test script’i yazarsa, ortaya o kadar kusursuz bir ürün çıkacakmış gibi bir illüzyon yaratılıyor.

Oysa otomasyon, sistemin davranışını garanti altına alan sihirli bir değnek değil; sadece daha önce tanımladığınız adımları insan yorulması olmadan tekrar tekrar icra eden bir ameledir. Ne bir eksik ne bir fazla.

Bizim düştüğümüz ilk tuzak, daha iş mantığı tam oturmamış, arayüzü ve akışları her iki günde bir değişen dinamik modülleri otomatize etmeye çalışmaktı. Geliştirici UI’da bir butonun yerini değiştirdiğinde ya da API kontratına ufak bir alan eklediğinde, o modül için yazdığımız yirmi test birden çöpe gidiyordu.

Bir süre sonra fark ettik ki; biz yeni özellikleri test etmiyoruz, ürünün kalitesini artırmıyoruz. Biz sadece dün yazdığımız otomasyon testlerini bugün ayakta tutabilmek için debeleniyoruz. Yani bakım maliyeti (maintenance cost), testin getirdiği katma değeri çoktan yutmuştu.

Bakım Yükü Altında Ezilen Mühendislik

Bir test otomasyon setinin gerçek başarısı, ilk yazıldığı gün değil; altıncı ayında anlaşılır.

Eğer bir sabah pipeline çöktüğünde ekibin ilk tepkisi "Kesin sistemde bug var" değil de "Yine bizim test patlamıştır, bir rerun edelim düzelir" oluyorsa, o otomasyon seti can çekişiyor demektir.

Biz o dönemde bunu çok acı bir şekilde yaşadık. Testler o kadar kırılgan, senaryolar o kadar birbirine bağımlı kurgulanmıştı ki, "flaky" testlerin yarattığı gürültü gerçek bug’ların üzerini örtmeye başladı. Yeşil rapora ulaşmak için assertion’ları gevşeten, sırf test geçsin diye araya körlemesine sleep koyan bir reflekse doğru savrulduk.

Her şeyi otomatize etme hırsı, ekibin analitik zihnini köreltmiş; geriye sadece test kodu tamirciliği yapan yorgun bir yapı bırakmıştı.

Masaya Dönüş: Neyi Otomatize Etmeli, Neyi Asla Etmemeli?

O altı ayın sonunda masaya oturup çok net bir karar aldık: Frene basmak ve bu gereksiz yarıştan çekilmek.

Test piramidi kitaplarda boşuna anlatılmıyordu. Biz tabanı (unit ve entegrasyon seviyesini) sağlamlaştırmadan, tüm yükü arayüz (UI) otomasyonuna yıkmaya çalışmıştık. Geriye adım atıp stratejimizi baştan aşağı değiştirdik:

• Sadece stabilize olmuş, çekirdek iş mantıklarını otomasyona devrettik. Her gün değişen, yarını belirsiz deneysel alanları otomasyonun hantal çarklarına kurban etmedik.
• UI yerine API katmanına ağırlık verdik. Arayüzdeki ufak bir piksel kaymasına kurban giden kırılgan testler yerine, arka planda hızlı koşan, net veri dönen servis testlerine odaklandık.
• Keşifçi (exploratory) testin değerini iade ettik. İnsanın merakını, sezgisini ve "acaba şuradan girsem ne olur?" deme refleksini hiçbir kod satırının taklit edemeyeceğini kabul ettik.

Sahadan Çıkan Ders

Otomasyon bir amaç değil, bir kaldıraçtır. Doğru yere koyarsanız yükünüzü hafifletir; yanlış yere koyarsanız üzerinize devrilir.

Bugün geriye dönüp baktığımda o kaybettiğimiz altı aya tamamen boşa geçmiş bir zaman gözüyle bakmıyorum. O süreç bize, her yeni teknolojik akıma gözü kapalı atılmamayı, araçların esiri olmamayı ve en önemlisi; kalitenin yazdığımız kod satırıyla değil, aldığımız stratejik kararlarla ölçüldüğünü çok net öğretti.

Bazen bir sistemi en iyi korumanın yolu, her yerine test yazmak değil; neyi nerede test edeceğini bilecek kadar sadeleşebilmektir.

Serinin ikinci bölümünde, sahadaki en büyük karadeliklerden birine ineceğiz: Test Verisi Çöplüğü: Bir Ekip Kendi Yarattığı Veride Nasıl Boğulur?