Web ve Yazılım Projesinde Kabul Testi Nasıl Yapılır?

Yazılımcınız “proje hazır, kontrol edebilirsiniz” dedi. Siteye girdiniz, birkaç sayfaya baktınız, renkler güzel görünüyor. Peki bu, projeyi kabul etmek için yeterli mi? Çoğu zaman değil. Web projesi kabul testi, teslim alınan sistemin anlaşılan işi gerçekten yapıp yapmadığını, sizin bakış açınızdan ve gerçek kullanım koşullarında doğrulama sürecidir. Bu adım atlandığında sorunlar genellikle canlıya geçtikten sonra, müşterileriniz tarafından fark edilir.

Bu yazıda kabul testini teknik bilgi gerektirmeden nasıl planlayıp yürütebileceğinizi, hataları nasıl bildireceğinizi ve onayı nasıl belgeleyeceğinizi anlatıyorum.

Kabul testi nedir, diğer testlerden farkı ne?

Bir yazılım geliştirilirken birkaç katmanda test edilir. Geliştirici kendi kodunu birim testleriyle sınar, modüllerin birlikte çalıştığını entegrasyon testleriyle kontrol eder. Bu testlerin ayrıntılarını yazılım testi nedir yazısında anlattım. Kabul testi ise son halkadır ve geliştiricinin değil, işi sipariş eden tarafın testidir.

Aradaki fark bakış açısıdır. Geliştirici “kod doğru çalışıyor mu?” diye sorar; siz ise “bu sistem işimi görüyor mu?” diye sorarsınız. Bir form teknik olarak sorunsuz çalışabilir ama talebin yanlış kişiye gitmesi, sizin açınızdan kabul edilemez bir hatadır.

Kabul kriterlerini teslimden önce belirleyin

Kabul testinin en sık yapılan hatası, neyin test edileceğinin teslim günü düşünülmesidir. Oysa kriterler, projenin başında kapsamla birlikte yazılmalıdır. İyi bir kabul kriteri ölçülebilir ve tartışmaya kapalıdır.

Belirsiz ifade	Ölçülebilir kabul kriteri
Site hızlı olmalı	Ana sayfa mobilde Core Web Vitals eşiklerini karşılamalı
İletişim formu çalışmalı	Form gönderildiğinde talep belirlenen e-postaya ulaşmalı ve kullanıcıya teşekkür mesajı gösterilmeli
Mobil uyumlu olmalı	Tüm sayfalar yaygın telefon ve tablet boyutlarında yatay kaydırma olmadan okunmalı
Ürünler yönetilebilmeli	Yönetici panelden ürün ekleyip fiyat değiştirebilmeli, değişiklik sitede hemen görünmeli

Hız kriteri için Google’ın Core Web Vitals eşikleri iyi bir ölçüttür: LCP için 2,5 saniye, INP için 200 milisaniye ve CLS için 0,1. Bu ölçütlerin ne anlama geldiğini Core Web Vitals rehberinde bulabilirsiniz. Kriterlerin sözleşmeye ya da kapsam belgesine eklenmesi de önemlidir; bu konuda yazılım sözleşmesinde olması gerekenler yazısına bakabilirsiniz.

Web projesi kabul testi adım adım

Kriterler hazırsa testin kendisi düzenli bir iş hâline gelir. Aşağıdaki sırayı izlemenizi öneririm.

1. Test ortamında başlayın: Kabul testi, canlı siteye geçmeden önce test (staging) ortamında yapılmalıdır. Böylece gerçek müşteriler hatalardan etkilenmez.
2. Senaryoları gerçek kullanıcı gibi yazın: “Bir ziyaretçi Google’dan hizmet sayfasına gelir, fiyat bilgisi ister, formu doldurur” gibi baştan sona akışlar hazırlayın.
3. Farklı cihaz ve tarayıcılarda deneyin: En az bir Android telefon, bir iPhone ve bir masaüstü tarayıcıda aynı senaryoları tekrarlayın.
4. Yönetici tarafını test edin: Panele girip içerik ekleyin, düzenleyin, silin. Siteyi yönetecek kişinin bu testi bizzat yapması çok değerlidir.
5. Hatalı veriyle deneyin: Formu eksik doldurun, yanlış e-posta yazın, çok uzun bir metin girin. Sistemin anlaşılır uyarılar verip vermediğine bakın.
6. Sonuçları kaydedin: Her senaryo için “geçti” ya da “kaldı” notu düşün ve kalanları ayrıntılı bildirin.

Hangi alanlar mutlaka kontrol edilmeli?

