Form Görünüşte Doğru. Veri Sözleşmesi Yanlış

Soru, AI tarafından oluşturulan bir formun üretime hazır görünüp görüneceği değil; verisini alan sistemin bunu kabul edip etmeyeceğidir.

Bir tarih seçici mükemmel bir şekilde görüntülenebilir ancak API ISO tarih beklerken yerel bağımlı bir dize gönderebilir. Bir onay kutusu evet ya da hayır diyebilir, fakat veritabanı Boolean bekler. Demo geçer, ekran görüntüsü temiz görünür ve hata akışın sonunda ortaya çıkar.

Form Gerçekte Ne Söz Veriyor?

Form tasarımı genellikle bir arayüz sorunu olarak incelenir. Etiketleri insanlar anlayabilir mi? Sekme sırası mantıklı mı? Sayfa bir telefon üzerinde düzgün çalışıyor mu? Bu sorular önemli, ancak işin tamamını tanımlamaz.

Bir form ayrıca başka bir sistemin yorumlayabileceği biçimde yapılandırılmış veri sağlamayı da vaat eder. Bu vaat, alan adları, veri tipleri, zorunlu değerler, izin verilen seçenekler, varsayılanlar, tanımlayıcılar ve hedef eşlemelerini kapsar. Alıcı sistemi değiştirmeden bunlardan birini değiştirirseniz, şık bir arayüz güvenilmez bir entegrasyona dönüşebilir.

Bu sınır, üretken AI belge otomasyonu metin taslağının ötesine geçip yapılandırılmış belgeler ve etkileşimli bileşenler üretmeye başladıkça görülmesi zorlaşır. Üretim hızlıdır çünkü bir model kısa bir açıklamadan makul bir düzen çıkarabilir. Ancak makul olmak, uyumlu olmakla aynı şey değildir.

IETF JSON Schema çalışma grubunun aktif Internet Taslağı, 26 Ağustos 2026’da son güncellenmiş, bir şemayı kabul edilen JSON değerlerini kısıtlayan kurallar kümesi olarak tanımlar. Ayrıca UI render’ları gibi üretken kullanım senaryolarını tartışır. Bu ikili, sorunun özüne dokunur: aynı şema bir arayüz oluşturmayı kolaylaştırabilir, ancak doğrulama hâlâ ortaya çıkan girdinin kabul edilen küme içinde olup olmadığını belirlemek zorundadır.

Sözleşme Neden Kayar?

AI, kötü bir sözleşme oluşturmak için bariz şekilde hatalı kod üretmek zorunda değildir. Sadece sistemin geri kalanının paylaşmadığı makul bir varsayımda bulunması yeterlidir.

“Müşteri Kimliği” etiketiyle bir onboarding formu hayal edin. Model alanı customer_id olarak adlandırır, ki bu mantıklı görünür. Mevcut API hâlâ account_number bekliyor. Her test kullanıcısı kutuyu doldurabilir, ancak entegrasyon beklenmeyen özelliği reddetmez ya da çevirmezse, tanımlayıcı doğru kayda hiç ulaşmayabilir.

Türler aynı tür uyumsuzluğunu yaratır. Boş bir alan boş dize, null ya da hiç bir özellik olmadan gelebilir. Bir sayı metin olarak gelebilir. Bir açılır menü dostane etiketler gösterebilir, ancak alıcı sistem sabit kodlar bekler. OpenAPI 3.2.0, giriş ve çıkış veri tiplerini tanımlamak için Şema Nesneleri kullanır ve ekiplere formu karşılaştırmak için makine tarafından okunabilir bir açıklama sunar; ekrana bakarak toplananlara güvenmek yerine.

Bağımlılıklar, kullanıcı seçimlerinin arkasında gizlendiği için gözden kaçması daha kolaydır. Bir ülke seçmek, bir eyalet, bölge ya da bölge alanını zorunlu kılabilir. “Şirket” yerine “bireysel” seçmek bir kayıt numarası gerektirebilir. JSON Schema’nın koşullu doğrulama özelliği, bağımlı gereksinimler ve koşullu alt şemalar aracılığıyla bu ilişkileri ifade edebilir, ancak üretilen form hâlâ aynı kuralları uygulamalıdır.

Geliştirici araçları, alan adlarını, tiplerini, değerlerini ve özelliklerini ortaya koyarak PDF form alanı doğrulamasını derleme sürecinin bir parçası haline getirir; bu, son aşamada görsel bir kontrol yerine gerçekleşir. Bu, bir şema doğrulayıcısını ya da bir API sözleşme testini değiştirmez. Geliştiricilere, bu testlerin incelemesi gereken form tarafı nesneleri üzerinde kontrol sağlar.

Kaymanın bir başka kaynağı daha vardır: form ve sözleşme başlangıçta uyumlu olabilir, ancak farklı takvimlerde değişebilir. Bir istem revize edilir. Bir alan etiketi yeniden adlandırılır. API bir seçeneği kaldırır ya da yeni bir zorunlu özellik ekler. Kimse bozuk bir düzen görmez, bu yüzden değişiklik zararsız gibi görünür.

Bu zararsız değildir.

Mutlu Yolun Ötesinde Nasıl Test Edersiniz?

