Yazılım firması “bitti” dedi: kabul testi nasıl yapılır, neye imza atarsınız?

Yazılım teslim edildiğinde vermeniz gereken karar "çalışıyor mu" değil, "sözleşmede yazan ölçütleri karşılıyor mu" sorusunun yazılı cevabıdır. O cevabı üretecek üç ayrı iş vardır: kabul testi, yani gerçek kullanıcıların taşınmış gerçek veriyle ve kendi yetkileriyle kendi işlerini uçtan uca yapması; operasyonel kabul, yani sistemi ayakta tutacak tarafın yedekten dönüşü, izlemeyi ve sürüm geri almayı kendi gözüyle görmesi; bir de devreye alma planı. Üçü tamamlanmadan atılan imza, sonradan çıkan sorunların faturasını sizin tarafınıza yazar. Türk Borçlar Kanunu bunu açıkça söyler: eseri gözden geçirmeyi ve ayıpları bildirmeyi ihmal eden işsahibi, eseri kabul etmiş sayılır.

Demo kabul testi değildir

Demoda yolu satıcı seçer. Veriyi o hazırlar, senaryoyu o kurar, takıldığı yerde "burası zaten canlıda farklı çalışacak" der ve devam eder. Kabul testinde yolu siz seçersiniz: veri taşınmış gerçek veridir, kullanıcı kendi hesabıyla girer, kendi rolüyle çalışır, kendi işini yapar.

Microsoft'un Dynamics 365 uygulama rehberi, kabul testi maddesinde sahada en sık atlanan iki noktayı doğrudan yazıyor: test sırasında herkese yönetici rolü vermeyin, kullanıcılara gerçek güvenlik rollerini atayın; testi üretime mümkün olduğunca benzeyen bir ortamda çalıştırın. Boş bir veritabanında ve yönetici yetkisiyle yapılan test, canlıda karşılaşacağınız durumun provası değildir.

Kabul ölçütü teslimden önce yazılır

Kabul ölçütünü teslim haftasında yazmaya başladıysanız test yapmıyorsunuz, pazarlık ediyorsunuz. Ölçüt sözleşme ekinde, gereksinimlerin yanında durmalı ve sayı içermeli. "Hızlı açılsın" bir ölçüt değildir; "sipariş listesi 50 bin kayıtta 2 saniyenin altında açılır" ölçüttür. Gereksinimi ölçülebilir yazmanın yolunu yazılım şartnamesi yazısında ele almıştık.

İşlevsel olmayan tarafı unutmamak için hazır bir liste var. ISO/IEC 25010 standardı 2023'te yenilendi ve ürün kalite modeli dokuz özellikten oluşuyor: işlevsel uygunluk, performans verimliliği, uyumluluk, etkileşim yeteneği, güvenilirlik, güvenlik, bakım yapılabilirlik, esneklik ve emniyet. 2011 sürümündeki "kullanılabilirlik" ve "taşınabilirlik" başlıkları yerini etkileşim yeteneği ile esnekliğe bıraktı, emniyet (safety) ise yeni eklendi. Bu dokuz başlığı kabul toplantısının gündemi olarak kullanabilirsiniz: her biri için ya bir ölçüt yazarsınız ya da "bu projede aranmıyor" dersiniz. Sessiz geçilen başlık, sonradan tartışma çıkan başlıktır.

Aslında dört ayrı kabul testi var

ISTQB'nin terminolojisinde kabul testi dört biçimde ele alınır: kullanıcı kabul testi, operasyonel kabul testi, sözleşmesel ve düzenleyici kabul testi, bir de alfa ve beta testi. Türkiye'deki projelerde atlanan neredeyse her zaman ikincisidir.

Operasyonel kabul, yazılımın kullanıcıya değil işletmeye hazır olup olmadığını sorar. Yedekten geri dönüş gerçekten denendi mi, ne kadar sürdü? İzleme ve alarm kurulu mu, alarm kimin telefonuna gidiyor? Sürümü geri alma adımı yazılı mı, bir kez uygulandı mı? Bir hata olduğunda log nerede duruyor, ne kadar süre saklanıyor? Bu sorular üretimde ilk kez sorulduğunda cevapları pahalıya mal olur. İzlenebilirlik, SLO ve hata bütçesi yazısı bu tarafın ölçülerini anlatıyor.

İmzadan önce kısa bir güvenlik kontrolü

