मॉड्यूल 1 · Software और QA की बुनियाद

टेस्टिंग रोल्स और ज़िम्मेदारियाँ

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

Testing कई activities का समूह है — test planning, test monitoring और control, test analysis, test design, test implementation, test execution और test completion — और हर activity के लिए किसी को ज़िम्मेदार होना चाहिए। ISTQB Foundation syllabus v4.0 दो मुख्य roles बताता है: test management role, जो test process, test टीम और test activities के नेतृत्व के लिए कुल मिलाकर ज़िम्मेदार है, और testing role, जो testing के engineering यानी technical पक्ष के लिए कुल मिलाकर ज़िम्मेदार है।

जैसा "सॉफ़्टवेयर कैसे बनता है" वाले पाठ में दिखा, role ज़िम्मेदारियों का एक सेट है, job title नहीं। छोटी टीम में एक ही QA engineer सोमवार को test plan लिख सकता है (test management role) और बाक़ी sprint में tests design करके चला सकता है (testing role)।

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

जब ज़िम्मेदारियाँ साफ़ नहीं होतीं, तो काम बीच में ही छूट जाता है: कोई तय नहीं करता कि testing कब पूरी हुई, test environment किसी का नहीं होता, और कोई risky बदलाव ship हो जाता है क्योंकि सबने मान लिया कि किसी और ने उसे टेस्ट कर लिया है। उल्टी सोच भी उतनी ही नुक़सानदेह है: अगर quality सिर्फ़ tester की ज़िम्मेदारी है, तो testing देर से आने वाला आख़िरी gate बन जाती है और छूटे हर bug का दोष एक व्यक्ति पर आता है।

Roles से job adverts भी समझ आते हैं। Titles कंपनी-दर-कंपनी बदलते हैं, पर उनके पीछे की activities नहीं, इसलिए activities जानकर आप समझते हैं कि किसी नौकरी में असल में क्या काम है और testing role से test leadership की ओर कैसे बढ़ें।

ISTQB v4.0 के दो roles

Test management role का मुख्य फ़ोकस test planning, test monitoring और control, और test completion पर है। यह तय करता है कि testing को क्या हासिल करना है, scope में क्या है, उसे कितना effort मिलेगा, progress कैसे track होगी और testing कब रुक सकती है; और monitoring व control के ज़रिए बाक़ी activities पर नज़र रखता है। Agile टीमों में इनमें से कुछ tasks टीम ख़ुद संभाल सकती है; कई टीमों में फैला काम टीम के बाहर के test manager के पास हो सकता है।

Testing role का मुख्य फ़ोकस test analysis, test design, test implementation और test execution पर है: test basis को tests में बदलने, उन्हें चलाने और जो मिले उसे report करने का hands-on काम।

Tasks का बँटवारा project और product के context, लोगों की skills और organisation पर निर्भर करता है। Test management role कोई team leader, test manager या development manager निभा सकता है, और एक ही व्यक्ति एक साथ दोनों roles निभा सकता है।

Test management role planning, monitoring और control, और completion का नेतृत्व करता है; testing role analysis, design, implementation और execution का; developers और business कई activities में योगदान देते हैं। वैचारिक मॉडल
Test activityTest management roletest manager, test lead, team leadTesting roletester, QA engineer, SDETDevelopersProduct owner और business
Test planningनेतृत्वscope, approach, exit criteriaयोगदानestimates, risks, data और environment की ज़रूरतेंयोगदानestimates, technical risksयोगदानpriorities, approach पर सहमति
Test monitoring और controlनेतृत्वplan के मुक़ाबले progress, control फ़ैसलेयोगदानprogress, blockers, खुले defectsयहाँ कोई मुख्य काम नहींयोगदानscope बदलाव पर सहमति
Test analysisदेखरेखनेतृत्वtest basis से test conditionsयहाँ कोई मुख्य काम नहींयोगदानtest basis स्पष्ट करना
Test designदेखरेखनेतृत्वtest cases और test dataयोगदानtest cases का reviewयोगदानtesters के साथ acceptance tests
Test implementationदेखरेखनेतृत्वprocedures, suites, environment की तैयारीयोगदानtest environment setupयहाँ कोई मुख्य काम नहीं
Test executionदेखरेखनेतृत्वtests चलाना, defects report करना, retestयोगदानcomponent testsयोगदानacceptance testing
Test completionनेतृत्वcompletion report, lessons learnedयोगदानtestware archive, regression suite updateयहाँ कोई मुख्य काम नहींयहाँ कोई मुख्य काम नहीं

यह आम बँटवारा है, नियम नहीं: ISTQB कहता है कि tasks context पर निर्भर करते हैं, और एक व्यक्ति दोनों roles निभा सकता है।

Lifecycle भर में tester की ज़िम्मेदारियाँ

