मॉड्यूल 2 · Software development lifecycle

टेस्टर्स के लिए Scrum

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

Scrum एक हल्का framework है जिसमें एक छोटी टीम product को तय लंबाई के चक्रों में deliver करती है, जिन्हें Sprints कहते हैं; हर Sprint एक महीने या उससे कम का होता है। 2020 Scrum Guide इसे तीन accountabilities, पाँच events (Sprint और उसके अंदर के चार events) और तीन artifacts से परिभाषित करती है, और हर artifact का एक commitment है, जैसे Definition of Done।

Scrum में tester भी Developers में से एक है। Food-delivery app के दो हफ़्ते के Sprint में वह किसी testing phase का इंतज़ार नहीं करता: वह Sprint से पहले story पर सवाल पूछता है, Sprint Planning में उसके tests की योजना बनाता है, जिस दिन वह बने उसी दिन उसे टेस्ट करता है, और यह तय करने में मदद करता है कि वह done है या नहीं।

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

Scrum planning, building, testing और review को कुछ हफ़्तों में समेट देता है। अगर टेस्टिंग Sprint का आख़िरी step हो, तो untested stories अंत में जमा हो जाती हैं, आधे टेस्ट हुए काम को done कह दिया जाता है, और defects production में पहुँच जाते हैं। Scrum Guide कहती है कि Sprint के दौरान quality कम नहीं होती; यह तभी सच है जब टेस्टिंग पहले दिन से योजना में हो।

Scrum को ठीक से जानना बताता है कि कहाँ कदम उठाना है: business rules के सवाल refinement में, खराब test environment Daily Scrum में, और बार-बार आने वाली quality समस्या Retrospective में। और Definition of Done आपको पूरी टीम का माना हुआ quality का पैमाना देता है।

Accountabilities, artifacts और उनके commitments

2020 Scrum Guide job titles की नहीं, accountabilities की बात करती है। Scrum Team में एक Product Owner, एक Scrum Master और Developers होते हैं, आम तौर पर 10 या उससे कम लोग, बिना sub-teams के; इसलिए इसमें कोई अलग test team नहीं होती। इसके तीनों artifacts में से हर एक का अपना commitment है। Product Backlog, यानी product की ज़रूरतों की क्रमबद्ध सूची, का commitment Product Goal है, जो टीम का लंबी अवधि का लक्ष्य है। Sprint Backlog, यानी Sprint के लिए चुने गए items और उन्हें deliver करने की Developers की योजना, का commitment Sprint Goal है, जो Sprint का एकमात्र लक्ष्य है। Increment, यानी Product Goal की ओर एक usable और अच्छी तरह verified कदम, का commitment Definition of Done है।

Product Backlog refinement, यानी items को छोटा करना और उनमें detail, order और size जोड़ना, लगातार चलने वाली activity है, event नहीं, और tester के सवालों के लिए सबसे सस्ती जगह है। हर accountability का आपके लिए मतलब:

  • Product Owner: product की value को अधिकतम करने और Product Backlog के प्रबंधन के लिए जवाबदेह, जिसमें Product Goal और items का क्रम शामिल है। Business rules और priority के सवाल यहीं जाते हैं।
  • Scrum Master: Scrum स्थापित करने और टीम की effectiveness के लिए जवाबदेह, जिसमें impediments हटवाना भी शामिल है, जैसे अस्थिर test environment।
  • Developers: Increment बनाने वाले सभी लोग, testers समेत। Sprint Backlog इनका है, ये Definition of Done का पालन करके quality लाते हैं और हर दिन अपनी योजना को Sprint Goal की ओर ढालते हैं।

हर event में tester क्या करता है

Sprint बाकी चार events को समेटता है, एक महीने या उससे कम का होता है, और ख़त्म होते ही अगला Sprint शुरू हो जाता है। Daily Scrum हमेशा 15 मिनट का होता है; नीचे दिए बाकी time-boxes एक महीने के Sprint की अधिकतम सीमा हैं, और छोटे Sprints में ये events आम तौर पर छोटे होते हैं।

दो lanes में एक Sprint: Product Backlog refinement, Sprint के अंदर के चार events उनके time-boxes के साथ, और रोज़ का काम, हर एक के साथ उसमें tester का काम। वैचारिक मॉडल
  1. Scrum event या activity:
    1Product Backlog refinementलगातार चलने वाली activity, event नहींItems को छोटा करना और detail, order व size जोड़ना

    आगे जाता है: आने वाले items और उनके acceptance criteria

    Tester क्या करता है:
    सवाल पूछें, स्पष्ट करेंRules, edge cases, risks: क्या हर item testable है?

    वापस जाता है: जवाब acceptance criteria या छोटे items बनते हैं

  2. Scrum event या activity:
    2Sprint Planningअधिकतम 8 घंटेक्यों, क्या और कैसे: Sprint Goal, items और योजना

    आगे जाता है: Sprint Goal और चुने गए items

    Tester क्या करता है:
    टेस्टिंग की योजनाSprint Backlog में test tasks, test data, environments और regression scope
  3. Scrum event या activity:
    3Daily Scrumहर working day 15 मिनटDevelopers Sprint Goal की ओर progress जाँचते हैं

    आगे जाता है: Progress और impediments

    Tester क्या करता है:
    टेस्टिंग को सबके सामने रखेंक्या टेस्ट हुआ, क्या blocked है, क्या टेस्टिंग के इंतज़ार में है

    वापस जाता है: अगले दिन की योजना बदली जाती है

  4. Scrum event या activity:
    4Sprint के भीतर कामSprint का हर दिनDevelopers चुने गए items को Done काम में बदलते हैं

    आगे जाता है: हर item तैयार होते ही

    Tester क्या करता है:
    लगातार टेस्ट करेंPairing, automation, exploration, defect reports, confirmation और regression tests
  5. Scrum event या activity:
    5Sprint Reviewअधिकतम 4 घंटेKey stakeholders के सामने नतीजे; अगले कदम तय

    आगे जाता है: सिर्फ़ Definition of Done पूरा करने वाले items

    Tester क्या करता है:
    सबूत साझा करेंक्या टेस्ट हुआ, ज्ञात risks, feedback दर्ज

    वापस जाता है: Feedback से Product Backlog बदलता है

  6. Scrum event या activity:
    6Sprint Retrospectiveअधिकतम 3 घंटे; इसी से Sprint ख़त्म होता हैIndividuals, interactions, processes, tools और DoD की जाँच

    आगे जाता है: Quality को किसने मदद दी, किसने नुकसान पहुँचाया

    Tester क्या करता है:
    सुधार सुझाएँसबूत के साथ: escaped defects, इंतज़ार का समय, flaky tests

    वापस जाता है: सुधार अगले Sprint Backlog या DoD में जा सकता है

चरण 1–6 के दौरान यह सब Sprint के भीतर होता है, जो एक महीने या उससे कम का है; यह ख़त्म होते ही अगला Sprint शुरू होता है।

Daily Scrum हमेशा 15 मिनट का होता है; बाकी time-boxes एक महीने के Sprint की अधिकतम सीमा हैं, और छोटे Sprints में ये events आम तौर पर छोटे होते हैं।

  • Sprint Planning (अधिकतम 8 घंटे): टीम तय करती है कि Sprint क्यों मूल्यवान है, क्या Done हो सकता है और कैसे। "कैसे" में टेस्टिंग जोड़ें: test tasks, test data, environments और regression scope।
  • Daily Scrum (हर working day 15 मिनट, Developers के लिए): Sprint Goal की ओर progress जाँचना और योजना बदलना। बताएँ कि क्या टेस्ट हुआ, क्या blocked है और क्या टेस्टिंग के इंतज़ार में है।
  • Sprint के दौरान: हर item को तैयार होते ही टेस्ट करें, आख़िर में एक साथ नहीं। Developers के साथ pairing करें, checks automate करें, explore करें, defects report करें, और confirmation व regression tests चलाएँ।
  • Sprint Review (अधिकतम 4 घंटे): टीम अपने नतीजे key stakeholders के सामने रखती है और सब मिलकर अगला कदम तय करते हैं। बताएँ कि क्या टेस्ट हुआ और कौन-से risks ज्ञात हैं, और देखें कि feedback Product Backlog तक पहुँचे।
  • Sprint Retrospective (अधिकतम 3 घंटे): टीम individuals, interactions, processes, tools और अपनी Definition of Done की जाँच करती है। Escaped defects या इंतज़ार के समय जैसे सबूत लाएँ, और एक ठोस सुधार सुझाएँ; वह अगले Sprint Backlog में भी जा सकता है।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

Definition of Done और tester

