Bir yapay zeka ajanının doğrulayabileceği kabul kriterleri nasıl yazılır
Kabul kriterleri (AC, acceptance criteria), bir değişikliğin tamamlanmış sayılması için doğru olması gereken koşullardır. Given/When/Then, Gherkin içindeki adım biçimidir; Cucumber bu dili davranış güdümlü geliştirme (BDD, behaviour-driven development) için kullanır: Given bir başlangıç durumu, When tek bir eylem gerçekleşir, Then gözlemlenebilir bir sonuç gelir. Ürün gereksinimleri belgesi (PRD, product requirements document), sorunu ve amaçlanan ürünü adlandıran düz yazıdır. Spesifikasyon odaklı geliştirme (SDD, spec-driven development), yapılandırılmış bir spesifikasyonu, tek başına o düz yazıyı değil, uygulamanın kendisine göre denetlendiği kaynak olarak ele alır. EARS (Easy Approach to Requirements Syntax), bir gereksinim tümcesini, yan tümceleri sabit bir sırada kalacak biçimde sınırlama yoludur. Sürekli entegrasyon (CI, continuous integration), önerilen her değişiklikte çalışan otomatik bir denetimdir; bu site SpecScore’un iki denetimini doğrulayıcılar sayfasında anlatır. Bu sayfa, yapay zeka (AI, artificial intelligence) kodlama ajanının doğrulayabileceği test edilebilir kabul kriterlerinin nasıl yazılacağını, kabul kriteri örnekleriyle birlikte gösterir ve SpecScore komut satırı arayüzünün (CLI, command-line interface) gerçekte neyi denetlediğini anlatır.
3 Kasım 2026 tarihinde güncellendi.
Kabul kriterleri nedir
Bir kabul kriteri «ne doğru olmalıdır?» sorusunu yanıtlar. Bir inceleyenin, bir testin veya bir ajanın kabul ya da ret edebileceği koşulu adlandırır. Çağrılacak işlevi ve düzenlenecek dosyayı adlandırmaz. Bu seçimler uygulamaya aittir.
Gereksinim kuraldır. SpecScore gereksinim spesifikasyonunda bir gereksinim, bir özelliğin içindeki #### REQ: başlığıdır: kendi tanımlayıcısı olan tek bir yükümlülük. Bir kabul kriteri, ilgili gereksinimleri tek bir koşulda toplar. Senaryo, koşulun tuttuğunu gösteren tek bir somut durumdur. Kabul kriterleri spesifikasyonu bunu şöyle söyler: kriterler «ne doğru olmalıdır?» sorusunu, senaryolar «bunu nasıl kanıtlarız?» sorusunu yanıtlar.
Bir PRD aynı niyeti paragraflar halinde taşıyabilir. Paragraflar bir kişiye yardım eder. Ajan yine de hangi tümcenin geçti/kaldı sınaması olduğunu tahmin etmek zorundadır. Kriteri kendi tümcesi olarak yazmak bu tahmini ortadan kaldırır.
Kabul kriterlerini test edilebilir kılan nedir
Bir yapay zeka kodlama ajanı bir kritere ancak sonraki bir okur kanıta işaret edip geçti ya da kaldı diyebildiğinde uyabilir. Bunu beş alışkanlık mümkün kılar. Hiçbiri bir tümce şablonu değildir. Bunlar, Given/When/Then ve bir kontrol listesi dahil, her şablona uygulanabilecek denetimlerdir.
Gözlemlenebilir
Sonuç, dışarıdan birinin görebildiği bir şeydir: sayfadaki bir ileti, saklanmış ya da saklanmamış bir kayıt, bir yönlendirme, reddedilen bir form. «Sistem alışveriş yapanı anlar» gözlemlenebilir değildir. «Sayfa, e-posta alanının yanında Enter a valid email address gösterir» gözlemlenebilirdir.
Belirli
Eyleyeni, girdiyi ve sonucu adlandırın. «Kötü girdi ele alınır» hangi girdiyi ve hangi ele almayı söylemez. «Alışveriş yapan, not-an-email adresini gönderir» söyler. Belirli olmak, her üretim değerini yapıştırmak demek değildir. Bir okurun bir fikstür uydurup ne olması gerektiğini bilebilmesi demektir.
Tek davranış
Bir kriter, bir davranış. «Alışveriş yapan oturum açabilir, bir parolayı sıfırlayabilir ve bir kilitleme iletisi görebilir» tek tümcede üç kriterdir. Birincisini uygulayıp üçüncüsünü atlayan bir ajan, tümcenin bittiğini yine de ileri sürebilir. Bunları ayırın.
Geçer ya da kalır
Test edilebilir bir kabul kriterinin iki sonucu vardır. «Form hızlı hissettirmeli» bir eğimdir, bir sonuç değildir. Bir sınır gerekiyorsa sınırı yazın: «ödeme sayfası, sunucuya başka bir istek olmadan hatayı gösterir». Başarısızlığın nasıl göründüğünü söyleyemiyorsanız tümce henüz bir kriter değildir.
Belirsiz sözcük yok
Sonucu gizleyen sözcükleri çıkarın: zarif, sezgisel, sağlam, kullanıcı dostu, kesintisiz, hızlı, «-meli» ve uygun. Her birini kabul edeceğiniz kanıtla değiştirin. «Hataları zarifçe ele almak», «alanın yanında Enter a valid email address göstermek ve siparişi vermemek» olur.
Given/When/Then ve kontrol listesi
İki biçim, ekiplerin gerçekten sakladığı kabul kriteri örneklerinin çoğunu karşılar. Given/When/Then bir senaryodur. Kontrol listesi bir sonuç listesidir. Durum, eylem ve sonucun sırası önemliyse senaryoyu kullanın. Tek bir eylemin birbirinden bağımsız sonuçlarını sıralıyorsanız kontrol listesini kullanın.
Cucumber’in Gherkin başvurusu adımlara Given, When, Then, And ve But anahtar sözcüklerini verir. Başvuru İngilizce kullanır; Gherkin’in bu sözcüklerin çevirileri de vardır. Anahtar sözcükten sonraki metin, Cucumber dosyayı çalıştırdığında step definition denen kodla eşleştirilir. SpecScore bu step definition katmanını kullanmaz. Aşağıdaki örnek, biçim tanıdık olsun diye gösterilen Gherkin’dir. Bir SpecScore dosyası değildir.
Given/When/Then
Scenario: Reject an email that is not a valid address
Given the shopper is on the checkout form
When the shopper submits the email "not-an-email"
Then the page shows "Enter a valid email address" beside the email field
And the order is not placed
Kontrol listesi
- Submitting the email "not-an-email" shows "Enter a valid email address" beside the email field.
- The order is not placed.
Tek bir When bırakın. İkinci bir eylem, ikinci bir senaryodur. And aynı anahtar sözcüğü sürdürür: bir Given daha ya da bir Then daha. İkinci bir davranışı gizlice sokmak için And kullanmayın.
Kontrol listesi, anahtar sözcükler olmadan aynı sözleşmedir. Her satır yine tek bir gözlemlenebilir sonuçtur. Yukarıdaki kontrol listesi, senaryonun Then’idir; denetimler olarak yazılmıştır.
Alistair Mavin rehberi, EARS’ı (Easy Approach to Requirements Syntax) metin gereksinimlerini nazikçe sınırlayan bir mekanizma olarak tanımlar. Yan tümceler tek bir sırada kalır. Rehber genel biçimi verir: While <optional pre-condition>, when <optional trigger>, the <system name> shall <system response>. Bir gereksinimin sıfır veya daha fazla önkoşulu, sıfır veya bir tetikleyicisi, bir sistem adı ve bir veya daha fazla sistem yanıtı vardır.
Bu tümce yükümlülüktür: sistemin karşılaması gereken kural. Kabul kriteri, yükümlülüğün yerine gelmiş sayılması için doğru olması gereken koşuldur. Bir Given/When/Then senaryosu, bu koşulun tek bir somut durumudur. Gereksinimi bir EARS tümcesiyle yazıp kriteri örnek girdilerden arınmış tutabilirsiniz.
Bir SpecScore özelliğinde gereksinim, #### REQ: başlığı altında EARS biçiminde bir tümce olabilir. Kriter soyut koşul olarak kalır. Örneği senaryo taşır. EARS bu ikisinin yerine geçmez. Yalnızca gereksinim tümcesini sınırlar.
Kabul kriteri örnekleri: belirsiz ve test edilebilir
Kanıtı adlandırmak
Belirsiz
The checkout form should handle bad input gracefully and feel fast.
Test edilebilir
When the shopper submits the email "not-an-email", the checkout page shows "Enter a valid email address" beside that field and does not place the order.
Belirsiz satır iki talebi (hatalar, hız) gizler ve kanıt vermez. Test edilebilir satırın bir eylemi ve bir kişinin ya da bir ajanın denetleyebileceği iki sonucu vardır. Örnekler İngilizce kalır, çünkü biçimin anahtar sözcükleri İngilizcedir.
Tek davranış
Belirsiz
Users can sign in, reset a password, and see an error if the account is locked.
Test edilebilir
When a visitor submits a known email and the matching password, the app sets a session cookie and redirects to /dashboard.
Oturum açma, sıfırlama ve kilitleme üç davranıştır. Test edilebilir satır oturum açmayı tutar. Sıfırlama ve kilitleme, kendi girdileri ve sonuçlarıyla ayrı birer kriter alır.
Sonuç, işlev adı değil
Belirsiz
The handler returns 400 from validateEmail().
Test edilebilir
When the shopper submits an email that is not a valid address, the checkout page shows "Enter a valid email address" and does not place the order.
Bir işlev adı ve bir durum kodu, kriteri bugünün koduna bağlar. Denetim başka bir işleve taşınsa da sonuç geçerliliğini korur. Durum kodu söz verdiğiniz davranış olduğunda durum kodunu tutun ve onu gözlemlenebilir sonuç olarak söyleyin.
SpecScore bunları nasıl saklar ve CI neyi denetler
SpecScore biçimi specscore/specscore deposunda, CLI’ı ise specscore/specscore-cli deposunda yayımlar. Bu iki belge kabul kriterlerini tam olarak aynı biçimde anlatmaz. İkisi de günceldir. Bu bölüm önce hangisinin hangisi olduğunu, sonra specscore spec lint komutunun gerçekte neyi reddettiğini söyler.
Kabul kriterleri spesifikasyonu — o URL’de sunulan özellik README dosyası — kriterleri özellik README dosyasının içine koyar. Her özelliğin bir ## Acceptance Criteria bölümü vardır. Her kriter bir ### AC: {slug} başlığıdır. Slug küçük harflidir ve tireyle ayrılır. Sonraki satır **Requirements:** olur ve kriterin topladığı gereksinimleri {feature-id}#req:{slug} biçiminde listeler. Ardından düz yazı gelir: bileşik koşul. Spesifikasyon bu düz yazının soyut kalmasını söyler. Given/When/Then adımları, örnek girdiler ve uygulama ayrıntısı içermemelidir. Henüz kriter yoksa bölüm «Not defined yet.» diye okunur ve Open Questions bölümü «Acceptance criteria not yet defined for this feature.» der. Kriterler isteğe bağlı gruplamadır: spesifikasyon, iki veya daha fazla gereksinimi toplayınca bir kriter eklenmesini, tek bir gereksinimi yalnızca yineleyecekse atlanmasını söyler.
Somut kanıt, özelliğin _tests/ dizinindeki bir senaryo dosyasıdır. Senaryo spesifikasyonu bir # Scenario: başlığı, bir ## Steps bölümü, büyük harfli GIVEN, WHEN, THEN ve AND ve tam olarak bir WHEN ister. İsteğe bağlı **Validates:** satırı senaryoyu {feature-path}#ac:{slug} ile ya da bir gereksinimle bağlar. Bir ## Rehearse bölümü, shebang ile başlayan yürütülebilir bir betiği rehearse bloğunda tutabilir.
CLI ayrıca, kriter başına bir tane olmak üzere, _acs/<slug>.ac.md yolundaki ince kriter dosyalarını okur. Oturum açma örneği ve Rehearse rehberi bu biçimi belgeler: # AC: <slug>, isteğe bağlı **Status:**, **Verifies:** ve **Applies-to:** ve koşul ## Statement altında. specscore rehearse acs <feature-dir> bu dosyalardan bir özet tablo basar. specscore rehearse acs --write özellik README dosyasındaki Acceptance Criteria bölümünü bu tabloyla ve bölümün üretildiğini, elle düzenlenmemesi gerektiğini söyleyen bir yorumla değiştirir. # AC: başlığı olmayan bir dosya, bu komutun hatasıdır.
Bu depodaki CI dogfood iş akışıdır. CLI v0.39.1 sürümünü kurar ve specscore spec lint komutunu pull request’lerde ve main’e yapılan push’larda çalıştırır. 3 Kasım 2026 tarihinde kontrol edildi: bu sürüm ve CLI’ın varsayılan dalı aşağıdaki kuralları içerir. Linter yapıyı denetler. İngilizceyi notlamaz.
ac-heading-format kuralı bir hatadır. Bir özellik README dosyasında (başlığı # Feature: olan bir dosyada) kabul kriteri başlığı gibi görünen bir satır, iki noktadan sonra bir boşluk ve kebab-case bir kimlikle tam olarak ### AC: <id> olmalıdır. ### AC: <id> (verifies ...) biçimindeki bir başlık da kabul edilir. --fix yalnızca boşlukları onarır. Büyük harf ya da alt çizgi içeren bir kimlik bildirilir ve kişiye bırakılır. Kural **Requirements:** satırını zorunlu tutmaz, «Not defined yet.» yer tutucusunu zorunlu tutmaz ve düz yazı Given, When ya da Then içerdiğinde uyarı vermez. Spesifikasyonun bu uyarı için kendi senaryosu, bu CLI’da bir lint kuralı değildir.
Bir kaynak özelliği adlandıran bir planda linter, o özelliğin Acceptance Criteria bölümündeki ### AC: başlıklarını okur. P-002 kuralı, bir görev **Verifies:** değerinin bu başlıklardan biri için <feature-slug>#ac:<ac-slug> olmadığını bildirir. P-001 kuralı, hiçbir görevin kapsamadığı ve ## Deferred AC Coverage altında listelenmemiş bir başlığı bildirir. Bu iki kural _acs/*.ac.md dosyalarını açmaz. rehearse acs --write özet tablosunda ### AC: başlığı yoktur, bu yüzden plan kuralları ince dosyaları görmez.
Aynı lint komutu senaryo adımı anahtar sözcüklerini denetlemez. specscore rehearse senaryo dosyalarını çalıştırır: Rehearse rehberi, çitli bir komutun üzerinde ## Given ya da ## When gibi bir başlık ve yeniden kullanılabilir bir denetimi çağırmak için **Use:** kullanır. Bir Given ve birkaç When dalı olan bir dosya ayrı durumlar olarak çalışır. specscore rehearse new <feature-slug>#ac:<ac-slug> özellik README dosyasını okur ve o kriterdeki Given/When/Then satırlarını spec/features/<feature-slug>/_tests/<ac-slug>.md içine çıkarır. Bunların hiçbiri dogfood iş akışında çalışmaz. İş akışı specscore spec lint çalıştırır.
Satır içi kriter, kabul kriterleri spesifikasyonundan
## Acceptance Criteria
### AC: invalid-email-rejected
**Requirements:** checkout#req:reject-invalid-email
An email that is not a valid address is rejected, and the order is not placed.
# AC: invalid-email-rejected
**Status:** accepted
**Verifies:** checkout#req:reject-invalid-email
## Statement
An email that is not a valid address is rejected, and the order is not placed.
Senaryo dosyası, senaryo spesifikasyonundan
# Scenario: Reject an invalid email
**Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected)
## Steps
GIVEN the shopper is on the checkout form
WHEN the shopper submits the email "not-an-email"
THEN the page shows "Enter a valid email address" beside the email field
AND the order is not placed
Rehearse senaryosu, Rehearse rehberindeki biçim
# Rehearse: Reject an invalid email
## Given a submitted email that is not a valid address
```bash
printf 'email=not-an-email\n' > form.txt
```
## When the response is recorded
```bash
printf 'Enter a valid email address\n' > out.txt
```
## Then the message is the invalid-email text
```bash
grep -q 'Enter a valid email address' out.txt
```
Dört örnek bu biçimlerin resmidir. Tam bir özellik ağacı değildirler ve bu sayfa onların tek başlarına specscore spec lint geçtiğini iddia etmez. Bu komut temiz sonuç versin diye bir özellik README dosyasının diğer zorunlu bölümleri de gerekir.
Belirsiz bir istekten kriteri çıkarmak için bir soru listesi istiyorsanız İyi sorular sormak sayfasını kullanın. Oturum açma anlatımı, diğer artefaktların arasında yerinde duran bir ince kriteri, session-hardened, gösterir.
Sık sorulan sorular
Kabul kriterleri nedir?
Kabul kriterleri (AC), bir değişikliğin tamamlanmış sayılması için doğru olması gereken koşullardır. SpecScore kabul kriterleri spesifikasyonunda soyutturlar: neyin doğru olması gerektiğini söylerler ve somut adımları bir senaryoya bırakırlar.
Given/When/Then nedir?
Given/When/Then, Gherkin’deki adım biçimidir: Given bir başlangıç durumu, When tek bir eylem gerçekleşir, Then gözlemlenebilir bir sonuç gelir. Cucumber anahtar sözcükleri Gherkin başvurusunda belgeler. SpecScore senaryo spesifikasyonu, senaryo dosyası başına tam olarak bir WHEN ile büyük harfli GIVEN, WHEN, THEN ve AND anahtar sözcüklerini kullanır.
Bir yapay zeka kodlama ajanı için kabul kriterleri nasıl yazılır?
Eyleyen, girdi ve sonuçla, belirsiz sözcük olmadan tek bir gözlemlenebilir davranış yazın. Örnek veriyi soyut kritere değil, bir senaryoya koyun. Ajan o zaman kritere göre uygulayabilir ve senaryoyu denetleyebilir.
Kabul kriterleri test durumlarıyla aynı şey midir?
Hayır. Bir kriter koşulu belirtir. Bir test durumu, ya da bir SpecScore senaryosu, koşulun tuttuğunu ya da tutmadığını gösteren, somut girdilerle tek bir çalıştırmadır. Birkaç senaryo bir kriteri destekleyebilir.
specscore spec lint belirsiz ifadeyi yargılar mı?
Hayır. Bu depodaki CI’ın kurduğu sürüm olan CLI v0.39.1 içinde ac-heading-format, ### AC: başlığını denetler. «graceful» ya da «fast» gibi sözcüklere puan vermez ve bir kriter Given/When/Then içerdiğinde uyarı vermez. İfade bir yazma işidir. Doğrulayıcılar sayfası bu deterministik lint’i elle yapılan yapay zeka incelemesinden ayırır.
Kabul kriterine değil, bir senaryoya. Kabul kriterleri spesifikasyonu, kriterin içinde Given/When/Then adımlarını yasaklar. Senaryo spesifikasyonu onları _tests/ altında, ## Steps bölümüne koyar. Rehearse, ilgili bir biçimi çalıştırır: _tests/ altında başlıklar ve çitli komutlar; Rehearse rehberinde belgelenmiştir. Linter adım anahtar sözcüklerini zorlamaz.
Kaynaklar
3 Kasım 2026 tarihinde okundu. Üçüncü taraf sayfalar yalnızca yayımladıkları tanımlar için alıntılanır.