Her ürün yöneticisi, QA mühendisi ve geliştirici bunu yaşamıştır.
Yayına çıkarsınız. Kullanıcılar akın eder. Ve daha ilk saat dolmadan biri gözünüzden kaçan hatayı bulur. En önemli akışı bozan hatayı. Tam orada, göz önünde saklanan hatayı.
Bu bir test sorunu değil. Bir süreç sorunu. Çoğu ekip çok geç, çok dar kapsamlı ve çok az bağlamla test ediyor. İşte bunu düzeltmenin yolu.
1. Geliştiricinin değil, kullanıcının gözünden test edin
Geliştiriciler ne geliştirdilerse onu test eder. Kullanıcılar ise beklemedikleri şeyi bozar. Bunlar birbirinden tamamen farklı iki şeydir.
Her sürümden önce ürününüzü ilk kez kullanan biri gibi baştan sona gezin. Kısayol yok, dahili URL yok, önceden doldurulmuş veri yok. Sıfırdan başlayın.
İlk beş dakikada üç hata bulacaksınız.
2. Yalnızca mutlu yolu (happy path) değil, uç durumları da kapsayın
Çoğu test paketi beklenen akışı kapsar. Kimse, özel karakterler içeren ve sonunda boşluk olan 64 karakterlik bir parolayla giriş yapmaz.
Ta ki biri yapana kadar. Ve sistem bozulur.
Uç durumlar istisna değildir. Gerçek kullanıcıların yaşadığı yer tam olarak orasıdır. Test kapsamınız bunu yansıtmalıdır.
3. Yalnızca arayüzü değil, tüm katmanları test edin
Hata her zaman ekranda gördüğünüz şey değildir. Yanlış durum kodu döndüren API'dir. Güncellenmeyen veritabanıdır. Arayüz başarı mesajı gösterirken sessizce hata veren üçüncü taraf entegrasyonudur.
Yayın öncesi kontrol listeniz arayüz davranışını, API yanıtlarını, veri bütünlüğünü ve üçüncü taraf bağımlılıklarını kapsamalıdır. Yalnızca Chrome'da nasıl göründüğünü değil.
4. Regresyonları yayına çıkmadan yakalayın
Bir şeyi her değiştirdiğinizde başka bir şeyi bozma riskini alırsınız. A hatasının düzeltmesi B hatasına yol açar. Her zaman.
Bunu ölçekli biçimde yakalamanın tek güvenilir yolu otomatik regresyon testidir. Ekibiniz bunu hâlâ elle yapıyorsa, her deployment'ta rulet oynuyorsunuz demektir.
5. QA'i staging'de değil, gereksinim aşamasında sürece katın
QA ürünü ancak yayına hazır olduğunda görüyorsa, anlamlı bir şey yakalamak için artık çok geçtir.
Kalite, tek satır kod yazılmadan önce, gereksinim aşamasında başlar. Test senaryoları özellikten önce var olmalıdır. Bu işleri yavaşlatmaz. Gerçekten hızlı ilerlemenin tek yolu budur.
Canlı ortamdaki bir hatanın gerçek maliyeti
Geliştirme sırasında yakalanan hatalar ucuzdur. Canlı ortama ulaşan hataları düzeltmek ise 10 kat daha pahalıdır. Düzeltmenin kendisi daha zor olduğu için değil. Kullanıcı güvenini yeniden kazanmak, kodu yamamaktan çok daha uzun sürdüğü için.
Güvenle yayına çıkan ekipler daha çok test edenler değildir. Daha erken, daha fazla bağlamla ve tüm katmanlarda test edenlerdir.
Yayın öncesi kontrol listeniz
Bunu her sürümden önce kullanın. İlerledikçe her maddeyi işaretleyin.