Definition of Done (DoD) Increment की उस स्थिति का औपचारिक विवरण है जब वह product के लिए ज़रूरी quality measures पूरे करता है। जो item इसे पूरा करता है वह Increment का हिस्सा बनता है; जो नहीं करता, उसे न release किया जा सकता है न Sprint Review में दिखाया जा सकता है, और वह Product Backlog में लौट जाता है। Organisation का DoD हर टीम के लिए न्यूनतम है; वह न हो तो टीम अपना DoD बनाती है।

ISTQB Foundation syllabus v4.0 बताता है कि Agile टीमें अक्सर अपने exit criteria को Definition of Done कहती हैं। Tester DoD को जाँचने लायक बनाने में मदद करता है, उसे ईमानदारी से लागू करता है और Retrospective में बदलाव सुझाता है। दो भाषाओं वाले web product का DoD कुछ ऐसा हो सकता है:

  • Test environment पर acceptance criteria verify हुए।
  • नए behaviour के automated checks pipeline में pass हैं।
  • प्रभावित areas के regression tests pass हुए।
  • Item पर कोई open Blocker या Critical defect नहीं।
  • Arabic और English screens जाँची गईं, right-to-left layout समेत।

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

Worked example: दो हफ़्ते के Sprint में एक story

एक food-delivery टीम दो हफ़्ते के Sprints में काम करती है, और Sprint Goal है "लौटने वाले customers दो taps में पुराना order दोबारा कर सकें"। यह Agile for Testers वाले lesson के exercise की reorder story जैसी ही story है; इस बार देखें कि tester के काम का हर हिस्सा Scrum में कहाँ होता है, क्रम से:

  • Refinement, पिछले Sprint में: tester पूछता है कि पुराने order का कोई item out of stock हो या उसकी price बदल गई हो तो क्या होगा। दो acceptance criteria जुड़ते हैं (basket आज की prices इस्तेमाल करता है, और customer को बताया जाता है कि कौन-सी prices बदलीं), और out-of-stock handling एक अलग item बन जाती है।
  • Sprint Planning: reorder request के API checks, बदली हुई price वाला test data, basket पर एक exploratory session और checkout का regression योजना में जुड़ते हैं।
  • Day 4 से Day 9: tester एक Daily Scrum में test data की कमी बताता है और event के बाद एक developer मदद करता है। एक defect (पुरानी price copy होना) उसी दिन fix होता है, उसका confirmation test होता है और automated check जुड़ता है; Day 9 पर item DoD पूरा करता है।
  • Review और Retrospective: एक stakeholder की नई माँग Product Backlog में जाती है; tester दिखाता है कि तीन items ने test data के लिए दो दिन इंतज़ार किया, इसलिए टीम अब test data Sprint Planning में ही पहचानती है।

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

आम गलतियाँ

  • Sprint को mini-waterfall की तरह चलाना: पहले build, आख़िरी दिनों में टेस्टिंग, और untested items आगे खिसकाना।
  • Code merge होने भर से item को done कह देना, जबकि DoD की checks अभी बाकी हैं।
  • Daily Scrum को status report या लंबी defect चर्चाओं के लिए इस्तेमाल करना, बजाय Sprint Goal की ओर progress जाँचने के।
  • Definition of Done और acceptance criteria को एक समझना, या टीम का DoD सुधारने की बजाय अपनी निजी checklist रखना।
  • Quality को सिर्फ़ tester का काम मानना; Scrum में हर Developer DoD के ज़रिए इसके लिए जवाबदेह है।

QA का नज़रिया

Scrum टीम में आप testing specialty वाले Developer हैं: Product Owner के साथ acceptance criteria और risks, developers के साथ testability और automation, और Scrum Master के साथ impediments तय करें। Test notes और defects उसी backlog item पर दर्ज करें ताकि उसकी असली स्थिति सबको दिखे।

हर Sprint में पूछें: क्या यह item Sprint के अंदर बनकर टेस्ट हो सकता है, इसे कौन-सा data और environment चाहिए, और यह क्या तोड़ सकता है? जब आख़िरी दिन कोई item DoD पूरा न करे, तो साफ़ कहें: वह Product Backlog में लौटता है।

अभ्यास

एक Sprint में अपनी टेस्टिंग की योजना बनाएँ

आपका काम

एक clinic booking web app एक हफ़्ते के Sprints में बनता है। Story: "एक मरीज़ के रूप में, मैं अपना appointment online cancel करना चाहता हूँ ताकि मुझे clinic को फ़ोन न करना पड़े।" Acceptance criteria: आने वाला appointment "मेरे appointments" से cancel हो सकता है, और appointment से 24 घंटे से कम पहले cancel की अनुमति नहीं है।

टीम का DoD: acceptance criteria verify; automated checks pass; कोई open Blocker या Critical defect नहीं; Arabic और English pages जाँचे गए। Refinement और हर event में tester के रूप में आप क्या करेंगे, लिखें, फिर DoD में एक सुधार सुझाएँ।

चरण
  1. Refinement: वे सवाल लिखें जिनका जवाब acceptance criteria में नहीं है।
  2. Sprint Planning: योजना में जोड़े जाने वाले test tasks, test data और regression scope की सूची बनाएँ।
  3. Daily Scrum, Sprint Review और Sprint Retrospective: हर एक में आप जो एक काम करेंगे या कहेंगे, वह लिखें।
  4. DoD की तुलना इससे करें कि यह story क्या तोड़ सकती है, और सबसे ज़रूरी एक सुधार सुझाएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Refinement: क्या 24 घंटे की सीमा clinic के time zone में गिनी जाती है, और क्या ठीक 24 घंटे पहले cancel allowed है? क्या cancel हुआ slot फिर से booking के लिए खुलता है? किसे सूचना जाती है? जवाब acceptance criteria या नए items बनते हैं।

Sprint Planning: 24 घंटे से थोड़ा कम, ठीक 24 घंटे और थोड़ा ज़्यादा पर boundary tests; cancel request के API checks; मेल खाता test data; "मेरे appointments" पर एक exploratory session; booking और rescheduling का regression। Time zone का नियम तय न होना risk के रूप में उठाएँ।

Sprint के दौरान: flow को उसी दिन टेस्ट करें जिस दिन वह test environment पर पहुँचे, और Daily Scrum में progress और blockers बताएँ, जैसे test data की कमी। Sprint Review में बताएँ कि क्या टेस्ट हुआ और कौन-से risks अभी खुले हैं, जैसे time zone का नियम; item तभी दिखाया जाता है जब वह DoD पूरा करे। Retrospective में इंतज़ार के समय या escaped defects जैसे सबूत लाएँ।

DoD सुधार: "प्रभावित areas के regression tests pass" जोड़ें, क्योंकि मौजूदा DoD मौजूदा booking features को नहीं बचाता।

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

क्या Scrum में tester का कोई रोल है?

अलग accountability के रूप में नहीं। 2020 Scrum Guide में तीन हैं: Product Owner, Scrum Master और Developers, और Developers वे सभी लोग हैं जो Increment बनाते हैं। Tester उन्हीं Developers में से एक है। कई टीमों में अब भी testing specialists होते हैं जो test analysis, exploratory testing और automation का नेतृत्व करते हैं, जबकि quality की जवाबदेही पूरी टीम की रहती है।

Definition of Done और acceptance criteria में क्या फ़र्क है?

Definition of Done quality measures का एक set है जो हर item और पूरे Increment पर लागू होता है। Acceptance criteria किसी एक item की शर्तें हैं। Item तभी done है जब वह अपने acceptance criteria और Definition of Done दोनों पूरे करे।

Sprint के अंत में जो story done नहीं हुई, उसका क्या होता है?

वह Increment का हिस्सा नहीं बनती, इसलिए न release हो सकती है न Sprint Review में दिखाई जा सकती है। वह Product Backlog में लौट जाती है, जहाँ Product Owner उसका क्रम फिर से तय करता है। उसे पूरा करने के लिए Sprint नहीं बढ़ाया जाता।

क्या Scrum में user stories या Definition of Ready ज़रूरी हैं?

नहीं। Scrum Guide user stories, acceptance criteria या Definition of Ready अनिवार्य नहीं करती; ये टीमों द्वारा जोड़ी गई practices हैं। Guide सिर्फ़ इतना कहती है कि जो items एक Sprint में Done हो सकते हैं, वे Sprint Planning में चुने जाने के लिए ready माने जाते हैं। ISTQB Foundation syllabus v4.0 Definition of Ready को user story के entry criteria के रूप में बताता है।

संदर्भ

  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
टूल्स

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

User Story → टेस्ट केस

किसी user story (As a / I want / So that) को टेम्पलेट और heuristics की मदद से संरचित टेस्ट केस में बदलें।

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

रिग्रेशन सिनेरियो जनरेटर

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

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

रिस्क-बेस्ड टेस्ट जनरेटर

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

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

और गहराई से

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

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