Teknik olmayan ekipler için 30 dakikada lansman öncesi test planı

Kısa bir lansman öncesi testi neden sonradan yaşanacak sıkıntıyı önler

Çoğu lansman hatası derin teknik bir arıza değildir. Gerçek müşteriler gibi uygulamayı kullananlarda ortaya çıkan küçük boşluklardır. Üreticiler genellikle kusursuz verilerle, yönetici hesaplarıyla ve sistemin nasıl işlemesi gerektiğine dair net bir zihinsel modele göre test eder. Gerçek kullanıcılar böyle yapmaz. Bu yüzden bozuk izinler, anlaşılmaz hata mesajları veya mobilde hiçbir şey yapmayan bir butonla karşılaşırsınız.

Müşteriler önce birkaç şeye dikkat eder ve size toparlanmak için fazla zaman vermezler: giriş yapamamak veya parolayı sıfırlayamamak, bir formun gönderilememesi (açıklama yok), ödemenin başarısız olması (veya iki kere ücretlendirme), onay gelmemesi veya bildirimlerin yanlış yere gitmesi.

Kısa bir lansman öncesi test planı bu anlara odaklanır. 30 dakikada tüm sistemin kusursuz olduğunu kanıtlamazsınız. İlk gün destek talepleri, iadeler ve churn yaratan sorunları yakalarsınız.

Bu hızlı kontrol, ana yolculuğu uçtan uca doğrulamak, bir telefon ve bir masaüstünde kontrol etmek, önemli mesajların ulaşıp güvenilir göründüğünü onaylamak ve kafa karıştıran metinleri, eksik yükleniyor durumlarını ve çıkmazları fark etmek için iyidir. Yük testi, derin güvenlik testi veya tüm kenar durumları kapsamaz. Onlar ayrı çalışmayı gerektirir.

Bunu çalıştıracak en iyi kişi inşa ekibinin dışındaki birisidir: operasyon, destek veya bir PM. Eğer AppMaster gibi kod-suz (no-code) bir araçla inşa ediyorsanız, teknik olmayan personelin müşterinin izlediği akışı birebir takip etmesi çok daha kolay olur. Her sürümden önce, hatta küçük değişikliklerden önce bile çalıştırın; çünkü küçük değişiklikler önemli anları bozabilir.

Kurulum: hesaplar, test verisi, cihazlar ve sıkı zaman kutusu

30 dakikalık bir test yalnızca temel hazırlıkları yaparsanız işe yarar. Amaç genişlik değil, odaklanmadır.

Gerçek para veya gerçek güvene karşılık gelen 1-2 kullanıcı yolculuğu seçin. Birçok ekip için bu kayıt olma, bir formu doldurma, ödeme yapma ve onay alma yoludur. Uygulamanızda roller varsa, ekibinizin en çok güvendiği tek görevi kapsayan kısa bir yönetici yolculuğu ekleyin.

Zamanlayıcıyı başlatmadan önce bunları hazır edin:

• Test hesapları: bir tamamen yeni kullanıcı, bir geri dönen kullanıcı ve (izinler varsa) bir admin veya personel hesabı.
• Güvenli test verisi: yeniden kullanabileceğiniz küçük bir isim, e-posta, telefon ve adres seti.
• Ödemeler: sandbox (tercih edilir) mı yoksa küçük gerçek bir ücret mi kullanacağınıza karar verin ve net bir iade kuralı belirleyin.
• Cihazlar ve tarayıcılar: müşterilerinizin gerçekten kullandığı iki cihaz ve iki tarayıcıyı seçin.
• Notlar: sorunları hemen kaydetmek için ortak bir yer.

Bunun “bir şey daha yapayım”a dönüşmemesi için zaman kutusu koyun. İşe yarayan basit bir dağılım:

• 5 dakika: yolculukları, hesapları ve cihazları teyit etme
• 20 dakika: kesintisiz yürütme
• 5 dakika: sorunları yazma ve hangi durumların lansmana engel olduğunu kararlaştırma

AppMaster kullanıyorsanız, test kullanıcılarını önceden kurun, Stripe modülünüzün beklenen modda (test ya da canlı) olduğunu doğrulayın ve e-posta/SMS/Telegram bildirimlerinin güvenli test alıcılarına yönlendiğinden emin olun. Zamanlayıcı başladığında deneyimi test ediyor olmalısınız, kimlik bilgilerini aramak değil.

Adım adım: 30 dakikalık yürütme

