Fatura formu testi: hangi senaryolar mutlaka denenmeli?

Fatura formu testi, kurumsal bir hesabın fatura bilgilerini toplayan ekranın farklı ülkelerde, farklı mükellef türlerinde ve eksik bilgi durumlarında nasıl davrandığını sınamaktır. Bu yazıda formda hangi alanların bulunduğunu, hangi senaryoların en sık atlandığını ve kurgusal bir kayıt kümesiyle bu senaryoların nasıl kurulacağını bulacaksınız.

Fatura formunda hangi alanlar bulunur?

Kurumsal bir fatura formu, kimlik, adres ve vergi olmak üzere üç grup alandan oluşur. Kimlik grubunda işletmenin unvanı ve varsa hukuki yapısı yer alır. Adres grubunda fatura adresi ayrı alanlar hâlinde toplanır. Vergi grubunda ise vergi numarası ve birlikte gereken diğer numaralar bulunur.

Bu gruplar birbirinden bağımsız değildir. Ülke alanı değiştiğinde adresin yapısı, posta kodunun biçimi ve vergi alanının zorunluluğu birlikte değişir. Mükellef türü değiştiğinde ise bazı alanlar tamamen kaybolur: bireysel bir hesapta işletme unvanı ve vergi numarası istenmez.

Tabloyu bir kontrol listesi olarak kullanmak, formun eksik tasarlanmasını engeller. Ancak asıl iş, bu alanların hangi koşulda görüneceğini doğru kurmaktır.

Ülkeye göre neler değişir?

Ülkeye göre değişen ilk şey adres düzenidir. Bazı ülkelerde adres, sokaktan şehre doğru daralan bir sırayla yazılır; bazılarında ise idari bölüm adresin ortasında yer alır. Posta kodu bazı ülkelerde harf de taşır, bazılarında yalnızca rakamdır; bazı ülkelerde ise posta kodu hiç kullanılmaz.

İkinci değişen şey vergi alanlarının zorunluluğudur. Bazı ülkelerde kurumsal bir fatura için vergi numarası zorunludur; bazılarında ise numara olmadan da fatura düzenlenebilir. Bu yüzden alanı her ülkede zorunlu tutmak, geçerli bir kaydı reddetmeye yol açar.

Üçüncü değişen şey, numaranın yanında istenen ek bilgidir. Bazı düzenlerde numaranın yanı sıra kayıt numarası ya da bir şube kodu da istenir. Bu alanları tüm ülkelerde göstermek formu gereksiz yere uzatır; hiç göstermemek ise bazı ülkelerde eksik beyana yol açar. Doğru yaklaşım, alanları ülkeye bağlı olarak göstermektir.

Dördüncü değişen şey, adres ile numaranın tutarlılığıdır. Bazı akışlarda vergi numarasının ülkesi ile fatura adresinin ülkesinin aynı olması beklenir. Bu kontrol, iki alan arasında bir bağımlılık kurar ve formun bu bağımlılığı kullanıcıya açıkça anlatması gerekir.

Mükellef türüne göre hangi alanlar kaybolur?

Bireysel ve kurumsal faturalama, aynı formun iki farklı dalıdır. Bireysel tarafta işletme unvanı, hukuki yapı ve vergi numarası istenmez; buna karşılık kişi adı ve kimlikle ilgili alanlar öne çıkar. Kurumsal tarafta ise bu alanların tamamı gerekir.

Bu ayrımın mühendislik tarafındaki sonucu, formun tek bir alan kümesi olarak değil, mükellef türüne göre değişen iki ayrı küme olarak kurulmasıdır. Alanları gizlemek yetmez; gizlenen alanların doğrulama kuralları da devre dışı kalmalıdır. Aksi hâlde görünmeyen bir alan, formu sessizce bloke eder ve kullanıcı hiçbir hata mesajı görmeden ilerleyemez.

İkinci sonuç, iki dal arasındaki geçiştir. Kullanıcı bireysel faturalamadan kurumsal faturalamaya geçtiğinde, daha önce girilmiş bilgiler korunmalı mı yoksa temizlenmeli mi? Bu karar ürün tarafında verilir; ancak hangi karar verilirse verilsin, test kümesinde bu geçiş ayrı bir senaryo olarak bulunmalıdır.

En sık atlanan senaryolar hangileridir?

Fatura formlarında en çok atlanan dört dal vardır. Bunların ortak özelliği, mutlu yolun dışında kalmalarıdır.

• Vergi numarası olan kurumsal kayıt: Beklenen ana yol. Alanların tamamı dolu gelir, doğrulama geçer.
• Vergi numarası olmayan kurumsal kayıt: Alan boş bırakılır. Bu dalda formun alanı zorunlu tutmaması ve faturayı yine de üretmesi gerekir.
• Sınır ötesi kayıt: Adresin ülkesi ile numaranın ülkesi farklıdır. Bu dalda tutarlılık kontrolünün ve vergi muamelesinin doğru çalışması gerekir.
• Bireysel kayıt: İşletme alanları hiç görünmez. Bu dalda gizlenen alanların doğrulamasının da kapandığı doğrulanmalıdır.