Kabul, güvenlik tarafının da son durağıdır. Beş soruyla başlayın: depoda gömülü API anahtarı veya parola kaldı mı, varsayılan yönetici hesapları kapatıldı mı, rol matrisi gerçekten uygulanıyor mu, bağımlılıkların bilinen açıkları tarandı mı, para ve yetki değiştiren işlemler denetim izine düşüyor mu?

Yetki kontrolünü ayrı bir tarama işine bırakmayın, doğrudan kabul senaryolarının içine koyun. "Satış temsilcisi A, temsilci B'nin müşteri kaydını açabiliyor mu" sorusu bir kullanıcının on saniyede test edebileceği bir şeydir ve sızdıran yetkilendirmelerin çoğu bu kadar basit bir denemeyle ortaya çıkar. Ayrıntılar için yetkilendirme modeli, sır yönetimi ve denetim izi tasarımı yazılarına bakabilirsiniz.

Senaryoyu iş diliyle yazın, ekran adımlarıyla değil

Kötü bir kabul senaryosu şuna benzer: "Siparişler ekranını aç, Yeni'ye tıkla, alanları doldur, Kaydet'e bas." Kullanıcı ne doğruladığını bilmez, tıklar ve geçer. İyi senaryo işi tarif eder: "Beklemede olan bir siparişi iptal et, iade faturasını oluştur, stoğun geri yüklendiğini ve muhasebe fişinin oluştuğunu kontrol et."

Her senaryonun tek bir davranışı doğrulaması, bir sahibi ve yazılı bir beklenen sonucu olsun. Kullanıcıların ayırabileceği süre kısıtlıdır, o yüzden en çok para ve itibar taşıyan 20 ila 30 senaryoyu seçip önceliklendirin. Test taşınmış gerçek veriyle yapılmalı; verinin kendi provası ayrı bir iştir ve onu eski sistemden yeni sisteme veri taşıma yazısında anlatmıştık.

Hata listesi karar üretmiyorsa işe yaramaz

Kabul testinden 300 maddelik bir liste çıkması normaldir. Sorun, listenin sınıflandırılmamış olmasıdır. Üç kova yeter: engelleyici (iş yapılamıyor, kabul durur), önemli (geçici çözüm var, sahibi ve tarihi belirlenir), küçük (sıraya girer). Şiddet ile öncelik ayrı şeylerdir: nadir kullanılan bir ekranda veri kaybettiren hata şiddetlidir ama sırası beklenebilir; ana ekranda yanlış hizalanmış bir buton hafiftir ama her müşteri gördüğü için öne alınabilir.

Kabul tutanağında üç liste bulunsun: kapatılanlar, kabulden önce kapatılacaklar (her birinin sahibi ve tarihiyle), bilinçli olarak ertelenenler. Üçüncü listedeki her madde için ertelemeyi kimin onayladığı yazılı olsun. Bu tek satır, altı ay sonraki "bunu kim kabul etti" tartışmasını bitirir.

Şartlı kabul, "kabul etmiyoruz" demekten daha işe yarar

Kabul ikili bir anahtar değildir. Kalan işler küçükse ve sistem iş yapmaya elverişliyse şartlı kabul, projeyi bloke etmeden elinizi korur: kabul edilir, açık kalemler listeye bağlanır, ödemenin bir bölümü o listenin kapanmasına bağlanır. Garanti süresi ve o süre içinde hangi tür hataların ücretsiz düzeltileceği aynı metinde tanımlanmalı.

Bakım ve garanti kapsamının nasıl faturalandığı sözleşme modeline göre değişir; iki modelin riski nasıl dağıttığını sabit fiyat mı, zaman-malzeme mi yazısında karşılaştırmıştık.

Gözden geçirmek bir hak değil, bir külfet

Türk hukukunda yazılım geliştirme işi çoğunlukla eser sözleşmesi sayılır ve Borçlar Kanunu işsahibine aktif bir görev yükler. Madde 474'e göre işsahibi, eserin tesliminden sonra işlerin olağan akışına göre imkan bulur bulmaz eseri gözden geçirmek ve ayıpları uygun bir süre içinde yükleniciye bildirmek zorundadır.

