मॉड्यूल 4 · टेस्ट प्रोसेस (STLC)

डेफ़िनिशन ऑफ़ रेडी और डेफ़िनिशन ऑफ़ डन

Mutqan Soft QA टीम द्वारा · · 19 मिनट · शुरुआती

Definition of Done (DoD) टीम की साझा सूची है जिसमें वे quality measures होते हैं जिन्हें हर काम को पूरा माने जाने से पहले पूरा करना होता है। 2020 Scrum Guide इसे Increment की उस state का formal description कहता है जब वह product के लिए ज़रूरी quality measures पूरे करता है। अगर DoD कहती है "code review हुआ, acceptance criteria pipeline में pass होने वाले tests से covered हैं, कोई Blocker या Critical defect खुला नहीं है", तो जो story developer के laptop पर चलती है लेकिन जिसका एक test fail है, वह done नहीं है, task board पर कुछ भी लिखा हो।

Definition of Ready (DoR) यही विचार शुरुआत में लागू करती है: एक छोटी checklist जिसे backlog item को sprint में लिए जाने से पहले पूरा करना चाहिए। यह Scrum Guide का हिस्सा नहीं, बल्कि कई टीमों द्वारा जोड़ी गई practice है। ISTQB CTFL v4.0 दोनों को exit और entry criteria के agile नाम मानता है, जो पिछले lesson का विषय थे।

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

साझा definition के बिना "done" का मतलब developer के लिए "merge हो गया", product owner के लिए "customers इस्तेमाल कर सकते हैं" और tester के लिए "तय browsers पर दोनों भाषाओं में जाँचा गया" होता है। काम पूरा दिखता है जबकि उसमें undone work छिपा होता है — missing tests, बिना review का code, बिना translation के messages — जो release के समय defects के ढेर के रूप में सामने आता है। DoD हर item के लिए एक ही bar तय करती है, ताकि Sprint Review में दिखाई गई progress असली हो।

DoR उल्टी लागत को संभालती है: ऐसी stories जो अस्पष्ट rules या अटकी dependency के साथ sprint में आ जाती हैं, और tester को gaps sprint के बीच में मिलते हैं, जब सवाल सबसे महँगे होते हैं। साथ मिलकर दोनों "please इसे ठीक से टेस्ट कर दो" को तय, जाँचे जा सकने वाले criteria में बदल देती हैं जिनकी मालिक पूरी टीम है।

Scrum Guide में Definition of Done

जैसा "टेस्टर्स के लिए Scrum" वाले lesson में देखा, DoD Increment की commitment है: जो item इसे पूरा नहीं करता, वह न release होता है, न Sprint Review में दिखाया जाता है। इसे लिखते समय 2020 Scrum Guide की दो और बातें मायने रखती हैं। एक ही product पर काम करने वाली टीमें एक ही DoD साझा करती हैं। और Guide इसका content तय नहीं करता; यह टीम का फ़ैसला है, इसलिए testers को इसे लिखने में हिस्सा लेना चाहिए।

  • यह हर item पर लागू होती है। किसी एक story के ख़ास rules उस story के acceptance criteria हैं।
  • यह binary है: item हर criterion पूरा करता है, वरना done नहीं है। "लगभग done" जैसी कोई state नहीं है।

DoD में कौन-से quality criteria हों

अच्छा criterion जाँचा जा सकने वाला होता है — कोई भी हाँ या ना में जवाब दे सके और सबूत दिखा सके — और sprint के अंदर पूरा किया जा सकता है। "Tested" जाँचा नहीं जा सकता; "हर acceptance criterion ऐसे test से covered है जो CI pipeline में pass होता है" जाँचा जा सकता है। Non-functional quality भी शामिल करें; ISO/IEC 25010 की characteristics एक अच्छी याद दिलाने वाली सूची हैं। "टेस्टर्स के लिए Scrum" वाले lesson की sample DoD एक अच्छी शुरुआत है। उसमें code review, accessibility और security scan जोड़ें और बाक़ी items को ज़्यादा सटीक बनाएँ, तो वह कुछ ऐसी हो सकती है:

  • Code किसी दूसरे developer ने review किया और main branch में merge हुआ।
  • हर acceptance criterion किसी test से covered; automated tests CI pipeline में pass।
  • Regression suite main branch पर pass।
  • इस item का कोई Blocker या Critical defect खुला नहीं; बाक़ी defects Product Backlog में दर्ज।
  • नई या बदली screens accessibility के लिए जाँची गईं: हर control सिर्फ़ keyboard से काम करता है और उसका ऐसा name है जिसे screen reader बोल सके; error messages साफ़ हैं।
  • Screens phone और desktop browser पर Arabic और English में जाँची गईं।
  • Security scan में कोई नई high-severity finding नहीं।

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

