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

टेस्टर्स के लिए एजाइल

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

Agile software बनाने का एक तरीका है जिसमें काम करने वाले product के छोटे और बार-बार आने वाले increments बनाए जाते हैं, और जिन लोगों को software चाहिए वे पूरे समय जुड़े रहते हैं। इसे 2001 में प्रकाशित Manifesto for Agile Software Development की चार values और बारह principles परिभाषित करते हैं। Agile अपने-आप में कोई एक method नहीं है: Scrum और Kanban जैसे approaches, जो अगले दो lessons हैं, इसे practice में लागू करते हैं।

पिछले lesson के sequential models की तुलना में tester के लिए सबसे बड़ा बदलाव timing का है: testing development के बाद किसी phase में नहीं, हर छोटे cycle के अंदर होती है। जब team "मेरा address save करें" feature बनाती है, तो tester coding शुरू होने से पहले ही पूछ लेता है कि customer कितने addresses रख सकता है।

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

Sequential project में requirement की गलतफ़हमी महीनों तक छिपी रह सकती है। Agile में काम का हर हिस्सा कुछ ही दिनों में specify, build और test होता है, इसलिए तब पकड़ी गई गलतफ़हमी की कीमत आम तौर पर redesign नहीं, बल्कि एक बातचीत और छोटा fix होती है। लेकिन देरी को सँभालने के लिए कोई test phase नहीं होता: अगर testing हर cycle का हिस्सा न हो, तो untested काम जमा होता जाता है और problems जल्दी users तक पहुँचती हैं।

Tester के लिए Agile techniques से ज़्यादा यह बदलता है कि आप कब और कैसे काम करते हैं: skills वही हैं, पर पहले, छोटे हिस्सों में और developers व product owner के साथ लगातार बातचीत में।

Tester की नज़र से Agile values और principles

Manifesto के दो हिस्से हैं: चार values और उनके पीछे के बारह principles। इनमें से कई principles testing को आकार देते हैं: working software बार-बार deliver करना, कुछ हफ़्तों से लेकर कुछ महीनों में, कम अवधि को प्राथमिकता देते हुए; development के आख़िरी दौर में भी बदलती requirements का स्वागत करना; business लोगों और developers का रोज़ साथ काम करना; working software ही progress का मुख्य पैमाना है; और team नियमित अंतराल पर सोचती है कि और प्रभावी कैसे बने, फिर अपना तरीका सुधारती है।

चारों values preferences हैं: पहली चीज़ को ज़्यादा महत्व दिया जाता है, लेकिन दूसरी की value भी बनी रहती है। हर value tester की आदतें बदलती है:

  • Individuals and interactions over processes and tools: developer के साथ पाँच मिनट अक्सर किसी लंबे defect thread से ज़्यादा सुलझा देते हैं।
  • Working software over comprehensive documentation: progress का मतलब है चलता हुआ, टेस्ट किया हुआ software। Tester फिर भी उतना लिखता है जितना काफ़ी हो: acceptance criteria, notes, defect reports, automated checks।
  • Customer collaboration over contract negotiation: product owner उपलब्ध रहता है, इसलिए आप specification पर बहस करने के बजाय पूछते हैं "क्या आपका मतलब यही था?"।
  • Responding to change over following a plan: requirements एक cycle से दूसरे cycle में बदल सकती हैं, इसलिए tests को update करना सस्ता होना चाहिए और regression checks ज़्यादातर automate किए जाते हैं।

Testing कहाँ फ़िट होती है: जल्दी, बार-बार और साझा

तीन ideas agile team में tester की जगह बताते हैं; नीचे की timeline एक story की तुलना sequential flow से करती है।

  • Early involvement: tester story बनने से पहले ही उस पर चर्चा करता है, आम तौर पर backlog refinement में; business, development और testing के नज़रियों की इस मुलाक़ात को कई teams "three amigos" कहती हैं। "अगर discount code expire हो गया हो तो?" जैसा सवाल एक example बनता है, फिर acceptance criterion, फिर test।
  • छोटे feedback loops: हर change पर automated checks चलते हैं, tester हर build को deployable होते ही explore करता है, और defects उसी cycle में, अक्सर कुछ घंटों में, report, fix और retest हो जाते हैं।
  • Whole team: ISTQB एक whole-team approach बताता है, जो Extreme Programming से आई practice है, जिसमें quality के लिए सब ज़िम्मेदार हैं और ज़रूरी knowledge और skills वाला कोई भी सदस्य कोई भी काम कर सकता है। Tester business representatives, जैसे product owner, को सही acceptance tests बनाने में मदद करता है, और developers के साथ test strategy और automation approach तय करता है। ISTQB के अनुसार जहाँ ऊँची test independence चाहिए, जैसे safety-critical systems में, वहाँ यह approach उपयुक्त न भी हो।
Sequential: testing waits for a phase of its own
  requirements -> design -> build -> test phase -> release
                                     ^ first feedback on the requirement, weeks later

