Geçen yıl danışmanlık yaptığım bir ekibin 4,000 otomatik testi ve kırmızıya dönmesi 90 dakika süren bir sürüm iş hattı vardı. Testler neredeyse her zaman yeşildi — ki bu bir kazanç gibi görünür, ta ki gerçek hataları yakalayanların ilk altı ayda yazdıkları aynı 200 test olduğunu fark edene kadar. Diğer 3,800 test bakım vergisiydi. Her UI değişikliği bunlardan yüzünü bozuyordu, mühendisler doğrulamaları gevşeterek başarısızlıkları "düzeltiyordu" ve pakete olan güven sessizce sıfıra iniyordu.
Test otomasyonunun gerçek başarısızlık biçimi budur. "Çok az kapsam" değil — yanlış katmanda otomatikleştirilen, sanki amaç nicelikmiş gibi savunulan yanlış kapsam.
Bir test yazmanın kolaylığıyla değil, yanılmanın maliyetiyle başlayın
Sorduğum ilk soru "bunu otomatikleştirebilir miyiz?" değildir. "Bu üretimde bozulduğunda bize neye mal olur ve altta yatan mantık ne sıklıkta değişir?" sorusudur. Bu iki eksen neredeyse her şeye karar verir.
Yılda iki kez değişen ve yanlış olduğunda sessizce para kaybettiren bir ödeme hesabı, ideal otomasyon hedefidir: yüksek etki alanı, kararlı mantık. Büyüme ekibinin her sprintte yeniden şekillendirdiği bir pazarlama açılış sayfası ise en kötüye yakındır — düşük başarısızlık maliyeti, sürekli değişim. İkincisini otomatikleştirmek, size belki zamanın %5'inde doğru nedenle, geri kalanında ise kozmetik nedenlerle başarısız olan bir test kazandırır.
Yanlış yapmanın pahalı ve elle doğrulamanın yavaş olduğu şeyi otomatikleştirin. Bozulması ucuz, göz kararı bakması daha da ucuz olanı ise bırakın.
Neler otomasyonu hak eder
- İş açısından kritik mantık. Fiyatlandırma, vergi, izinler, para hareketi, uyumluluk ya da güvenlik boyutu olan her şey. Bunlar yoğun birim ve entegrasyon kapsamını hak eder.
- Regresyona yatkın yollar. Zaten iki kez geri gelen hata. İkinci kez düzelttiğiniz anda testi yazın — artık onun kırılgan olduğuna dair kanıtınız var.
- Sıkıcı, tekrarlayan doğrulama. API sözleşmeleri, veri dönüşümleri, bir insanın asla sabırla kontrol etmeyeceği girdi permütasyonları. Makineler burada gerçekten daha iyidir.
- Kritik kullanıcı yolculukları — birkaç tanesi. Kayıt olma, ödeme, giriş, gelir üreten o tek akış. Beş yüz değil, ürünü gerçekten işleten beş ila on uçtan uca test.
Neyi atlamalı ya da farklı yapmalı
Atlamak bir tembellik itirafı değil, bir stratejidir. Bazı şeyleri otomatikleştirmek, hiçbir zaman kazandıracaklarından daha pahalıya mal olur.
- Piksel piksel kusursuz UI ve yerleşim. Bir insan bozuk bir yerleşimi iki saniyede görür; bir anlık görüntü testi ise meşru bir yeniden tasarımı her seferinde başarısızlık olarak işaretler. Görsel karşılaştırma araçlarını her bileşende bir refleks olarak değil, birkaç önemli ekranda bilinçli olarak kullanın.
- Tek kullanımlık ya da keşif amaçlı özellikler. Özelliğin çeyreği atlatıp atlatamayacağından emin değilseniz, yoğun otomasyon silebileceğiniz bir kod üzerine oynanmış bir bahistir. Riskli çekirdeği elle test edin, yayına alın, sonra kalıcı olduğunu kanıtlayanı otomatikleştirin.
- Nadiren çalıştırılan, düşük riskli yönetici yolları. Üç kişinin ayda bir kullandığı dahili araç, bir E2E paketini nadiren haklı çıkarır. Kısa bir manuel kontrol listesi hem dürüst hem de daha ucuzdur.
- Her şeyi UI üzerinden yapmak. En sık gördüğüm hata: ekipler tüm testlerini en yavaş, en istikrarsız katmana yükler. Mantık bir API ya da birim testiyle doğrulanabiliyorsa, öyle yapılmalıdır. Tarayıcıyı gerçekten bir tarayıcı gerektiren şeyler için saklayın.
Piramit hâlâ geçerli — çoğu tersine çevirme kendi kendine yapılmıştır
Şekil değişmedi: geniş bir hızlı birim testi tabanı, daha ince bir entegrasyon testi bandı, küçük bir uçtan uca test tepesi. Ekipler bunu tersine çevirir çünkü UI testleri daha çok şey kanıtlıyormuş gibi hissettirir. Aslında daha azını, daha yavaş kanıtlar ve daha sık bozulur. Tam olarak bozuk fonksiyonda başarısız olan 30 saniyelik bir birim testi, size yalnızca "ödeme mutsuz" diyen 6 dakikalık bir E2E testinden daha iyidir.
İstikrarsız testler, hiç test olmamasından daha kötüdür
20 çalıştırmadan 1'inde rastgele başarısız olan bir test, ölçek büyüdüğünde neredeyse her iş hattı çalıştırmasında bir yerde başarısız olur. Ekibiniz yeniden dene tuşuna basmayı öğrenir. Yeniden deneme bir refleks hâline geldiğinde, gerçek bir başarısızlık da yeniden denenerek göz ardı edilir — ve artık paketiniz aktif olarak hataları gizlemektedir. İstikrarsız testleri hızlıca karantinaya alın, düzeltin ya da silin ve istikrarsızlığı bir sıkıntı olarak değil, bir Sev-2 olarak ele alın. Güvendiğiniz daha küçük bir paket, güvenmediğiniz büyük bir paketten daha iyidir.
Pazartesi nereden başlamalı
Bir otomasyon girişimi başlatmayın. Bunun yerine şunu yapın: son 20 üretim olayını çekin ve bir testin hangilerini ucuza yakalayabileceğini sorun. Bu liste, sizin gerçek öncelik kuyruğunuzdur — kapsam yüzdelerine değil, sizi gerçekten neyin incittiğine dayanır.
Kapsam bir sayıdır. Hedef ise güvendir — ve bu ikisi yalnızca gevşek bir şekilde ilişkilidir. Kimse kapsamı ölçmeseydi, yarın paketinizden neyi silerdiniz?