Web Sitesindeki İletişim Formlarının Çalıştığı Nasıl Kontrol Edilir? Form İzleme Rehberi

Bir iletişim formunun ekranda görünmesi ve “mesajınız gönderildi” uyarısı vermesi, talebin gerçekten ilgili kişiye veya sisteme ulaştığını tek başına göstermez. Form; tarayıcıda doğru çalışabilir, sunucuda kaydedilebilir fakat e-posta gönderiminde, CRM aktarımında ya da webhook bağlantısında sessizce durabilir.

Bu nedenle form kontrolü yalnızca gönder düğmesine basmaktan ibaret olmamalıdır. Kullanıcının alanları doldurmasından başlayıp talebin e-posta kutusuna, CRM kaydına veya ilgili entegrasyona ulaşmasına kadar bütün zincir doğrulanmalıdır. Kritik formlar için test sonucu, tarih, kullanılan test verisi ve alınan aksiyon da kayıt altına alınmalıdır.

Önce Hangi Formların Kritik Olduğunu Belirleyin

İlk adım, web sitesindeki formların envanterini çıkarmaktır. Yalnızca iletişim sayfasındaki formu değil, kullanıcı veya potansiyel müşteri talebi oluşturan bütün noktaları listeleyin:

• İletişim formu
• Teklif veya keşif talebi formu
• İş başvurusu formu
• Bayilik, üyelik veya kayıt formu
• Ürün ya da hizmet bilgi formu
• Randevu ve rezervasyon formu
• Dosya yüklenen başvuru formları
• Bülten veya etkinlik kayıt formu

Her form için sayfa adresini, formun amacını, beklenen alıcıyı, varsa CRM veya webhook hedefini ve iş tarafındaki sorumluyu yazın. Böylece yalnızca teknik ekibin bildiği dağınık bir yapı yerine kontrol edilebilir bir form listesi oluşur.

Formların önceliği aynı olmayabilir. Satış talebi alan teklif formu, genel geri bildirim formundan daha kritik görülebilir. Ancak öncelik kararı yalnızca formun adına göre verilmemelidir. Talebin iş sürecindeki rolü, beklenen kullanım yoğunluğu, içerdiği veri ve arıza hâlinde oluşabilecek operasyonel etki birlikte değerlendirilmelidir.

Başarı Mesajı Neden Yeterli Değildir?

Bir form gönderildiğinde kullanıcı genellikle üç sonuçtan birini görür: başarı mesajı, alan doğrulama uyarısı veya genel hata bildirimi. Bu mesajlar kullanıcı deneyimi için gereklidir. W3C Web Accessibility Initiative form bildirimleri rehberi, kullanıcının gönderimin başarılı olup olmadığı ya da hangi hatayı düzeltmesi gerektiği konusunda açık biçimde bilgilendirilmesini önerir.

Ancak kullanıcıya gösterilen mesaj, zincirin yalnızca görünen kısmıdır. Uygulama başarı yanıtını verdikten sonra aşağıdaki işlemlerden biri başarısız olabilir:

• Form kaydı veri tabanına yazılamayabilir.
• E-posta servisi iletiyi kabul etmeyebilir veya yanlış adrese gönderebilir.
• Mesaj spam ya da karantina klasörüne düşebilir.
• CRM bağlantısı yetki, alan eşleştirmesi veya API değişikliği nedeniyle çalışmayabilir.
• Webhook yanıt verebilir fakat veriyi işleyemeyebilir.
• Dosya eki boyut, biçim veya depolama sınırına takılabilir.
• Bildirim alıcısı değiştiği hâlde eski adres kullanılmaya devam edebilir.

Dolayısıyla “başarı mesajını gördük” ile “talep hedef sisteme ulaştı” iki ayrı kontrol sonucudur. Form testi bu iki sonucu ayrı ayrı kaydetmelidir.

Yedi Aşamalı Uçtan Uca Form Kontrolü

Aşağıdaki matris, farklı yapıdaki formları ortak bir yöntemle kontrol etmek için kullanılabilir.

1. Sayfayı ve Form Davranışını Kontrol Edin

Form sayfasını yalnızca ofis bilgisayarında açmak yeterli değildir. En azından projenin desteklediği güncel masaüstü ve mobil görünümlerde alanların, seçim kutularının, dosya yükleme bileşenlerinin ve gönder düğmesinin kullanılabildiğini kontrol edin. Klavyeyle erişim, alan etiketleri ve hata mesajlarının anlaşılabilir olması da forma ulaşabilmenin bir parçasıdır.

2. Geçerli ve Geçersiz Veriyi Ayrı Ayrı Deneyin

Boş zorunlu alan, hatalı e-posta biçimi, çok uzun metin, seçilmemiş onay alanı veya desteklenmeyen dosya gibi senaryoları deneyin. W3C’nin form doğrulama rehberi, istemci tarafındaki kontrollerin kullanıcı hatalarını azaltabileceğini; ancak güvenlik için verinin sunucu tarafında da doğrulanması gerektiğini belirtir.

Kontrol yalnızca hatayı engellemekle bitmemelidir. Kullanıcı hangi alanın neden reddedildiğini ve nasıl düzelteceğini anlayabilmelidir. Geçerli bir gönderim ise yanlışlıkla engellenmemelidir.

3. Sunucu Tarafındaki İşlemi Doğrulayın

Tarayıcıdan gelen isteğin sunucuya ulaşıp ulaşmadığını ve beklenen iş akışının başlatılıp başlatılmadığını kontrol edin. Uygulamaya göre bu aşama veri tabanı kaydı, bildirim kuyruğu, dosya yükleme işlemi veya entegrasyon çağrısı olabilir.

Burada yalnızca HTTP yanıtına bakmak yeterli olmayabilir. Form işlemi birkaç adımdan oluşuyorsa, ilk adım başarılı görünürken sonraki adım başarısız olabilir. Test kaydının zamanını ve ayırt edici kimliğini bilmek, sunucu olayı ile hedef sistemdeki kaydı eşleştirmeyi kolaylaştırır.

4. Kullanıcıya Gösterilen Sonucu Kontrol Edin

Başarılı gönderim sonrasında kullanıcıya ne olacağı açık olmalıdır. Mesajın kaybolması, sayfanın boş kalması veya teknik hata metninin gösterilmesi, kullanıcıyı tekrar tekrar gönderim yapmaya yöneltebilir. Başarısız durumda da yalnızca “bir hata oluştu” demek yerine, güvenliği ihlal etmeden kullanıcının atabileceği adım açıklanmalıdır.

Kullanıcı mesajıyla gerçek işlem sonucu aynı olmalıdır. Sunucu işlemi başarısızken başarı mesajı gösterilmesi, sessiz form arızalarının en riskli örneklerinden biridir.

5. E-posta, CRM ve Webhook Teslimini Kontrol Edin

Form hangi hedeflere bağlanıyorsa her hedef ayrı doğrulanmalıdır. E-posta kullanılıyorsa doğru alıcı kutusunda test mesajını bulun. CRM kullanılıyorsa kaydın doğru alanlarla, doğru kaynak bilgisiyle ve beklenen sorumluya atanarak oluştuğunu kontrol edin. Webhook varsa isteğin yalnızca gönderildiğini değil, hedef sistemin veriyi işlediğini de doğrulayın.

Her projede bu üç kanalın tamamı bulunmak zorunda değildir. Kontrol matrisi, yalnızca onaylanan proje mimarisindeki gerçek hedefleri içermelidir.

6. Logları ve Test Kimliğini Eşleştirin

Kumsal Ajans bakım yaklaşımında form hataları ve başarısız gönderimler, proje kapsamına göre sunucu logları üzerinden takip edilir. OWASP Logging Cheat Sheet, uygulama hataları, bağlantı sorunları ve üçüncü taraf servis hata mesajları gibi olayların uygulama seviyesinde kaydedilmesini; aynı kullanıcı etkileşimine ait olayların ilişkilendirilebilmesini önerir.

Test gönderiminde ayırt edici ancak kişisel veri içermeyen bir test kimliği kullanmak yararlıdır. Örneğin ad veya açıklama alanına proje ekibinin bildiği bir test notu ve tarih eklenebilir. Böylece test talebi gerçek müşteri kayıtlarıyla karışmaz ve e-posta, CRM, webhook ile log kayıtları aynı işlem üzerinden eşleştirilebilir.

Log kaydı oluşturmak, form verisinin tamamını sınırsız süreyle saklamak anlamına gelmez. OWASP aynı rehberde erişim anahtarları, yüksek hassasiyetli veriler ve gereksiz kişisel bilgilerin kayda alınmaması; gerekli verilerin erişim ve saklama kurallarıyla korunması gerektiğini vurgular. Log kapsamı proje, güvenlik ve veri koruma gereksinimlerine göre belirlenmelidir.

7. Düzeltmeden Sonra Aynı Zinciri Yeniden Test Edin

Bir yapılandırma değişikliğinin kaydedilmiş olması, arızanın sona erdiğini tek başına göstermez. Aynı test senaryosunu yeniden çalıştırın ve kullanıcı mesajından hedef teslimine kadar bütün adımları tekrar doğrulayın. Sadece hata veren aşamayı değil, değişikliğin zincirin diğer noktalarını etkileyip etkilemediğini de kontrol edin.

Test Taleplerini Gerçek Taleplerden Nasıl Ayırabilirsiniz?

Test verisinin satış veya operasyon ekiplerinde gerçek talep olarak işlem görmesi karışıklık yaratabilir. Bu nedenle test kaydı için önceden belirlenmiş bir düzen kullanın:

• Ad veya şirket alanında açık bir test ifadesi kullanın.
• Açıklamaya tarih, form adı ve kısa test kimliği ekleyin.
• Proje için ayrılmış test e-posta adresi varsa onu kullanın.
• CRM’de test etiketi veya ayrı durum alanı tanımlanabiliyorsa uygulayın.
• Test tamamlandığında kaydın silinmesi mi, arşivlenmesi mi gerektiğini belirleyin.
• Gerçek kişilerin bilgilerini test amacıyla kullanmayın.

Test yöntemi spam filtrelerini, otomatik atamaları veya raporları etkiliyorsa ilgili ekipleri önceden bilgilendirin. Kontrolün amacı yeni bir operasyon sorunu üretmeden zincirin çalıştığını doğrulamaktır.

Form Kontrol Kaydında Hangi Alanlar Bulunmalı?

Basit bir tablo bile tekrarlanabilir kontrol için yeterli olabilir:

Bu kayıt, “form en son ne zaman kontrol edildi?” sorusunu cevaplamanın yanında, benzer bir arıza tekrarlandığında önceki çözümün incelenmesini de kolaylaştırır.

Kontrol Sıklığı Nasıl Belirlenir?

Bütün siteler için geçerli tek bir kontrol aralığı yoktur. Sıklık; formun iş açısından önemi, değişiklik yoğunluğu, entegrasyon sayısı, geçmiş arızalar ve bakım kapsamına göre belirlenmelidir. Kritik bir başvuru formu ile nadiren kullanılan genel geri bildirim formunun aynı plana sahip olması gerekmeyebilir.

Kumsal Ajans projelerinde formlar, onaylanan bakım kapsamına göre düzenli aralıklarla test edilebilir. E-posta, CRM ve webhook iletileri proje mimarisine göre uçtan uca kontrol edilir. Düzenli kontrol ve müdahalenin yıllık bakım paketine dahil olup olmadığı ise teklif ve bakım kapsamındaki görevlerle açıkça belirlenir. Bu ifade, bütün projeler için 7/24 izleme veya sabit müdahale süresi taahhüdü anlamına gelmez.

Kontrol sıklığını ve sorumlulukları yazılı hâle getirirken ücretsiz destek ile yıllık bakım arasındaki farkları açıklayan rehberden yararlanabilirsiniz.

Plan hazırlanırken en az şu olaylardan sonra ek kontrol düşünülmelidir:

• Form alanı veya tasarımı değiştiğinde
• E-posta sağlayıcısı ya da alıcı adresi değiştiğinde
• CRM, API veya webhook yapılandırması güncellendiğinde
• Alan adı, DNS, sunucu veya güvenlik katmanı değiştiğinde
• Spam önleme veya doğrulama servisi güncellendiğinde
• Yeni dil sürümü ya da yeni form sayfası yayımlandığında

Arıza Tespit Edildiğinde Nasıl İlerlenmeli?

Önce arızanın hangi aşamada oluştuğunu belirleyin. Form hiç gönderilemiyorsa kullanıcı arayüzü, doğrulama veya sunucu isteği incelenir. Başarı mesajı var fakat e-posta yoksa bildirim servisi ve alıcı kuralları kontrol edilir. CRM veya webhook kaydı eksikse yetki, alan eşleştirme, hedef adres, yanıt ve hata kayıtları incelenir.

