Kabul Kriterleri

Kabul kriterleri, bir işin tamamlanmış sayılması için karşılaması gereken belirli koşullardır. Bir gereksinime veya kullanıcı hikayesine eşlik ederler, işe başlamadan önce kararlaştırılırlar ve sonucun değerlendirildiği objektif temeli sağlarlar. İşlevleri, niyetin genel bir tanımını, tartışılmaktan ziyade doğrulanabilir bir şeye dönüştürmektir.

Onların yokluğu, tahmin edilebilir ve pahalı bir düzene yol açar. İş genel terimlerle tanımlanır, bir kişinin yorumuna göre oluşturulur ve farklı bir yoruma sahip biri tarafından gözden geçirilir; bu noktada anlaşmazlık, en uygunsuz anda yeniden çalışma olarak ortaya çıkar. Kriterleri önce yazmak, bu anlaşmazlığı, çözümü yeniden inşa etmek yerine bir konuşmaya mal olacak noktaya taşır.

İki format baskındır. Basit bir kontrol listesi, geçerli olması gereken her koşulu belirtir; bu, basit gereksinimlere uygundur ve yazılması hızlıdır. Davranış odaklı geliştirmeden alınan "verilen-ne zaman-o zaman" yapısı, bir başlangıç ​​bağlamı, bir eylem ve beklenen bir sonucu belirtir; bu, koşullu davranışa uygundur ve doğrudan otomatik testlere eşlenir. İkisi de özünde üstün değildir ve bir ekip içindeki tutarlılık, seçimden daha önemlidir.

En değerli kriterler, anlatının atladığı noktaları kapsayanlardır. Olumlu senaryo genellikle açıktır ve nadiren tartışılır; tartışmalar doğrulama kuralları, hata durumları, boş ve aşırı veriler, izin sınırları, harici bir hizmetin başarısız olması durumunda ne olacağı ve davranışın cihazlar arasında nasıl farklılık gösterdiği ile ilgilidir. Sadece beklenen durum için kriterler yazan ekipler, geri kalanını test sırasında keşfederler ve bu da genellikle zaman çizelgesinin oluştuğu yerdir.

Kriterler, uygulama yerine sonuçları tanımlar ve bu da ekibin bir yaklaşım seçme yeteneğini korur. Bir kullanıcının belirli bir süre içinde onay alması gerektiğini belirtmek bir kriterdir; hangi kuyruk teknolojisinin bunu göndermesi gerektiğini belirtmek ise kabul bildiriminde yer almaması gereken bir tasarım kararıdır. Uygulamayı belirten kriterler, karar verme yetkisine sahip kişileri kısıtlar ve sıklıkla gereksiz olduğu ortaya çıkan bir çözümü kodlar.

Kriterler ve testler arasındaki izlenebilirlik, ikisinin zaman içinde birbirinden uzaklaşmasını engeller. Her bir kriterin, otomatik veya manuel olsun, bir doğrulamaya karşılık geldiği durumlarda, kapsam görünür olur ve gereksinimdeki bir değişiklik, testte de bir değişikliğe yol açar. Ayrı ayrı tutulduklarında ise, testler zamanla sistemin yapması gerekeni değil, yaptığı şeyi tanımlamaya başlar; bu da niyetin tersine dönmeyi yakalama yeteneklerini ortadan kaldırır.

İşlevsel olmayan beklentiler, önemli olduklarında kriterlere dahil edilir ve genellikle atlanır. Performans eşikleri, erişilebilirlik gereksinimleri, tarayıcı ve cihaz desteği ve güvenlik kısıtlamaları, kabul koşullarının tümüdür ve bunların örtük bırakılması, tutarsız bir şekilde ele alınmalarına veya daha sonraki bir denetimde keşfedilmelerine yol açar. Bir ekip, tüm çalışmaları kapsayan ortak bir "tamamlanma tanımına" sahip olduğunda, bireysel kriterlerin yalnızca bu tanımdan sapmaları belirtmesi yeterlidir.

Bu kriterlerin birlikte yazılması, belgenin kendisinden ziyade fayda sağlayan şeydir. Bir kişi tarafından taslak haline getirilip teslim edilen kriterler bir spesifikasyonu aktarır; yeteneği isteyen kişi, onu geliştiren kişi ve test eden kişi arasında tartışılan kriterler, belirsizlikler henüz ortaya çıkmadan önce onları gün yüzüne çıkarır. Tartışma sıklıkla gereksinimi değiştirir, ki bu da asıl amaçtır.

Kriterler neyin test edileceğini tanımladığından, gereksinim tanımlamasını ardışık aşamalar olarak ele almak yerine, doğrudan kalite güvencesine bağlarlar. Uygulamada bunlar şu şekilde yazılır: ürün geliştirme İyileştirme sürecinin bir parçası olarak, kullanılabilirlik ve erişilebilirlik koşulları, belirlenen standartlar doğrultusunda dikkate alınmıştır. kullanıcı deneyimi denetimi Bu sayede kabul edilebilir olan şey, ürünün yalnızca işlevsel davranışını değil, sunmayı amaçladığı deneyimi de yansıtmalıdır.