Çoğu ekip "test kapsamı" sözünü duyunca aklına yüzde gelir.
Bu yanlış bir çerçeve.
Test kapsamını en iyi ölçen şey, testlerinizin sizin konfor alanınıza değil, gerçek kullanıcıların davranışına ne kadar yakın olduğudur.
Asıl değişim test sayısında değil
Asıl değişim, reaktif testten süreç tasarımına geçiştir.
Sprint sonunda test ettiğinizde de hata yakalayabilirsiniz. Bazen.
Ama staging'e gönderdiğiniz anda tasarım problemi değişir. Artık sorunları erken yakalamıyorsunuz. Diğer her şeyden sağ çıkmış olanları buluyorsunuz.
Asıl soru artık şu değil: "Bunu test ettik mi?"
Artık şu: "Bunu, kullanıcıların gerçekte nasıl kullanacağını yansıtacak şekilde test ettik mi?"
Güçlü bir test kapsamı stratejisi nasıl görünür
1. Gereksinim aşamasında başlar
QA ürünü ancak yayına hazır olduğunda görüyorsa çoktan geç kalınmıştır. En iyi kapsam, tek satır kod yazılmadan önce başlar.
2. Çıktısı kolayca gözden geçirilir
İyi test çıktıları: başarı ve başarısızlık kriterleri net, yapılandırılmış test senaryoları, geliştirme başlamadan önce belgelenmiş uç durum senaryoları, her deployment'ta çalışan regresyon paketleri.
Kötü test çıktıları: kimsenin güncellemediği tablolar, tek bir QA oturumundan kalma el notları, iş bittikten sonra hafızadan yazılmış test senaryoları.
3. Kapsamın bir yapısı vardır
En güçlü paketler her seferinde aynı üç katmanı kapsar: mutlu yol (happy path), uç durumlar ve entegrasyon noktaları.
4. Hatalar geri alınabilir
Bir hata canlı ortama ulaşırsa onu hızla tespit edip yeniden üretebiliyor ve düzeltebiliyor musunuz? Yanıt hayırsa test paketiniz size yeterli bağlamı vermiyor demektir.
5. Kapsam riskle örtüşür
En önemli olana odaklanın: ödeme akışı, giriş, veri gönderimi. Yalnızca test etmesi en kolay olana değil.
Sıkıcı kapsam neden daha iyidir
Her deployment'ta çalışan sıkıcı bir test paketi ciddi bir kaldıraç yaratır.
Girişi kontrol edin. Ödemeyi kontrol edin. API yanıtını kontrol edin. Girdi yanlış olduğunda ne olduğunu kontrol edin.
Kulağa iddialı geldiği için değil. Kullanıcılara ulaşıp duran o hata sınıfını tam olarak ortadan kaldırdığı için.
Öncesi ve sonrası
Öncesi: QA, build'i yayından bir gün önce alır. Ana akışların üzerinden elle geçer. İki hata bulur. Altısını kaçırır. Kaçırdıkları yayına çıkar.
Sonrası: test senaryoları, gereksinim yazıldığı anda ondan üretilir. Uç durumlar otomatik olarak kapsanır. Regresyon her push'ta koşar. Hatalar, geliştirici dizüstü bilgisayarını kapatmadan önce Jira ticket'ı açar.
Kapsam Karnesi
Herhangi bir şeyi yayına almadan önce bunu kullanın.
| Kontrol | Soru | |-------|----------| | Zamanlama | Testler geliştirme başlamadan önce yazıldı mı? | | Kapsam | Ana akışları, uç durumları ve entegrasyon noktalarını kapsıyor mu? | | Netlik | Her testin net bir başarılı ya da başarısız sonucu var mı? | | Regresyon | Daha önce düzeltilen tüm hataların bir testi var mı? | | Bağlam | Testler gerçek gereksinimden mi yazıldı? |
5 yeşil: güvenle yayına alın. 3 yeşil: önce kapsamı artırın. 2 veya daha az: yayına almayın.
"Hacim kapsam değildir. Hız strateji değildir."
Test kapsamı tuzağı kaçınılmaz değil. Bu bir süreç sorunu. Süreç sorunlarının da çözümü var.
Gereksinimden mi test ediyorsunuz, yoksa staging ortamından mı?