मॉड्यूल 5 · Requirements और static testing

एक्सेप्टेंस क्राइटेरिया

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 19 मिनट · शुरुआती

Acceptance criteria वे शर्तें हैं जिन्हें किसी user story के implementation को पूरा करना होता है, ताकि stakeholders उसे accept करें। ISTQB Foundation syllabus tester के लिए सबसे ज़रूरी नज़रिया जोड़ता है: acceptance criteria को वे test conditions माना जा सकता है जिन्हें tests को exercise करना चाहिए। ये आम तौर पर Conversation से निकलते हैं, यानी three Cs में से दूसरा C, जिसे आपने user stories वाले lesson में देखा, और लिखे जाने पर यही तीसरा C, यानी Confirmation, बनते हैं।

यह story लें: "एक library member के रूप में, मैं borrowed book को online renew करना चाहता हूँ, ताकि library गए बिना उसे ज़्यादा समय तक रख सकूँ।" Story ज़रूरत बताती है, पर यह नहीं कि कितना ज़्यादा समय, कितनी बार, या तब क्या होगा जब कोई और उस book का इंतज़ार कर रहा हो। "Renewal due date को 14 दिन आगे बढ़ाता है" और "किसी दूसरे member की reserved book renew नहीं हो सकती" जैसे criteria इन सवालों का जवाब देते हैं, और हर एक को साफ़ pass या fail से जाँचा जा सकता है।

यह क्यों ज़रूरी है

Syllabus बताता है कि acceptance criteria किस काम आते हैं: story का scope तय करना, stakeholders में सहमति बनाना, positive और negative दोनों scenarios बताना, story की acceptance testing का आधार बनना, और सटीक planning व estimation संभव करना। इनके बिना हर कोई ख़ाली जगहें अपनी assumptions से भरता है, और फ़र्क़ अक्सर sprint review में ही सामने आता है, जब काम दोबारा करना पड़ता है।

Tester के लिए acceptance criteria expected results का पहला स्रोत हैं। जो expected result आपने ख़ुद गढ़ा, वह इस बात का अंदाज़ा है कि business क्या चाहता था; जो किसी तय criterion से लिया गया, उसे कोई भी परख सकता है। Development से पहले criteria का review static testing का सबसे सस्ता रूप भी है: refinement में ठीक किया गया vague या contradictory criterion कभी code में defect नहीं बनता।

Rule-oriented और scenario-oriented criteria

ISTQB syllabus दो आम formats बताता है। Rule-oriented criteria एक bulleted verification list होते हैं, या inputs को outputs से map करने वाली table। Scenario-oriented criteria behaviour-driven development (BDD) में इस्तेमाल होने वाले Given/When/Then format में ठोस examples होते हैं। Team चाहे तो अपना format भी इस्तेमाल कर सकती है, बशर्ते criteria साफ़ तरह परिभाषित और unambiguous हों।

दोनों formats साथ काम करते हैं। Rules policy को संक्षेप में बताते हैं और उनमें कमियाँ review करना आसान है; scenarios policy को असली data पर चलते हुए दिखाते हैं और rule के मतलब पर शक दूर करते हैं। कई teams पहले rules लिखती हैं और हर उस rule के लिए scenario जोड़ती हैं जिसे दो तरह पढ़ा जा सकता हो। Cucumber tool की भाषा Gherkin में तो Rule keyword भी है, जो एक business rule को दिखाने वाले scenarios को group करता है।

Rule list limits, permissions, validations और calculations के लिए ठीक है, जैसे "हर loan पर ज़्यादा से ज़्यादा 2 renewals"।
Input-output table कई conditions वाले rule के लिए ठीक है, जहाँ हर combination का जवाब चाहिए।
Scenarios ऐसे behaviour के लिए ठीक हैं जो state या events के क्रम पर निर्भर हो, और उन examples के लिए जिन्हें team automate करना चाहती है।

LIB-42  Borrowed book को online renew करना
एक library member के रूप में, मैं borrowed book को online renew करना चाहता हूँ,
ताकि library गए बिना उसे ज़्यादा समय तक रख सकूँ।

Acceptance criteria (rule-oriented)
AC1  Renewal due date को 14 दिन आगे बढ़ाता है, जो current due date से गिने
     जाते हैं, renewal वाले दिन से नहीं।
AC2  एक loan ज़्यादा से ज़्यादा 2 बार renew हो सकता है। "मेरे loans" बचे renewals
     दिखाता है।
