Regression Testing & Release QA

Release Öncesi Test Neden Kritik?

Bir mobil uygulamayı yayınlamak web'den çok farklıdır. Web'de hata çıkarsa dakikalar içinde fix deploy edebilirsiniz. Mobil'de ise store review süreci var, kullanıcılar güncellemeyi hemen yüklemeyebilir ve kötü bir sürüm store puanınızı ciddi şekilde düşürebilir.

Bu yüzden her release öncesinde sistematik bir test süreci uygulamak zorunludur.

Smoke Test vs Regression Test

Smoke Test:

• Uygulamanın temel fonksiyonlarının çalışıp çalışmadığını hızlıca doğrular
• 15-30 dakika sürer
• "Uygulama açılıyor mu? Login olabiliyor muyum? Ana akışlar çalışıyor mu?"
• Her build sonrası yapılır

Regression Test:

• Yeni değişikliklerin mevcut özellikleri bozup bozmadığını kontrol eder
• Saatler sürebilir (kapsamlı suite)
• Daha önce düzeltilmiş bugların tekrar çıkıp çıkmadığını doğrular
• Release öncesi yapılır

Her build'den sonra smoke test, her release öncesinde full regression test yapmanız gerekir.

Test Checklist Oluşturma

Temel Fonksiyonlar:

• Uygulama sorunsuz açılıyor (cold start ve warm start)
• Kullanıcı kayıt ve giriş akışları çalışıyor
• Ana navigasyon tüm sekmelerde sorunsuz
• Push notification doğru ekrana yönlendiriyor
• Deep link'ler çalışıyor

Veri ve Ağ:

• Offline durumda uygulama crash etmiyor
• Yavaş bağlantıda timeout'lar düzgün handle ediliyor
• API hata durumlarında anlamlı mesaj gösteriliyor

Platform Spesifik:

• iOS: en düşük desteklenen sürümde test edildi
• Android: farklı ekran boyutlarında test edildi
• Dark mode'da UI elementleri görünür

Feature Flag ile Güvenli Release

Feature flag, yeni bir özelliği kodun içinde açıp kapayabilmenizi sağlar. Release riskini büyük ölçüde azaltır.

• Yeni özelliği önce %5 kullanıcıya açıp metrikleri gözlemleyebilirsiniz
• Sorun çıkarsa store güncellemesi yapmadan flag'i kapatabilirsiniz
• A/B test yapabilirsiniz

Popüler araçlar: LaunchDarkly, Firebase Remote Config (ücretsiz), Statsig, Unleash (open source), PostHog Feature Flags.

Kritik kural: eski flag'leri temizleyin. Kullanılmayan flag'ler kod tabanını karmaşıklaştırır.

Staged Rollout (Google Play)

Google Play yeni sürümü kademeli yayınlamanıza olanak tanır:

1. %1: İlk gün, crash rate ve ANR rate izleyin
2. %5: 1-2 gün bekleyin, kullanıcı yorumlarını takip edin
3. %10: Performans metriklerini karşılaştırın
4. %25: Geniş cihaz çeşitliliğinde test
5. %50: Ciddi sorun çıkmadıysa devam
6. %100: Full rollout

Sorun görürseniz "Halt rollout" ile dağıtımı durdurun.

Phased Release (App Store)

Apple'ın phased release sistemi 7 gün boyunca otomatik kademeli dağıtım yapar: 1. gün %1, 2. gün %2, 3. gün %5, 4. gün %10, 5. gün %20, 6. gün %50, 7. gün %100.

Manuel güncelleme yapan kullanıcılar bu kademeden etkilenmez. Phased release'i istediğiniz zaman duraklatabilir veya hemen %100'e çıkarabilirsiniz.

Rollback Stratejisi

Mobil'de gerçek anlamda rollback yapamazsınız. Bunun yerine:

• Hotfix release: Sorunu düzelten yeni sürümü hızlıca yayınlayın
• Feature flag kapatma: Sorunlu özelliği uzaktan devre dışı bırakın
• Server-side kontrol: Backend'de versiyon bazlı farklı davranış
• Staged rollout durdurma: Tüm kullanıcılara ulaşmadıysa dağıtımı durdurun

Hotfix Süreci

1. Sorunu tespit et ve severity'sini belirle
2. main/release branch'ten hotfix branch'i oluştur
3. Minimal düzeltmeyi yap (yeni feature ekleme)
4. Smoke test uygula
5. Versiyon numarasını güncelle (patch increment)
6. Store'a gönder ve expedited review talep et

TestFlight ve Internal Testing

TestFlight (iOS): Internal testing (100 kişi, review gerektirmez), External testing (10.000 kişi, beta review gerekir). Crash raporları otomatik toplanır.

Google Play Internal Testing: Internal track (anında, review yok), Closed testing (Alpha), Open testing (Beta). Pre-launch report ile otomatik cihaz testi yapılır.

Her release'den önce en az internal testing aşamasından geçirin.

Release Notes Yazma

• Teknik jargondan kaçının ("API refactor" yerine "Daha hızlı yükleme süreleri")
• Bug fix varsa kabul edin ("Bilinen çökme sorunu giderildi")
• "Bug fixes and performance improvements" gibi genel ifadelerden kaçının

Release süreci bir pipeline'dır. Her aşamayı atlamamak ve süreci dokümante etmek, uzun vadede uygulamanızın kalitesini ve store puanınızı doğrudan etkiler.

İlgili Konular

• A/B Testing (Uygulama Ici)
• Remote Config & Feature Flags
• İlk Uygulama Yayınlama Checklist'i