Tester का काम चलाने लायक software बनने से पहले शुरू होता है और आख़िरी test के बाद ख़त्म होता है। एक release के दौरान tester आम तौर पर testing role की hands-on activities का नेतृत्व करता है और बाक़ी में योगदान देता है:

  • Backlog refinement: code लिखे जाने से पहले user stories और acceptance criteria में gaps, ambiguity और testability की जाँच करना।
  • Planning: estimates, risks, और test data व environment की ज़रूरतें जोड़ना, भले ही plan किसी और का हो।
  • Analysis और design: test basis से test conditions निकालना और ऐसे test cases design करना जो requirements तक trace हों।
  • Implementation: test data, procedures और suites तैयार करना, और जाँचना कि test environment तैयार है।
  • Execution: tests चलाना, defects report करना, और fixes के बाद confirmation testing और regression testing करना।
  • Monitoring और completion: progress और blockers ईमानदारी से report करना, testware archive करना, regression suite update करना और lessons learned दर्ज करना।

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

Job titles और roles से उनका संबंध

Job titles employer तय करते हैं, ISTQB नहीं, इसलिए एक ही title का दो कंपनियों में अलग काम हो सकता है। Job description को इस सवाल से पढ़ें: यह कौन-सी activities कवर करती है? आम patterns:

  • QA engineer, QA analyst या software tester: मुख्य रूप से testing role, अक्सर कुछ API testing या automation के साथ।
  • SDET (software development engineer in test) या test automation engineer: engineering फ़ोकस वाला testing role — automated tests, frameworks और tooling, जो developers के साथ codebase और CI (continuous integration) pipeline में बनते हैं।
  • Test lead या QA lead: आम तौर पर एक टीम या project के लिए दोनों roles — testing की planning और coordination, काम बाँटना, status report करना, और ख़ुद भी hands-on testing।
  • Test manager या QA manager: कई टीमों या projects के स्तर पर test management role — strategy, staffing, coaching, budget, और management को quality व risk की रिपोर्ट।

Quality पूरी टीम की ज़िम्मेदारी

ISTQB whole-team approach बताता है, जो Extreme Programming से आई practice है: ज़रूरी knowledge और skills वाला टीम का कोई भी सदस्य कोई भी task कर सकता है, और quality की ज़िम्मेदारी सबकी है। Testers business representatives को उपयुक्त acceptance tests बनाने में मदद करते हैं, और developers के साथ test strategy और automation approach तय करते हैं। 2020 Scrum Guide, Scrum Team में तीन accountabilities तय करता है — Product Owner, Scrum Master और Developers — और अलग tester का कोई ज़िक्र नहीं करता: Scrum Team के testers Developers ही गिने जाते हैं।

साझा ज़िम्मेदारी का मतलब ज़िम्मेदारी का न होना नहीं है। Developers आम तौर पर component (unit) testing करते हैं, acceptance testing आदर्श रूप से intended users करते हैं, acceptance criteria और priorities product owner के पास होती हैं, और tester test design, risk की नज़र और सबूत लाता है। यह approach हर context में फ़िट नहीं होता: जैसे safety-critical systems को test independence के ऊँचे स्तर की ज़रूरत हो सकती है। Quality culture वाला पाठ इसमें और गहराई से जाता है।

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

Worked example: एक feature, हर activity का एक owner

एक टीम किसी clinic के लिए online appointment booking बना रही है। टीम में एक product owner, तीन developers, एक QA engineer और टीम का नेतृत्व करने वाला एक engineering manager है। किसी का title test manager नहीं, फिर भी हर activity का owner है:

  • Planning: QA engineer एक पेज का test approach लिखता है, जिसमें मुख्य risks (दो मरीज़ों का एक ही slot book करना, SMS का कभी न जाना) और exit criteria हैं — यही test management role है। Engineering manager इस पर product owner से सहमति लेता है।
  • Analysis और design: QA engineer पूछता है कि अगर doctor bookings वाला दिन cancel करे तो क्या होगा, और product owner का जवाब एक acceptance criterion बन जाता है। एक developer QA engineer के test cases का review करता है।
  • Implementation और execution: developers slot-locking logic के component tests CI में चलाते हैं। QA engineer test environment में doctors और schedules तैयार करता है, system tests चलाता है, double-booking defect report करता है और fix के बाद retest करता है।
  • Monitoring और control: खुला defect daily meeting में report होता है, और engineering manager व product owner कम priority वाली एक story अगले sprint में भेज देते हैं।
  • Completion: product owner feature को उसके criteria के आधार पर accept करता है, और QA engineer double-booking test को regression suite में जोड़ता है।

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

आम गलतियाँ

  • Job title को role समझ लेना: मान लेना कि QA engineer कभी planning नहीं करता या test manager कभी test नहीं करता। Title नहीं, duties पढ़ें।
  • यह मानना कि quality सिर्फ़ tester की है, जिससे code बिना टेस्ट हुए testing तक पहुँचता है और हर छूटे defect का दोष tester पर आता है।
  • पूरी टीम की ज़िम्मेदारी को किसी की भी ज़िम्मेदारी नहीं समझना: हर कोई थोड़ा-थोड़ा टेस्ट करता है, पर plan, exit criteria या regression suite किसी का नहीं होता।
  • टीम में test manager नहीं है, इसलिए test management के tasks छोड़ देना: न तय scope, न exit criteria, न completion report।
  • सिर्फ़ test execution के समय जुड़ना, बजाय शुरुआत से requirements review करने और planning में योगदान देने के।
  • यह सोचना कि SDET सिर्फ़ code लिखता है: automated tests उतने ही अच्छे होते हैं जितना उनके पीछे का test analysis और test design।

