Mobil Uygulama Testi: QA, Beta ve Yayın Öncesi Kontroller

Mobil uygulama testi, bir uygulamanın işlev, performans, cihaz uyumluluğu, güvenlik ve erişilebilirlik açısından mağazaya çıkmadan önce doğrulanmasıdır. Sağlam bir süreç dört katmandan oluşur: geliştirici testleri, QA ekibinin cihaz matrisi testleri, TestFlight ve Google Play kapalı testiyle beta ve yazılı kabul kriterlerine dayanan yayın kararı.

Bu katmanlardan birini atlamanın bedeli somut. Apple'ın 2025 App Store Transparency Report verisine göre mağaza ekibi yıl boyunca 9,1 milyon başvuruyu inceledi ve 2,09 milyonunu reddetti. Eksik uygulama, çökme, yanıltıcı metadata ve uyumluluk sorunlarını kapsayan performans kategorisinde red sayısı 1.354.418 oldu. Bu rakam tasarım, hukuk, iş modeli ve güvenlik kategorilerinin toplamından bile yüksek.

Türkiye'de tablo Android tarafında daha karmaşık. StatCounter verisine göre Ağustos 2026'da Türkiye'deki mobil cihazların %73,76'sı Android kullanıyor ve tek bir Android sürümünün payı %21'i geçmiyor. Uygulamayı yalnızca geliştiricinin telefonunda denediyseniz, kullanıcılarınızın büyük bölümünün cihazını hiç test etmediniz demektir.

Bu rehber, uygulama yayınlama sürecini anlattığımız yazının bir adım öncesine odaklanıyor. Test türlerini, cihaz matrisini, beta kanallarının güncel kurallarını, hata raporlama düzenini ve yayın kararını veren kabul kriterlerini sırayla işliyoruz.

Bu rehberde neler var?

• Mobil uygulama testi neden yayın tarihini belirler?
• Test türleri: neyi, ne zaman test etmelisiniz?
• Cihaz matrisi: hangi telefonlarda test etmeli?
• Manuel test mi, test otomasyonu mu?
• Beta testi: TestFlight ve Google Play test kanalları
• Hata raporlama düzeni
• Kabul kriterleri ve yayın kararı
• Yayından sonra: kademeli dağıtım ve izleme
• Türkiye pazarına özel test kontrolleri
• Sıkça Sorulan Sorular

Mobil uygulama testi neden yayın tarihini belirler?

Testi takvimin sonuna eklenen bir hafta gibi düşünmeyin. İki mağazanın kuralları da mobil uygulama testini doğrudan yayın tarihine bağlar.

Apple, App Review Guidelines 2.1 maddesinde uygulamayı göndermeden önce gerçek cihazda hata ve kararlılık testi yapmanızı açıkça ister. Giriş ekranı olan uygulamalar için demo hesap bilgisi ve çalışır durumda bir backend de bekler. Çöken veya bariz teknik sorun gösteren derlemeleri reddeder.

Google Play tarafında test bir ön koşuldur. Play Console kuralına göre 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesapları, en az 12 test kullanıcısıyla ve 14 gün kesintisiz kapalı test yapmadan üretim erişimine başvuramaz. Başvurunun incelemesi de genellikle 7 gün veya daha kısa sürer.

Mağazalar kaliteyi yayından sonra da ölçer. Android vitals, son 28 günlük veride kullanıcının fark ettiği çökme oranı %1,09'u veya ANR oranı %0,47'yi aşan uygulamayı "kötü davranış" eşiğinde sayar. Tek bir telefon modeli için eşik %8'dir. Uygulama eşiği geçerse Play uygulamanın görünürlüğünü düşürebilir ve mağaza sayfasında kullanıcıya uyarı gösterebilir.

Düşük yazılım kalitesinin makro maliyeti de hesaplanmış durumda. CISQ'nun 2022 raporu, yalnızca ABD'de bu maliyeti en az 2,41 trilyon dolar olarak tahmin ediyor. Mobil uygulama testine ayırdığınız zaman, bu maliyetin projenizdeki karşılığını en ucuz aşamada yakalar.

Test türleri: neyi, ne zaman test etmelisiniz?

