Bir mobil uygulamanın başarısı yalnızca arayüz kalitesiyle ölçülmez. Yayına çıktıktan sonra yaşanan çökme, giriş sorunları, veri sızıntısı ya da bazı cihazlarda sorunsuz çalışırken başka modellerde bozulan ekranlar, projenin itibarını kısa sürede zedeler. İyi planlanmış bir mobil uygulama test süreci, geliştirme ekibinin son hafta panik içinde hata kapatmasına değil; risklerin sprint boyunca görünür olmasına odaklanır.
Buradaki kritik nokta, testi projenin sonuna sıkıştırmamaktır. Örneğin 12 haftalık bir mobil proje düşünelim. Test faaliyetleri yalnızca 11. haftada başlarsa, kullanıcı kabul testinde bulunan bir hata; analiz, geliştirme, yeniden test ve mağaza yayını takvimini doğrudan sarkıtır. Buna karşılık her sprintte fonksiyonel test yapan, her sürümde cihaz matrisi kontrolünü yürüten ve yayın öncesinde güvenlik taraması uygulayan ekipler daha öngörülebilir sonuçlar alır.
Bu yazıda, yayın öncesi hata oranını düşürmeye yardımcı olan pratik bir planı ele alacağız: test aşamaları, UAT kurgusu, cihaz testi yaklaşımı ve güvenlik kontrol listesi. Amaç teorik bir çerçeve çizmek değil; gerçek projelerde uygulanabilir bir akış sunmak.
Mobil uygulama test süreci ne zaman başlamalı?
Kısa cevap: geliştirme ile aynı anda. Test planı, ilk satır kod yazıldıktan sonra değil; kapsam netleştiğinde hazırlanmalıdır. En azından şu dört başlık proje başlangıcında tanımlanmalıdır: kapsam, riskli modüller, desteklenecek cihazlar ve yayın kabul kriterleri.
Somut bir senaryo üzerinden ilerleyelim. Bir B2C mobil uygulamada kullanıcıların kayıt olduğunu, OTP ile doğrulama yaptığını, kart kaydettiğini ve bildirim aldığını düşünelim. Bu yapıda en yüksek riskli alanlar çoğu zaman ana sayfa tasarımı değil; oturum yönetimi, ödeme akışı, bildirim izinleri ve düşük bağlantıda uygulamanın nasıl davrandığıdır. Test planı da bu modüllere ağırlık vermelidir.
Sağlıklı bir başlangıç planında şu zamanlama işe yarar:
- 1. hafta: test stratejisi, kabul kriterleri, cihaz listesi
- 2-3. hafta: temel akışlar için test senaryoları
- Her sprint sonunda: regresyon ve kritik akış kontrolü
- Yayından 7-10 gün önce: UAT, güvenlik kontrolleri, mağaza hazırlığı
Burada “her şeyi test edelim” yaklaşımı çoğu ekipte işe yaramaz. Önceliklendirme şarttır. Kullanıcının para ödediği, veri paylaştığı, hesap oluşturduğu veya kimlik doğruladığı akışlar ilk sırada yer alır.
Test planı hangi katmanlardan oluşmalı?
Tek bir test türü yeterli değildir. Mobil projelerde sorunlar farklı katmanlarda ortaya çıkar: iş kuralı, arayüz, cihaz uyumu, ağ koşulları, güvenlik ve mağaza gereksinimleri. Bu nedenle planın katmanlı olması gerekir.
1) Fonksiyonel testler
Uygulamanın beklenen işi yapıp yapmadığını kontrol eder. Kayıt ol, giriş yap, şifre sıfırla, profil güncelle, ödeme tamamla, sipariş geçmişini görüntüle gibi akışlar burada yer alır. İyi bir fonksiyonel test setinde yalnızca “mutlu yol” değil, hatalı girişler de bulunur. Mesela 6 haneli OTP ekranında 5 hane girildiğinde ne olur? Arka planda süre dolduğunda sayaç doğru şekilde yenilenir mi?
2) Regresyon testleri
Yeni geliştirilen bir özelliğin, daha önce çalışan alanları bozup bozmadığını kontrol eder. Özellikle 2 haftalık sprint düzeninde çalışan ekiplerde her sürüm için kısa bir regresyon paketi gerekir. Tipik olarak 15-30 kritik senaryodan oluşan bir set, yayın adayı sürümde yeniden çalıştırılır.
3) Kullanılabilirlik testleri
Bazı hatalar teknik değildir ama yine de dönüşümü düşürür. Örneğin “Devam Et” butonu küçük ekranlı bir cihazda klavyenin altında kalıyorsa uygulama teknik olarak çalışıyor olabilir; ancak kullanıcı işlemi tamamlayamaz. 5 kişilik küçük bir pilot kullanıcı grubuyla yapılan gözlem bile bu tür sorunları erken yakalar.
4) Performans ve ağ davranışı testleri
Mobil uygulamalar yalnızca kusursuz Wi‑Fi ortamında değil, zayıf 4G bağlantısında da çalışmalıdır. Ekran açılış süreleri, timeout davranışı, çevrimdışı mesajları ve tekrar deneme akışları kontrol edilmelidir. Örneğin ürün listesi API'si 8 saniyede yanıt verirse kullanıcıya boş ekran mı gösteriliyor, yoksa yükleniyor durumu ve geri bildirim mi veriliyor?
UAT nasıl kurgulanmalı? Kabul testi neden son anda yapılmamalı?
UAT, yani kullanıcı kabul testi, teknik ekibin değil iş biriminin “bu ürün kullanıma hazır” dediği aşamadır. Buradaki amaç yalnızca bug bulmak değildir. Gerçek iş akışının, beklendiği şekilde karşılanıp karşılanmadığı ölçülür.
UAT tarafında sık yapılan hata, geliştirme bittikten sonra bir Excel listesi gönderip hızlı onay istemektir. Daha sağlam yöntem, senaryoları rol bazlı hazırlamaktır. Örneğin saha ekibi uygulamayı kullanacaksa bir UAT senaryosu şöyle yazılabilir: “Kullanıcı sabah 08:30’da düşük çekim gücü olan bir bölgede giriş yapar, müşteri kaydı açar, fotoğraf yükler ve taslak olarak kaydeder.” Bu senaryo, ofiste yüksek hızlı internet altında yapılan basit bir kontrolden çok daha değerlidir.
UAT planında en az şu unsurlar yer almalıdır:
- Teste katılacak kullanıcı rolleri: operasyon, satış, bayi, son kullanıcı temsilcisi
- Her rol için 8-15 gerçek senaryo
- Onay kriteri: kritik hata 0, yüksek öncelikli açık hata kabul edilmiş sınırın altında
- Test süresi: çoğu projede 2 ila 5 iş günü
- Geri bildirim formatı: ekran görüntüsü, cihaz modeli, işletim sistemi sürümü, tekrar adımları
UAT bulgularını “istek” ve “hata” olarak ayırmak da önemlidir. “Buton rengini değiştirelim” bir iyileştirme olabilir. “Şifre sıfırlama e-postası hiç gelmiyor” ise yayını durdurabilecek düzeyde bir hatadır.
Cihaz testi nasıl planlanmalı? Her model test edilmeli mi?
Hayır. Piyasadaki tüm cihazlarda test yapmak gerçekçi değildir. Buradaki hedef, uygulamanın kullanıcı tabanını temsil eden bir cihaz matrisi oluşturmaktır. Matris oluşturulurken işletim sistemi sürümü, ekran boyutu, üretici farklılıkları ve donanım özellikleri dikkate alınır.
Pratik bir yaklaşım, cihazları dört eksende seçmektir: iOS/Android dağılımı, eski-yeni işletim sistemi sürümü, küçük-büyük ekran, düşük-orta-yüksek donanım sınıfı. Örneğin 8 cihazlık bir başlangıç matrisi, erken aşamada ciddi görünürlük sağlar. Ardından analitik veriye göre bu liste güncellenir.
Cihaz testinde mutlaka kontrol edilmesi gereken alanlar:
- Farklı ekran çözünürlüklerinde layout bozulması
- Klavye açıldığında form alanlarının görünürlüğü
- Kamera, konum, galeri, biyometrik giriş izinleri
- Push notification davranışı
- Arka plandan geri dönüş ve uygulama yaşam döngüsü
- Düşük batarya veya zayıf ağ koşulunda kararlılık
Özellikle Android tarafında üretici özelleştirmeleri sürprizler çıkarabilir. Aynı Android sürümünde iki farklı marka cihaz, bildirim veya dosya erişim izinlerini farklı şekillerde yönetebilir. Bu yüzden yalnızca emülatör kullanmak yeterli değildir. Kritik akışlar gerçek cihazda mutlaka görülmelidir.
Kurumsal projelerde sık karşılaşılan bir başka konu da MDM veya kurumsal güvenlik politikalarıdır. Eğer uygulama şirket cihazlarına yüklenecekse, test ortamında bu kısıtlar da simüle edilmelidir. Aksi halde uygulama laboratuvarda çalışır, sahada açılmaz.
Yayın öncesi güvenlik kontrol listesi
Mobil uygulama güvenliği yalnızca giriş ekranına parola koymaktan ibaret değildir. Uygulama ile API arasındaki trafik, cihazda tutulan veriler, oturum süresi, yetki kontrolleri ve üçüncü parti SDK'lar birlikte ele alınmalıdır. Yayın öncesinde uygulanacak kısa ama disiplinli bir kontrol listesi büyük fark yaratır.
Temel güvenlik kontrolleri
- HTTPS zorunluluğu: Tüm API trafiği TLS üzerinden çalışmalı. Düz HTTP çağrısı kalmamalı.
- Token yönetimi: Erişim anahtarları güvenli biçimde saklanmalı; süresi dolan token için yenileme akışı tanımlanmalı.
- Hassas veri saklama: Şifre, kart verisi, kimlik bilgisi düz metin olarak cihazda tutulmamalı.
- Sunucu tarafı yetki kontrolü: Kullanıcı arayüzünde butonu gizlemek yetmez; API tarafında rol doğrulaması yapılmalı.
- Log temizliği: Üretim loglarında OTP, token, kişisel veri ya da ham hata yığınları yer almamalı.
- Üçüncü parti SDK incelemesi: Kullanılan kütüphanelerin izinleri ve veri toplama davranışı gözden geçirilmeli.
Kontrol edilmesi gereken pratik senaryolar
Test ekibi şu senaryoları özellikle denemelidir: Oturum kapatıldıktan sonra geri tuşuyla korumalı ekrana dönülebiliyor mu? Parola sıfırlama linki tekrar kullanılabiliyor mu? Aynı kullanıcı hesabı iki cihazda eşzamanlı oturum açtığında beklenen davranış ne? API isteğinde kullanıcı kimliği değiştirilirse başka hesaba ait veri dönüyor mu?
Eğer proje KVKK kapsamındaki kişisel verileri işliyorsa, veri minimizasyonu ve erişim yetkileri ayrıca gözden geçirilmelidir. Burada hukuki değerlendirme ayrı bir başlıktır; ancak teknik ekibin en azından hangi verinin neden toplandığını açıkça belgelemesi gerekir.
Yayın adayı sürüm için son kontrol akışı
Uygulama mağazaya gönderilmeden önce “release candidate” sürüm üzerinde kısa ama net bir geçiş kapısı tanımlanmalıdır. Bu akış çoğu projede 1 iş günü ile 3 iş günü arasında tamamlanabilir.
- Build numarası ve ortam ayarları kontrol edilir.
- Kritik akış regresyonu gerçek cihazlarda çalıştırılır.
- UAT bulgularının kapandığı doğrulanır.
- Crash reporting ve analytics araçlarının üretim yapılandırması gözden geçirilir.
- Gizlilik politikası, izin metinleri, mağaza ekran görüntüleri ve açıklamalar tamamlanır.
- Son güvenlik checklist'i imzalanır.
Burada küçük bir ayrıntı önemlidir: test edilen build ile mağazaya yüklenen build aynı olmalıdır. Son anda yapılan “küçük bir düzeltme” yeni risk üretir. Eğer düzeltme kaçınılmazsa, ilgili regresyon testleri yeniden çalıştırılmalıdır.
Başarılı bir mobil test süreci için operasyonel öneriler
Teknik doğruluk kadar süreç disiplini de belirleyicidir. Hata kayıtlarında tekrar adımları, ekran görüntüsü, uygulama sürümü ve cihaz bilgisi yoksa çözüm süresi uzar. Aynı şekilde, hangi hatanın yayını engellediği baştan tanımlanmadıysa ekipler gereksiz tartışmalara girer.
İşe yarayan birkaç operasyonel uygulama şunlardır:
- Kritik, yüksek, orta, düşük öncelik sınıflandırmasını proje başında netleştirin.
- Her hata kaydına cihaz modeli ve OS sürümü zorunlu alan olarak ekleyin.
- Her sprint sonunda 20-30 dakikalık hata triyaj toplantısı yapın.
- Canlıya çıktıktan sonra ilk 7 gün crash ve performans verilerini günlük izleyin.
Yayın öncesi kaliteyi artıran ekipler, test yükünü yalnızca QA ekibine bırakmaz. Geliştirici birim test yazar, iş birimi UAT’ye aktif katılır, ürün sahibi kabul kriterlerini netleştirir. Kalite ortak sorumluluktur.
Özetle, etkili bir mobil uygulama test süreci; erken planlama, gerçekçi cihaz matrisi, rol bazlı UAT senaryoları ve yayın öncesi güvenlik kontrolleri üzerine kurulur. Bu yapı kurulduğunda hedef “hiç hata çıkmaması” değildir. Asıl hedef, kritik hataların kullanıcıdan önce ekip tarafından yakalanmasıdır. Sağlam bir test planı da tam olarak bunu sağlar.
