Yazılım ve performans / DIJION
Mobil uygulama ve oyunlar için kalite test matrisi
Kritik görevleri cihaz, bağlantı, veri ve kesinti koşullarıyla eşleştirerek uygulanabilir bir yayın kontrolü hazırlayın.
“Telefonda çalışıyor” tek başına bir test sonucu değildir. Hangi telefon, hangi görev, hangi bağlantı ve hangi veriyle çalıştığını bilmek gerekir. Küçük bir ekip için her olasılığı denemek mümkün olmayabilir; ancak kritik akışları ve riskleri açıkça seçmek mümkündür. Bu rehber belirli bir ürüne ait ölçüm veya sorunsuz çalışma garantisi sunmaz.
Önce kritik görevleri seçin
Bir uygulamada kayıt oluşturma veya bilgiye erişme; bir oyunda ilk bölüme başlama, kontrolü kullanma ve kesintiden dönme kritik olabilir. Kullanıcıyı durduran, veri kaybettiren veya yanlış sonuç üreten akışlara öncelik verin. Görsel ayrıntıların listesiyle başlamayın.
Her görev için başlangıç koşulunu ve beklenen sonucu yazın. “Form çalışıyor” yerine “Geçerli giriş gönderildiğinde onay gösterilir; başarısızlıkta metin korunur” gibi gözlenebilir bir ifade kullanın. Sonucu doğrulamak için gerçek kullanıcı verisi gerekmez; kontrollü test kayıtları yeterlidir.
Matrisi anlamlı koşullarla kurun
Tüm sütunlar için tabloyu yatay kaydırabilirsiniz.
| Boyut | Örnek koşullar | Aranan risk |
|---|---|---|
| Cihaz ve ekran | Küçük/büyük ekran; desteklenen düşük kapasiteli cihaz | Taşma, kesilme, yavaş tepki |
| Dil ve metin | Türkçe/İngilizce; uzun içerik; büyük sistem metni | Kaybolan etiket veya eylem |
| Bağlantı | Normal, yavaş, kopan, yeniden gelen | Sonsuz yükleme veya yinelenen işlem |
| Veri | İlk kullanım, mevcut veri, boş sonuç, hatalı giriş | Yanlış boş durum veya kayıp veri |
| Kesinti | Arka plan, kilit ekranı, uygulamaya geri dönüş | Kaybolan ilerleme veya hazırlıksız devam |
| Erişilebilirlik | Ekran okuyucu; renk dışı işaretler; azaltılmış hareket | Anlaşılmayan durum veya erişilemeyen eylem |
Bütün boyutların tüm kombinasyonlarını koşulsuz çoğaltmak test maliyetini hızla artırır. Önce yüksek riskli çiftleri seçin: küçük ekran ve uzun çeviri, gönderim ve bağlantı kesilmesi, oyun sırasında arka plana geçiş. Ardından ürünün gerçek kullanımına göre kapsamı genişletin.
Tekrarlanabilir senaryo kartı yazın
Tüm sütunlar için tabloyu yatay kaydırabilirsiniz.
| Alan | Örnek |
|---|---|
| Kimlik | CONTACT-RETRY-01 |
| Ön koşul | Form doldurulmuş; test servisi kontrollü |
| Adımlar | Gönder; bağlantıyı kes; sonucu gözle; yeniden bağlan |
| Beklenen | Giriş korunur; sonuç doğru anlatılır; mükerrer gönderim oluşmaz |
| Kanıt | Ekran kaydı veya hata metni; sürüm ve cihaz |
| Sonuç | Geçti / kaldı / test edilemedi |
“Test edilemedi” seçeneğini koruyun. Eksik cihazı veya erişilemeyen servisi geçti diye işaretlemek, sonraki sürümde yanlış güven yaratır. Hata kaydında kişisel içerik yerine test verisi kullanın; ekran görüntüsünde hesap bilgisi görünmediğini kontrol edin.
Performansı doğru ölçümle değerlendirin
Açılış gecikmesi, takılma, çökme ve uzun süren işlemler farklı sorunlardır. Aynı cihaz ve senaryoda tekrar edilebilir koşullar belirleyin; tek bir hızlı denemeyi bütün kullanıcılar için sonuç saymayın. Android vitals gibi platform araçları, yayımlanmış uygulamaların gerçek kullanım sinyallerini ayrıca değerlendirmeye yardımcı olabilir.
Web için Lighthouse puanı, native uygulama performansını ölçmez. Laboratuvar ölçümü ile gerçek kullanıcı ölçümü de ayrı kaynaklardır. INP, LCP veya CLS gibi web metriklerini mobil oyun kare süresiyle aynı başlıkta başarılı ilan etmeyin. Ölçümün platformunu, koşulunu ve sınırını yazın.
Bulgunun etkisini ve tekrar koşulunu ayırın
Kritik bir veri kaybı seyrek görünse bile yüksek öncelik taşıyabilir. Sık görülen küçük bir hizalama sorunu ise aynı aciliyette olmayabilir. Önem derecesini kullanıcı etkisiyle, tekrar koşulunu ise yeniden üretme adımlarıyla kaydedin. Böylece ekip “kaç kez oldu?” ile “ne kadar zarar veriyor?” sorularını karıştırmaz.
- P0: Kritik görevi durduran veya ciddi veri kaybı oluşturan doğrulanmış durum.
- P1: Ana akışı zorlaştıran ve kullanıcıların toparlanmasını güçleştiren sorun.
- P2: Kullanımı etkileyen ama alternatif yol bulunan iyileştirme.
- P3: Düşük etkili, sonraki geliştirmelerle ele alınabilecek ayrıntı.
Yayın kararını kanıtla ilişkilendirin
Kritik senaryoların sonucu, açık kalan hatalar, test edilmeyen koşullar ve geri dönüş seçeneği birlikte gözden geçirilmelidir. Bir düzeltmeden sonra etkilenen akışı ve komşu davranışları yeniden kontrol edin. Amaç her sürümde aynı uzun listeyi mekanik biçimde tekrarlamak değil; değişen risklere göre anlamlı kanıt toplamaktır.