Başarılı bir gönderim, bir değer kombinasyonunun bir kez çalıştığını kanıtlar. Üretim formları daha sıkı bir inceleme gerektirir.

Ekran görüntüsü yerine yüklemeden (payload) başlayın. Bilinen iyi bir örneği gönderin ve gerçek serileştirilmiş çıktıyı sözleşmeyle karşılaştırın. Özellik adlarını, tiplerini, iç içe yapıyı ve izin verilen değerleri kontrol edin. Ardından bu yüklemeyi gerçek entegrasyondan geçirin ve aynı değerlerin CRM, ERP veya veritabanına giden ve geri gelen turda korunup korunmadığını doğrulayın.

Sonraki testler başarısız olacak şekilde tasarlanmalıdır. Eksik bir zorunlu değer, null beklenen yerde boş dize, sınırların dışındaki bir sayı, beklenmeyen bir açılır menü seçeneği ve sözleşmenin tanımadığı bir özellik deneyin. Faydalı bir doğrulama katmanı yalnızca isteği engellemez; hatalı alanı ve kuralı, bir geliştiricinin, operatörün ya da kullanıcının düzeltmesi için yeterince açık bir şekilde tanımlar.

Koşullu dallanmalar kendi başına bir geçiş hakkına sahiptir. Bir form beş seçenek içeriyorsa ve bu seçenekler farklı takip alanlarını ortaya çıkarıyorsa, beşini de çalıştırın. Geri dönüşü de test edin: bir gizli alan, kullanıcı daha önceki yanıtı değiştirdiğinde eski bir değeri göndermemelidir. Bu, bir belge yapısı ve bağlamı makalesinin sıradan yazılım testleriyle buluştuğu yerdir. Belgedeki ilişkileri anlamak, bu ilişkilerin serileştirme sonrası da korunması durumunda faydalıdır.

Alan kimliği, alan ifadesinden daha önemlidir. Etiketler açıklık, çeviri ve marka sesini sağlamak için değişir. Kararlı iç kimlikler bunlarla birlikte değişmemelidir. Bu nedenle bir sürüm kontrolü, görünür etiketi, iç adı, beklenen türü ve hedef eşlemesini ayrı özellikler olarak karşılaştırmalıdır.

Son olarak, alıcı sistem mevcut olmadığında veya gönderimi reddettiğinde ne olduğuna dikkat edin. Form, kullanıcının çalışmasını korur mu? Güvenli bir şekilde yeniden deneme yapar mı, yoksa kopyalar oluşturur mu? Bir operatör, ham günlükleri okumadan hatayı izleyebilir mi? belge işleme iş akışları ve kurumsal sistemler arasında veri hareketi, devretme tamamlanmadan önce gösterilen bir başarı mesajı yerine gözlemlenebilir bir hata yolu gerektirir.

Yayınlandıktan Sonra Sözleşmeyi Kim Sahiplenir?

Sözleşme testi, yalnızca sürüm öncesinde yapılan tek seferlik bir temizlik olamaz. Form, şema ve aşağı akış arayüzü değişmeye devam edecektir.

Bir ekip, iş akışının parçalarını birkaç ekip sahipleniyor olsa bile sözleşmenin net sahipliğine ihtiyaç duyar. Bu sahibi, her kopya değişikliğini onaylamak zorunda değildir. Ancak hangi değişikliklerin gönderilen veriyi değiştirebileceğini, hangi testlerin çalıştırılması gerektiğini ve doğrulama hataları ortaya çıktığında kimin yanıt vereceğini bilmelidir.

Şemayı, form tanımıyla sürümleyin. Şablon, istem, form kodu veya API değiştiğinde sürekli entegrasyonda temsilci sözleşme testlerini çalıştırın. Üretimde, reddedilen gönderimleri ve alan ve sözleşme sürümüne göre eşleme hatalarını izleyin. Bir sürüm sonrası bir hatada artış, “form çalışmayı durdurdu” gibi belirsiz bir rapordan çok daha kolay teşhis edilir.

Şema doğrulamasının kanıtlayabileceği şeylerin bir sınırı vardır. Bir değerin bildirilen kısıtlamalara uyduğunu gösterebilir. Ancak kullanıcının doğru değeri seçtiğini, iş kuralının mantıklı olduğunu veya iş akışının her güvenlik, gizlilik, erişilebilirlik veya uyumluluk gereksinimini karşıladığını kanıtlayamaz. Takımlar, sonuçların gerektirdiği durumlarda hâlâ politika kontrollerine ve insan yargısına ihtiyaç duyar.

Bu istisna, bir sözleşme için savunmayı zayıflatmaz. Sözleşmenin görevini tanımlar.

Sonuç

Yapay zeka, bir tanımdan çalışan bir forma geçiş süresini kısaltabilir. Ayrıca, arkasındaki vaat henüz kimse tarafından test edilmeden bir arayüzün tamamlanmış gibi görünmesini sağlayabilir.

Sürüm kararı, açık alan semantiğine, hata durumlarını içeren sözleşme testlerine ve sonraki değişikliklere dayanacak sahipliğe dayanmalıdır. Temiz bir ekran hoş karşılanır. Önemli olan daha zor sorudur: kabul edilen her girdi, onu alan sistem tarafından doğru şekilde yorumlanabilir mi?