AC3  जिस book को किसी दूसरे member ने reserve किया है, वह renew नहीं हो सकती:
     message "किसी दूसरे member के लिए reserved" दिखता है और due date नहीं बदलती।
AC4  Overdue loan online renew नहीं हो सकता: message
     "Overdue loans सिर्फ़ desk पर renew होते हैं" दिखता है।

Given/When/Then scenario की बनावट

Scenario एक behaviour का एक example है। Given context बताता है: कुछ भी होने से पहले system की state और उसका data। When test होने वाला event या action बताता है। Then expected outcome बताता है। And और But अपने पहले वाले keyword को आगे बढ़ाते हैं, इसलिए Given के बाद आया And और context जोड़ता है, और Then के बाद आया And एक और outcome।

दो आदतें scenarios को काम का बनाए रखती हैं। हर scenario में एक ही When step रखें; दूसरे की ज़रूरत का मतलब आम तौर पर यह है कि आप दूसरा behaviour बता रहे हैं और scenario को बाँटना चाहिए। और हर Then को observable outcome बनाएँ: Cucumber का Gherkin reference ऐसी चीज़ माँगता है जो system से बाहर आती हो, जैसे कोई report, user interface या message, न कि अंदर दबा कोई behaviour, जैसे database record।

Context को facts के रूप में लिखें, clicks के रूप में नहीं। "Given Sara ने Desert Stars borrow की है, due date 10 March 2026" screens का redesign होने पर भी सही रहता है; "Given Sara मेरे loans खोलती है और पहली row पर click करती है" नहीं रहता, और यह छिपा देता है कि कौन-सा data मायने रखता है। जब एक behaviour को कई data sets चाहिए, तो Scenario Outline अपनी Examples table की हर row के लिए एक बार चलता है, जैसे नीचे renewal limit में।

LIB-42 के renewal scenario के हिस्से: Given और And context तय करते हैं, एक ही When 5 March को loan renew करता है, और Then दिखने वाले results बताता है जो expected results बनते हैं।

Story LIB-42 का test T1, scenario के रूप में

भाग 1:1Scenario: Renewing moves the due date 14 days later
  भाग 2:2Given Sara has borrowed "Desert Stars", due on 10 March 2026
  भाग 3:3And nobody has reserved the book
  And Sara has not renewed this loan before
  भाग 4:4When Sara renews the loan on 5 March 2026
  भाग 5:5Then the due date shown on My loans is 24 March 2026
  भाग 6:6And My loans shows 1 renewal left

2–3Context → test case की preconditions और test data
4Action → test step और उसका input
5–6Outcomes → expected results

1Scenario का titleएक behaviour का नाम: AC1 का वह rule जिसे यह example दिखाता है।
2Given: contextAction से पहले की state, concrete data वाले facts के रूप में: कौन, कौन-सी book, कौन-सी due date।
3And: और contextReservation और पिछले renewals को बाहर रखता है, ताकि न AC3 और न renewal limit result बदल सके।
4When: एक actionTest होने वाला एक ही event। 5 March को renew करने पर due date से गिनें तो 24 March आता है, आज से गिनें तो 19 March।
5Then: दिखने वाला outcomeMember page पर जो देखता है वही pass या fail तय करता है, database का कोई record नहीं।
6And: दूसरा outcomeउसी action का एक और दिखने वाला result: "मेरे loans" पर बचे renewals, जिन्हें AC2 माँगता है; इसीलिए T1, AC1 और AC2 दोनों से trace है।

Scenario Outline: एक loan ज़्यादा से ज़्यादा 2 बार renew हो सकता है
  Given Sara का "Desert Stars" वाला loan <before> बार renew हो चुका है
  And किसी ने book reserve नहीं की है
  When Sara loan renew करती है
  Then renewal <result> होता है

  Examples:
    | before | result |
    | 0      | accept |
    | 1      | accept |
    | 2      | reject |

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

अच्छे और कमज़ोर acceptance criteria

अच्छा criterion product owner, developer और tester को एक ही result पर एक ही verdict तक पहुँचाता है। ये checks ज़्यादातर कमज़ोर criteria पकड़ लेते हैं, और नीचे के जोड़े आम सुधार दिखाते हैं।

