Bir yazılım ve donanım projesinin en kritik anı, “hazır” denildiği andır. Bu noktada sistem kurulmuş, ekranlar açılıyor, cihazlar bağlanmıştır. Ama sistemin gerçekten işi taşıyıp taşımadığı, ancak doğru yapılmış bir kabul testinde ortaya çıkar. Bu test aceleye getirilirse, eksikler ilk yoğun günde, müşterinin ya da ekibin önünde görünür.
Kabul testi, teslim alan tarafın sistemi kendi işi açısından denediği ve “bunu teslim alıyorum” dediği aşamadır. Bu yazıda kabul testinin nasıl hazırlanacağını, neyin kontrol edilmesi gerektiğini ve teslimin hangi belgelerle tamamlanacağını anlatıyoruz.
Kabul ölçütleri proje başında yazılır
Kabul testinin en sık yapılan hatası, ölçütlerin teslim günü düşünülmesidir. O noktada iki taraf da yorgundur, takvim baskısı vardır ve “çalışıyor mu?” sorusunun cevabı kişiden kişiye değişir. Oysa neyin kabul edileceği, projenin başında ihtiyaçlarla birlikte yazılmalıdır.
İyi bir kabul ölçütü gözlemlenebilir bir cümledir: “Depo görevlisi gelen bir koliyi el terminaliyle okutup rafa yerleştirdiğinde stok, satış ekranında güncel görünür.” Böyle bir cümleyi herkes aynı biçimde dener ve sonucu tartışmasızdır. “Stok modülü düzgün çalışır” gibi genel ifadeler ise teslimde anlaşmazlık yaratır.
Test senaryolarını iş akışından türetin
Kabul testi, ekranların tek tek açılıp kapatılması değildir. Sistemin desteklediği her ana iş akışı, gerçek hayatta olduğu gibi baştan sona yürütülür. Örneğin bir sipariş girilir, depoda toplanır, etiketi basılır, sevk edilir, faturası kesilir ve raporlarda görünür. Bu yolculuğun her adımında beklenen sonuç yazılıdır.
Senaryolar hazırlanırken yalnız “her şeyin yolunda gittiği” durumlar değil, sıradışı durumlar da eklenmelidir:
- Stokta olmayan ürün siparişe eklenirse ne olur?
- Yarıda bırakılan bir işlem sonradan nasıl tamamlanır?
- Yanlış okutulan bir ürün nasıl geri alınır?
- İptal ve iade akışları nasıl işler?
- Aynı kayıt üzerinde iki kişi aynı anda çalışırsa ne görünür?
Gerçek kullanımda sorunların çoğu bu kenar durumlarda çıkar; testte görülmeleri, sahada görülmelerinden çok daha ucuzdur.
Testi gerçek veriyle ve gerçek kişilerle yapın
Deneme verisiyle yapılan testler, gerçek verinin tuhaflıklarını göstermez: çok uzun ürün adları, özel karakterli müşteri unvanları, eksik adres bilgileri, eski sistemden kalan tekrar eden kayıtlar. Taşınan gerçek verinin bir kopyasıyla test yapmak, hem veri taşımanın doğruluğunu hem de ekranların gerçek içerikle nasıl göründüğünü sınar.
Testi yapacak kişiler de önemlidir. Sistemi geliştiren ekip nasıl kullanılması gerektiğini bildiği için, farkında olmadan doğru yolu izler. Asıl kullanıcılar ise alışkanlıklarıyla, beklenmedik sırayla ve hızla çalışır. Kabul testinde günlük işi yapan kişilerin bulunması, sistemin gerçek ekipte nasıl davranacağını gösterir.
Donanım ve ağ ayrı bir başlık
Yazılım ve donanımın birlikte teslim edildiği projelerde cihazlar da kabul testinin parçasıdır. Her cihaz türü kendi gerçek kullanım yerinde denenir:
| Kontrol | Nasıl denenir? |
|---|---|
| El terminali | Sahanın en uzak noktasında okutma |
| Etiket yazıcısı | Gerçek etiket rulosuyla baskı |
| Barkod okuyucu | Yıpranmış ve küçük etiketler |
| Kablosuz ağ | Raf araları ve köşelerde dolaşma |
| Bağlantı kesintisi | Ağ kapatılıp işlem sürdürme |
| Elektrik kesintisi | Sunucu ve ağ cihazının dönüşü |
Özellikle bağlantı kesintisi testi atlanmamalıdır. Ağ kısa bir süre gittiğinde sistemin işlemleri nasıl sakladığı ve bağlantı geri geldiğinde veriyi eksiksiz gönderip göndermediği, ancak bilinçli olarak kesinti yaratılarak görülür.
Entegrasyonları da uçtan uca deneyin
Sistem muhasebe programı, e-ticaret sitesi, kargo firması ya da e-belge entegratörü gibi dış sistemlerle konuşuyorsa, bu bağlantılar da kabul testine dahil edilir. Bir siparişin karşı sisteme doğru alanlarla ulaştığı, karşı taraftan dönen bilginin doğru kayda işlendiği ve bağlantı hata verdiğinde bunun bir yerde görünür olduğu kontrol edilir. Dış sistemin test ortamı varsa önce orada, yoksa kontrollü birkaç gerçek işlemle denenir. Entegrasyon hataları çoğu zaman sessizdir; testte görülmezse ilk fark eden müşteri olabilir.
Yoğunluk anını taklit edin
Sistem tek bir kullanıcıyla sorunsuz çalışabilir; ama ay sonu, kampanya dönemi ya da sabah vardiya başlangıcı gibi anlarda bütün ekip aynı anda işlem yapar. Kabul testinde bu yoğunluğu mümkün olduğunca taklit etmek gerekir: Birden fazla kişi aynı anda sipariş girer, raporlar alınırken depo okutma yapar, toplu etiket basılır. Ekranların yavaşlayıp yavaşlamadığı ve kayıtların karışıp karışmadığı bu sırada gözlenir.
Raporlar da bu aşamada kontrol edilmelidir. Yöneticinin her gün baktığı rapor, testte girilen işlemleri doğru topluyor mu? Eski sistemden alınan bir raporla yeni sistemin aynı döneme ait raporu karşılaştırıldığında farklar açıklanabiliyor mu? Rakamların tutması, ekibin yeni sisteme güvenmesinin en hızlı yoludur.
Yetkiler, yedek ve geri dönüş
Çoğu kabul testinde unutulan üç konu vardır. Birincisi yetkilerdir: Her rol yalnız görmesi gerekeni görüyor mu? Depo görevlisi fiyat değiştirebiliyor mu, satış ekibi maliyetleri görebiliyor mu? Her rol için ayrı bir kullanıcıyla giriş yapıp kontrol etmek gerekir.
İkincisi yedeklemedir. Yedeğin alındığını görmek yeterli değildir; yedekten bir geri dönüşün gerçekten yapılabildiği en az bir kez denenmelidir. Geri yüklenemeyen bir yedek, yedek sayılmaz.
Üçüncüsü geri dönüş planıdır. Yeni sistem yayına alındıktan sonra beklenmedik ciddi bir sorun çıkarsa ne yapılacağı, eski düzene nasıl dönüleceği ya da hangi işin elle sürdürüleceği önceden yazılmalıdır.
Hataları önemine göre sınıflayın
Kabul testinde hata bulunması olağandır; önemli olan, bulunan hataların nasıl ele alınacağının baştan konuşulmuş olmasıdır. Basit bir sınıflama işi kolaylaştırır:
- Kritik: ana iş akışını durduran ya da veriyi bozan hatalar. Bunlar giderilmeden kabul yapılmaz.
- Önemli: işi zorlaştıran ama bir yolu bulunan hatalar. Kabul, giderilme planı yazılı olarak yapılabilir.
- Küçük: görünüm, yazım ya da konfor sorunları. Bir listeye alınır ve sonraki güncellemelerde ele alınır.
Her hata, nasıl tekrarlanacağı, beklenen ve görülen sonuçla birlikte tek bir listede tutulur. Düzeltilen her madde yeniden denenir ve listede kapatılır. Hangi sınıfa gireceği tartışmalı olan maddeler için son sözün kimde olduğu da baştan belirlenmelidir.
Teslim paketinde neler olmalı?
Teslim yalnız sistemin çalışır hâlde bırakılması değildir. Sonraki dönemde sistemi kullanacak, bakımını yapacak ya da genişletecek herkesin ihtiyaç duyacağı bilgiler de teslim edilir:
- Kullanıcı rehberleri ve kısa iş akışı anlatımları,
- Cihaz listesi, ağ düzeni ve kurulum ayarları,
- Kullanıcı ve yetki yapısı,
- Yedekleme düzeni ve geri dönüş adımları,
- Destek talebinin nasıl açılacağı ve iletişim kanalı,
- Kabul testi sonuçları ve açık kalan maddelerin listesi.
Teslimin sonunda iki tarafın imzaladığı kısa bir kabul tutanağı, neyin teslim alındığını ve hangi maddelerin sonraya bırakıldığını kayıt altına alır.
Yayına aldıktan sonraki ilk dönem
Kabul testi ne kadar iyi yapılırsa yapılsın, gerçek kullanımın ilk döneminde yeni sorular ve küçük sorunlar çıkar. Bu dönemde destek ekibinin daha yakında olması, ekiplerin sorularına hızlı cevap verilmesi ve gözlenen sorunların kayda geçirilmesi, sistemin benimsenmesini belirler. İlk dönem sonunda kısa bir değerlendirme yapıp açık kalan maddeleri gözden geçirmek, teslimin asıl tamamlandığı andır.
Bu değerlendirmede yalnız hatalar değil, kullanım alışkanlıkları da konuşulmalıdır. Ekip bazı ekranları beklenenden farklı mı kullanıyor, elle sürdürülen bir iş kaldı mı, bazı raporlar hiç açılmıyor mu? Bu gözlemler, sonraki geliştirmelerin önceliğini belirlemek için en değerli kaynaktır. Kabul testinde hazırlanan senaryolar da saklanmalıdır; sonraki her güncellemede aynı senaryoları tekrar çalıştırmak, yeni bir değişikliğin eskiden çalışan bir şeyi bozmadığını görmenin en kolay yoludur.
Bunny Soft teslimi nasıl yürütüyor?
Yazılımı ve onu çalıştıracak sunucu, cihaz ve ağ kurulumunu tek ekip olarak üstlendiğimiz için teslimi de bütün olarak ele alıyoruz. Sistemi gerçek kullanım senaryolarıyla uçtan uca deniyor, ekibinizi eğitiyor ve ardından teslim ediyoruz; teslimde neyin nasıl çalıştığı belgelenir. Kurulumu çalışma saatlerinizi ve yoğun dönemlerinizi gözeterek planlıyor, gerektiğinde geçişi aşamalara bölüp eski düzenle yeni sistemi bir süre birlikte çalıştırıyoruz.
Birden fazla lokasyonlu projelerde kurulumu genellikle bir lokasyonda deneyip doğruladıktan sonra diğerlerine yayıyoruz. Teslimden sonra yazılım ve donanım için tek muhatabınız oluyoruz; destek ve bakımın kapsamını, müdahale şeklini ve iletişim kanalını teslimden önce sizinle yazılı olarak netleştiriyoruz.
Projenizin yazılımını, donanımını ve teslimini tek elden yürütmek için proje yazılımı ve donanımı sayfamızı inceleyebilirsiniz.