Agile: one story inside a two-week iteration
  Before  refinement  tester asks for examples; they become acceptance criteria
  Day 1   planning    team agrees how the story will be tested and by whom
  Day 2   build       developer writes code and component tests; tester prepares data
  Day 3   test        automated checks run on each change; tester explores the build
  Day 3   fix         defect reported, fixed and retested the same day
  Day 4   done        acceptance tests pass and join the automated regression suite

Agile testing quadrants: testing के चार हिस्से

Agile testing quadrants, जिन्हें Brian Marick ने परिभाषित किया और जिनका वर्णन Lisa Crispin व Janet Gregory की किताब Agile Testing और ISTQB Foundation syllabus v4.0 में है, उन तरह की testing का नक्शा हैं जिनकी team को ज़रूरत होती है। Business-facing tests उन terms में होते हैं जिन्हें business expert समझे, technology-facing tests code के terms में। Team को support करने वाले tests development को दिशा देते हैं; product को critique करने वाले tests उसके व्यवहार को expectations के मुक़ाबले मापते हैं।

Agile testing quadrants: business-facing या technology-facing tests, जो या तो बनाते समय team को support करते हैं या बने हुए product को critique करते हैं, हर quadrant के आम tests और उन्हें आम तौर पर चलाने के तरीके के साथ। वैचारिक मॉडल
किसकी भाषा मेंTests क्या करते हैं
Team को supportdevelopment को चलते-चलते दिशाProduct को critiqueउसके व्यवहार को expectations पर मापना
Business-facingbusiness expert की भाषाQ2 · Functional tests, examples, user story tests, UX prototypes, API tests, simulationsAcceptance criteria जाँचते हैं · manual या automatedQ3 · Exploratory, usability और user acceptance testingUser-oriented · अक्सर manual
Technology-facingcode और उसका designQ1 · Component (unit) और component integration testsDevelopers लिखते हैं · हर change पर CI में automatedQ4 · Performance, load, security और बाकी non-functional tests; smoke testsअक्सर automated · specialised tools
  • आम तौर पर automated
  • Manual या automated
  • आम तौर पर manual

Numbers सिर्फ़ quadrants के नाम हैं, काम का क्रम नहीं।

Numbers नाम हैं, काम का क्रम नहीं। Story या release plan करते समय पूछें कि change को किन quadrants की ज़रूरत है और हर quadrant कौन cover करेगा; खाली quadrant एक blind spot है।

  • Q1, technology-facing, team को support करता है: component (unit) और component integration tests, जिन्हें developers लिखते हैं और जो continuous integration (CI) में automated चलते हैं।
  • Q2, business-facing, team को support करता है: functional tests, examples, user story tests, user experience prototypes, API tests और simulations, जो acceptance criteria जाँचते हैं; manual या automated।
  • Q3, business-facing, product को critique करता है: exploratory, usability और user acceptance testing; user-oriented और अक्सर manual।
  • Q4, technology-facing, product को critique करता है: performance, load, security और usability को छोड़कर बाकी non-functional tests, साथ में ISTQB की list के smoke tests; अक्सर tools के साथ automated।

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

Worked example: एक iteration में एक story

Story: "एक shopper के रूप में, मैं checkout पर discount code लगाना चाहता हूँ, ताकि मुझे कम भुगतान करना पड़े।" Refinement में tester पूछता है: क्या एक order में दो codes लग सकते हैं? Expired code के साथ क्या होगा? क्या codes case-sensitive हैं? जवाब examples के साथ acceptance criteria बन जाते हैं, और team quadrant के हिसाब से testing plan करती है:

  • Day 3: exploration में पता चलता है कि code लगाने के बाद item हटाने पर पुराना discount बना रहता है। उसी दिन fix और retest होता है, और यह scenario उन automated Q2 checks में जुड़ जाता है जो हर change पर चलते हैं।
Story: apply a discount code at checkout

Q1  developers     unit tests: 10% of 200.00 -> 20.00
                   15% of 99.99 -> 15.00 (the agreed rounding)
Q2  tester + devs  acceptance tests from the examples, automated:
                   SAVE10 on a 200.00 SAR basket -> total 180.00 SAR
                   expired code -> rejected with the expiry message
                   second code on the same order -> rejected
Q3  tester         30-minute exploratory session: remove items after applying
                   the code, back button, two browser tabs, Arabic layout
Q4  tester + devs  many wrong codes in a row -> rate-limited (own test env only)
                   response time of code checks under campaign load

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

आम गलतियाँ

  • "Working software over comprehensive documentation" को "कोई documentation नहीं" समझ लेना। जो team को दोबारा चाहिए, वह रखें।
  • Story पूरी तरह ख़त्म होने तक testing का इंतज़ार करना, जिससे हर iteration एक छोटा waterfall बन जाता है।
  • "Whole team" को किसी एक छोर तक ले जाना: यह मान लेना कि अब testers की ज़रूरत नहीं, या यह कि quality सिर्फ़ tester की ज़िम्मेदारी है।
  • Quadrants को क्रम (पहले Q1, फिर Q2…) या ऐसा quota मान लेना जिसे हर story को भरना ही है, risk चाहे जो हो।
  • Stable checks को automate करने की बजाय हर iteration में पूरा regression suite हाथ से चलाना।