Testable: observable result और साफ़ pass या fail। "Renew करना आसान है" में दोनों नहीं हैं।
Specific: numbers, limits, messages और roles साफ़ लिखे हों, अंदाज़े पर न छोड़े जाएँ।
Behaviour के बारे में: user क्या अनुभव करता है, न कि developer कौन-सी table, field या API बदलता है।
Complete: refusals covered हों, यह भी कि action allowed न होने पर user क्या देखता है।
Focused: हर criterion में एक rule, ताकि fail हुआ test एक ही rule की ओर इशारा करे।
Story के अंदर: जिस condition को किसी दूसरे feature की ज़रूरत है, वह दूसरी story की है।

कमज़ोर:   Renewal जल्दी होना चाहिए।
Testable: Renew चुनने के 2 सेकंड के अंदर नई due date दिखती है
          (value product owner confirm करेगा)।

कमज़ोर:   Member book renew कर सकता है।
Testable: हर renewal current due date में 14 दिन जोड़ता है।
Testable: एक loan ज़्यादा से ज़्यादा 2 बार renew हो सकता है।

कमज़ोर:   Errors ठीक से handle होते हैं।
Testable: Reserved book renew नहीं हो सकती; message
          "किसी दूसरे member के लिए reserved" दिखता है।

कमज़ोर:   renew_count column increment होता है।
Testable: "मेरे loans" पर बचे renewals 1 कम हो जाते हैं।

आज़माएँ: AI Acceptance Criteria रिव्यूअर

Criteria से tests तक: ATDD का परिचय

Acceptance test-driven development (ATDD) एक test-first approach है: test cases story implement होने से पहले बनाए जाते हैं, अलग-अलग नज़रिए वाले लोगों द्वारा, जैसे customers, developers और testers। इसकी शुरुआत specification workshop से होती है, जहाँ team story का analysis करती है, बचे हुए criteria लिखती है और gaps, ambiguities और defects सुलझाती है। कुछ teams इस meeting को "three amigos" कहती हैं।

फिर criteria से test cases निकाले जाते हैं। वे इस बात के examples हैं कि software को कैसे काम करना चाहिए, इसीलिए ATDD में "examples" और "tests" लगभग एक ही अर्थ में इस्तेमाल होते हैं। Syllabus एक क्रम सुझाता है: पहले positive cases, फिर negative cases, फिर performance efficiency या usability जैसी non-functional characteristics। Tests को story की हर characteristic cover करनी चाहिए, उससे आगे गए बिना, और कोई दो tests एक ही characteristic न बताएँ। Tests manually भी चलाए जा सकते हैं और automate भी किए जा सकते हैं: अगर उन्हें ऐसे format में लिखा जाए जिसे automation framework चला सके, तो feature बनते समय ही उन्हें automate किया जा सकता है और वे executable requirements बन जाते हैं।

Given test case की preconditions और test data बनता है।
When test step और उसका input बनता है।
Then expected result बनता है, जो test चलाने से पहले लिखा जाता है।
हर test उस criterion से trace होता है जिसे वह जाँचता है, ताकि आप बता सकें कि कौन-से criteria covered हैं।

Worked example: renewal story के tests

LIB-42 के specification workshop में tester हर criterion को ऊपर वाले checks से पढ़ता है और test data सुझाता है। AC1 साफ़ कहता है कि 14 दिन due date से गिने जाते हैं, फिर भी कोई developer आज से गिन सकता है, इसलिए tester ऐसा data चुनता है जो दोनों readings में फ़र्क़ करे: 10 March को due loan, 5 March को renew होने पर 24 March पर जाना चाहिए, जबकि renewal वाले दिन से गिनने पर 19 March आएगा।

Tests syllabus के क्रम में हैं: पहले positive cases T1 और T2, फिर negative cases T3 से T5 तक। हर Given उन refusals को बाहर रखता है जिनके बारे में test नहीं है, जैसे reservation या overdue loan, ताकि result सिर्फ़ एक rule तय करे। हर test अपने criterion से trace है, और हर expected result कोई code लिखे जाने से पहले तय हुआ।

खुला सवाल Q1: AC2 यह नहीं बताता कि limit पूरी होने पर member क्या देखता है, इसलिए T3 अभी message नहीं लिख सकता। फ़ैसला product owner का है; tester सवाल story पर दर्ज करता है।
खुला सवाल Q2: कोई loan एक ही समय overdue और reserved दोनों हो सकता है। कौन-सा message दिखेगा? जवाब एक नया criterion और एक नया test बनता है।

LIB-42 के tests (पहले positive, फिर negative)

T1  AC1, AC2  Given: due 10 Mar 2026, अभी तक कोई renewal नहीं, reserved नहीं
              When:  5 Mar 2026 को renew
              Then:  due date 24 Mar 2026; बचे renewals: 1
T2  AC1, AC2  Given: due 24 Mar 2026, एक बार renewed, reserved नहीं
              When:  20 Mar 2026 को renew
              Then:  due date 7 Apr 2026; बचे renewals: 0
T3  AC2       Given: दो बार renewed, overdue नहीं, reserved नहीं
              When:  renew
              Then:  reject; due date नहीं बदलती (message: Q1 देखें)
T4  AC3       Given: कोई renewal नहीं, overdue नहीं, दूसरे member ने reserve की
              When:  renew
              Then:  "किसी दूसरे member के लिए reserved"; due date नहीं बदलती
T5  AC4       Given: due 10 Mar 2026, आज 12 Mar 2026, कोई renewal नहीं, reserved नहीं
              When:  renew
              Then:  "Overdue loans सिर्फ़ desk पर renew होते हैं"

आज़माएँ: User Story → टेस्ट केस आज़माएँ: Requirements → टेस्ट केस

आम गलतियाँ

ऐसे शब्द इस्तेमाल करना जिन्हें मापा न जा सके, जैसे "fast", "आसान", "ठीक से" या "user-friendly"। उनकी जगह number या observable result माँगें।
सिर्फ़ happy path लिखना। हर limit, permission और refusal को ऐसा criterion चाहिए जो बताए कि user क्या देखता है।
Behaviour की जगह clicks और screens लिखना, जिससे हर redesign पर scenarios टूटते हैं और यह छिप जाता है कि कौन-सा data मायने रखता है।
एक scenario में कई behaviours डालना, When और Then steps की chain के साथ। Fail होने पर कोई नहीं जानता कि कौन-सा rule टूटा।
Criteria को ऐसा fixed text मानना जो tester को बस मिलता है। वे conversation में तय होते हैं, और जो tester सिर्फ़ उन्हें पढ़ता है वह defects पकड़ने का सबसे सस्ता मौक़ा खो देता है।
Sprint के बीच team को बताए बिना criterion बदल देना, जिससे code और tests अलग-अलग versions पर बनते हैं।

QA का नज़रिया

आपका सबसे बड़ा योगदान code बनने से पहले होता है। Refinement या specification workshop में हर criterion पढ़ें और पूछें "मैं इसे कैसे test करूँगा?" और "अगर ऐसा हो तो क्या होगा?"। ठोस examples और test data सुझाएँ, vague शब्दों की ओर ध्यान दिलाएँ, और छूटे हुए negative criteria प्रस्तावित करें। Business rules product owner तय करता है; आपका काम यह पक्का करना है कि फ़ैसला ऐसे रूप में लिखा जाए जिसे हर कोई जाँच सके।

तय हुए criteria story पर ही दर्ज करें, खुले सवालों, उनके owner और तारीख़ के साथ। हर test को उस criterion से link करें जिसे वह जाँचता है, और लिखें कि कौन-से automated हैं। Sprint के दौरान कोई criterion बदले तो उसी change में उसके tests भी update करें। Sprint review में हर criterion के लिए evidence दिखाएँ, ताकि acceptance एक check हो, बहस नहीं।

अभ्यास

Delivery address वाली story के criteria सुधारें

आपका काम

एक grocery app में यह story और इसके draft criteria हैं। पता करें कि हर criterion को क्या कमज़ोर बनाता है, उन्हें testable rules के रूप में दोबारा लिखें, फिर Given/When/Then में दो scenarios और उन tests की list लिखें जो आप निकालेंगे।

जहाँ कोई value नहीं है, वहाँ एक value सुझाएँ और उसे ख़ुद तय करने की बजाय product owner के लिए सवाल के रूप में mark करें।

सामग्री

GRO-17  किसी order का delivery address बदलना
एक customer के रूप में, मैं order देने के बाद delivery address बदलना चाहता हूँ,
ताकि order वहाँ पहुँचे जहाँ मैं रहूँगा।

AC1  Customer आसानी से address बदल सकता है।
AC2  Order के काफ़ी आगे बढ़ जाने तक बदलाव संभव होना चाहिए।
AC3  Invalid addresses को ठीक से handle किया जाता है।
AC4  Update fast होना चाहिए।

चरण

हर वह शब्द या phrase mark करें जिसे दो readers अलग-अलग समझ सकते हैं।
Criteria को rule-oriented list के रूप में दोबारा लिखें, हर criterion में एक rule, refusals समेत।
ठोस data के साथ Given/When/Then में एक positive और एक negative scenario लिखें।
जो tests आप निकालेंगे उन्हें लिखें: पहले positive, फिर negative, हर एक किसी criterion से trace।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

कमज़ोर जगहें: "आसानी से" का कोई observable result नहीं और यह बस story दोहराता है; "चाहिए" से साफ़ नहीं कि rule mandatory है या नहीं; "काफ़ी आगे बढ़ जाने" किसी order status का नाम नहीं लेता; "invalid" और "ठीक से handle" न यह बताते हैं कि कौन-से addresses, न यह कि customer क्या देखता है; "fast" में कोई number नहीं।

Rules, सुझाई गई values सवालों के रूप में mark। AC1: जब तक order status "Preparing" है, customer order page से delivery address बदल सकता है, और फिर order नया address दिखाता है। AC2: status "Out for delivery" होने के बाद change का option नहीं दिखता, और API से भेजा गया change reject होता है (सवाल: क्या "Preparing" सही cut-off है?)। AC3: delivery zone से बाहर का address message "हम इस address पर delivery नहीं करते" के साथ reject होता है, और पुराना address बना रहता है (सवाल: और कौन-से addresses invalid माने जाएँगे, जैसे बिना building number वाला address?)। AC4: save करने के 2 सेकंड के अंदर order पर नया address दिखता है (सवाल: value confirm करें, या इसे team-wide performance criterion से cover करें)।

Positive scenario: Given order 5531 का status "Preparing" है और address 12 Palm Street है; When customer address बदलकर 40 Garden Road करता है; Then order page पर 40 Garden Road दिखता है। Negative scenario: Given order 5531 का status "Out for delivery" है; When customer order page खोलता है; Then address बदलने का कोई option नहीं दिखता।

Tests: T1 "Preparing" के दौरान change (AC1); T2 "Out for delivery" में option छिपा (AC2); T3 "Out for delivery" में API से change reject (AC2); T4 zone से बाहर का address message के साथ reject, पुराना address बना रहे (AC3); T5 2 सेकंड की limit, confirm होने के बाद (AC4), आख़िर में क्योंकि यह non-functional है। Workshop के लिए एक और सवाल: अगर नया address अलग delivery fee वाले zone में हो, तो fee का क्या होगा?

अक्सर पूछे जाने वाले सवाल

क्या acceptance criteria को Given/When/Then में ही लिखना ज़रूरी है?

नहीं। ISTQB syllabus rule-oriented और scenario-oriented को दो सबसे आम formats बताता है और custom format भी स्वीकार करता है, बशर्ते criteria साफ़ परिभाषित और unambiguous हों। Gherkin syntax तभी ज़रूरी है जब Cucumber जैसा कोई BDD tool scenarios चलाएगा।

Acceptance criteria कौन लिखता है?

आम तौर पर product owner या business analyst draft लिखता है, और team उन्हें conversation में निखारती है। Rules business तय करता है, developers feasibility जाँचते हैं, और tester हर criterion को testable बनाता है और negative cases जोड़ता है। ATDD में ये specification workshop में मिलकर पूरे किए जाते हैं।

Acceptance criteria और test cases में क्या अंतर है?

Criterion वह शर्त बताता है जिसे story को पूरा करना है; test case उसकी ठोस जाँच है, preconditions, inputs और expected result के साथ। एक criterion को आम तौर पर कई test cases चाहिए, जैसे उसका positive case, उसके refusals और उसकी boundaries।

ATDD, BDD और TDD में क्या फ़र्क़ है?

तीनों code से पहले tests लिखते हैं। TDD code के स्तर पर काम करता है: developer पहले fail होने वाला unit test लिखता है, फिर वह code जो उसे pass कराए, और फिर refactor करता है। ATDD पूरी team के साथ story implement होने से पहले acceptance criteria से acceptance tests निकालता है। BDD चाहे गए behaviour को natural language में Given/When/Then examples के रूप में लिखता है जिन्हें stakeholders पढ़ सकें, और अक्सर उन्हें Cucumber जैसे tool से चलाया जाता है।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
Gherkin Reference — CucumberCucumberexecutable specifications के लिए Gherkin सिंटैक्स: Feature, Rule, Scenario, Given/When/Then steps, Background, Scenario Outline और Examples।
Behaviour-Driven Development — CucumberCucumberBehaviour-Driven Development तीन अभ्यासों के रूप में — discovery, formulation और automation — जो business और technical लोगों द्वारा तय ठोस उदाहरणों पर आधारित हैं।