Her test türü farklı bir riski yakalar. Aşağıdaki tablo, küçük ve orta ölçekli bir uygulama projesinde hangi testi hangi aşamada koşmanız gerektiğini özetliyor.

Fonksiyonel test ve regresyon. Fonksiyonel testin temeli, her kritik akış için yazılmış test senaryosudur. Kayıt, giriş, şifre sıfırlama, sepet ve ödeme akışlarını yalnızca "mutlu yol" ile denemeyin. Yanlış şifre, yarıda kesilen ödeme ve süresi dolmuş oturum gibi olumsuz senaryolar, gerçek kullanıcıların sık yaşadığı durumlardır. Regresyon seti ise bu senaryolardan her sürümde yeniden koşan alt kümedir.

Performans, pil ve ağ testi. Soğuk açılış süresini, kaydırma akıcılığını ve bellek kullanımını gerçek cihazda ölçün. Android Studio Profiler ve Xcode Instruments bu iş için ücretsiz araçlardır. Ağ testinde bağlantıyı yavaşlatın, uçak modunu açıp kapatın ve bir isteğin ortasında bağlantıyı kesin. Uygulama hata mesajı göstermek yerine donuyorsa, kullanıcı bunu çökme gibi algılar.

Kesinti ve güncelleme testi. Mobil kullanıcı uygulamayı sessiz bir masada kullanmaz. Form doldururken telefon çalar, uygulama arka plana düşer, işletim sistemi belleği boşaltmak için süreci kapatır. Gelen arama, bildirim, ekran kilidi ve arka plandan dönüş sonrasında girilen verinin korunduğunu test edin. İzin ekranlarında "reddet" seçeneğini de deneyin; konum veya kamera izni vermeyen kullanıcıda uygulama çökmemeli, ne yapması gerektiğini anlatmalıdır. Güncelleme testi en sık atlanan kontroldür: mağazadaki mevcut sürümü kurun, veri oluşturun, ardından yeni sürüme geçin. Oturum, yerel veritabanı ve kayıtlı ayarlar güncellemeden sonra yerinde durmalıdır.

Bellek tarafı yakında mağaza görünürlüğünü de etkileyecek. Android vitals belgelerine göre Google, bellek kullanımı ve kod optimizasyonu eşiklerini aşan uygulamalarda Şubat 2027'den itibaren görünürlüğü düşürmeye başlayabilir.

Güvenlik ve erişilebilirlik testi. Güvenlik testinde token'ların cihazda şifreli saklandığını, API'nin başka bir kullanıcının verisini döndürmediğini ve loglarda kişisel veri kalmadığını kontrol edin. Ayrıntılı kontrol listesi mobil uygulama güvenliği rehberimizde yer alıyor.

Erişilebilirlik tarafında Apple, App Store Connect'teki Accessibility Nutrition Labels ile VoiceOver, Voice Control, büyük metin, yeterli kontrast ve azaltılmış hareket gibi özellikleri beyan etmenizi sağlıyor. Bir özelliği beyan etmeden önce, yaygın görevleri yalnızca o özellikle tamamlayıp tamamlayamadığınızı test edin.

Cihaz matrisi: hangi telefonlarda test etmeli?

Cihaz matrisi, testlerin koşacağı cihaz, işletim sistemi sürümü ve ekran boyutu kombinasyonlarının listesidir. Hedefiniz her cihazı denemek olmamalı. Kullanıcı kitlenizin büyük bölümünü temsil eden en küçük seti arayın.

Türkiye'deki Android sürüm dağılımı bu seçimin neden önemli olduğunu gösteriyor:

StatCounter'ın sürüm verisine göre ilk altı sürüm birlikte yaklaşık %87 pay tutuyor ve 2020'de çıkan Android 11 hâlâ ilk beşte. iOS tarafı daha homojen: Apple'ın 7 Haziran 2026 ölçümüne göre tüm iPhone'ların %79'unda iOS 26 yüklü.

Pratik bir cihaz matrisini üç halkada kurun:

1. Birinci halka (her sürümde): Analitikte en çok görünen 3-4 Android cihaz ve 2 iPhone. iPhone'lardan biri en güncel iOS'u, diğeri desteklediğiniz en eski sürümü çalıştırsın. Yeni bir projede analitik verisi yoksa, düşük bellekli bir Android cihazı mutlaka listeye ekleyin.
2. İkinci halka (sürüm adayında): Desteklenen en düşük Android sürümü, küçük ekranlı bir telefon, bir tablet ve farklı üreticilerin arayüz katmanları.
3. Üçüncü halka (bulut cihaz çiftliği): Ekipte olmayan kombinasyonlar için bulut tabanlı test servisleri.

Bulut tarafında Firebase Test Lab, ücretsiz Spark planında günde 10 sanal ve 5 fiziksel cihaz test koşusu sunar. Blaze planında günlük 60 dakika sanal ve 30 dakika fiziksel cihaz süresi ücretsizdir. Bu sürenin ötesinde Google, sanal cihaz saati için 1 $, fiziksel cihaz saati için 5 $ ücret alır.

Emülatör ve simülatörler hızlı geri bildirim için idealdir, CI hattında her commit'te koşabilirler. Ancak kamera, biyometrik doğrulama, bildirim izinleri, pil tüketimi ve gerçek performansı yalnızca fiziksel cihaz doğru gösterir. Dengeli yaklaşım şudur: fonksiyonel regresyonun büyük kısmını emülatörde, donanıma bağlı akışları ve performans ölçümünü gerçek cihazda koşun.

Matrisin üst sınırını mağaza kuralları belirler. Google Play'in hedef API kuralına göre 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Android 16'yı (API 36) hedeflemek zorunda. Ek süre talebiyle bu tarih 1 Kasım 2026'ya uzayabiliyor. Hedef API yükseltmesi davranış değişikliklerini tetiklediği için bu geçişi ayrı bir regresyon turuyla doğrulayın.

Matrisi bir kez kurup unutmayın. Her çeyrekte analitikteki cihaz ve OS dağılımına bakın, birinci halkadaki cihazları bu veriye göre güncelleyin. Desteği bıraktığınız en eski OS sürümünü de mağaza sayfasında ve uygulama içinde kullanıcıya açıkça söyleyin.

Manuel test mi, test otomasyonu mu?

İkisi birbirinin alternatifi sayılmaz. Otomasyon tekrarlanan kontrolleri ucuzlatır, manuel test ise insan gözünün yakaladığı sorunları bulur. İyi bir mobil uygulama testi planı ikisini aynı takvimde kullanır.

Otomatikleştirmeniz gerekenler:

• Her build'de koşan smoke test: uygulama açılıyor mu, kullanıcı giriş yapabiliyor mu, ana ekran geliyor mu?
• Kritik akışların regresyon seti: kayıt, ödeme, abonelik ve veri senkronizasyonu.
• İş kuralı içeren birim testleri: fiyat hesaplama, indirim ve form doğrulama.

Manuel bırakmanız gerekenler:

• Keşif testi (exploratory testing): senaryo dışı kullanım ve beklenmedik adım sıraları.
• Görsel ve UX değerlendirmesi: hizalama, animasyon ve metin taşması.
• Yeni geliştirilen ve tasarımı hâlâ sık değişen ekranlar.

Otomasyon aracını uygulamanın teknolojisi belirler:

Espresso ve XCUITest platformların resmi araçlarıdır ve ücretsizdir. Appium ve Maestro açık kaynaklıdır, tek bir test setiyle iki platformu kapsar. Küçük bir projede her şeyi otomatikleştirmeye çalışmak bütçeyi erken tüketir. MVP aşamasında önce smoke testi ve en kritik 3-5 akışın regresyonunu otomatikleştirin, kapsamı ürün oturdukça genişletin.

Beta testi: TestFlight ve Google Play test kanalları

Beta testi, uygulamayı QA ekibinin dışındaki gerçek kullanıcılara kontrollü biçimde açmaktır. İki mağaza bunun için farklı kanallar sunar ve kuralları birbirinden oldukça farklıdır.

TestFlight ile iOS beta testi

TestFlight, Apple Developer Program üyeliğiyle birlikte gelir. Dahili testçiler, App Store Connect hesabında rolü olan ekip üyeleridir ve derlemeye inceleme beklemeden erişir. Harici gruba eklediğiniz ilk derleme ise Apple'ın Beta App Review sürecinden geçer, sonraki derlemeler her zaman tam inceleme gerektirmez.