Bildirim kanalı da önceden belirlenmelidir. Kumsal Ajans projelerinde arıza bildirimleri destek e-postası veya proje için belirlenen iletişim kanalı üzerinden alınır. Bildirimde form adresi, yaklaşık zaman, kullanılan test kimliği, görünen mesaj ve beklenen hedef yer almalıdır. Parola, erişim anahtarı veya gerçek müşteri verisi açık destek mesajına eklenmemelidir.

İsimsiz Gerçek Örnek: Başarı Mesajı Vardı, CRM Kaydı Yoktu

İsmi ve sektörü paylaşılmayan bir projede form, kullanıcıya başarılı gönderim mesajı gösteriyordu. Buna rağmen kontrollü test kaydı CRM’de bulunamadı. İncelemede webhook yapılandırmasının beklenen aktarımı tamamlamadığı görüldü. Yapılandırma düzeltildikten sonra aynı ayırt edici test verisiyle form yeniden gönderildi ve CRM kaydının oluştuğu doğrulandı.

Bu örnek, başarı mesajının neden tek başına yeterli olmadığını gösterir. Sorun, form sayfasının açılmaması değil; görünen sonuç ile arka plandaki teslim zincirinin birbirinden ayrılmasıydı. Örneğe ilişkin müşteri, tarih, hacim veya ticari etki bilgisi paylaşılmadığı gibi ölçülmemiş bir gelir ya da talep kaybı sonucu da ileri sürülmemektedir.

Sonuç: Formu Değil, Teslim Zincirini Kontrol Edin

Web sitesi form kontrolünü yalnızca sayfanın açılması ve başarı mesajının görünmesiyle tamamlamayın. Kritik formları listeleyin, kontrollü test verisi kullanın, geçerli ve geçersiz senaryoları deneyin, sunucu işlemini inceleyin ve talebin gerçek hedefe ulaştığını doğrulayın. Log, test kimliği, tarih, sorumlu ve tekrar test sonucu aynı kayıtta bulunsun.

Bakım planında hangi formların, hangi hedeflerin ve hangi koşullarda kontrol edileceğini açıkça tanımlamak; sessiz arızaları daha erken fark etmeyi ve teknik ekip ile iş ekibinin aynı sonuç üzerinden ilerlemesini kolaylaştırır. Formların yayın öncesindeki kabul adımlarını da düzenlemek için kurumsal web sitesi teslim kontrol listesini kullanabilirsiniz. Projenize özel form, entegrasyon ve bakım kapsamını değerlendirmek için Kumsal Ajans web tasarım hizmetini inceleyebilirsiniz.

Sık Sorulan Sorular

Form başarı mesajı görünüyorsa talep kesin olarak ulaşmış mıdır?

Hayır. Başarı mesajı, kullanıcının gördüğü arayüz sonucudur. Talebin ulaştığını doğrulamak için sunucu işlemi ile hedef e-posta, CRM veya webhook kaydı da kontrol edilmelidir.

İletişim formları ne sıklıkla test edilmelidir?

Her site için geçerli tek bir sıklık yoktur. Formun iş açısından önemi, entegrasyonları, değişiklik geçmişi ve onaylanan bakım kapsamı dikkate alınarak bir kontrol planı oluşturulmalıdır.

Form testi sırasında gerçek müşteri verisi kullanılmalı mı?

Hayır. Kişisel veri içermeyen, açıkça test olduğu anlaşılan bir kayıt ve ayırt edici test kimliği kullanılmalıdır. Testin silinme veya arşivlenme yöntemi de önceden belirlenmelidir.

E-posta ulaşıyor ancak CRM kaydı oluşmuyorsa ne kontrol edilmelidir?

Webhook veya API hedefi, yetkilendirme, alan eşleştirme, servis yanıtı ve ilgili hata logları incelenmelidir. Düzeltmeden sonra aynı test kimliğiyle uçtan uca tekrar test yapılmalıdır.

Form kontrolü yıllık bakım hizmetine dahil midir?

Bu, teklif veya bakım paketinde tanımlanan görevlere bağlıdır. Kumsal Ajans projelerinde düzenli form kontrolü ve müdahale, onaylanan yıllık bakım kapsamına göre dahil edilebilir; sabit sıklık veya 7/24 izleme kendiliğinden varsayılmaz.