Definition of Ready: टीम की अपनी practice

Scrum Guide में Definition of Ready नहीं है। वह सिर्फ़ इतना कहता है कि जिन items को टीम एक sprint में Done कर सकती है, उन्हें Sprint Planning में चुने जाने के लिए ready माना जाता है, आम तौर पर refinement के बाद। DoR इसी अपेक्षा को एक छोटी checklist के रूप में लिखती है जो refinement में इस्तेमाल होती है।

इसे contract नहीं, बातचीत का साधन मानें। जो DoR पहले से हर detail माँगती है वह हर sprint को छोटा waterfall बना देती है, इसलिए कई टीमें लगभग ready item भी ले लेती हैं जब खुला सवाल sprint की शुरुआत में सुलझ सकता हो। इसके आम items:

  • Story बताती है कि किसे क्या चाहिए और क्यों।
  • Acceptance criteria लिखे हैं, और एक developer व एक tester ने testability के लिए उन्हें review किया है।
  • दूसरी टीम की API या translations जैसी dependencies पता और उपलब्ध हैं।
  • Interface बदलने पर designs attached हैं, right-to-left layout समेत।
  • Test data की ज़रूरतें पता हैं, और item एक sprint में आ जाता है; वरना उसे split किया जाता है।

आज़माएँ: User Story → टेस्ट सिनेरियो

DoR और DoD का entry और exit criteria से रिश्ता

ISTQB CTFL v4.0 बताता है कि agile development में exit criteria को अक्सर Definition of Done कहा जाता है, यानी releasable item के लिए टीम के objective measures, और development व testing शुरू होने से पहले user story को जो entry criteria पूरे करने होते हैं उन्हें Definition of Ready कहा जाता है। यह mapping क़रीबी है, लेकिन तीन अंतर मायने रखते हैं:

  • Scope: test plan में exit criteria आम तौर पर हर test level या release के लिए तय होते हैं; DoD हर sprint में हर item के लिए स्थायी agreement है।
  • Content और ownership: DoD में code review, documentation और deployment भी आते हैं, और यह test manager की नहीं, पूरी Scrum Team की होती है।
  • Levels: कुछ टीमें उन checks के लिए अलग release checklist रखती हैं जो हर sprint में नहीं समाते (पूरा regression, performance test)। यह release के exit criteria का काम करती है; उसमें जो खुला है वह undone work है, और ऐसे checks को DoD में लाने की सही जगह retrospective है।
DoR बनाम DoD: Definition of Ready टीम की practice है जो Sprint Planning से पहले refinement में जाँची जाती है; Definition of Done, Scrum Guide की commitment है जिसे हर item Increment में शामिल होने से पहले पूरा करता है।

Definition of ReadyDoR

क्या टीम बिना अंदाज़े के यह item शुरू कर सकती है?

स्रोत:
टीम की practice; 2020 Scrum Guide में नहीं
कब जाँची जाती है:
Refinement में, Sprint Planning में item चुने जाने से पहले
किस पर लागू:
चुने जाने से पहले हर Product Backlog item
ISTQB CTFL v4.0 में नाम:
User story के entry criteria
पूरा न हो तो:
Refine या split करें; यह Product Backlog में रुकता है
Tester के आम criteria:
Testable acceptance criteria, पता test data, उपलब्ध dependencies

Definition of DoneDoD

क्या यह item पूरा हुआ, बिना कोई छिपा काम बाक़ी रहे?

स्रोत:
2020 Scrum Guide: Increment की commitment
कब जाँची जाती है:
Sprint Review में item दिखाने या release करने से पहले
किस पर लागू:
हर item और पूरा Increment
ISTQB CTFL v4.0 में नाम:
Releasable item के exit criteria
पूरा न हो तो:
न दिखाया जाता है न release; Product Backlog में लौटता है
Tester के आम criteria:
CI में tests pass, regression suite pass, कोई Blocker या Critical defect खुला नहीं

Worked example: ready से done तक एक story

Story: "एक returning customer के रूप में, मैं पाँच तक delivery addresses save करना चाहता हूँ ताकि checkout तेज़ हो।" Refinement में tester इसे DoR से जाँचता है, और दो items पूरे नहीं होते: छठे address पर क्या होगा, यह कहीं नहीं लिखा, और दूसरी टीम की address-validation API अगले sprint में ही आएगी। टीम एक criterion जोड़ती है ("छठा address ऐसे message के साथ reject होता है जो पाँच की limit बताता है"), और product owner validation को अलग story में ले जाता है। अब story Sprint Planning के लिए ready है।