Üç kuralı takvime baştan yazın:

• Her derleme 90 gün geçerlidir. App Store Connect belgelerine göre süre dolunca testçiler derlemeyi açamaz. Uzun betalarda yeni derleme yüklemeyi planlayın.
• Testçiye ödül verilemez. Guideline 2.2, TestFlight üzerinden dağıtılan uygulamaların herhangi bir ücret veya ödül karşılığında test ettirilmesini yasaklar.
• Herkese açık linke filtre koyun. Cihaz türü ve iOS sürümü kriteriyle beta grubunu cihaz matrisinize uygun hale getirin.

Testçiler uygulamanın içinden ekran görüntüsü alıp işaretleyerek geri bildirim gönderebilir. Çökme yaşandığında size çökme raporu ulaşır ve testçi ek açıklama ekleyebilir. Bu sayede ilk betayı ayrı bir hata bildirim aracı kurmadan başlatırsınız.

Google Play dahili, kapalı ve açık test

Play Console'daki test kanalları kademeli bir yapı kurar. Dahili teste yüklediğiniz yeni App Bundle, testçilere dakikalar içinde ulaşır. Kapalı testi e-posta listeleri veya Google Grupları ile seçtiğiniz kişilere açarsınız. Açık test ise Google Play'de görünür ve herkes katılabilir.

Yeni kişisel hesaplarda kapalı test, üretim erişiminin anahtarı olduğu için en kritik aşamadır. 12 test kullanıcısı şartında iki ayrıntı sık atlanır:

1. Kesintisizlik: 14 gün dolmadan testten çıkan kullanıcı sayıma girmez. Testçileri seçerken betayı sonuna kadar sürdürecek kişileri tercih edin.
2. Başvuru formu: Şartlar sağlandığında Play Console; kapalı testi, uygulamayı ve yayına hazırlığı soran bir form ister. Testçi geri bildirimlerini ve yaptığınız düzeltmeleri kayıt altında tutarsanız formu gerçek veriyle doldurursunuz.

Play Console ayrıca her App Bundle yüklemesinde otomatik bir pre-launch report üretir. Rapor kararlılık, Android uyumluluğu, performans ve erişilebilirlik sorunlarını listeler ve çoğunlukla bir saat içinde gelir. Uygulamanızda giriş ekranı varsa test hesabı bilgisi tanımlayın, aksi halde otomatik tarayıcı giriş ekranının ötesine geçemez.

Beta grubunu seçme ve yönetme

Beta grubunun büyüklüğünden çok bileşimi önemlidir. Nielsen Norman Group'un analizine göre 5 kullanıcıyla yapılan bir kullanılabilirlik testi sorunların yaklaşık %85'ini ortaya çıkarır. Aynı kaynak, 15 kişilik tek bir çalışma yerine 5'er kişilik üç tur öneriyor. Beta için çıkan ders nettir: küçük grupla başlayın, düzeltin, sonra genişletin.

Pratik bir beta planı beş adımdan oluşur:

1. Hedefi yazın. "Ödeme akışını üç farklı bankanın kartıyla doğrulamak" gibi ölçülebilir bir hedef, "genel geri bildirim toplamak" hedefinden daha fazla sonuç üretir.
2. Grubu matrise göre seçin. Farklı üreticiler, düşük bellekli cihazlar ve desteklenen en eski OS sürümleri grupta temsil edilsin.
3. Görev verin. Her hafta testçilere 2-3 somut görev gönderin.
4. Tek kanal kullanın. Geri bildirim WhatsApp, e-posta ve telefon arasında dağılırsa kaybolur.
5. Kapanış kriterini baştan belirleyin. Beta, takvim dolduğunda değil kabul kriterleri sağlandığında biter.

Testçilerden serbest yorum beklemek yerine her görevin sonunda aynı üç soruyu sorun:

• Görevi tamamladınız mı, hangi adımda takıldınız?
• Beklemediğiniz bir şey oldu mu?
• Bu özelliği gerçek hayatta ne sıklıkla kullanırdınız?

İlk iki soru hataları ve kullanılabilirlik sorunlarını, üçüncüsü özelliğin önceliğini ortaya çıkarır. Cevapları görev bazında bir tabloya dökmek, aynı sorunu kaç testçinin yaşadığını da gösterir.