• Tüm formlar, bildirim e-postaları ve otomatik mesajlar
• Ödeme, sepet ve sipariş akışı (varsa test kartlarıyla)
• Üye girişi, şifre sıfırlama ve yetki ayrımları
• Sayfa başlıkları, meta açıklamalar ve yönlendirmeler gibi SEO ayarları
• KVKK aydınlatma metni, çerez bildirimi ve yasal sayfalar
• Kırık bağlantılar, eksik görseller ve yazım hataları

Hataları nasıl bildirmelisiniz?

“Form çalışmıyor” gibi bir bildirim, geliştiricinin sorunu yeniden üretmesini zorlaştırır. İyi bir hata bildirimi şu bilgileri içerir:

• Hangi sayfada ve hangi adımda oldu?
• Ne yaptınız, ne bekliyordunuz, ne oldu?
• Hangi cihaz ve tarayıcıyı kullandınız?
• Varsa ekran görüntüsü ya da kısa ekran kaydı

Bildirimleri tek bir listede toplamak ve her birini “kritik”, “önemli” ya da “kozmetik” olarak sınıflandırmak, düzeltmelerin doğru sırayla yapılmasını sağlar. Kritik bir hata (ödeme alınamaması gibi) teslimi durdurur; kozmetik bir hata (bir boşluk farkı gibi) ise kabulü engellemeyip sonraki küçük güncellemeye bırakılabilir.

Onay, tutanak ve sonrası

Tüm kritik ve önemli hatalar giderildiğinde kabul resmîleştirilir. Bunun için kısa bir kabul tutanağı yeterlidir: Test edilen kapsam, test tarihi, kalan küçük işler ve tarafların onayı. Bu belge hem garanti süresinin başlangıcını hem de bakım döneminin çerçevesini belirler.

Kabulden sonra canlıya geçiş yapılır ve teslim edilen dosyalar, şifreler ve dokümanlar kontrol edilir. Bu son adımlar için web sitesi teslim kontrol listesi pratik bir rehber sunar. Web projesi kabul testi ile teslim kontrolü birbirini tamamlar: Biri sistemin doğru çalıştığını, diğeri her şeyin eksiksiz size devredildiğini doğrular.

Bu işi nasıl birlikte yaparız?

1. Kriterleri baştan yazıyoruz: Kapsamı konuşurken kabul kriterlerini de birlikte belirliyor ve teklif belgesine ekliyorum.
2. Test ortamı ve senaryolar: Geliştirme sırasında size özel bir test adresi açıyor, kabul testinde kullanabileceğiniz hazır bir senaryo listesi paylaşıyorum.
3. Bildirim ve düzeltme: Notlarınızı tek bir listede topluyor, öncelik sırasına göre düzeltip tekrar test etmeniz için haber veriyorum.
4. Tutanak, canlıya geçiş ve destek: Kabul tutanağını imzaladıktan sonra canlıya geçişi planlıyor, garanti ve destek sürecini başlatıyoruz.

Yeni bir projeye başlamadan önce kabul kriterlerini birlikte netleştirmek isterseniz iletişim sayfasından bana yazabilirsiniz.

Sık sorulan sorular

Kabul testini kim yapmalı?

Sistemi gerçekten kullanacak kişiler yapmalıdır. Siteyi yönetecek çalışan, satış ya da müşteri hizmetleri sorumlusu, teknik bilgisi olmasa bile en değerli test kullanıcısıdır.

Kabul testi ne kadar sürer?

Projenin büyüklüğüne bağlıdır. Kurumsal bir sitede birkaç gün yeterli olabilirken, ödeme ve üyelik içeren sistemlerde daha uzun bir süre ayırmak gerekir. Süreyi baştan takvime eklemek önemlidir.

Küçük hatalar varken projeyi kabul edebilir miyim?

Kritik ve önemli hatalar giderildiyse, kozmetik eksikler tutanağa “kalan işler” olarak yazılarak kabul yapılabilir. Böylece hem süreç ilerler hem de eksikler kayıt altında kalır.

Kabulden sonra çıkan hatalar ne olur?

Anlaşılan kapsam içindeki hatalar genellikle garanti süresinde giderilir. Yeni istekler ise ayrı bir talep olarak değerlendirilir; bu ayrımın sözleşmede net olması gerekir.

Sonuç

Planlı bir web projesi kabul testi, teslim gününü bir formaliteden gerçek bir güvenceye dönüştürür; projeniz için bu süreci birlikte kurmak isterseniz bana ulaşabilirsiniz.