Bir zamanlayıcı ayarlayın. Normal bir kullanıcı hesabı kullanın (admin değil). Teknik olarak çalışsa bile kafa karıştıran her şeyi not alın.

Gerçekçi bir yolculuğu uçtan uca çalıştırın: uygulamayı açın, giriş yapın, bir şey oluşturun, ödeyin (ilgiliyse) ve doğru mesajı aldığınızı doğrulayın. Kullanıcıların lansmanda erişeceği aynı ortamı kullanın, özel bir önizlemeyi değil.

Zamanlamayı rehber olarak kullanın:

• İlk 3 dakika: uygulamanın yüklendiğini, ana sayfaların açıldığını ve düzenlerin bariz şekilde kırık olmadığını teyit edin.
• Sonraki 7 dakika: iki persona ile erişimi test edin (tamamen yeni kullanıcı ve geri dönen kullanıcı). Kayıt, giriş, çıkış ve şifremi unuttum işlemlerini kontrol edin.
• Sonraki 8 dakika: önemli bir formu tamamlayın. Kaydedin, düzenleyin, yenileyin ve değişikliğin gerçekten kalıcı olduğunu doğrulayın.
• Sonraki 7 dakika: bir ödemeyi baştan sona çalıştırın. Uygulamada “ödenmiş” durumunun güncellendiğini ve müşterinin net bir kanıt gördüğünü teyit edin.
• Son 5 dakika: bildirimleri tetikleyin ve teslimatı doğrulayın. Beklediğiniz ile olanı karşılaştırın.

Bir ekip arkadaşı yardım almadan yolculuğu bitiremiyorsa, bunu lansman hatası olarak ele alın. Amaç ilk müşterilerinizi testçi yapmak değil.

Giriş ve erişim kontrolleri (hızlı ama özensiz değil)

Lansman günü sorunları genellikle kapı girişinde başlar. İnsanlar giriş yapamıyorsa başka hiçbir şey önemli değildir.

Müşteriye benzeyen gerçek bir test hesabı ile temiz bir girişle başlayın. SSO (Google, Microsoft, Okta) destekliyorsanız bir SSO oturum açmayı da test edin. Bu akışlar küçük yapılandırma değişikliklerinden sonra şaşırtıcı şekilde başarısız olur.

Sıralı olarak bu kontrolleri yapın:

• Doğru e-posta ve parola ile giriş yapın, yenileyin ve hâlâ girişli olduğunuzu doğrulayın.
• Bir kez yanlış parola girin ve mesajın net ve yardımcı olduğundan emin olun.
• Şifremi unuttum akışını uçtan uca tamamlayın: e-posta gelsin, link açsın, yeni parola çalışsın.
• Çıkış yapın, sonra tekrar giriş yapın. "Beni hatırla" sunuyorsanız her iki durumu da test edin.
• Normal bir kullanıcı olarak admin-only bir sayfayı açmayı deneyin ve kibar bir mesajla ya da yönlendirme ile engellendiğinizi doğrulayın.

Destek talepleri yaratan detaylara dikkat edin. Sıfırlama e-postası bir dakika içinde geliyor mu? Sıfırlama linki gizli pencerede temiz açılıyor mu? Çıkış yaptıktan sonra geri düğmesiyle özel ekranlar görünmeye devam ediyor mu?

AppMaster ile inşa ediyorsanız, göndermeden önce kimlik doğrulama ayarlarının ve rol kurallarının beklediğinizle hâlâ eşleştiğini doğrulamak için bu iyi bir zamandır.

Formlar: doğrulama, kaydetme ve anlaşılır hata mesajları

Formlar küçük sorunların kayıp kayıtlar ve destek işine dönüştiği yerdir.

Normal yolla başlayın: her şeyi doğru doldurun, gönderin ve net bir başarı durumu (mesaj, yönlendirme veya yeni ekran) arayın. Sonra kaydın personel tarafından beklenen yerde var olduğunu doğrulayın.

Sonra formu gerçekçi şekillerde bozmaya çalışın. Amacınız "hack" yapmak değil. Uygulamanın normal bir kişinin nasıl toparlanabileceğini yardımcı olup olmadığını kontrol etmek.

Hızlı bir form kontrol seti:

• Bir zorunlu alanı boş bırakıp gönderin. Hata alanın yakınında görünmeli ve ne yapılması gerektiğini açıklamalı.
• Yanlış format girin ("@" olmayan e-posta, içinde harf olan telefon) ve bunun yakalandığını doğrulayın.
• Fazladan boşluk ekleyin (ör. " Jane ") ve kaydedilen değerin temiz göründüğünü kontrol edin.
• Yüklemeler için çok büyük bir dosya ve yanlış tür deneyin. Mesaj hangi türlerin kabul edildiğini söylemeli.
• Gönder'e iki kez hızlıca tıklayın. Çoğaltma oluşmamalı.

Bir "başarı"dan sonra personelin gönderiyi gerçekten admin görünümünde veya kullandıkları posta kutusunda bulabildiğini doğrulayın. Uygulama kaydedildiğini iddia ediyorsa ama kimse bulamıyorsa, müşteriler göz ardı edildiğini düşünecektir.

Ödemeler: para akışını ve müşteriye verilen kanıtı doğrulayın

Ödemeler küçük hataları pahalı hale getirir. Testiniz müşteri deneyimini, para akışını ve dahili kayıtların hepsinin örtüştüğünü kanıtlamalı.

Bir satın alma işlemini baştan sona çalıştırın: bir plan seçin (veya sepete ekleyin), ödeme yapın, net bir onay ekranına gelin. Hataları kolay fark edecek şekilde tanınması kolay bir fiyat seçin.

Müşterilerin kontrol ettiği şeyleri kontrol edin: tutar, para birimi, vergi ve indirimler. Sonra ekibinizin güvendiği şeyi kontrol edin: dahili durum ve ödeme sağlayıcı durumu uyuşmalı.

Minimum ödeme sağduyusu kontrolü:

• Toplam ve para birimi doğru
• Ödeme başarılı olduktan sonra sipariş sadece "ödenmiş" olarak görünür
• Başarısızlık net bir mesaj ve güvenli bir yeniden deneme yolu gösterir
• İade varsa (destekleniyorsa) sipariş ve müşteri kaydı güncellenir

Bilerek başarısız bir ödeme de test edin (bilinen başarısız test kartı veya iptal edilmiş ödeme). Siparişin ödenmiş olarak işaretlenmediğini, mesajın anlaşılır olduğunu ve yeniden denemenin çoğaltma yaratmadığını doğrulayın.

AppMaster ile Stripe kullandıysanız, müşterinin gördüğü onayı ve dahili sipariş durumunun Stripe'ın gerçekten işlediğiyle örtüştüğünü doğrulayın.

Bildirimler: e-posta, SMS ve push kontrolleri

Bildirimler "bu işe yaradı" ile "güvenmiyorum" arasındaki farkı oluşturur. Müşteriler yavaş bir sayfaya tolerans gösterebilir ama asla gelmeyen bir şifre sıfırlama ya da şüpheli görünen bir makbuzu affetmezler.

Mesajı gerçek bir müşterinin yapacağı şekilde tetikleyin. Müşterilerin kullandığı yol değilse admin kısayolundan test mesajı göndermekten kaçının.

Her mesaj için doğrulayın:

• Zamanlama: hızlı ve tutarlı geliyor mu
• Güven sinyalleri: gönderen adı, gönderici adresi/numarası, konu ve ön izleme metni doğru mu
• İçerik: gerçekleşen olayla eşleşiyor mu ve doğru isim ve sipariş bilgilerini kullanıyor mu
• Linkler: butonlar doğru ekranı açıyor mu ve çıkış yapmışken bile çalışıyor mu

Bir linke tıkladıktan sonra testi gizli pencerede tekrar edin. Birçok ekip, sihirli linkin veya sıfırlama linkinin sadece zaten girişliyseniz çalıştığını gözden kaçırır.

Personel bildirimlerini unutmayın. Yeni bir sipariş veya yeni bir destek bileti tetikleyin ve doğru kişilerin uyarı aldığına emin olun. Ayrıca gürültü olmadığını kontrol edin: tek bir eylem üç e-posta ve iki sohbet mesajı üretmemeli.

AppMaster kullanıyorsanız, kimlik doğrulama, ödemeler veya mesaj şablonlarında değişikliklerden sonra bu bölümü yeniden çalıştırın. Bu alanlardaki "küçük" düzenlemeler sıklıkla teslimatı bozabilir.

Gerçek müşteri sıkıntısını yakalayan ekstra kontroller

Gerçek kullanıcılar daha eski telefonlarda, zayıf bağlantılarda ve boş hesaplarla gelir.

Bir yavaş ağ anı yapın: bir telefonda hücresel (veya zayıf Wi-Fi) kullanarak giriş yapmak, bir form göndermek veya checkout açmak gibi önemli bir eylemi tekrarlayın. Sonsuz dönen ikonlar, eksik yükleniyor mesajları ve iki kez tıklanabilen butonlara dikkat edin.

Sonra boş durumları kontrol edin. Yeni kullanıcıların siparişleri, kayıtlı kartları, geçmişleri yoktur. Boş ekranlar ne yapılacağını açıklamalı, kırık görünmemeli.

Beş dakikaya sığdırılabilecek birkaç hızlı ekstra:

• Cihazları değiştirin (bir telefon, bir masaüstü) ve çekirdek akışı yeniden çalıştırın
• Makbuzlardaki, rezervasyonlardaki ve "son güncelleme" etiketlerindeki tarih ve saatleri kontrol edin
• Buton metinlerini ve hata mesajlarını yüksek sesle okuyun, anlaşılır mı görün
• Başarının bariz olduğundan emin olun (ekran, e-posta, makbuz)

Saat dilimleri sıkça tuzağa düşürür. Ekip tek bir bölgede olsa bile başka bir saat dilimindeki bir test hesabı deneyin ve kullanıcının gördüğünün niyet ettiğinizle eşleştiğini kontrol edin.

Teknik olmayan ekiplerin yaptığı yaygın hatalar

En büyük hata sadece mutlu yolu kontrol etmektir. Gerçek müşteriler parola yazım hatası yapar, süresi dolmuş kart kullanır veya ödeme sırasında sekmeyi kapatır. Bu hataları hiç denemezseniz sürprizlerle karşılaşırsınız.

Bir diğer yaygın eksiklik sadece personel hesaplarıyla test etmektir. Ekip hesapları genellikle ekstra erişime, kaydedilmiş detaylara ve önceden doğrulanmış e-postalara sahiptir. İlk kez gelen kullanıcı farklı ekranlar görür ve takılma olasılıkları artar.

Takımlar ayrıca arka ofis sonucunu doğrulamayı unutuyor. Ekranda "Başarılı" yazması yeterli değildir. Kaydın var olduğundan, durumun doğru (ödenmiş vs beklemede) olduğundan ve dahili görünümün müşterinin yaptığıyla uyuştuğundan emin olun.

Mobil genellikle müşteri şikayet edene kadar göz ardı edilir. Masaüstünde iyi görünen bir form mobilde klavye altında gönder butonunu gizleyebilir veya ödeme sayfası küçük ekranda okunması zor olabilir.

Son olarak, testler sürüklenir. Zamanlayıcı ve yazılı not yoksa insanlar tıklayıp çıkıp "gibi görünüyor" diye ayrılır. Sıkı tutun ve adımları kaydedin.

Bu tuzaklardan kaçınmak için basit bir yol:

• Her ana adım (giriş, form, ödeme, bildirim) için bir başarı ve bir hata testi yapın.
• Tamamen yeni bir kullanıcı ve normal bir geri dönen kullanıcı kullanın (admin değil).
• Her eylemden sonra admin/arrière ofis görünümünde doğru kaydın ve durumun göründüğünü doğrulayın.
• Hızlı bir mobil geçiş yapın: kayıt ol, ana formu doldur, öde.

AppMaster ile inşa ediyorsanız, Stripe ödemelerine ve mesajlaşma modüllerine ekstra dikkat gösterin: müşterinin doğru kanıtı gördüğünden ve dahili durum güncellemesinin gerçekten işlenenle uyuştuğundan emin olun.

Her sürümden önce çalıştırılacak hızlı kontrol listesi

Bunu gönder tuşuna basmadan önce son 10–30 dakikanız olarak tutun. Derin bir QA değil. Müşterilerin önce fark edeceği sorunlar için hızlı bir kontroldür.

Bir "mutlu yol" (en yaygın kullanıcı hedefi) ve bir "bir şeyler ters gitti" anı (yanlış parola, eksik alan, başarısız ödeme) seçin. Ekranların gerçekçi görünmesi için gerçekçi test verileri kullanın.

Beş kontrol:

• Uygulamayı iki cihaz ve iki tarayıcıda açın. Yüklendiğini, metnin okunabilir olduğunu ve ana butonların kolayca tıklanabildiğini doğrulayın.
• Tamamen yeni bir kullanıcı oluşturun ve kayıt, doğrulama (kullanılıyorsa), giriş ve çıkışı doğrulayın. Bir yanlış parola deneyin ve mesajın net olduğunu onaylayın.
• Bir ana form gönderin. Doğrulamayı, gönderimi, yenilemeyi kontrol edin ve personelin kaydedilen veriyi görebildiğini doğrulayın.
• Başarılı bir ödeme yapın ve müşteri kanıtını yakalayın (onay ekranı, makbuz veya e-posta). Sonra başarısız bir ödeme yapıp yeniden deneme yolunun güvenli olduğunu doğrulayın.
• Bir ana bildirimi tetikleyin ve müşterinin doğru içeriği aldığını ve dahili kaydın güncellendiğini doğrulayın.

Herhangi bir şey kafa karıştırıcı, yavaş veya tutarsızsa, "çalışıyor" olsa bile hataymış gibi ele alın.

Kod yazılmadan (no-code) bir araçla AppMaster kullanıyorsanız, aynı tip dağıtıma (cloud vs self-hosted) karşı bu kontrol listesini çalıştırın ki son kilometre de aynı davransın.

Örnek senaryo: basit bir kayıt-to-ödeme yolculuğunu test etme

Müşterinin oynayacağı gerçek bir ürün yolunu canlandırın. Üç kişi olması daha sakin bir süreç sağlar: biri müşteri rolünde normal bir cihazda, biri admin tarafını izler (kullanıcılar, siparişler, durum değişiklikleri) ve biri not tutar.

Bunu beş adımda çalıştırın:

• Yeni bir hesap oluşturun (taze e-posta) ve çıkış yaptıktan sonra tekrar giriş yapabildiğinizi doğrulayın.
• Ana istek formunu normal verilerle gönderin, sonra bir kötü alan deneyin ve hata mesajını görün.
• Test yöntemiyle ödeme yapın ve başarı ekranına geldiğinizi doğrulayın.
• Müşteri kanıtını kontrol edin: makbuz sayfası, sipariş ID'si ve net bir "aldık" onayı.
• Arka ofisi doğrulayın: kullanıcı var mı, istek kaydedildi mi ve ödeme doğru durumda mı.

İyi notlar üreticilerin hatayı hızlıca tekrar etmesine yardımcı olur. Adım numarasını, tıklanan veya yazılan şeyi, ekranı ve cihaz/tarayıcıyı, beklenen ile gerçek sonucu, kesin hata metnini ve saat bilgisini kaydedin.

Ciddiyet basit kalabilir: kayıt, form gönderimi, ödeme veya temel görev engelleniyorsa bloklayıcıdır. Kullanıcı tamamlayabiliyorsa ama bir şey yanlış görünüyorsa (kafa karıştıran metin, eksik e-posta) "çalışılabilir ama acil" olarak işaretleyin.

Sonraki adımlar: bunu tekrarlanabilir hale getirin

Bu test, rutin hale geldiğinde en çok işe yarar.

Yürütmeyi bitirdikten hemen sonra bulduklarınızı her sürümde çalıştırılabilecek kısa bir kontrol listesinden oluşan hale getirmek için 10 dakika harcayın. Kısa ve sade bir dil kullanın, beklenen sonucu yazın. Sonra her alan için bir sahip atayın (sahiplerin teknik olması gerekmez, sadece tutarlı olmaları yeterli): giriş/erişim, formlar/veri kaydı, ödemeler/iade, bildirimler ve admin/destek araçları.

Nelere lansman öncesi düzeltilmesi gerektiğine vs karar verin. Kayıt, ödeme veya temel görevi engelleyen her şey lansmanı durdurur. Kafa karıştıran metin veya küçük düzen sorunları genellikle sonrasında planlanabilir, yeter ki destek hazır olsun.

AppMaster kullanıyorsanız, bu retestleri pratik tutmak için temel akışları (kayıt, checkout, şifremi unuttum) standart hale getirebilir ve değişikliklerden sonra yeniden çalıştırabilirsiniz. Gereksinimler değiştiğinde uygulamayı yeniden üretmek, üretilen kaynak kodun temiz ve tutarlı kalmasına yardımcı olur; böylece eski düzeltmeler yeni sürümlerde takılmaz.

Aynı 30 dakikalık planı sonraki sürümde çalıştırın ve sonuçları karşılaştırın. Bir hata tekrar ederse, onu kalıcı bir test vakasına yükseltin ve erken nasıl fark edileceğine dair bir satır ekleyin. Birkaç sürüm içinde, bu ekibinizin güvenebileceği bir güvenlik ağı haline gelir.