Yeni Mobil Uygulamalar İçin Kullanılabilirlik (UX) ve Performans Testi: Adım Adım Rehber
Yeni bir mobil uygulamada “çalışıyor” olmak yetmez: Kullanıcıların işi hızlıca yapabilmesi (kullanılabilirlik) ve uygulamanın akıcı/kararlı kalması (performans ve stabilite) birlikte ele alınmadığında, gerçek sorunlar genellikle yayına çıktıktan sonra görünür olur. Bu rehber iki hattı paralel kurar:
- Saha verisi (field telemetry): Gerçek cihaz ve ağ koşullarında crash/ANR/donma, yavaş açılış ve ağ gecikmesi gibi sinyaller.
- Laboratuvar testleri (lab): Kontrollü koşullarda profilleme, yeniden üretme (repro) ve görev bazlı UX testleri.
Android tarafında Google Play Console Android Vitals içindeki metrikler, uygulama kalitesini izlemek için resmi bir çerçeve sunar. Android vitals | App quality
Test stratejisini 30 dakikada netleştirin: hedef, kapsam, başarı ölçütü
1) Hedefleri yazın (tek sayfa)
- Kullanılabilirlik hedefi: Kullanıcılar ana akışları (ör. kayıt olma, arama, ödeme, içerik paylaşma) yardım almadan tamamlayabiliyor mu?
- Performans hedefi: Uygulama açılış, ekran geçişleri ve ağ isteklerinde “yavaş” hissi yaratıyor mu; crash/ANR/hang sinyalleri var mı?
2) Kapsamı sınırlayın (kritik akış listesi)
İlk turda her şeyi test etmeye çalışmak yerine 5–7 kritik akış belirleyin. Örnek:
- İlk açılış ve izinler
- Hesap oluşturma / giriş
- Ana ekran ve ilk içerik yükleme
- Arama/filtreleme
- Sepete ekleme / ödeme (varsa)
- Bildirim tıklayıp ilgili ekrana gitme
3) Başarı ölçütlerini tanımlayın (ölçülebilir ve izlenebilir)
- Görev başarı ölçütleri: Görev tamamlanma, takılma noktaları, hata türleri, kullanıcı ifadeleri.
- Teknik ölçütler: Crash/ANR/hang oranları (saha), ağ gecikmesi ve özel izler (trace) gibi performans sinyalleri.
Not: Platformların metrik adları ve raporlama biçimleri farklıdır. Buradaki amaç tek bir “skor” yaratmak değil, aynı problemi iki pencereden (kullanıcı davranışı + telemetri/profil) yakalamaktır.
Adım adım kullanılabilirlik (UX) testi: kısa görevler, gerçekçi senaryolar
Mobil bağlamda oturumlar çoğu zaman kısadır; bu yüzden UX testini uzun mülakat yerine kısa görevler ve net senaryolar üzerinden kurgulamak daha verimlidir. Parmak hedefleri ve içerik önceliği gibi mobil-davranışa özgü kontroller de önemlidir. Bu bakış açısı NN/g’nin mobil kullanılabilirlik derlemelerinde vurgulanır. Progress in Mobile User Experience
1) Senaryoları görev cümlelerine çevirin
- “E-posta ile hesap aç ve ana ekrana gel.”
- “İstediğin ürünü/konuyu arayıp filtrele ve birini favorilere ekle.”
- “Bir bildirimden gelen içeriği aç ve geri dön.”
2) Mobilde kritik UX kontrolleri (hızlı kontrol listesi)
- Parmak hedefleri: Dokunulabilir alanlar çok küçük mü; yanlış dokunma oluyor mu?
- İçerik önceliği: En önemli bilgi ilk ekranda anlaşılır mı?
- Hata toleransı: Geri alma/iptal mümkün mü; hata mesajı açıklayıcı mı?
- Boş durumlar: İlk kullanımda boş ekranlar kullanıcıyı yönlendiriyor mu?
- Yükleme durumları: Gecikmede “dondu” hissini azaltan geri bildirim var mı?
3) Oturumu yürütün: düşünerek ilerleme + zaman damgaları
- Görev tamamlandı mı; nerede takıldı?
- Kullanıcı hangi ifadeleri kullandı?
- Hangi ekranda geri döndü, neden?
- “Yavaş” dediği anlar hangileri? (mümkünse zaman damgası ekleyin)
İpucu: UX testinde “yavaş” diye işaretlenen anlar, birazdan kuracağınız telemetri/profil analizinde doğrudan hedef olur.
Performans ve stabilite testi: saha telemetrisi + profilleme
1) Android: Play Console Android Vitals ile temel sinyalleri izleyin
Android tarafında düzenli bir Android Vitals kontrol rutini oluşturun. Resmi dokümantasyon, vitals metriklerinin uygulama kalitesini izlemek için nasıl kullanıldığını ve bazı metriklerin 28 günlük hareketli pencere ile takip edildiğini açıklar. Android vitals | App quality
- Ne ararsınız? Crash ve ANR kümeleri, “emerging issues” (yeni beliren sorunlar) ve trendler.
- Nasıl kullanılır? Etkilenen kullanıcı sayısı ve tekrar oranına göre önceliklendirin; ardından lab ortamında repro/profil çalışmasına geçin.
2) Android: Firebase Performance Monitoring ile ölçüm kurun (neyi ölçer?)
Firebase Performance Monitoring’i, resmi “Get started” kılavuzunda tarif edildiği şekilde SDK entegrasyonu, test sırasında veri doğrulama ve ihtiyaç duyduğunuz akışlara custom trace ekleme amacıyla konumlandırın. Bu yaklaşım, performansı “tahmin” etmek yerine uygulamanın içinden ölçmenizi sağlar. Get started with Performance Monitoring for Android
Uygulanabilir bir kurulum sırası:
- SDK entegrasyonunu resmi kılavuza göre tamamlayın.
- Test build’lerinde debug doğrulaması yapın: performans verisi panellere geliyor mu?
- Custom trace ekleyin: Örn. feed_load, search_results_render, checkout_submit. (Akış/ekran bazlı ölçümü siz tanımlarsınız.)
- Release öncesi aynı akışları farklı cihaz/ağ koşullarında çalıştırıp karşılaştırın.
3) iOS: Instruments ile hang (donma) ve ana iş parçacığı analizi
iOS tarafında “uygulama dondu” hissi çoğu zaman ana iş parçacığında bloklanma ile ilişkilidir. Apple’ın WWDC23 oturumu, Instruments ile hang analizi ve kök neden bulma akışını ele alır; ayrıca ana iş parçacığında yapılan işlerin mümkün olduğunca kısa tutulmasına (ör. ~100 ms ölçeği) dikkat çeker. Analyze hangs with Instruments — WWDC23
- Problemin görüldüğü akışı netleştirin (hangi ekranda, hangi etkileşimde?).
- Instruments ile kaydı başlatın, akışı tekrar edin.
- Hang/Thread State görünürlükleriyle ana iş parçacığındaki bekleme anlarını işaretleyin.
- Time Profiler ile CPU örneklemesini inceleyin: hangi fonksiyonlar süreyi uzatıyor?
- Düzeltin ve aynı senaryoda yeniden ölçün.
Test matrisi (lab + saha): cihaz katmanları, OS sürümleri, ağ koşulları
Performans ve kullanılabilirlik sorunları çoğu zaman belirli cihaz/OS/ağ kombinasyonlarında ortaya çıkar. Bu yüzden “tek cihazda geçti” yerine, küçük ama temsil gücü yüksek bir test matrisi belirleyin:
- Cihaz katmanları: düşük/orta/üst seviye (en az 1’er cihaz).
- OS sürümleri: minimum desteklediğiniz sürüm + yaygın 1–2 yeni sürüm.
- Ağ koşulları: Wi‑Fi, hücresel, zayıf ağ/packet loss simülasyonu ve kısa süreli offline.
- Durum geçişleri: arka plan/ön plan, ekran döndürme (varsa), soğuk/ılık başlatma senaryoları.
Saha telemetrisi (Vitals/Performance Monitoring) “hangi kombinasyonlar sorun çıkarıyor?” sorusunu işaretler; lab profilleme ise “neden?” sorusuna iner.
Crash/ANR/hang sinyali geldiğinde: saha verisini repro ile tamamlayın
Crash/ANR/hang sinyalleri saha verisiyle hızlı yakalanır; çözüm ise çoğu zaman laboratuvarda yeniden üretme (repro) gerektirir. Bu nedenle iki aşamalı bir rutin kullanın:
- Saha: Android Vitals ve Performance Monitoring panellerinde en çok kullanıcıyı etkileyen kümeleri belirleyin. Android vitals / Firebase Performance Monitoring
- Lab: Aynı OS sürümü, cihaz sınıfı ve adımlarla repro yapın; Instruments/profiler ile kök nedeni doğrulayın. WWDC23 Instruments
Önceliklendirme: hangi sorun önce çözülmeli?
- Yaygınlık: Kaç kullanıcıyı etkiliyor? (saha)
- Şiddet: Görevi engelliyor mu (crash/ANR/hang), yoksa “rahatsız edici” mi?
- Tekrarlanabilirlik: Lab ortamında reprodu edilebiliyor mu?
- Çözüm maliyeti: Hızlı düzeltme mi, mimari değişiklik mi?
Pratik bir karar tablosu
| Sinyal | İlk hareket | Sonraki adım |
|---|---|---|
| Crash kümesi artıyor | En büyük kümeleri belirle | Lab’da repro + kök neden analizi |
| ANR / donma hissi | Hangi ekranda/etkileşimde? | Instruments/Profiler ile main thread analizi |
| “Yavaş” geri bildirimi | Akışı zaman damgasıyla işaretle | Firebase custom trace + ağ/başlatma sinyallerine bak |
| UX testinde görev başarısız | Takılma noktasını kaydet | Akış sadeleştir + yeniden test |
Release öncesi kontrol listesi (kopyala-yapıştır)
Kullanılabilirlik
- Kritik akış görevleri yazılı ve en az bir tur test edildi
- Parmak hedefleri ve yanlış dokunmalar notlandı, düzeltildi
- Boş durumlar ve hata mesajları yönlendirici
- Yükleme anlarında kullanıcıya geri bildirim var
Performans ve stabilite
- Android Vitals panelleri kontrol edildi; crash/ANR için plan çıkarıldı (kaynak)
- Firebase Performance Monitoring kuruldu; test build’lerinde veri akışı doğrulandı (kaynak)
- Performans kritik akışlar için en az 1–3 adet custom trace eklendi
- iOS’ta Instruments ile en az bir kritik akışta hang/main thread incelemesi yapıldı (kaynak)
Operasyonel
- Haftalık izleme rutini belirlendi (trend + yeni beliren sorun taraması)
- Saha verisiyle gelen sorunlar için “repro adımı” tanımlandı
Sonuç: tek seferlik test değil, döngü kurun
Kaliteyi yükselten şey tek bir test oturumu değil; ölçüm kurma → test etme → düzeltme → yeniden ölçme döngüsüdür. Android’de Play Console Android Vitals ile saha trendlerini izlemek; Firebase Performance Monitoring ile ağ/başlatma ve sizin tanımladığınız custom trace’lerden sinyal toplamak; iOS’ta Instruments ile hang ve main thread darboğazlarını analiz etmek bu döngünün pratik temel taşlarıdır. UX tarafında ise kısa görevler ve mobil etkileşime özgü kontroller, “kullanıcı yapabiliyor mu?” sorusuna hızlı yanıt verir.