QA का नज़रिया

नई टीम में पता करें कि test management role कौन निभा रहा है, भले ही किसी के पास यह title न हो। पूछें: scope कौन तय करता है? Exit criteria पर सहमति कौन देता है? Test environment और test data किसके हैं? Known defects के साथ release जाए या नहीं, यह कौन तय करता है? अगर जवाब "कोई नहीं" या "सिर्फ़ tester" है, तो यह मुद्दा पहली release से पहले उठाएँ, बाद में नहीं।

Test plan या टीम के working agreement में हर activity का owner लिखें। Report करते समय तथ्यों और फ़ैसलों को अलग रखें: आप quality और risk की जानकारी देते हैं, और release का फ़ैसला product के लिए जवाबदेह लोगों का है, जैसे product owner।

अभ्यास

छोटी टीम में test activities बाँटें

आपका काम

एक टीम दो sprints की release शुरू कर रही है, जो एक accounting web app में Arabic PDF invoices जोड़ती है। टीम में एक product owner, एक team lead जो development भी करता है, दो developers और एक QA engineer हैं, और कोई test manager नहीं। पिछली release में किसी ने तय नहीं किया कि testing कब पूरी हुई, और test environment में आख़िरी दिन तक Arabic fonts नहीं थे।

हर test activity के लिए लिखें कि उसका नेतृत्व कौन करता है और कौन योगदान देता है। फिर दोनों पुरानी समस्याओं को एक-एक owner दें।

चरण
  1. सातों test activities को ISTQB के क्रम में लिखें।
  2. हर activity के लिए लिखें कि नेतृत्व कौन करता है और योगदान कौन देता है।
  3. हर activity को test management role या testing role में रखें।
  4. हर पुरानी समस्या को उसकी activity से जोड़ें और owner का नाम लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

ISTQB के क्रम में सात activities: test planning, test monitoring और control, test analysis, test design, test implementation, test execution और test completion।

Test planning, monitoring और control, और completion (test management role): नेतृत्व QA engineer का, जो test approach, exit criteria और completion summary का draft बनाता है; team lead और product owner इन पर सहमति देते हैं और story खिसकाने जैसे control फ़ैसले लेते हैं; developers estimates और PDF में right-to-left layout जैसे risks जोड़ते हैं।

Test analysis, design, implementation और execution (testing role): नेतृत्व QA engineer का; product owner invoice के नियम स्पष्ट करता है और sample invoices को acceptance criteria से जाँचता है; एक developer test cases का review करता है; developers CI में component tests चलाते हैं।

पुरानी समस्या 1: testing कब पूरी हुई, यह exit criteria तय करते हैं, जो test planning का हिस्सा हैं; owner: QA engineer, जो उनका draft बनाता है ताकि team lead और product owner पहले sprint की शुरुआत से पहले उन पर सहमति दें। पुरानी समस्या 2: environment की तैयारी test implementation का हिस्सा है, इसलिए एक नामित developer पहले sprint में Arabic fonts install करता है और QA engineer execution से पहले तैयारी जाँचता है। कोई और बँटवारा भी ठीक है, बशर्ते हर activity का एक नामित owner हो।

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

क्या QA engineer और tester एक ही हैं?

कई job adverts में हाँ: काम मुख्य रूप से testing role का होता है, जैसा QA, QC और testing वाले पाठ में बताया गया। कुछ कंपनियाँ यह title बड़े काम के लिए इस्तेमाल करती हैं, जैसे process सुधारना या release से पहले के quality gates संभालना। ज़िम्मेदारियाँ पढ़ें।

Test lead और test manager में क्या अंतर है?

Titles बदलते रहते हैं, पर test lead आम तौर पर एक टीम या project की testing coordinate करता है और ख़ुद भी hands-on testing करता है, जबकि test manager कई टीमों या projects के स्तर पर test management role निभाता है और लोगों, budget और strategy को भी संभालता है। ISTQB की भाषा में दोनों test management role निभाते हैं, बस अलग-अलग पैमाने पर।

क्या whole-team approach का मतलब है कि testers की ज़रूरत नहीं?

नहीं। इसका मतलब है कि quality की ज़िम्मेदारी सब साझा करते हैं, यह नहीं कि testing skills की ज़रूरत ख़त्म हो गई। Testers test design, risk analysis और एक स्वतंत्र नज़र लाते हैं, और testing का ज्ञान बाक़ी टीम तक पहुँचाते हैं। ISTQB यह भी कहता है कि safety-critical systems जैसे कुछ contexts में test independence का ऊँचा स्तर चाहिए।

क्या एक व्यक्ति दोनों roles निभा सकता है?

हाँ। ISTQB syllabus साफ़ कहता है कि एक व्यक्ति एक साथ testing role और test management role निभा सकता है। जब टीम में एक ही tester हो, तो यह आम बात है।

संदर्भ

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

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

Requirements → टेस्ट केस

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

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

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

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

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

और गहराई से

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

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