Bir yazılım demosunda düğmeye basıldığında başarı mesajı çıkması, işlemin gerçekten tamamlandığını kanıtlamaz. Kayıt oluşmamış, bildirim gitmemiş veya yanlış müşteriye bağlanmış olabilir. Kabul testi, iş gereksiniminin uçtan uca karşılandığını doğrular. Bu nedenle test listesi proje sonunda aceleyle hazırlanan bir belge değil, ihtiyaç analizi sırasında yazılmaya başlanan ortak beklentidir.
Her senaryonun başlangıcını ve sonucunu yazın
Kim hangi yetkiyle giriş yapıyor, hangi örnek veri mevcut ve hangi işlem yapılıyor? Beklenen sonuç ekranın yanında veri ve bildirim tarafını da kapsasın. Örneğin teklif kaydedildiğinde doğru müşteriyle ilişkilendirilmeli, yetkili kişinin listesinde görünmeli ve gerekiyorsa bildirim kuyruğuna alınmalıdır. Her senaryonun tek bir ana davranışı doğrulaması hatanın yerini bulmayı kolaylaştırır.
Sadece mutlu yolu denemeyin
Eksik alan, yanlış biçim, bağlantı kesintisi ve tekrar gönderim günlük kullanımın parçasıdır. Hata halinde kullanıcı ne yapacağını anlayabilmeli ve mümkün olduğunda emeğini kaybetmemelidir. Sistem de yarım kalmış işlemi tutarlı yönetmelidir. Test verisini özellikle sınırları gösterecek biçimde seçin: uzun ad, Türkçe karakter, boş liste ve aynı anda güncellenen kayıt gibi örnekler gerçek sorunları ortaya çıkarabilir.
Örnek bir servis planlama sisteminde aynı teknisyene aynı saatte iki görev verildiğini düşünün. Beklenen davranış engellemek, uyarmak veya yetkili onayı istemek olabilir. Hangisinin doğru olduğu iş kuralına bağlıdır. Testin amacı geliştiricinin tercih ettiğini onaylamak değil, önceden belirlenen iş kuralının gerçekleştiğini göstermektir. Belirsiz kural test sırasında fark edilirse önce karar netleştirilmelidir.
Farklı rollerle ayrı oturumlar kullanın
Yönetici hesabıyla çalışan işlem standart kullanıcıda başarısız olabilir; tersine standart kullanıcı gereğinden fazla kayda erişebilir. Testleri rol matrisine göre tekrarlayın. Bir hesabın çıkış yapması, pasifleştirilmesi ve yetkisinin değişmesi gibi durumları da kapsayın. Gerçek müşteri verisini test amacıyla gereksiz yere kullanmayın; benzer yapıda temsili veri hazırlayın ve test ortamının erişimini sınırlandırın.
Harici sisteme gerçekten ulaşıldığını doğrulayın
E-posta, CRM, ödeme veya muhasebe entegrasyonlarında uygulama içindeki başarı bildirimi tek kanıt değildir. Hedef sistemde doğru kayıt ve alanları kontrol edin. Harici hizmet yanıt vermediğinde tekrar deneme ve kullanıcı mesajı nasıl çalışıyor? Aynı olay yeniden geldiğinde kayıt çoğalıyor mu? Bu soruların cevabı işletmenin hata anındaki operasyonunu belirler. Test sağlayıcısı ile canlı ortam farklarını ayrıca kaydedin.
- Senaryonun başlangıç verisi ve beklenen sonucu açık mı?
- Hata ve tekrar gönderim durumları denendi mi?
- Her rol için izin verilen ve reddedilen işlem var mı?
- Harici sistemdeki sonuç gözle doğrulandı mı?
- Açık sorunların önceliği ve sorumlusu belli mi?
Sonucu tarihli ve tekrarlanabilir kaydedin
Test tarihi, sürüm, ortam ve sonucu kaydedin. Geçmeyen bir senaryo için beklenen ile gözlenen davranışı ayrı yazın. Her küçük görsel sorun yayını durdurmak zorunda değildir; fakat veri kaybı veya yetkisiz erişim gibi etkiler farklı değerlendirilmelidir. Teslim kararı hangi açık sorunların kabul edildiğini de göstermelidir. Düzeltme sonrasında yalnızca ilgili akışı ve etkilenebilecek bağlantılı senaryoları tekrar kontrol edin.
Güvenlik kontrol kapsamı için OWASP Web Security Testing Guide teknik referans sağlar. İhtiyaç analizi kabulün temelidir; yazılım projenizi teslim senaryolarıyla birlikte değerlendirebiliriz.