Yazılım Teslimi: Kabul Testleri ve Güvenli Yayın Planı

Kabul ölçütünü özellik yazılırken belirleyin

Bir özellik için başlık yazmak kolaydır: “Bayi sipariş verebilecek.” Fakat hangi ürünleri göreceği, hangi fiyatın uygulanacağı, yetkisiz işlemde ne olacağı ve bağlantı koparsa kaydın durumu bu başlıkta yoktur. Kabul ölçütü bu boşlukları doldurur. İşletme sorumlusu ve teknik ekip, aynı cümlenin farklı anlamlarını taşımamalıdır.

Önerilen senaryoda koşul, eylem ve beklenen sonuç ayrı yazılır: “Aktif bayi, yetkili olduğu fiyat listesindeki ürünü seçip siparişi onayladığında tek sipariş kaydı oluşur; ürün ve fiyat sürümü kayda bağlanır.” Bu sentetik bir örnektir, bütün projeler için zorunlu tasarım değildir. Ama bir ekranın görünmesinden daha denetlenebilirdir.

Her kritik özellik için normal davranış, yanlış veri, eksik yetki ve tekrar durumunu düşünün. Bütün olasılıkları ilk günde sıralamak mümkün olmayabilir; keşfedilen yeni durumlar kabul setine eklenmelidir. Önemli olan belirsizliği tamamlandı etiketiyle kapatmamaktır.

Altı katmanlı teslim matrisi oluşturun

Tablo, projeye uyarlanacak bir öneridir. Her satırı yalnızca bir kutu olarak işaretlemek yerine hangi sürümde, hangi ortamda ve hangi veriyle test edildiğini kaydedin. Testi yapan kişi ve kabul yetkilisi de belli olsun. “Geçti” sonucunu destekleyen kayıt olmadan geçmiş testleri yeniden yorumlamak zorlaşır.

Otomatik testler ve insan değerlendirmesi farklı işler yapabilir. Hesaplama ve yetki kuralları otomatik kontrol edilebilirken, karmaşık formun anlaşılır olup olmadığı gerçek kullanım incelemesi gerektirebilir. Bir yöntemin varlığını diğerinin gereksiz olduğu şeklinde yorumlamayın. Kapsamı risk ve kullanıcı akışı üzerinden seçin.

Olumsuz testler teslimin merkezinde yer alsın

Yalnız doğru veriyle yapılan başarılı işlemler, hataların nasıl yönetildiğini göstermez. Yetkisi kaldırılmış kullanıcı, süresi dolmuş oturum, eksik ürün eşleştirmesi ve aynı isteğin tekrar gönderilmesi için beklenen davranışları yazın. Kullanıcıya gösterilen mesaj kadar kalıcı verinin doğru kalması da önemlidir.

OWASP ASVS, güvenlik gereksinimlerini doğrulama çerçevesi sağlar. Projede hangi gereksinimlerin uygulandığı, test yöntemi ve açık bulgular belirtilmelidir. Bir tarayıcı raporunda hata bulunmaması, kapsamlı güvenlik değerlendirmesinin tamamlandığı anlamına gelmez. [2]

Önerilen yayın koşullarında kritik veri sızıntısı veya yanlış tahsilat gibi hatalar ayrı engel olarak tanımlanabilir. Ortalama test başarı oranı yüksek diye bu hatalar önemsizleşmez. Hangi bulgunun yayını durduracağı ve hangi düşük etkili konunun planlı düzeltmeye bırakılabileceği önceden kararlaştırılmalıdır.

Performansı kullanıcı işiyle ilişkilendirin

“Sunucu ayakta” bilgisini “kullanıcı işini tamamlayabiliyor” ile karıştırmayın. Ana sayfa açılırken sipariş onayı çalışmıyor olabilir. Bu nedenle ölçüm, kritik akışı temsil etmelidir. Google SRE yaklaşımında hizmet seviyesi göstergeleri ve hedefleri, güvenilirliği karar alınabilir biçimde tanımlamak için kullanılır; hata bütçesi de bu hedefle ilişkilendirilir. [1]

Tamamen varsayımsal bir ölçümde 30.000 uygun işlemin en az yüzde 99,5’inin başarılı olması hedeflensin. Bu tanımla 150 başarısız işlem hedefin hata payını oluşturur. 75 başarısız işlem bu payın yarısıdır. Bu örnek bir Ganz hizmet garantisi veya önerilen evrensel eşik değildir; pay ve paydanın açık tanımlanmasının önemini gösterir.