Sprint Review से पहले टीम DoD जाँचती है और सबूत story से link करती है:

  • Review, acceptance tests (पाँचवाँ address save, छठा reject), regression suite, phone और desktop पर Arabic और English screens, security scan: पूरा।
  • Defects: exploratory session में एक Minor defect मिला जो backlog में दर्ज है; कोई Blocker या Critical defect खुला नहीं: पूरा।
  • Accessibility check: अधूरा — icon वाले "Delete" button तक keyboard से पहुँचा जा सकता है, लेकिन उसका कोई accessible name नहीं है, यानी वह text जो assistive technology किसी control के लिए पढ़ती है, इसलिए screen reader सिर्फ़ "button" बोलता है।
  • नतीजा: story done नहीं है। Developer name जोड़ता है और tester उसी दिन फिर जाँचता है (confirmation testing)। ठीक न होने पर story Sprint Review में नहीं दिखाई जाती और Product Backlog में लौट जाती — उसे कभी "accessibility छोड़कर done" नहीं कहा जाता।

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

आम गलतियाँ

  • DoD को tester की sign-off list मान लेना। यह पूरी टीम की commitment है, और इसके लिए ज़रूरी testing sprint के अंदर होती है।
  • "Tested" या "कोई bug नहीं" जैसे criteria लिखना जिन्हें कोई जाँच न सके। Testing defects की मौजूदगी दिखाती है, ग़ैरमौजूदगी नहीं: "कोई Critical defect खुला नहीं" पक्का किया जा सकता है, "कोई bug नहीं" नहीं।
  • Acceptance criteria और DoD को मिला देना, या यह मान लेना कि सिर्फ़ story के acceptance criteria पूरे होने से वह done हो जाती है।
  • "Testing छोड़कर done" report करना या checks को बाद के "testing sprint" में धकेलना, जो undone work को release तक छिपाता है।
  • DoR को सख़्त gate बना देना, या उसे Scrum का हिस्सा बताना।
  • DoD को कभी revisit न करना, जिससे एक ही तरह का defect sprint दर sprint निकलता रहे।

QA का नज़रिया

Refinement में अक्सर tester ही सबसे पहले देखता है कि story ready नहीं है: missing negative cases, testable न होने वाली wording, अनजान test data। सवाल वहीं पूछें, और जब कोई gap बार-बार आए तो ऐसा DoR item प्रस्तावित करें जो उसे पकड़ ले। Sprint Planning में जाँचें कि test design, automation और exploratory sessions sprint tasks के रूप में planned हैं, वरना DoD समय पर पूरी नहीं हो सकती।

हर DoD criterion का सबूत story से link करें: pipeline run, session notes, accessibility check। जब कोई defect निकल जाए, तो retrospective में ठोस प्रस्ताव लाएँ, जैसे "forms सिर्फ़ keyboard से जाँचे जाते हैं"। और अगर कोई item को done कहना चाहे जबकि कोई criterion अधूरा है, तो इसे सबके सामने लाएँ: DoD बदलना टीम का खुला फ़ैसला है, किसी एक story के लिए चुपचाप दी गई छूट नहीं।

अभ्यास

कमज़ोर DoD दोबारा लिखें और story की readiness जाँचें

आपका काम

Clinic booking system बनाने वाली टीम की Definition of Done यह है: "Code complete. Tested. कोई bug नहीं। Product owner खुश। ज़रूरत हो तो documentation update।" इसे जाँचे जा सकने वाले criteria के रूप में दोबारा लिखें, जिनमें कम से कम दो non-functional concerns हों।

फिर एक छोटी DoR लिखें और इस story को उससे जाँचें: "एक patient के रूप में, मैं अपनी visit से पहले अपने insurance card की photo upload करना चाहता हूँ ताकि clinic में check-in तेज़ हो।" लिखें कि क्या पूरा नहीं होता और refinement में आप कौन-से सवाल पूछेंगे।

चरण
  1. DoD की हर line से पूछें: क्या कोई सबूत के साथ हाँ या ना में जवाब दे सकता है? उसे दोबारा लिखें या हटा दें।
  2. छूटे हुए quality concerns के लिए criteria जोड़ें।
  3. DoR लिखें और story को उससे जाँचें।
  4. Product owner के लिए अपने सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Lines क्यों fail होती हैं: "Code complete" और "Tested" जाँचे नहीं जा सकते, "कोई bug नहीं" testing से कभी पक्का नहीं हो सकता, "Product owner खुश" एक भावना है, और "ज़रूरत हो तो" यह खुला छोड़ता है कि कौन तय करेगा।

