Test Stratejisi: Neyi Test Etmeli, Neyi Etmemeli?

Test neden ertelenir?

Çünkü kısa vadede yavaşlatır. Baskı altındaki ekipler testi ilk kesilen kalem olarak görür.

Ancak testi olmayan sistemde her değişiklik risk taşır ve ekip zamanla değişiklik yapmaktan çekinir. Bu noktada gelişim durur.

Hangi kodu test etmeli?

Hesaplama yapan kodu. Fiyat, vergi, komisyon, indirim ve prim hesapları en yüksek öncelikli test hedefleridir; çünkü hatası doğrudan paraya dönüşür.

Karar veren kodu. Yetki kontrolleri, iş kuralları ve durum geçişleri.

Sık değişen kodu. Sürekli dokunulan bölümler, regresyon riskinin en yüksek olduğu yerlerdir.

Hangi kodu test etmeye değmez?

Basit veri aktarım kodu ve arayüz yerleşimi. Bunların testi kırılgandır ve bakım maliyeti faydasını aşar.

Üçüncü taraf kütüphanelerin kendi işlevi. Onların testi onların sorumluluğudur.

Test seviyeleri

Birim testleri hızlıdır ve hesaplama mantığı için idealdir. En çok bu seviyede test yazın.

Entegrasyon testleri, veritabanı ve dış servislerle birlikte çalışmayı doğrular. Kritik akışlar için gereklidir.

Uçtan uca testler kullanıcının gerçek yolculuğunu doğrular. Yavaş ve kırılgandır, bu yüzden yalnız en kritik birkaç akış için yazılmalıdır.

Manuel testin yeri

Her şey otomatikleştirilemez ve otomatikleştirilmemelidir.

Görsel doğruluk, kullanılabilirlik ve mobil cihaz davranışı manuel kontrol gerektirir.

Yayın öncesi kısa bir kontrol listesi, kapsamlı otomasyondan daha pratik olabilir. Önemli olan listenin her yayında uygulanmasıdır.

En kritik nokta: etkileşim testi

Sayfanın açılması, sayfanın çalıştığı anlamına gelmez. Görsel olarak doğru görünen bir ekranda düğmeler ölü olabilir, form gönderimi sessizce başarısız olabilir.

Kendi projelerimizde tasarımdan koda geçiş sonrası bu durumu sistematik olarak denetliyoruz: her düğmeye basılıyor mu, her form gerçekten kaydediyor mu, her bağlantı var olan bir sayfaya gidiyor mu?

Bu denetim yapılmadığında sorun mağaza incelemesinde ya da müşteride ortaya çıkar.

Üretim verisiyle test

Gerçek kişisel veriyi test ortamında kullanmayın. Maskeleme ya da üretilmiş veri kullanın.

Test ortamında gönderilen e-posta ve bildirimlerin gerçek kişilere ulaşmadığından emin olun. Bu, sık yapılan ve utandırıcı bir hatadır.

Testleri sürekli çalıştırmak

Yazılan testler çalıştırılmıyorsa değeri yoktur. Her değişiklikte otomatik çalışan bir düzen kurulmalıdır.

Testlerin hızlı olması kritiktir; yarım saat süren test paketi, ekip tarafından atlanmaya başlar.

Hızlı testleri her değişiklikte, yavaş olanları günlük çalıştırmak pratik bir dengedir.

Kırık bir testi devre dışı bırakmak yerine düzeltin; devre dışı bırakılan testler bir daha açılmaz.

Test verisi yönetimi

Testler birbirinden bağımsız olmalı ve kendi verisini kendisi hazırlamalıdır.

Önceki testin bıraktığı veriye bağımlı testler, sıra değiştiğinde kırılır ve güven kaybettirir.

Üretim verisinin kopyasını test ortamında kullanacaksanız kişisel verileri maskeleyin.

Test ortamından gerçek kişilere e-posta ve bildirim gitmediğinden emin olun; bu kontrol her yeni ortam kurulumunda tekrarlanmalıdır.