Bu rehberde
İlk yedi gün, lansmanın işe yarayıp yaramadığını söyler ve sorunların düzeltilmesinin en ucuz olduğu zamandır. Bu liste süreli, böylece gün boyu panelleri izlemek zorunda kalmazsın. Her maddenin bir nedeni ve kontrol yolu var. Araçların farklı olabilir; sorular aynı kalır.
0. gün (lansman günü): çalışıyor mu?
| # | Madde | Neden | Nasıl kontrol edilir |
|---|---|---|---|
| 1 | Temiz bir cihaza canlı mağaza sürümünü kur | Mağaza build'i test build'inden farklı olabilir | Mağazadan kur, test bağlantısından değil; temel işi yap |
| 2 | Çökme ve hata raporlamanın canlı build'i gösterdiğini kontrol et | Veri yoksa kör olursun | Panelde canlı build numarasını bul |
| 3 | Arka ucu kontrol et: hatalar, yanıt süreleri, yük | Lansman trafiği gerçek sınırlara çarpar | Sunucu panelini belirli saatlerde aç (örneğin sabah ve akşam) |
| 4 | Kayıt ve, satıyorsan satın almayı gerçek bir hesapla kontrol et | Lansman sorunlarının en pahalıya mal olduğu yerler bunlar | İkisini de kendin tamamla |
1-3. günler: neler bozuluyor?
| # | Madde | Neden | Nasıl kontrol edilir |
|---|---|---|---|
| 5 | Her gün her çökme grubunu bir kez oku | Erken çökmeler genelde az ve düzeltilebilir | Etkilenen kullanıcılara göre sırala; cihaz/OS desenlerini not et |
| 6 | Her mağaza yorumunu ve destek mesajını oku | Erken yorumlar tonu belirler | Nazik ve somut yanıt ver; henüz bir üslubun yoksa yorumlara nasıl yanıt verilir yazısına bak |
| 7 | Karşılama sırasındaki kopmaları, takip ediyorsan kontrol et | En büyük kayıp genelde erken aşamadadır | Başlatılan ve tamamlanan adımları karşılaştır |
| 8 | Birkaç gerçek kullanıcıya tek bir soru sor | Sayılar ne olduğunu söyler, insanlar neden olduğunu | Ulaşabildiklerine kısa bir mesaj gönder |
| 9 | Hotfix mi, değil mi kararı ver: ana akışta çökme, veri kaybı, ödeme hatası | Bunlar hızlı bir güncellemeyi haklı çıkarır | Kuralı ihtiyacın olmadan önce yaz |
4-7. günler: ne öğrenmeliyiz?
| # | Madde | Neden | Nasıl kontrol edilir |
|---|---|---|---|
| 10 | Geri bildirimi temaya göre grupla | Tekrarlar tek şikâyetlerden daha önemlidir | Bir takip tablosu doldur ve say |
| 11 | Sıradaki düzeltmeye karar ver | Karar olmadan liste sadece büyür | Çabaya göre değil etkiye göre sırala: uygulama geri bildirimi nasıl önceliklendirilir |
| 12 | Mağaza sayfasını kontrol et: ekran görüntüleri ve metin, uygulamanın yapmadığı bir şeyi vaat ediyor mu? | Uyuşmazlık kötü yorum olarak geri döner | Yorum ifadelerini mağaza sayfanla karşılaştır |
| 13 | Bir düzeltme gelen herkese yanıt ver | Döngüyü kapatmak güven kazandırır | Yanıtında sürümü belirt |
| 14 | Haftanın kısa bir değerlendirmesini yaz | Sonraki lansman bundan yararlanır | Üç satır: neyin bozulduğu, neyin şaşırttığı, neyin değişmesi gerektiği |
Şablon: günlük kayıt
Tarih: [ ] Canlı sürüm: [ ]
Çökmeler (yeni / toplam): [ ] En çok çöken: [ ]
Okunan yorumlar / mesajlar: [ ] Temalar: [ ]
Arka uç sorunları: [ ]
Bugünkü karar: [ ] yok [ ] hotfix [ ] sonraki sürüm
Uyarla
Tek başına çalışan geliştirici: 0-3. günleri günde iki kısa oturumda yap. Ekip: her satır için bir sorumlu ata. Araç olmadığın satırları atla, ama orada kör olduğunu not et. Kullanıcılardan karşılığında uygulamayı puanlamalarını isteme; yanıt vermek ve düzeltmek senin işin, puan vermek onların.
İlgili
- Merkez: Mobil uygulama test kontrol listesi merkezi
- Uygulama güncelleme yayın kontrol listesi
- Yeni uygulama dili yayınlama kontrol listesi
AppReviewX, sorun daha fazla kullanıcıya görünmeden önce 4-7. günlerde kullanabileceğin özel ve yapılandırılmış geri bildirim verir. Yazdığın her geri bildirim 1 kredi; yeni hesaplar 0 krediyle başlar. Ücretsiz başla.