Otomasyon kabul testi nasıl hazırlanır?

Çalışıyor demek için ortak bir ölçüt gerekir

Bir otomasyon dosyaları okuyup teklif tablosu oluşturuyor. Geliştirici ekranda sonuç gördüğü için işi tamamlanmış sayıyor, işletme ise bazı satırların eksik olduğunu fark ediyor. İki tarafın aynı sonuca bakıp farklı karar vermesinin nedeni kabul ölçütünün baştan belirlenmemesidir. Kabul testi, hangi girdinin hangi çıktıya dönüşmesi gerektiğini ortak ve kontrol edilebilir biçimde tanımlar. Böylece teslim konuşması yalnız izlenime dayanmaz.

Teste yazılım bittikten sonra başlamak yerine süreç tasarlanırken başlayın. İş sahibiyle birlikte küçük bir örnek veri kümesi oluşturun ve doğru sonucu elle açıklayın. Teklif hesabında hangi alanların alınacağını, hangi durumda kayıt atlanacağını ve hangi işlemin insan onayı gerektirdiğini yazın. Geliştirici aynı örneklerle çalışsın. Sonradan bulunan her yeni durumun kapsam değişikliği mi yoksa mevcut kurala aykırılık mı olduğu daha açık görülür.

Temsili veri kümesini seçin

Yalnız düzgün kayıtlarla test yapmak kolaydır, fakat günlük iş böyle ilerlemez. Boş alan, tekrar eden kayıt, yanlış tarih, beklenmeyen karakter ve aynı isimli farklı müşteri gibi durumları örneklere ekleyin. Her örneğin neden seçildiğini belirtin. Gerçek kişisel veriyi gereksiz yere test ortamına taşımayın. Temsili veri kullanırken gerçek sistemin alan uzunluklarını ve biçimlerini koruyun; örnekler uygulamanın karşılaşacağı koşullara benzesin.

Bir dosyadaki satır sayısı tek başına doğruluk ölçütü değildir. Kaynak ve hedef alanların eşleşmesini, toplamların nasıl hesaplandığını ve geçersiz kayıtların nereye yazıldığını da kontrol edin. Kayıt atlanıyorsa sebebi görülebilsin. Tekrar çalıştırılan işlem aynı kaydı iki kez oluşturmasın. Örneklerin bir kısmını geliştiriciyle paylaşabilir, bir kısmını teslim kontrolü için ayırabilirsiniz; bütün beklentiler yine açık iş kurallarına dayanmalıdır.

Beklenen sonucu yazıya dökün

Her test satırında senaryo, girdi, işlem, beklenen çıktı ve gerçekleşen sonuç alanları olsun. Örneğin boş ürün koduyla gelen kaydın teklif oluşturmak yerine inceleme listesine alınması beklenebilir. Beklenen sonuca hata mesajının anlamını da ekleyin. Kullanıcı hangi alanı düzeltmesi gerektiğini anlayabilsin. Doğru çıktı dosyasının oluşması kadar yanlış işlemin yapılmaması da kabul testinin parçasıdır.

Yuvarlama, tarih ve metin karşılaştırmalarında belirsiz ifadeler kullanmayın. İş sahibinin kabul ettiği kuralı somut örnekle gösterin. Bir fiyatın hangi kaynaktan geldiği veya farklı para birimlerinin nasıl ele alındığı netleşmeden test sonucu yorumlanamaz. Yazılımın karar veremediği durumda işlemi durdurması ya da yetkili kişiye yönlendirmesi gerekiyorsa bu davranışı ayrıca sınayın. Tahminle devam etmek her süreçte uygun değildir.

Hata ve kesinti senaryolarını unutmayın

Dosya bulunamadığında, ağ bağlantısı kesildiğinde veya dış hizmet yanıt vermediğinde ne olacağını yazın. Bir işlemin yarısı tamamlandıysa yeniden başlatmak önceki kayıtları bozacak mı? Kullanıcı hatayı görebilecek mi? İşlem günlüğü hangi kaydın tamamlandığını gösterecek mi? Bu sorular, otomasyonun yalnız başarılı akışını değil, işletmenin kontrolünü koruyan davranışını da sınar. Kesinti denemelerini canlı işlem üretmeyen test ortamında yapın.

Geri dönüş planı da somut olsun. Yanlış çıktı oluştuğunda kaynak veri korunuyor mu, önceki sonuç arşivlenebiliyor mu ve hangi adımlar geri alınabiliyor? Geri alınamayan işlem varsa otomatik çalıştırmadan önce insan onayı veya ayrı bir kontrol noktası düşünün. Testte oluşturulan kayıtların temsili olduğu açıkça belirtilsin. Gerçek müşterilere deneme bildirimi göndermek veya gerçek ödeme başlatmak kabul testi için uygun bir kestirme değildir.

Yetki ve kullanıcı akışını birlikte sınayın

Tek bir yönetici hesabıyla yapılan test normal kullanıcının yaşadığı sorunları saklayabilir. İlgili rollerle hangi ekranların açıldığını ve hangi işlemlerin yapılabildiğini kontrol edin. Yetkisiz kullanıcı yalnız düğmeyi görmemeli değil, işlemi de gerçekleştirememelidir. Hangi hesapla test yapıldığını rapora yazın. Başarılı sonucu hangi kullanıcı rolünün ürettiği anlaşılmazsa aynı davranışın diğer çalışanlarda geçerli olduğu varsayılamaz.

Kullanıcı adımlarını baştan sona izleyin: veriyi seçme, ön kontrol, çalıştırma, sonucu görme ve istisnayı çözme. Otomasyonun çıktısını başka bir uygulama kullanacaksa aktarımı da test kapsamına alın. İlgili dosyanın oluşması tek başına yeterli olmayabilir. İş sahibi sonucu günlük görevinde kullanabiliyor mu, yanlış sonucu ayırt edebiliyor mu? Otomasyon iş akışını bu teslim noktalarıyla tanımlayın.

Teslim raporunu karar belgesine dönüştürün

Test sonunda geçen, kalan ve uygulanmayan senaryoları ayrı gösterin. Kalan bir hata için etkisini, geçici çözümü ve yeniden test koşulunu yazın. Çözülmeyen durumları başarılı sayıya dahil etmeyin. İş sahibi raporu okuyarak teslimi kabul etmek veya düzeltme istemek için yeterli bilgiye sahip olsun. Sürüm, test tarihi ve kullanılan veri kümesi kaydedildiğinde yeni sürümde hangi testlerin tekrar edilmesi gerektiği de belirlenebilir.

İlk kabulden sonra her küçük değişiklikte tüm sistemi baştan sınamak gerekmeyebilir. Değişen kurala bağlı testleri ve temel akışı yeniden çalıştırın. Daha önce geçen bir sonuç yeni sürümün kanıtı değildir. Veri işlerinde toplu veri aktarımı kapsamını kayıt karşılaştırmasıyla birlikte ele alın. Küçük, açık ve tekrarlanabilir bir test kümesi zamanla işletmenin değişiklik kontrolüne dönüşür.

Dikkat: gösterim ile kabul aynı değildir

Hazır bir videoda akışın düzgün görünmesi gerçek kabul testinin yerine geçmez. Test, belirli sürüm ve veriyle tekrarlanabilir olmalıdır. Performans beklentisi varsa kullanılan ortamı ve ölçüm yöntemini açıklayın; doğrulanmamış süre veya başarı oranı vaat etmeyin. Amaç kusursuzluk iddiası üretmek değil, teslimin sınırlarını görünür kılmak ve işletmenin hangi davranışı kabul ettiğini açıkça kaydetmektir.

Çalışmayı bitirirken kullanılan örneği ve alınan kararı aynı yerde saklayın. Sonraki ekip üyesi neden bu yolun seçildiğini anlayabilsin. Belirsiz kalan noktayı gizlemek yerine ilgili sorumluyla birlikte netleştirin. Küçük bir uygulama denemesi, kapsamlı görünen fakat kullanılmayan bir belgeden daha fazla bilgi verebilir. Bu denemeyi düzenli geri bildirimle geliştirin.

Sık sorulan sorular

İlk adım nedir?

Tek bir gerçek görev ve temsili örnek seçerek beklenen sonucu açıklayın.

Kim doğrulamalı?

Süreci bilen iş sahibi ve uygulamayı kullanan kişi birlikte kontrol etmelidir.

Ne zaman güncellenmeli?

İlgili süreç veya uygulama değiştiğinde etkilenen adımları yeniden doğrulayın.