दोबारा लिखी DoD: code review और merge; हर acceptance criterion ऐसे test से covered जो CI में pass होता है; regression suite pass; कोई Blocker या Critical defect खुला नहीं; नई screens सिर्फ़ keyboard से और साफ़ error messages के लिए जाँची गईं; screens phone और desktop पर Arabic और English में जाँची गईं; users को दिखने वाला behaviour बदलने पर help text update। Keyboard check और भाषा-और-device check, ये दो non-functional criteria हैं।

DoR: value बताई गई; acceptance criteria लिखे और review हुए; dependencies उपलब्ध; designs attached; test data पता; item एक sprint में आता है। Story सिर्फ़ value वाला item पूरा करती है: उसके कोई acceptance criteria नहीं हैं; dependencies अनजान हैं (क्या card insurer से verify होता है, और क्या वह service उपलब्ध है?); upload screen का design नहीं है; और test data साफ़ नहीं है: अलग-अलग file types और sizes की images, एक धुँधली photo और एक expired card चाहिए, सब synthetic, क्योंकि असली insurance cards personal data हैं। जब तक insurer वाला check तय नहीं होता, कोई नहीं जानता कि story एक sprint में आएगी या नहीं; उसे अभी upload और बाद में verification में split किया जा सकता है।

सवाल: कौन-से file types और कितना maximum size स्वीकार है? क्या card insurer से verify होता है, और card expired या rejected होने पर patient को क्या दिखता है? Image कौन देख सकता है, और वह कितने समय तक रखी जाती है? क्या patient उसे बदल या delete कर सकता है? Upload बीच में fail हो जाए तो क्या होता है?

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

Definition of Ready और test plan के entry criteria में क्या अंतर है?

दोनों बताते हैं कि काम शुरू होने से पहले क्या सच होना चाहिए (ISTQB CTFL v4.0, DoR को user story के entry criteria कहता है), लेकिन scope और timing में ये अलग हैं। Test plan के entry criteria आम तौर पर किसी test level या activity के लिए तय होते हैं और उसके शुरू होने से पहले एक बार जाँचे जाते हैं, जैसे "test environment उपलब्ध है और smoke tests pass हैं"। DoR हर backlog item के लिए refinement में जाँची जाती है और पूछती है कि क्या वह item बनाने और टेस्ट करने लायक समझा जा चुका है। टीम दोनों इस्तेमाल कर सकती है: अपनी stories के लिए DoR, और मसलन customer द्वारा acceptance testing के लिए entry criteria।

टीम हर item पर DoD को बिना धीमे हुए कैसे जाँचे?

जो pipeline जाँच सकती है, वह pipeline को जाँचने दें: acceptance criteria के tests, regression suite और security scan हर change पर चलते हैं, और उनके results story से link होते हैं। जो checks किसी व्यक्ति को करने होते हैं, जैसे keyboard check और दोनों भाषाओं वाला check, उन्हें छोटा रखें और sprint tasks के रूप में plan करें। Automated accessibility checkers सिर्फ़ कुछ समस्याएँ पकड़ते हैं, जैसे missing accessible name, इसलिए वे keyboard check में मदद करते हैं, उसकी जगह नहीं लेते।

DoD में क्या जाएगा, यह कौन तय करता है?

अगर organisation ने DoD को standard के रूप में तय किया है, तो हर टीम को कम से कम उसे मानना होता है। वरना Scrum Team इसे बनाती है, Developers को इसका पालन करना ज़रूरी है, और टीम हर Sprint Retrospective में इसे inspect करती है। Testers उन defects के आधार पर, जो production तक पहुँचे, जाँचे जा सकने वाले quality criteria प्रस्तावित करके योगदान देते हैं।

क्या DoD, test plan के exit criteria की जगह ले लेती है?

Sprint के अंदर के काम के लिए आम तौर पर हाँ। लेकिन contractual या regulatory दायित्वों वाले projects, या customer द्वारा acceptance testing जैसे अलग test levels वाले projects, अक्सर उन levels या release के लिए test plan में exit criteria तय करते रहते हैं।

संदर्भ

  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Certified Tester Foundation Level Agile Tester (CTFL-AT)ISTQBagile टीमों के भीतर टेस्टिंग पर ISTQB का foundation-level extension; ISTQB इसे बंद कर रहा है (अंग्रेज़ी परीक्षा 6 मई 2027 तक) और इसकी जगह CTFL v4.0 व CTAL-AT सुझाता है।
टूल्स

Mutqan tools से अभ्यास करें

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

टेस्ट डिज़ाइन

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा