Web uygulamasını gerçek iş senaryoları, roller, cihazlar ve kabul kriterleriyle sınayın; tekrarlanabilir hata kayıtları ve yeniden testle yayın kararını güvenceye alın.
Kalite güvencesi hatayı son hafta aramak değildir
Web uygulaması teknik olarak açılabilir fakat yanlış tutar hesaplayabilir, kullanıcının görmemesi gereken veriyi gösterebilir veya nadir bir durumda kaydı iki kez oluşturabilir. Kalite güvencesi, gereksinimden yayına kadar kabul ölçütlerini, test verisini, ortamı ve hata geri bildirimini düzenler. Amaç “hiç hata olmayacak” garantisi değil, önemli riskleri erken ve tekrarlanabilir biçimde bulmaktır.
QA ile UAT aynı şey değildir. QA işlevin teknik ve tanımlı gereksinime uygun çalışmasını sınar. UAT’de gerçek iş temsilcileri, sistemin günlük görevi ve süreç kuralını karşılayıp karşılamadığını doğrular. Geliştirici, test uzmanı ve iş birimi aynı senaryoya farklı risk açısından bakar; roller birbirini tamamlar.
Kabul kriteri testin başlangıç noktasıdır
“Sipariş modülü çalışacak” test edilebilir bir ifade değildir. Hangi rolün hangi alanlarla sipariş oluşturduğu, stok yetersizliğinde ne olduğu, toplamın nasıl hesaplandığı ve başarı sonrası hangi kaydın üretildiği yazılır. İyi kabul kriteri ana yolu, sınır koşulunu ve beklenen sonucu açıklar; uygulamanın iç koduna gereksiz çözüm dayatmaz.
Kriterler geliştirme başlamadan hazırlanırsa ekip farklı beklentileri erken görür. UAT senaryosu oluşturmak için kabul kriterleri ve UAT rehberi iş diliyle örnek yapı sunar. Değişen gereksinimlerde test ve doküman aynı karar kaydına göre güncellenir.
Risk tabanlı test kapsamı
Her alanı sonsuz kombinasyonla test etmek mümkün değildir. Finansal etki, veri kaybı, yetki, kullanım sıklığı, entegrasyon ve değişiklik büyüklüğü dikkate alınır. Kritik akışlar ayrıntılı; düşük etkili ve nadir alanlar temsilî senaryolarla sınanır. Yeni geliştirilen bölüm kadar değişiklikten etkilenebilecek eski işlevler de regresyon kapsamına alınır.
| Risk | Örnek | Test yaklaşımı |
|---|---|---|
| Yüksek etki + sık kullanım | Giriş, sipariş, tahsilat, ana kayıt | Pozitif, negatif, sınır, rol ve veri bütünlüğü ayrıntılı test |
| Yüksek etki + nadir | Toplu silme, yıl sonu işlem, geri yükleme | Kontrollü ortam ve geri dönüş doğrulaması |
| Düşük etki + sık | Filtre, sıralama, görünüm tercihi | Temsilî cihaz ve regresyon otomasyonu |
| Harici bağımlılık | Ödeme, kargo, e-posta, API | Kesinti, zaman aşımı, tekrar ve sahte servis senaryosu |
Test ortamı ve veri yönetimi
Test ortamı üretime benzer sürüm, yapılandırma ve veri hacmine sahip olmalıdır; ancak gerçek kullanıcıya veya arama motoruna açık bırakılmaz. Üretim verisi kopyalanacaksa kişisel ve hassas alanlar anonimleştirilir, erişim süreli ve sınırlı olur. Sentetik veri, sınır durumlarını bilinçli üretmek için kullanılır.
Her testin başlangıç durumu tekrar kurulabilir olmalıdır. Bir senaryo önceki testten kalan sipariş veya kullanıcıya bağlıysa sonuç güvenilmezleşir. Test hesaplarının rolleri, şube kapsamları ve parolaları merkezi yönetilir. Ödeme veya e-posta servislerinde test modu ile üretim anahtarları kesin olarak ayrılır.
Fonksiyonel ve negatif senaryolar
- Geçerli veriyle ana görev baştan sona tamamlanır.
- Zorunlu alan, yanlış biçim, sınır değer ve tekrar kayıt davranışı sınanır.
- Sayfa yenileme, geri tuşu ve çift tıklamada yinelenen işlem aranır.
- Yetkisiz rol doğrudan URL ve değiştirilmiş istekle denenir.
- Bağlantı kesintisi, zaman aşımı ve harici servis hatası çalıştırılır.
- Eşzamanlı iki kullanıcının aynı stok, koltuk veya kaydı değiştirmesi test edilir.
- İptal, geri alma ve arşiv davranışında veri geçmişi kontrol edilir.
Hata mesajı teknik ayrıntıyı ifşa etmeden kullanıcıya düzeltme yolu göstermelidir. Sunucu logu, aynı olayın araştırılabilmesi için işlem kimliği ve güvenli bağlam taşır.
Rol ve yetki testi görünmeyen erişim yollarını kapsar
Menünün gizli olması yeterli değildir. API, dosya indirme, dışa aktarma, toplu işlem ve sıra numarası değiştirilmiş kayıt isteği sunucu tarafından reddedilmelidir. Kullanıcı yalnızca kendi şubesi veya sorumlu olduğu kayıtları görüyorsa liste sayısı, arama, rapor ve bildirimlerde de aynı kapsam korunur.
Rol değişikliği açık oturuma nasıl yansıyor, pasif hesap erişime devam ediyor mu, yönetici işlemleri loglanıyor mu kontrol edilir. Karmaşık yapılar dinamik yetkilendirme kapsamında izin matrisi ve olumsuz test setiyle geliştirilebilir.
Cihaz, tarayıcı, erişilebilirlik ve performans matrisi
Kullanıcı kitlesini temsil eden tarayıcı ve cihazlar seçilir; “bütün cihazlar” gibi test edilemeyen söz verilmez. Küçük ve büyük ekran, dokunma, klavye, dosya seçici, kamera izni ve yazdırma gibi proje işlevleri değerlendirilir. Responsive görünümde yalnızca taşma değil, görevin tamamlanabilirliği sınanır.
Kritik akışlarda klavye odağı, form etiketi, hata duyurusu, kontrast ve ekran okuyucu temel kontrolleri yapılır. Ayrıntılı standart değerlendirmesi web erişilebilirlik denetimi ile yürütülebilir. Performans testinde gerçekçi veri hacmi ve eşzamanlılık kullanılır; tek boş veritabanı ölçümü canlı davranışı temsil etmez.
Hata kaydı geliştiricinin sorunu tekrar edebilmesini sağlamalıdır
Hata başlığı, önem derecesi, ortam, sürüm, ön koşul, adımlar, beklenen ve gerçekleşen sonuç ile kanıt içerir. Ekran görüntüsü tek başına yeterli olmayabilir; zaman, URL ve kullanıcı rolü eklenir. Parola, erişim anahtarı ve gerçek kişisel veri hata kaydına yazılmaz. Engelleyici, yüksek, orta ve düşük önem tanımları proje etkisine göre önceden belirlenir.
Düzeltme sonrası yalnızca aynı adım değil, yakın işlevler de regresyon testine alınır. Kapanan hata yeniden üretilemez durumdaysa kullanılan ortam ve kanıt kaydedilir.
UAT oturumu gerçek işi temsil etmelidir
- Süreç sahibi ve farklı kullanıcı rollerinden temsilciler seçilir.
- Menü eğitimi yerine günlük iş senaryoları ve beklenen sonuç paylaşılır.
- Test verisi gerçekçi fakat güvenli örneklerden hazırlanır.
- Bulgular hata, gereksinim boşluğu, eğitim ihtiyacı ve yeni fikir olarak ayrılır.
- Kritik kabul kriterleri sonuçlarıyla birlikte imzalanır veya onay kaydına alınır.
- Bilinen sınırlamalar ve canlı sonrası takip planı yayın kararına eklenir.
UAT sırasında ortaya çıkan her yeni istek hata değildir. Onaylanan kapsamı karşılamayan davranış düzeltilir; yeni fikirler etkisi ve takvimiyle sonraki sürüme planlanabilir. Bu ayrım yayın tarihinin belirsizce kaymasını önler.
Test teslimi ve yayın kapısı
Teslimde gereksinim–test izlenebilirlik matrisi, senaryolar, test verisi notları, cihaz/tarayıcı kapsamı, hata listesi, yeniden test sonucu, UAT kararı ve bilinen riskler bulunur. Yayın kapısı kritik hata sayısı, gerekli onaylar, yedek ve geri dönüş hazırlığı gibi ölçütlerle tanımlanır. Sıfır hata iddiası yerine kabul edilen riskler görünür tutulur.
Proje ilk sürüm aşamasındaysa özel yazılım MVP kapsamı ile kabul kriterleri birlikte hazırlanabilir. Başlangıç görüşmesine iş akışları, kullanıcı rolleri, mevcut hata örnekleri, hedef cihazlar, entegrasyonlar ve yayın tarihi getirilmelidir. Kalite güvencesi, test sonunda kalın bir rapor üretmekten çok ekiplerin aynı “tamamlandı” tanımında buluşmasını sağlar.
Bu çözüm kimler için uygun?
- Yeni web uygulamasını canlıya alacak işletmeler
- Sürüm değişikliklerinde aynı hataları tekrar yaşayan ekipler
- Tedarikçi teslimini ölçülebilir kabul kriterleriyle değerlendirmek isteyen kurumlar
Proje kapsamında planlanabilenler
- Kabul kriteri ve risk tabanlı test planı
- Fonksiyonel, rol, form ve veri doğrulama senaryoları
- Cihaz ve tarayıcı uyumluluk kontrolleri
- Hata raporu, yeniden test ve yayın kararı özeti
Sık sorulan sorular
Web Uygulaması Test, UAT ve Kalite Güvencesi hakkında merak edilenler
Bu hizmet penetrasyon testi yerine geçer mi?
Hayır. Temel güvenlik davranışları kontrol edilebilir; ancak bağımsız ve kapsamlı penetrasyon testi ayrı uzmanlık, yetkilendirme ve çalışma planı gerektirir.
UAT testlerini kim onaylar?
İş sürecini bilen müşteri temsilcileri kabul senaryolarını doğrular. Teknik ekip ortamı, veri setini ve hata kayıtlarını hazırlayarak süreci destekler.