Hangi işlemlerin uygun sayıldığını, neyin başarı kabul edildiğini ve ölçüm aralığını yazın. Kullanıcının geçersiz form göndermesi ile sunucunun doğru isteği işleyememesi aynı sınıf olmayabilir. Ölçüm tanımı net değilse iki ekip aynı olayı farklı raporlayabilir. Hedefi işletmenin kabul edilebilir deneyimiyle birlikte belirleyin.

Yayın kararını küçük ve geri izlenebilir hale getirin

Önerilen yayın paketi kod sürümü, veri değişikliği, etkinleştirilecek özellik, etkilenen kullanıcı grubu ve geri dönüş adımlarını içersin. Bir özellik anahtarıyla yeni işlevi sınırlı gruba açmak değerlendirilebilir. Ancak anahtarı kapatmanın veri üzerindeki etkileri geri alıp almadığı ayrıca incelenmelidir.

İlk kullanıcı grubunu sadece teknik ekibin kolay ulaşabildiği kişilerden seçmek yerine, temsilî iş akışlarını kapsayacak şekilde düşünün. Kademeli yayın sırasında hangi ölçüm bozulursa durulacağı ve kararı kimin vereceği belli olsun. “Bir sorun olursa bakarız” ifadesi işletim planı değildir.

Yayından önce ve sonra aynı kontrol listesini çalıştırın. Kimlik doğrulama, kayıt oluşturma, rapor alma ve ilgili dış sistemlere aktarım gibi kritik noktaları gözlemleyin. Gerçek kullanıcıya sahte bildirim veya sipariş oluşturmayan kontrollü yöntemler kullanın. Test amacıyla canlı veriye müdahale gerekiyorsa ayrıca yetki ve kapsam belirlenmelidir.

Geri dönüş planını yalnız uygulama sürümüyle sınırlamayın

Yeni sürümü kapatmak, yeni sürümün değiştirdiği veriyi geri getirmeyebilir. Örneğin alan silinmişse veya iki kayıt birleştirilmişse eski kod aynı veriyi beklediği biçimde bulamayabilir. Geri dönüş belgesinde uygulama, şema, veri ve dış sistem etkilerini ayrı ele alın.

Yedek alındığının kaydı ile yedeğin çalışır biçimde geri yüklenebildiğinin kaydı farklıdır. Önerilen provada izole ortamda geri yükleme yapılır ve kritik iş akışı yeniden denenir. Ne kadar veri kaybının ve ne kadar toparlanma süresinin kabul edilebilir olduğu işletmeyle belirlenir. Bu hedefler ölçülmeden müşteriye mutlak süre sözü verilmemelidir.

Geri dönüş sırasında oluşan yeni işlemlerin ne olacağı da yazılmalıdır. İki sistem arasında kaybolan kayıtları sonradan elle bulmak zorunda kalmamak için eşleştirme ve mutabakat yöntemini önceden düşünün. Provanın değeri, yalnız komutun çalışması değil, işin tutarlı şekilde devam edebilmesidir.

Kabul dosyasını herkesin okuyabileceği bir özetle teslim edin

Dosyada sürüm kimliği, kapsam, geçirilen senaryolar, geçirilmemiş senaryolar, bilinen sınırlamalar ve açık bulgular bulunsun. Ekran görüntüleri yardımcı olabilir; ancak hangi adımların izlendiğini ve beklenen sonucu tek başına açıklamayabilir. Yeniden denemek isteyen kişinin aynı sonuca nasıl ulaşacağını belirtin.

Kaynak kodu, kurulum bilgisi, bağımlılıklar ve hesap sahipliği de teslim kapsamının parçası olarak ele alınmalıdır. Şifreleri açık belgede paylaşmak yerine güvenli devir yöntemi belirleyin. Bakım dönemi başlayınca hata, değişiklik isteği ve yeni özellik talebinin nasıl ayrılacağını netleştirin.

Yüzde 100 test kapsamı sıfır hata demek midir?

Hayır. Kapsamın neyi ölçtüğü ve testlerin hangi davranışı kontrol ettiği önemlidir. Hiç düşünülmemiş bir iş kuralı, mevcut testlerin tamamı geçerken sorun oluşturabilir. Sonucu “bu kapsam bu koşullarda doğrulandı” şeklinde ifade edin.

Müşteri kabulü teknik ekibin testinden ayrı mı olmalı?

İşletmenin gerçek iş beklentisini onaylaması ayrı bir sorumluluktur. Teknik testler bu kararı destekler. İyi teslim süreci, bütün sorumluluğu müşteriye aktarmadan ve müşteriyi devre dışı bırakmadan iki tarafın beklentisini ortak kanıtta birleştirir.