Bu dört dalın yanına üç senaryo daha eklenmelidir: eksik zorunlu alan, geçersiz biçimde numara ve aynı formun iki kez gönderilmesi. Sonuncusu özellikle önemlidir; çift tıklama veya ağ yeniden denemesi, aynı faturanın iki kez oluşmasına yol açabilir.

Fatura numarasının her faturada tek olması ve aynı isteğin tekrar gönderildiğinde ikinci bir fatura üretmemesi, formun kendisinden çok sunucu tarafındaki akışın konusudur. Ancak bu davranışın test kümesinde karşılığı olmalıdır; çünkü en sık üretim hatası burada çıkar.

Kurgusal kayıtla bu senaryolar nasıl kurulur?

Bu senaryoların hepsi, gerçek bir işletmenin bilgisi olmadan kurulabilir. Gereken şey, her dal için ayrı bir kurgusal kayıttır: vergi numarası dolu bir kurumsal kayıt, numarası boş bir kurumsal kayıt, adresi ile numarasının ülkesi farklı bir kayıt ve bireysel bir kayıt.

Kurgusal kaydın buradaki faydası, senaryoların birbirine karışmamasıdır. Gerçek kayıt kullanıldığında, hangi dalın hangi veriyle denendiği zamanla belirsizleşir; kurgusal kayıtta ise kaydın hangi dal için üretildiği unvandan ve adresten anlaşılır. Kaydın kurgu olduğu ilk bakışta görülecek biçimde seçilmelidir.

Bu kayıtları elle yazmak yerine üretmek, kümenin tutarlı kalmasını sağlar. Ülke değiştiğinde adresin, posta kodunun ve numaranın birlikte değişmesi gerekir; bu bağı elle korumak kırılgandır. Sitedeki test şirket verisi üreticisinde ülke seçip kayıt üretmek, bu tutarlılığı baştan sağlar.

Geliştiriciler için: vaka matrisi, tekrar gönderim ve hata sırası

Fatura formunu test ederken ilk adım, vaka matrisini yazılı hâle getirmektir. Matrisin iki ekseni vardır: mükellef türü ve ülke. Her hücrede vergi numarasının dolu veya boş olması ayrı bir satır oluşturur. Bu matrisi yazmadan teste başlamak, kaç dalın hiç denenmediğini görünmez kılar.

İkinci konu, tekrar gönderimdir. Kullanıcı gönder düğmesine iki kez bastığında veya ağ isteği yeniden denendiğinde, aynı faturanın iki kez oluşmaması gerekir. Bunun yolu, her gönderim isteğine istemci tarafında üretilen bir anahtar eklemek ve sunucunun aynı anahtarla gelen ikinci isteği yeni bir kayıt oluşturmadan yanıtlamasıdır. Bu davranışın testi, isteğin kasıtlı olarak iki kez gönderilmesiyle yapılır.

Üçüncü konu, doğrulama sırasıdır. Alanların doğrulaması tek bir geçişte değil, kullanıcının formu doldurma sırasına yakın biçimde yapılmalıdır. Kullanıcı ülkeyi seçmeden posta kodunu doğrulamak anlamsızdır; çünkü hangi biçimin beklendiği henüz bilinmiyordur. Bu yüzden doğrulama, bağımlı olduğu alan dolduğunda çalışmalıdır.

Dördüncü konu, hatanın yerini göstermektir. Uzun bir formda yalnızca üstte genel bir hata göstermek, kullanıcıyı hatayı aramaya bırakır. Hatanın alanın yanında görünmesi ve formun o alana kaydırılması gerekir. Birden fazla hata varsa, ilk düzeltilmesi gereken alan öne çıkarılmalıdır.

Beşinci konu, test verisinin işaretlenmesidir. Deneme kayıtları, üretim kayıtlarından her bakışta ayırt edilebilmelidir; bunun için unvanda yapay bir ifade ve varsa kayıt üzerinde bir bayrak kullanılabilir. Bu işaret, verinin yanlışlıkla üretim ortamına taşınmasını engelleyen en basit korumadır. Deneme ve üretim ortamlarının veritabanı düzeyinde ayrılması ise bir tercih değil, zorunluluktur.

Son olarak, faturanın görünen yüzünü de sınayın: unvanın uzun bir birleşik ad olduğu, adresin çok satıra yayıldığı ve numaranın farklı uzunlukta geldiği durumlarda çıktının bozulmadığını kontrol edin. Form doğru veriyle çalışsa bile, çıktı yerleşimi bu durumlarda kırılabilir. Bu senaryoları kurgusal kayıtlarla güvenle deneyebilirsiniz.

Sonraki adımlar

İlk adım, vaka matrisini yazmak ve hangi hücrelerin hiç denenmediğini işaretlemektir; eksikler genellikle vergi numarası boş olan ve sınır ötesi olan dallarda toplanır. İkinci adım, aynı formu iki kez göndermeyi denemek ve ikinci bir faturanın oluşmadığını doğrulamaktır.

Farklı ülkelerden kurgusal kayıt üretmek için test şirket verisi üreticisine, numaranın doğrulama tarafı için vergi numarası doğrulama kuralları yazısına, sürecin bütünü için ise KYB deneme listesine bakabilirsiniz.

Bu yazıdaki yöntemler yalnızca yazılım testi içindir; gerçek bir fatura düzenlemek, gerçek bir vergi beyanı vermek ya da bir işletme adına işlem yapmak için kullanılamaz.