Madde 477 sonucu bağlar: eserin açıkça veya örtülü olarak kabulünden sonra yüklenici her türlü sorumluluktan kurtulur, gözden geçirmeyi ve bildirimde bulunmayı ihmal eden işsahibi eseri kabul etmiş sayılır. Sonradan ortaya çıkan ayıbı gecikmeksizin bildirmezseniz yine kabul etmiş sayılırsınız. Kasten gizlenen ve usulüne uygun bir gözden geçirmede fark edilemeyecek ayıplar bu kuralın dışındadır. Madde 478 ise süreyi koyar: taşınmaz yapılar dışındaki eserlerde ayıp sebebiyle açılacak davalar teslimden itibaren iki yılda, yüklenicinin ağır kusuru varsa yirmi yılda zamanaşımına uğrar. Pratik karşılığı şu: kabul testi bir nezaket değil, hakkınızı ayakta tutan işlemdir ve tarihli, imzalı bir tutanağı olmalıdır. Kamuya yazılım satıyor ya da alıyorsanız süreç zaten bağlıdır; 4735 sayılı kanunun 11. maddesine göre kurulan muayene ve kabul komisyonu işi teslim alır.

Devreye alma provasız yapılmaz

Kabul imzalandıktan sonra geriye takvimin en dar penceresi kalır. Microsoft'un go-live kontrol listesi devreye almadan önce şunları arıyor: kapsamın paydaşlarla mutabık olması, bütün test döngülerinin çıkış ölçütleriyle kapanıp imzalanması, geçiş sırasında çalıştırılacak betiklerin önceden test edilip onaylanması, dış bağımlılıkların takvimle hizalanması, üretim ortamının hazırlanması ve destek planının kurulmuş olması. Veri taşımanın birkaç kez prova edilmesi ve geçiş penceresine sığdığının ölçülmesi de aynı listede.

Geçiş planı saat saat yazılır: hangi adım, kim yapar, ne kadar sürer, kim doğrular. Kararı verecek tek bir isim olsun ve geri dönüş tetikleyicisi önceden yazılsın. "Kötü giderse döneriz" bir plan değildir; "iki saat içinde sipariş akışı başlamazsa eski sisteme dönülür" plandır. Kesintiyi azaltan teknikleri sıfır kesintili yayına alma yazısında toplamıştık.

İlk iki hafta ayrı bir iştir

Devreye almadan sonraki yoğun destek dönemine sektörde hypercare deniyor ve planlanması gereken bir kalemdir: kim bakıyor, hangi kanaldan, hangi saatlerde, ne kadar süreyle ve hangi eşikte ekip toplanıyor. Bu dönem aynı zamanda kabul testinin gözden kaçırdığı şeyleri gösterir, çünkü gerçek kullanıcı sayısı ve gerçek yük ilk kez oradadır.

Kabulle birlikte teslim alınacaklar listesi de bu haftalarda tamamlanmalı:

• Depo ve tüm sürüm geçmişi, temiz bir makinede çalıştığı doğrulanmış derleme ve dağıtım talimatıyla birlikte.
• Ortam değişkenlerinin ve sırların nerede tutulduğu, kimlerin eriştiği.
• Bulut, alan adı, sertifika, e-posta ve ödeme sağlayıcı hesaplarının şirket adına açılmış olması.
• Çalıştırma kitabı: yedekten dönüş, sürüm alma, sık görülen arızalar ve ilk müdahale adımları.
• Kabul senaryolarının kendisi ve varsa otomatik testler. Bunlar bir sonraki sürümün de güvencesidir, test otomasyonu yazısı nedenini anlatıyor.
• Açık hata listesi, bilinen sınırlar ve bağımlılık ile lisans dökümü.

Hakların hukuken devri bundan ayrı bir başlıktır ve tek başına kodun elinizde olduğu anlamına gelmez; kaynak kod mülkiyeti ve emanet yazısı o tarafı ele alıyor.

Bu haftaya sığan ilk adım

Sözleşmenizde "kabul" kelimesinin geçtiği maddeyi bulun ve üç soruyu cevaplayın: kabul ölçütleri nerede yazılı, kabulü kim imzalıyor, imzadan sonra hangi süre boyunca hangi hatalar garanti kapsamında düzeltiliyor? Üçünden biri boşsa teslim tarihinden önce doldurun. Teslim haftasında açılan bu konuşma pazarlığa döner, öncesinde açılırsa prosedür olur.

Kabul testini yürütecek tarafsız bir göz arıyorsanız Wedevit olarak bu incelemeyi uzaktan yapıyoruz: ölçütlerin yazılması, senaryoların hazırlanması, bulguların sınıflandırılması ve devreye alma kontrol listesi. Sonuçta elinizde imzalanabilir bir tutanak ve savunulabilir bir karar kalır.