QA का नज़रिया

Agile team में tester का बहुत-सा असर execution से पहले होता है: refinement और planning में हर story के examples, edge cases और risk पूछें, और जब कोई story जैसी लिखी है वैसे टेस्ट न हो सके तो साफ़ कहें। Iteration के दौरान पूरी story की बजाय पहला deployable build टेस्ट करें, और findings रोज़ की बातचीत में बताएँ।

जो team को दोबारा चाहिए वह record करें: examples, exploratory session notes, नए automated checks और खुले risks। उसी दिन fix होने वाले defects अक्सर बातचीत से निपट जाते हैं; जो defer हों या बाद में मिलें, वे tracker में जाते हैं। Retrospective में process की problems उठाएँ, जैसे stories का आख़िरी दिन testing तक पहुँचना।

अभ्यास

Reorder story की testing plan करें

आपका काम

आप इस story के refinement में tester हैं, कोई code बनने से पहले: "एक registered customer के रूप में, मैं पिछला order एक tap में दोबारा देना चाहता हूँ, ताकि अपनी रोज़ की groceries जल्दी खरीद सकूँ।" Draft acceptance criteria: history में हर delivered order पर "Reorder" button है, जो उसके सारे items आज की कीमतों पर cart में जोड़ देता है।

चरण
  1. चार सवाल लिखें जिनका जवाब draft criteria में नहीं है।
  2. हर quadrant के लिए एक या ज़्यादा test ideas लिखें, और यह कि हर idea कौन करेगा।
  3. चिह्नित करें कि कौन-से ideas automate करेंगे और कौन-से manual रहेंगे।
  4. Planning का एक ऐसा agreement बताएँ जो testing को आख़िरी दिन पर जमा होने से रोके।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

सवाल: जो item out of stock है या अब बिकता नहीं, उसका क्या होगा? क्या items पहले से भरे cart में जुड़ेंगे या cart बदल जाएगा? क्या promoted items पर quantity limits लागू होंगी? क्या cancelled या returned orders को reorder किया जा सकता है?

Q1 (developers): order lines को cart में copy करने के unit tests। Q2 (tester और developers): examples से acceptance tests, जैसे 3 ordered items आज की कीमतों पर वही 3 items देते हैं, या एक discontinued item होने पर 2 items और उसका नाम बताने वाला message।

Q3 (tester): बहुत पुराने order को explore करना, एक साथ दो devices, और out-of-stock message को Arabic और English में जाँचना। Q4 (tester और developers): बड़े order का response time, और team के अपने test environment पर यह check कि order id बदलकर किसी दूसरे customer का order reorder नहीं होता।

Q1, Q2 और order-id check automate करें, क्योंकि इन्हें हर change पर चलना है; Q3 manual रखें; Q4 का response-time check release से पहले tool से चलाएँ। Planning में तय करें कि reorder का basic path पहले deploy हो, ताकि testing day 2 या 3 पर शुरू हो सके।

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

क्या Agile और Scrum एक ही हैं?

नहीं। Agile, Agile Manifesto की values और principles का नाम है। Scrum उन्हें लागू करने वाला एक framework है, जिसकी अपनी accountabilities, events और artifacts हैं; Kanban और Extreme Programming (XP) दूसरे approaches हैं जिन्हें agile teams इस्तेमाल करती हैं। अगले lessons Scrum और Kanban को tester की नज़र से समझाते हैं।

अगर quality पूरी team का काम है, तो क्या agile teams को अब भी testers चाहिए?

Whole-team approach का मतलब है कि quality की ज़िम्मेदारी सब साझा करते हैं, यह नहीं कि testing skills की अहमियत ख़त्म हो गई। कई agile teams में testing के specialists होते हैं जो tests design करते हैं, explore करते हैं, दूसरों को coach करते हैं और blind spots की ओर ध्यान दिलाते हैं। Safety-critical systems जैसे कुछ contexts में ज़्यादा independent testing भी ज़रूरी होती है।

क्या हर story के लिए चारों quadrants में tests चाहिए?

नहीं। Quadrants सोचने का tool हैं, quota नहीं। छोटे text change को शायद सिर्फ़ एक Q2 check और एक नज़र चाहिए; नए payment flow को चारों की ज़रूरत हो सकती है। फ़ैसला risk से करें, और quadrants से पक्का करें कि फ़ैसला सोच-समझकर लिया गया, भूल से नहीं।

संदर्भ

  • Manifesto for Agile Software DevelopmentThe Agile Manifesto authors · 2001agile software development के चार मूल्य, जैसे विस्तृत documentation से ऊपर चलता हुआ software, और योजना पर चलने से ऊपर बदलाव का जवाब देना।
  • 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एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
  • Principles behind the Agile ManifestoThe Agile Manifesto authors · 2001manifesto के पीछे के बारह सिद्धांत, जिनमें चलता हुआ software प्रगति का मुख्य पैमाना होना और ऐसी गति शामिल है जिसे टीम लगातार बनाए रख सके।
टूल्स

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

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

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

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

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

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

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

और गहराई से

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

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

इस topic से पहले