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

यूज़र स्टोरीज़

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

User story किसी feature का छोटा विवरण है, उस व्यक्ति की नज़र से जिसे उसकी ज़रूरत है। इसका आम format तीन हिस्सों का होता है: As a [role], I want [goal], so that [benefit], यानी "[role] के रूप में, मैं [goal] चाहता हूँ, ताकि [benefit]"। उदाहरण: "Delivery का इंतज़ार कर रहे customer के रूप में, मैं चाहता हूँ कि order के out for delivery होते ही मुझे SMS मिले, ताकि मैं उसे लेने के लिए मौजूद रहूँ।" कई agile teams अपने ज़्यादातर backlog items stories के रूप में लिखती हैं, और tester के लिए ये test basis का एक मुख्य हिस्सा हैं।

लेकिन यह वाक्य अकेले पूरा requirement नहीं है। Story business, development और testing के बीच conversation से, और अपने acceptance criteria से पूरी होती है, जो बताते हैं कि team कैसे जानेगी कि story done है। यह lesson format, 3 Cs और INVEST की खूबियाँ, बहुत बड़ी story को split करना, और refinement में tester story के साथ क्या करता है, यह सब सिखाता है।

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

Story जान-बूझकर छोटी रखी जाती है, इसलिए जो उसमें नहीं लिखा वह बातचीत में तय होता है। जब tester उस बातचीत में नहीं होता, तो gaps देर से सामने आते हैं: testing के दौरान, defects के रूप में या इस बहस के रूप में कि story का मतलब क्या था। बहुत बड़ी story की एक और कीमत है: वह iteration के आख़िरी दिनों में पूरी होती है, और उसकी testing या तो दब जाती है या अगले iteration में खिसक जाती है।

Tester के लिए stories असर डालने का सबसे पहला मौक़ा हैं। जब story अभी card ही है, तब "हम कैसे जानेंगे कि यह काम करता है?" पूछना सबसे सस्ती static testing है: अस्पष्ट benefit या छूटा हुआ rule अभी सिर्फ़ एक सवाल की कीमत रखता है, बाद में reopen हुई story और दोबारा बने feature की। छोटी और testable stories test design भी आसान करती हैं: हर story के साफ़ acceptance criteria, तय test data और done होने का साफ़ पल होता है।

Story का format और 3 Cs

ISTQB Foundation syllabus सबसे आम format बताता है: As a [role], I want [goal], so that [benefit], और उसके बाद acceptance criteria। Syllabus Ron Jeffries के 3 Cs भी इस्तेमाल करता है, तीन पहलू जो मिलकर story बनाते हैं: Card, Conversation और Confirmation। Card वह माध्यम है जिस पर story रहती है, जैसे काग़ज़ का index card या किसी electronic board या tracker में एक entry, और उस पर role, goal और benefit वाला एक वाक्य होता है। हर हिस्सा tester को काम की कोई चीज़ देता है:

  • Card, role: feature कौन इस्तेमाल करता है। इससे पता चलता है कि किस user और किन permissions के साथ टेस्ट करना है।
  • Card, goal: user क्या हासिल करना चाहता है, screen कैसी दिखे यह नहीं। यही main path बनता है जिसे आप टेस्ट करते हैं।
  • Card, benefit: user यह क्यों चाहता है, ताकि आप तय कर सकें कि feature ज़रूरत पूरी करता है या नहीं। नीचे के उदाहरण में: order के depot से निकलते ही भेजा गया SMS क्या इतनी जल्दी आता है कि customer घर पहुँच सके?
  • Conversation: वह चर्चा जिसमें details तय होती हैं, बोलकर या लिखकर। Card जान-बूझकर छोटा होता है, और जो फ़ैसले उस पर वापस नहीं लिखे जाते, वे story के testing तक पहुँचने से पहले खो जाते हैं।
  • Confirmation: acceptance criteria जो बताते हैं कि story कब done है। ये आपके test cases का शुरुआती बिंदु हैं; इन्हें कैसे लिखें, यह अगला lesson बताता है।
STORY-214  Delivery SMS
Delivery का इंतज़ार कर रहे customer के रूप में,
मैं चाहता हूँ कि order के out for delivery होते ही मुझे SMS मिले,
ताकि मैं उसे लेने के लिए मौजूद रहूँ।

Conversation (refinement के बाद story में लिखे गए फ़ैसले)
- SMS order में दिए phone number पर जाए, account वाले number पर नहीं।
- SMS उसी भाषा में जाए जिसमें order किया गया (Arabic या English)।
- Status दो बार set हो, तो भी सिर्फ़ एक SMS जाए।

Confirmation (acceptance criteria)
AC1  Order status "Out for delivery" होने पर 2 मिनट के अंदर order में दिए
     phone number पर एक SMS जाता है।
AC2  SMS में order number और delivery का time window होता है।
AC3  Store से pick-up होने वाले orders को delivery SMS नहीं जाता।
Delivery SMS story की बनावट: card role, goal और benefit देता है, conversation फ़ैसले जोड़ता है, और confirmation उसके acceptance criteria हैं।
Story का हिस्साDelivery SMS story मेंTester को क्या मिलता है
RoleCard · “As a …”Delivery का इंतज़ार कर रहा customerकिस user और किन permissions के साथ टेस्ट करना है
GoalCard · “I want …”Order के out for delivery होते ही SMSटेस्ट करने का main path, screen design नहीं
BenefitCard · “so that …”Order लेने के लिए मौजूद रहनाFeature ज़रूरत पूरी करता है या नहीं: क्या SMS इतनी जल्दी आता है कि घर पहुँचा जा सके?
Conversationदूसरा COrder में दिया phone number, order की भाषा, सिर्फ़ एक SMSTesting से पहले story पर वापस लिखे जाने वाले फ़ैसले
Confirmationतीसरा CAcceptance criteria AC1 से AC3Story कब done है: test cases का शुरुआती बिंदु

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

INVEST: अच्छी story के छह सवाल

INVEST, Bill Wake का दिया acronym है, जिसे ISTQB syllabus भी इस्तेमाल करता है; यह अच्छी story की छह खूबियाँ बताता है। इन letters को refinement में सवालों की तरह इस्तेमाल करें, भरने वाले form की तरह नहीं। हर एक testing के लिए मायने रखता है।

Testable वह खूबी है जिसे tester सबसे अच्छी तरह परख सकता है। Syllabus कहता है कि जब stakeholders को नहीं पता कि story को कैसे टेस्ट करें, तो हो सकता है story अस्पष्ट हो, उनके लिए कोई value न दिखाती हो, या उन्हें बस testing में मदद चाहिए। Story बनने से पहले यह पता कर लेना फ़ायदेमंद है कि वजह इनमें से कौन-सी है।

  • Independent: क्या इसे किसी दूसरी story का इंतज़ार किए बिना build, test और release किया जा सकता है? Dependencies testing का क्रम और ज़रूरी test data तय करती हैं।
  • Negotiable: यह ज़रूरत बताती है, कोई तय design नहीं। Details conversation में तय होती हैं, इसलिए मान लेने से पहले पूछें।
  • Valuable: इससे किसी user या customer को कुछ मिलता है। जो "story" अपने आप में कुछ नहीं देती, जैसे database table, उसे user की तरफ़ से टेस्ट नहीं किया जा सकता।
  • Estimable: team इसका size बता सकती है, testing समेत। अगर कोई नहीं बता सकता कि इसे कैसे टेस्ट करेंगे, तो आम तौर पर इसका estimate भी नहीं हो सकता।
  • Small: यह testing के साथ एक iteration में आराम से पूरी हो जाती है। बड़ी stories testing को आख़िरी दिनों तक धकेल देती हैं।
  • Testable: यह तय करने का तरीका है कि story done है। "fast", "easy" या "better" जैसे शब्दों को काम शुरू होने से पहले मापने लायक अर्थ चाहिए।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर

बहुत बड़ी story को split करना

जो story एक iteration में पूरी न हो सके, उसे अक्सर epic कहा जाता है। उसे ऐसे split करें कि हर छोटी story एक vertical slice बनी रहे: वह feature की हर ज़रूरी layer से गुज़रे, screen से API होते हुए database तक, और user को कुछ ऐसा दे जिसे वह आज़मा सके।

यह epic लें: "Customer के रूप में, मैं items online return करना चाहता हूँ, ताकि support को call किए बिना मेरा पैसा वापस मिल जाए।" Layer के हिसाब से split करने पर यह returns table, returns API और returns screen बन जाता है: इनमें से किसी को कोई user आज़मा नहीं सकता, तीनों पूरे होने तक कुछ भी end to end टेस्ट नहीं हो सकता, और integration defects आख़िर में सामने आते हैं। Slices में split करने पर पहली story है "deliver हो चुका पूरा order return करना और original payment method में refund": छोटी पर पूरी, इसलिए done होते ही टेस्ट हो सकती है, और layers पहली story में ही मिल जाती हैं। Split करने के उपयोगी तरीके:

Online returns epic को layers में split करने से ऐसी तीन stories बनती हैं जिन्हें सबके पूरे होने तक न कोई आज़मा सकता है न end to end टेस्ट कर सकता है; vertical slices में हर story done होते ही टेस्ट हो सकती है।

Layer के हिसाब से splitइससे बचें

Database, API और screen अलग-अलग stories

क्या user पहली story आज़मा सकता है?:
नहीं
End to end testing:
तीनों stories पूरी होने के बाद ही
Integration defects कब दिखते हैं:
आख़िर में, जब layers मिलती हैं
  • Database में returns table
  • Returns API
  • Returns screen

Vertical slices में splitइसे चुनें

हर story screen से database तक जाती है

क्या user पहली story आज़मा सकता है?:
हाँ: पूरा order return हो सकता है
End to end testing:
हर story, done होते ही
Integration defects कब दिखते हैं:
पहली story में ही
  • Deliver हुआ पूरा order return, original payment method में refund
  • Order के चुने हुए items return
  • देर से आए और gift card वाले returns का refusal, कारण के साथ
  • Workflow step के हिसाब से: सबसे सरल end-to-end path पहले दें और बाकी steps बाद में जोड़ें, जैसे return request अभी और courier pickup की booking बाद वाली story में।
  • Business rule के हिसाब से: हर story में एक rule, या rule का एक variation, जैसे पहले पूरा order, फिर चुने हुए items, फिर देर से आए returns और gift cards का refusal।
  • Path के हिसाब से: पहले main success path, फिर हर error या exception path अपनी अलग story में, अपने acceptance criteria के साथ, जिसकी planning हो, न कि "बाद में, अगर समय मिला"।
  • Data या channel के हिसाब से: पहले एक payment method, file type या platform, और बाकी follow-up stories में।
  • Operation के हिसाब से: create, view, change और delete अलग stories के रूप में, जब हर एक अपने आप में उपयोगी हो।
  • Spike: जब किसी अनजानी चीज़, जैसे external API, की वजह से team estimate नहीं कर पाती, तो एक छोटी time-boxed जाँच जवाब ढूँढती है, और असली story उसके बाद लिखी जाती है। Spike से knowledge मिलता है, टेस्ट करने लायक feature नहीं।

Worked example: refinement में tester

Product owner returns वाला epic refinement में लाता है। Meeting से पहले tester ने उसे पढ़ा है, साथ में business rules वाले lesson का returns rule BR-03 (delivery के 14 दिन के अंदर return, gift cards का कभी नहीं) और courier company के API notes भी। Meeting में tester epic को INVEST से जाँचता है और नीचे दिए points उठाता है।

फिर team list के बाद दिखाए गए split पर सहमत होती है। Tester जाँचता है कि हर नई story अपने आप में टेस्ट हो सकती है, कि RET-3 में BR-03 का "बाकी हालात में" (otherwise) वाला outcome बना रहे, और कि test data पता है: 14 और 15 दिन पहले deliver हुए orders, और gift card वाला एक order। जवाब stories में लिखे जाते हैं, और ready मानी जाने से पहले हर story को acceptance criteria मिलते हैं।

  • Small नहीं, Estimable नहीं: epic में items चुनना, partial refunds, दो refund methods, courier pickup और refusals छिपे हैं।
  • जैसा लिखा है वैसा Testable नहीं: "पैसा वापस मिल जाए" न रकम बताता है न समय। क्या delivery fee भी refund होगी?
  • Independent नहीं: pickup एक ऐसे courier API पर निर्भर है जिसे team में किसी ने इस्तेमाल नहीं किया।
  • खुले सवाल: 14 दिन किस पल से गिने जाते हैं, और किस time zone में? क्या customer return cancel कर सकता है? Refund pending रहने तक customer क्या देखता है?
Epic: Online returns
RET-1  Deliver हो चुका पूरा order return; original payment method में refund
RET-2  Order के चुने हुए items return; सिर्फ़ उन्हीं items का refund
RET-3  14 दिन के बाद या gift cards के returns refuse करें, और कारण दिखाएँ
RET-4  Spike, 2 दिन: क्या courier API pickups book कर सकता है? जवाब से RET-5 लिखें
RET-5  Return के लिए courier pickup book करना
RET-6  Card की जगह in-app wallet में refund

Stories में लिखे गए फ़ैसले:
- Delivery fee सिर्फ़ तब refund होगी जब पूरा order return हो।
- 14 दिन delivery scan से गिने जाते हैं, Saudi Arabia time (UTC+3) में।

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

आम गलतियाँ

  • एक वाक्य वाले card को ही पूरा requirement मान लेना, या refinement के फ़ैसले लोगों के दिमाग़ और chat threads में छोड़ देना, जिससे story के testing तक पहुँचने पर वे ग़ायब मिलते हैं।
  • अस्पष्ट या ग़ायब benefit ("ताकि यह बेहतर काम करे") स्वीकार कर लेना: इसके बिना कोई तय नहीं कर सकता कि delivered feature ज़रूरत पूरी करता है या नहीं।
  • Technical tasks को user stories कहना ("Developer के रूप में, मुझे returns table चाहिए"): ये user को आज़माने के लिए कुछ नहीं देते और user की तरफ़ से टेस्ट नहीं हो सकते।
  • Vertical slices की जगह layer या activity के हिसाब से split करना, जैसे एक "build" story और एक "test" story, जबकि हर slice अपने आप में end to end टेस्ट होनी चाहिए।
  • "Happy path पहले" को "सिर्फ़ happy path" बन जाने देना: error paths, refusals और non-functional ज़रूरतें बाद की ऐसी stories में चली जाती हैं जिनकी कभी planning नहीं होती।
  • Story के testing में पहुँचने तक इंतज़ार करना और तब कहना कि वह testable नहीं है, बजाय इसके कि refinement में ही यह बात उठाएँ, जब बदलाव अभी सस्ता है।

QA का नज़रिया

ज़्यादातर agile teams में stories का owner product owner होता है, लेकिन ISTQB Foundation syllabus उन्हें मिलकर लिखने की बात करता है, जिसमें business, development और testing के नज़रिए साथ हों; जैसा टेस्टर्स के लिए एजाइल वाले lesson में देखा, कई teams इसे three amigos कहती हैं। Tester का योगदान ठोस है: refinement से पहले story और उससे जुड़े rules, designs और contracts पढ़ें; सवाल और ठोस examples लेकर आएँ; INVEST की खूबियाँ खुलकर जाँचें, ख़ासकर Testable और Small; और ऐसे splits सुझाएँ जिनका हर हिस्सा अपने आप में टेस्ट हो सके।

Refinement के बाद पक्का करें कि हर फ़ैसला story में लिखा गया है, किसी chat thread में नहीं छूटा, और story iteration में जाने से पहले team की Definition of Ready पूरी करती है। Story को जिस test data और environments की ज़रूरत है उन्हें नोट करें, उसे उसके business rules से और बाद में test cases से link करें, और acceptance criteria से test conditions का draft बनाएँ। अगर फिर भी कोई story gaps के साथ testing तक पहुँचे, तो उन्हें story पर ही दर्ज करें, ताकि अगला refinement बेहतर हो।

अभ्यास

Refinement से पहले story review और split करें

आपका काम

आप एक supermarket delivery app टेस्ट करते हैं, और refinement कल है। Product owner ने नीचे की story लिखी है। इसे INVEST से जाँचें, card दोबारा लिखें, इसे vertical slices में split करें और meeting में पूछे जाने वाले सवाल तैयार करें।

सामग्री
User के रूप में, मैं shopping lists बनाना, उन्हें परिवार के साथ share करना
और पिछले orders से suggestions पाना चाहता हूँ, ताकि shopping बेहतर हो।
चरण
  1. Role, goal और benefit पहचानें, और बताएँ कि हर एक में क्या कमज़ोर है।
  2. INVEST के छह letters एक-एक करके देखें और हर समस्या नोट करें।
  3. Story को ऐसे vertical slices में split करें जिनमें से हर एक अपने आप में टेस्ट हो सके।
  4. Product owner के लिए कम से कम चार सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Role, goal और benefit: "user" बहुत सामान्य है; role वह व्यक्ति है जो घर की shopping plan करता है, और sharing एक दूसरा role जोड़ती है, परिवार का वह सदस्य जिसे list मिलती है। Goal तीन features को "और" से जोड़ता है। Benefit "shopping बेहतर हो" जाँचा नहीं जा सकता; काम का version है "ताकि मैं अपनी ज़रूरत की हर चीज़ एक बार में order कर सकूँ"।

INVEST: Small नहीं (तीन features); Estimable नहीं (अभी कोई नहीं जानता कि उपयोगी suggestions के लिए पिछले orders का data काफ़ी है या नहीं); Testable नहीं ("बेहतर" का कोई जाँचने लायक अर्थ नहीं, और acceptance criteria नहीं हैं); Independent सिर्फ़ आंशिक रूप से (sharing को lists चाहिए, और suggestions को order history)। Benefit दोबारा लिखने के बाद Valuable और Negotiable ठीक हैं।

एक संभव split: (1) घर की shopping करने वाले के रूप में, मैं list बनाकर catalogue से products जोड़ना चाहता हूँ, ताकि अगला order plan कर सकूँ। (2) घर की shopping करने वाले के रूप में, मैं एक step में list को cart में बदलना चाहता हूँ, ताकि जल्दी order कर सकूँ। (3) घर की shopping करने वाले के रूप में, मैं account वाले परिवार के सदस्य के साथ list share करना चाहता हूँ, ताकि वह अपनी ज़रूरत की चीज़ें जोड़ सके। (4) एक time-boxed spike: क्या पिछले orders से उपयोगी suggestions बन सकते हैं? Suggestions वाली story उसके जवाब से लिखी जाती है। Story 1 पहले आती है, क्योंकि बाकी दोनों को list चाहिए; उसके बाद stories 2 और 3 एक-दूसरे पर निर्भर नहीं हैं, और हर एक अलग से build, test और release हो सकती है।

सवाल: क्या lists की, या एक list में products की, कोई maximum संख्या है? List के किसी product का stock ख़त्म हो जाए या price बदल जाए तो क्या होगा? क्या परिवार का सदस्य list delete कर सकता है, या सिर्फ़ उसमें जोड़ सकता है? Owner अपना account बंद कर दे तो shared list का क्या होगा? क्या product names Arabic और English दोनों में दिखते हैं?

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

User stories कौन लिखता है: product owner या tester?

आम तौर पर product owner उनका owner होता है और उनका क्रम तय करता है, हालाँकि team का कोई भी सदस्य draft लिख सकता है। ISTQB Foundation syllabus business, development और testing के नज़रियों के साथ मिलकर लिखने की बात करता है। Tester शायद ही card लिखता है, पर अक्सर conversation और acceptance criteria को आकार देता है।

क्या user story एक requirement है?

हाँ, user या stakeholder requirement का छोटा रूप। लेकिन सिर्फ़ वाक्य से टेस्ट नहीं किया जा सकता: test basis है story, उसके acceptance criteria, conversation से दर्ज फ़ैसले, और उससे जुड़े business rules, designs और API contracts।

क्या हर story में "As a / I want / so that" template ज़रूरी है?

नहीं। यह सबसे आम format है, नियम नहीं, और Scrum Guide user stories को ज़रूरी भी नहीं बताता। ज़रूरी यह है कि item बताए कि वह किसके लिए है, उन्हें क्या चाहिए और क्यों, और team कैसे पक्का करेगी कि वह done है।

Story कितनी छोटी होनी चाहिए?

इतनी छोटी कि team उसे एक iteration के अंदर Definition of Done तक build और test कर सके, बेहतर हो कि काफ़ी पहले, ताकि testing आख़िर में जमा न हो। एक practical संकेत: अगर आप कुछ मिनटों में उसके acceptance criteria और test data नहीं लिख पाते, तो वह शायद अभी भी बहुत बड़ी है।

संदर्भ

  • 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 सुझाता है।
  • Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
टूल्स

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

User Story → टेस्ट केस

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

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

AI Requirement अस्पष्टता डिटेक्टर

requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।

आवश्यकता विश्लेषण AI

और गहराई से

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

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