Başarı ölçütünü görüşmeden önce yazın
Bir demo ekranında adisyon açılması tek başına canlıya çıkma onayı değildir. Doğru rezervasyon, masa, lokasyon, gelir merkezi, kapanış ve ödeme eşleşmesi birlikte doğrulanmalıdır. Testte hem beklenen sonucu hem de hata halinde beklenen güvenli davranışı belirleyin.
Temel rezervasyon testi
Örnek bir rezervasyon açın, desteklenen masaya atayın ve check-in yapın. Simphony'de yalnız hedef gelir merkezinde doğru adisyonun oluştuğunu kontrol edin. Adisyonun numarası ve ilgili rezervasyon kimliği test kaydına yazılmalıdır.
Ardından test ürünü ekleyip POS üzerinde kapatın; doğrulanmış kapanış harcamasının doğru rezervasyona dönüp dönmediğini kontrol edin. Oracle Checks API adisyon işlemlerini RVC bağlamında yürütür.
İstisna ve tekrar testleri
Masa atanmamış rezervasyonu deneyin; yanlış gelir merkezinde rastgele adisyon açılmamalıdır. Aynı check-in isteği tekrarlanırsa ikinci bir adisyon oluşmaması beklenir. Hatalı check-in geri alındığında boş adisyon ve ürün/ödeme içeren adisyon için farklı güvenli davranışları sınayın.
Ön ödeme ve kapatma testi
Tahsil edilmiş uygun ön ödeme için tanımlanmış ödeme türü ve kalan bakiye kontrol edilir. Kısmi, tam ve açık bakiyeyi aşan örneklerde sonucun nasıl ele alındığını yazın. Provizyon ile tahsilatı birbirine karıştırmayın.
Gün sonu mutabakatında Rezervem'deki tahsilat, Simphony ödeme kaydı ve banka/ödeme sağlayıcısı kaydı ayrıca karşılaştırılmalıdır.
Test sonuçları nasıl imzalanır?
Her kabul testi için beklenen sonuç, gerçekleşen sonuç, test tarihi, işletme lokasyonu ve onaylayan ekip kaydedilmelidir. Adisyon numarası veya rezervasyon kimliği gibi örnek kayıtlar üretim dışı test verisiyle tutulmalı; gerçek misafir bilgileri gereksiz yere belgeye eklenmemelidir.
Örneğin aynı check-in çağrısı iki kez yapıldığında ikinci bir adisyon oluşmaması bekleniyorsa yalnız 'başarılı' işareti yeterli değildir: iki çağrının aynı işlemle ilişkilendirildiği veya ikinci çağrının güvenli biçimde reddedildiği gösterilmelidir. Sonuç kabul edilmeden başka gelir merkezine geçiş yapılmamalıdır.
Bildirim ve kesinti senaryosu
Oracle'ın STS Gen2 webhook dokümanı bildirimlerin yeniden gönderim garantisi olmadığını açıklıyor. Bu nedenle kritik kapanış veya durum güncellemelerinin eksik kalması halinde operatörün nasıl fark edeceği, hangi kontrollü sorgulama veya telafi adımını kullanacağı teknik ekiple tanımlanmalıdır.
Bir test lokasyonu başarılı olmadan diğer outletleri açmayın. Mevcut canlıya geçiş rehberi operasyonel hazırlığı tamamlar.
Oracle resmî kaynakları
Oracle Simphony integration programme · STS Gen2 API · API Accounts.