Hata raporlama düzeni

Beta ve QA'nın değerini, ekibin bulduğu hataları ne kadar hızlı çözdüğü belirler. "Uygulama çalışmıyor" mesajı geliştiriciye neredeyse hiçbir şey anlatmaz. İyi bir hata kaydı şu alanları içerir:

• Başlık: Sorunu tek cümlede anlatır. Örnek: "Kupon uygulandığında sepet toplamı güncellenmiyor."
• Adımlar: Hatayı yeniden üretmek için numaralı adımlar.
• Beklenen ve gerçekleşen sonuç: İkisi ayrı satırlarda.
• Ortam: Cihaz modeli, OS sürümü, uygulama sürümü, build numarası ve ağ türü.
• Kanıt: Ekran görüntüsü, ekran kaydı veya çökme logu.
• Önem derecesi: Aşağıdaki tabloya göre.

Kayıtları Jira, Linear veya GitHub Issues gibi tek bir araçta toplayın. Çökmeler için Firebase Crashlytics gibi bir araç, stack trace'i cihaz ve sürüm bilgisiyle otomatik kaydeder. Beta dağıtımını Firebase App Distribution ile yapıyorsanız, Crashlytics her test derlemesinin kararlılık metriklerini ayrıca gösterir.

Önem derecesini bir kişi belirlemeli ve kararı herkes kabul etmelidir. Aksi halde her testçi kendi bulduğu hatayı P0 olarak işaretler ve öncelik listesi anlamını kaybeder. Haftalık 30 dakikalık bir triage toplantısı, bu işi çoğu projede yeterince düzenli tutar.

Yeniden üretemediğiniz hataların kaydını hemen kapatmayın. Çökme logunu, cihaz modelini ve saati not edin; aynı imza üç farklı kullanıcıda tekrar ederse hatayı yeniden önceliklendirin. Her kaydı kapatırken hangi build'de düzeldiğini yazmak, regresyon setine eklemeniz gereken senaryoları da ortaya çıkarır.

Kabul kriterleri ve yayın kararı

Kabul kriterleri, bir özelliğin "bitti" sayılması için sağlanması gereken koşulların yazılı listesidir. Kriter yoksa yayın kararı, toplantıda en yüksek sesle konuşan kişinin görüşüne kalır.

Kriterleri test edilebilir biçimde yazmanın en yaygın yolu Given/When/Then kalıbıdır. Türkiye'deki bir e-ticaret uygulamasının ödeme akışı için örnek:

• Given (durum): Kullanıcının sepetinde 2 ürün var ve kayıtlı kartı yok.
• When (eylem): Kullanıcı yeni kart bilgisini girip ödemeyi onaylıyor.
• Then (sonuç): 3D Secure ekranı açılıyor, onaydan sonra sipariş numarası görünüyor ve sipariş e-postası 1 dakika içinde gidiyor.

Özellik düzeyindeki kriterlere ek olarak sürüm düzeyinde bir go/no-go listesi kullanın:

• Açık P0 ve P1 hata sayısı sıfır.
• Regresyon seti birinci halkadaki tüm cihazlarda geçti.
• Beta derlemesinin çökme oranı hedefin altında.
• Demo hesabı çalışıyor ve backend yayın ortamında açık.
• Hedef API seviyesi ve mağaza gizlilik beyanları güncel.
• Pre-launch report'taki kritik uyarılar kapandı.
• Analitik ve çökme raporlama yayın derlemesinde aktif.

Çökme hedefi için iki referans kullanın. Birincisi Google'ın eşikleridir: Android vitals genel eşiği %1,09'dur ve Google, 2022 duyurusunda telefon modeli bazında %2'den kötü olmayan metrikleri hedeflemeyi öneriyor. İkincisi sektör verisidir: Luciq'in (eski adıyla Instabug) Mobile App Stability Outlook 2025 raporunda medyan crash-free oturum oranı %99,95, 3 yıldızın altındaki uygulamalarda ise %99,82. Aradaki fark küçük görünür ama 10.000 oturumda 5 çökme ile 18 çökme arasındaki farka denk gelir.

Mağaza gönderiminden önceki son kontrol için uygulama yayın kontrol listesi aracımızı kullanın. Mobil uygulama testinde gözden kaçan ve red riski taşıyan maddeleri ise App Store red nedenleri rehberimizde ayrıntılı işledik.

Yayından sonra: kademeli dağıtım ve izleme

Test ortamı, gerçek kullanıcı çeşitliliğini hiçbir zaman tam yansıtmaz. Bu yüzden mobil uygulama testinin son katmanı, yayını kademeli olarak açmaktır.

App Store'da phased release, otomatik güncellemeleri 7 güne yayar. Apple'ın takvimine göre güncelleme 1. gün kullanıcıların %1'ine ulaşır. Oran sonraki günlerde %2, %5, %10, %20 ve %50 olur, 7. gün %100'e çıkar. Sorun görürseniz dağıtımı toplamda 30 güne kadar duraklatın. Kullanıcılar güncellemeyi App Store'dan elle her zaman indirebilir.

Google Play'de staged rollout, yüzdesini sizin belirlediğiniz kademeli dağıtımdır. Play Console belgelerine göre bu özellik yalnızca güncellemelerde çalışır, ilk yayında kullanılamaz. Sorun fark ettiğinizde dağıtımı durdurun; güncellemeyi almış kullanıcılar o sürümde kalır. İlk yayında bu seçenek olmadığı için kapalı ve açık test, ilk sürümün tek güvenlik ağıdır.

Kademeli dağıtımdan önce bir geri dönüş planı da hazırlayın. Web sitesinin aksine, kullanıcının cihazındaki uygulamayı anında eski sürüme döndüremezsiniz; düzeltme yeni bir derleme ve yeni bir mağaza incelemesi ister. Bu yüzden riskli özellikleri uzaktan açıp kapatabileceğiniz bir feature flag arkasında yayınlayın. Sorun çıktığında özelliği sunucu tarafında kapatırsınız ve kullanıcı yeni sürümü beklemeden sağlam akışa döner.

Kademeli dağıtım süresince çökme oranını, ANR oranını ve kritik huni adımlarını her gün izleyin. Yeni sürümün metriklerini bir önceki sürümle aynı gün aralığında karşılaştırın. Hangi metriklerin takip edileceğini mobil uygulama analitiği rehberimizde ayrıntılı anlattık.

Türkiye pazarına özel test kontrolleri

Global test kontrol listeleri, Türkiye'ye özgü bazı hataları kapsamaz. Türkiye'deki kullanıcılara yönelik bir uygulamada mobil uygulama testi senaryolarına şu kontrolleri ekleyin:

• Türkçe İ/ı dönüşümü: Cihaz dili Türkçe olduğunda Java'daki toUpperCase() gibi locale'e duyarlı çağrılar "title" kelimesini "TİTLE" yapar. Büyük/küçük harf dönüşümüne dayanan e-posta karşılaştırması, arama veya kod eşleştirmesi bu yüzden bozulabilir. Testleri cihaz dili Türkçe iken de koşun.
• Para birimi ve sayı biçimi: Tutarların "1.250,50 TL" biçiminde göründüğünü ve ondalık ayırıcı olarak virgül kabul eden formların doğru çalıştığını kontrol edin.
• Tarih ve saat: Tarihlerin gg.aa.yyyy biçiminde göründüğünü ve sunucu UTC ile çalışırken sipariş ve randevu saatlerinin Türkiye saatine (UTC+3) doğru çevrildiğini kontrol edin.
• Telefon ve kimlik alanları: +90 ön ekli ve ön eksiz numaraları, 11 haneli T.C. kimlik numarası doğrulamasını ve Türkçe karakterli ad-soyad alanlarını deneyin.
• Ödeme akışı: 3D Secure yönlendirmesini, taksit seçeneklerini ve banka ekranından uygulamaya dönüşü ödeme kuruluşunun test ortamında doğrulayın.
• SMS doğrulama: Tek kullanımlık şifre mesajlarının farklı operatörlerde gelip gelmediğini ve otomatik doldurmanın çalıştığını kontrol edin.
• KVKK uyumlu test verisi: Test ortamında gerçek müşteri verisi kullanmayın. KVKK'nın açıklamasına göre anonim veri, başka verilerle eşleştirildiğinde bile belirli bir kişiyi göstermemelidir. Sentetik test verisi üretmek bu riski baştan ortadan kaldırır.

Bu kontrollerin çoğu bir e-ticaret uygulamasında doğrudan gelir kaybına dönüşür. Virgüllü tutarı reddeden bir ödeme formu veya Türkçe cihazda çalışmayan bir kupon kodu, yalnızca Türkiye'deki kullanıcılarda ortaya çıkar. Yurt dışındaki bir test ekibi bu hataları çoğu zaman hiç görmez.

Sıkça Sorulan Sorular

Mobil uygulama testi ne kadar sürer?

Süre kapsama göre değişir, ancak takvimde iki ayrı pencere planlamanız gerekir: geliştirme boyunca süren QA ve yayın öncesi beta. Google Play'de 13 Kasım 2023'ten sonra açılmış kişisel hesaplarda kapalı test en az 14 gün sürer. Ardından gelen üretim erişimi incelemesi genellikle 7 gün veya daha kısadır.

Beta testi için kaç kullanıcı gerekir?

Kullanılabilirlik sorunlarını bulmak için küçük gruplar yeterlidir; Nielsen Norman Group'a göre 5 kullanıcı sorunların yaklaşık %85'ini ortaya çıkarır. Yeni kişisel Google Play hesaplarında kapalı test için en az 12 kullanıcı zorunludur. TestFlight harici testi ise 10.000 kişiye kadar çıkar.

Emülatörde test etmek yeterli mi?

Hayır. Emülatör ve simülatörler hızlı fonksiyonel test için uygundur, ancak kamera, biyometrik doğrulama, pil tüketimi ve gerçek performansı yalnızca fiziksel cihaz doğru gösterir. Kritik akışları yayından önce birkaç gerçek Android cihaz ve iPhone üzerinde doğrulayın.

TestFlight kullanmak ücretli mi?

TestFlight için ayrı bir ücret ödemezsiniz; Apple Developer Program üyeliği (yıllık 99 $) yeterlidir. Testçiler ücretsiz TestFlight uygulamasını indirir ve her derlemeyi yüklendiği günden itibaren 90 gün boyunca test edebilir.

Alfa testi ile beta testi arasındaki fark nedir?

Alfa testi, uygulamanın ekip içinde ve kontrollü bir ortamda, çoğu zaman tüm özellikler tamamlanmadan yapılan testidir. Beta testi ise özellikleri tamamlanmış sürümün gerçek kullanıcılarla, gerçek cihaz ve ağ koşullarında denenmesidir. TestFlight dahili grubu ve Play dahili testi alfa için, harici gruplar ve kapalı test beta için uygundur.

Google Play kapalı testi her hesap için zorunlu mu?

Hayır. Kural, 13 Kasım 2023'ten sonra açılmış kişisel geliştirici hesaplarına uygulanır ve bu hesaplar 12 kullanıcılı, 14 günlük kapalı testi tamamlamadan üretime çıkamaz. Kurumsal hesaplarda bu şart yoktur, ancak kapalı test yine de önerilen bir adımdır.

Test otomasyonu küçük bir proje için gerekli mi?

Tam kapsamlı otomasyon gerekmez. Her build'de koşan bir smoke test ve en kritik 3-5 akışın regresyon testi, küçük projelerde de tekrarlanan manuel kontrol yükünü belirgin biçimde azaltır. Kalan kapsamı manuel ve keşif testiyle yönetmek, MVP aşamasında en dengeli yaklaşımdır.

Mobil uygulama testi kodun bittiği gün başlamaz; ilk sprintten yayın sonrası kademeli dağıtıma kadar süren bir disiplindir. Test türlerini, cihaz matrisini, beta kanallarını ve kabul kriterlerini baştan planlayan ekip, mağaza reddi ve ilk hafta gelen tek yıldızlı yorum riskini belirgin biçimde azaltır.

Mobil uygulama geliştirme hizmetimizde QA, TestFlight ve Google Play kapalı test yönetimini proje takviminin standart parçası olarak planlıyoruz. Uygulamanızın test ve yayın planını birlikte çıkarmak için bizimle iletişime geçin.