मॉड्यूल 25 · प्रोफ़ेशनल QA और टेस्ट मैनेजमेंट

टेस्ट मैनेजमेंट और टूल्स

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

Test management testing का वह हिस्सा है जो काम plan करता है, उसकी progress पर नज़र रखता है, हक़ीक़त plan से हटे तो उसे सही दिशा देता है और अंत में report के साथ उसे बंद करता है। ISTQB Foundation syllabus v4.0 के अनुसार test management role मुख्य रूप से test process की तीन activities पर केंद्रित है: test planning, test monitoring और control, और test completion। Test management tool वह software है जिसमें इन activities के records रहते हैं: test cases, plans, runs और results, जो requirements और defects से linked होते हैं।

उदाहरण: तीन testers एक clinic booking app पर काम करते हैं, जिसकी हर महीने नई release आती है। उनके tool में हर release का एक plan है, हर build का एक run, failed step से issue tracker में linked defect खुलता है, और release के दिन lead एक report पढ़ता है जो हर user story के लिए उसके tests के latest results और उसके open defects दिखाती है। Traceability और QA documentation वाले lessons ने तय किया कि क्या record करना है; यह lesson दिखाता है कि वे records कहाँ रहते हैं और tool उन्हें जवाबों में कैसे बदलता है।

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

Shared record के बिना test management तभी बिखर जाता है जब टीम में कई testers हों या release के कई builds हों। Results निजी spreadsheets में पड़े रहते हैं, कोई नहीं बता पाता कि कोई "pass" किस build का है, status reports जोड़ने में घंटों लगते हैं और भेजे जाने तक पुरानी हो जाती हैं, और release meeting risks की जगह numbers पर बहस करती है।

Tool कमज़ोर process को ठीक नहीं करता, लेकिन ठीक से set up किया गया tool process को दिखने लायक बनाता है: progress, coverage और blockers कभी भी पढ़े जा सकते हैं, लोगों के जाने के बाद भी history बची रहती है, और auditor देख सकता है कि किसने किस build पर क्या चलाया। बुरी तरह set up किया गया tool spreadsheet से भी बुरा हो सकता है, क्योंकि पुराने cases और unmapped results भरोसेमंद दिखने वाले लेकिन गलत dashboards बनाते हैं। Tool अपने जवाब कैसे निकालता है, यह जानना tester के काम का हिस्सा है।

Test management activities और हर एक के लिए tool क्या record करता है

ISTQB की भाषा में test management एक role है, job title नहीं: यह test process की overall ज़िम्मेदारी लेता है और उन तीन activities पर ध्यान देता है जो analysis, design, implementation और execution को घेरती हैं। ISO/IEC/IEEE 29119-2 इन्हीं तीन को अपने test management processes में रखता है। Agile टीमों में इनमें से कुछ tasks टीम खुद संभालती है।

दो सहायक disciplines तीनों activities के काम आती हैं। Configuration management testware और test items को पहचानता और version करता है, ताकि हर result अपना exact build और environment बताए और हर test case की history हो; testing के लिए approve हुआ item baseline बन जाता है, जो सिर्फ़ change control से बदलता है। Defect management हर reported anomaly को एक तय workflow से खोज से closure तक ले जाता है। हर activity, और tool उसके लिए क्या record करता है:

  • Test planning: objectives, scope, approach, entry और exit criteria, resources और schedule तय करना। Tool में: हर release का plan, scope में शामिल suites और requirements, cycles और assignments।
  • Test monitoring: plan से progress की तुलना करने और exit criteria जाँचने के लिए लगातार जानकारी जुटाना। Tool में: results की live counts, हर requirement की coverage और linked defects।
  • Test control: monitoring जो दिखाए उस पर कदम उठाना। Syllabus के उदाहरण: कोई risk असली issue बन जाए तो tests की priority बदलना, rework के बाद entry या exit criteria दोबारा जाँचना, environment देर से आए तो schedule बदलना, और जब और जहाँ ज़रूरत हो वहाँ resources जोड़ना। Tool में: बदली हुई priorities, दोबारा assign हुए tests, नए build के लिए नया run।
  • Test completion: release या iteration के अंत जैसे milestone पर results समेटना, काम का testware archive करना या सौंपना, lessons learned दर्ज करना और test completion report लिखना। Tool में: closed cycle, final report का export, आगे ले जाए गए open defects।

Test management tool क्या करता है, product चाहे कोई भी हो

Syllabus management tools को testing के tool support के प्रकारों में गिनता है: ये SDLC, requirements, tests, defects और configuration को manage करने में मदद करके test process को ज़्यादा efficient बनाते हैं। यह spreadsheet को भी test tool मानता है। Products के नाम और screens अलग होते हैं, और यह lesson किसी की सिफ़ारिश नहीं करता; brands की जगह capabilities देखें।

Feature list से नहीं, अपने process से चुनें: लिखें कि टीम कैसे plan, run, link और report करती है, stakeholders को सच में कौन-सी reports चाहिए उनकी list बनाएँ, और tools की छोटी list को एक असली release पर आज़माएँ। जिन capabilities को देखना है:

  • Test repository: ids, preconditions, steps, expected results, priority और owner वाले test cases, suites में grouped, shared steps, parameters और version history के साथ।
  • Planning और execution: हर release के plans या cycles, हर build और environment के runs, testers को assignment, और evidence attach करके step-by-step results।
  • Integrations: requirements और defects आम तौर पर टीम के issue tracker में रहते हैं और copy नहीं, link किए जाते हैं; automated results CI से आते हैं, अक्सर JUnit XML report के रूप में, और test cases से map किए जाते हैं।
  • Traceability और reporting: requirements, tests, results और defects के बीच links, और उनसे निकलने वाली progress, coverage और defect reports।
  • Administration: roles और permissions, किसने क्या बदला या execute किया इसका audit trail, custom fields और review workflows, import, export और API।
पाँच layers में test management set-up: नीचे जुड़े हुए sources, फिर test repository, plans और runs, traceability links, और सबसे ऊपर नीचे की हर चीज़ से निकली reports।

हर layer अपने नीचे के records से बनती है

  1. 1Reports और dashboardsStakeholders पढ़ते हैंProgress, हर requirement की coverage, status के हिसाब से defects, completion report का export

    नीचे की layers जितनी ही सही

  2. 2Traceability linksRequirement, test case, result और defect, हर record के fields से linked

    Tests लिखते समय दर्ज, release से ठीक पहले नहीं

  3. 3Plans, cycles और runsहर release का plan, हर build और environment का run, evidence के साथ step results

    हर build के लिए नया run

  4. 4Test repositoryIds, steps, expected results और version history वाले test cases और suites

    Product के साथ बदलती है

  5. 5जुड़े हुए sourcesIssue tracker (requirements, defects), CI pipeline (JUnit XML में automated results), build versions

    Link होते हैं, copy नहीं

Generic capabilities: products में नाम और screens अलग होते हैं, और किसी product की ओर इशारा नहीं है। Ids, statuses, fields और permissions की conventions पहले import से पहले तय होती हैं।

आज़माएँ: XML फ़ॉर्मेटर आज़माएँ: JSON से CSV

Tool में traceability और reporting

Requirements traceability वाले lesson में links एक matrix में थे। Tool में हर link किसी record का field है: test case बताता है कि वह कौन-सी story या requirement cover करता है, result एक run का हिस्सा है जो अपना build और environment बताता है, और defect failed result से linked है। Matrix एक report बन जाती है जिसे tool बनाता है, और कोई result दर्ज होते ही वह current हो जाती है।

हर report इन records पर चलने वाली query है, इसलिए present करने से पहले उसके पीछे के rules जानें और टीम के साथ तय करें। Execution reporting वाले lesson के counting rules अब भी लागू हैं:

  • Scope: कौन-सी release, कौन-सा build और कौन-सा environment। पिछले हफ़्ते के build पर pass आज के build के बारे में कम ही बताता है।
  • Latest result: scope में कोई test कई बार चला हो तो आम तौर पर latest result गिना जाता है; उसी build पर fail के बाद pass जाँच का सवाल है, pass नहीं।
  • Requirement status rule: जैसे, passed तभी जब हर linked test scope में pass हुआ हो और Major या उससे ऊँची severity का कोई linked defect open न हो; not covered जब कुछ भी linked न हो।
  • Mapping: automated results तभी गिने जाते हैं जब वे test cases से map हों; unmapped results coverage में दिखते ही नहीं।
  • Export: dashboard के पीछे का data, जैसे CSV में, completion report और audits के लिए रखें।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: CSV को PDF में बदलें

Worked example: release coverage report पढ़ना

Sahl Clinics (काल्पनिक) एक appointment booking app है। Release 4.2 में पाँच user stories और उनसे linked 38 test cases हैं। ज़्यादातर staging पर manually चलते हैं; API tests automated हैं, और उनके JUnit XML results CI से import होकर अपने test cases से map होते हैं। Go/no-go meeting की सुबह lead release candidate की coverage report export करता है:

  • ऊपर दिखने वाला pass rate 97% है (34 executed में से 33 passed), फिर भी सिर्फ़ BK-101 तैयार है। Total से नहीं, story के हिसाब से पढ़ें।
  • BK-104 का कोई linked test नहीं। या तो tests हैं पर कभी link नहीं हुए (repository और कोई unmapped CI results हों तो उनमें खोजें), या SMS reminder कभी test ही नहीं हुआ। यह बात सिर्फ़ links से निकली coverage दिखाती है।
  • BK-102 failed है और D-311 open है: triage और product owner तय करते हैं कि अगले build पर fix करके confirm करें या accepted और दर्ज risk के साथ release करें।
  • BK-103, D-308 की वजह से blocked है। Blocked का मतलब test नहीं हुआ: अनजाना risk, कभी pass नहीं।
  • BK-105 का एक test नहीं चला: आज चलाएँ या न चलाने की वजह दर्ज करें।
  • Control actions भी tool में जाते हैं: नए assignments और उसी suite से rc4 का run, ताकि rc3 के results record के रूप में बने रहें। Final export test completion report का appendix बनता है।
Requirements coverage: release 4.2, build 4.2.0-rc3, staging
Counting: latest result of each test in this scope
Story status: Passed = every linked test passed and no linked defect
              of severity Major or higher is open

Story   Summary              Tests  Pass  Fail  Blocked  Not run  Defects  Status
BK-101  Book an appointment  12     12    0     0        0        -        Passed
BK-102  Free cancellation    8      6     1     0        1        D-311    Failed
BK-103  Reschedule           6      4     0     2        0        D-308    Blocked
BK-104  SMS reminder         0      -     -     -        -        -        Not covered
BK-105  Staff calendar view  12     11    0     0        1        -        In progress
Total                        38     33    1     2        2

आज़माएँ: प्रतिशत कैलकुलेटर

आम गलतियाँ

  • टीम के process पर सहमति से पहले tool set up करना: ids, statuses, fields और ज़रूरी reports। फिर tool ऐसा workflow थोपता है जिसे कोई नहीं मानता।
  • पुरानी spreadsheets के सारे cases बिना review import कर देना, जिससे repository शुरू से ही duplicates और हटाए गए features के tests से भरी होती है।
  • Tracker से link करने की जगह requirements और defects को test tool में copy करना, जिससे सच के दो versions बन जाते हैं।
  • Automated tests को unmapped छोड़ देना, जिससे coverage reports असल में चलने वाली ज़्यादातर testing को नज़रअंदाज़ करती हैं।
  • Scope और counting rule जाने बिना dashboard present करना: पुराने builds के results, pass rate में छिपे blocked tests, और ऐसा rerun जो failure को pass बना दे।
  • Tool को ही test management मान लेना। Tool plans और decisions record करता है; scope, priorities और release risk तय करना अब भी लोगों का काम है।

QA का नज़रिया

कई टीमों में tester ही tool का रोज़ का user होता है और अक्सर उसका अनौपचारिक administrator भी। Conventions जल्दी तय करें और एक पेज पर लिखें: requirements और defects कहाँ रहते हैं, id format, कौन-से statuses हैं और हर एक का मतलब क्या है, automated tests के नाम या tags कैसे रखें ताकि वे test cases से map हों, और approved case कौन बदल सकता है। Retrospectives में इन्हें review करें।

Tool को numbers बनाने के लिए नहीं, सवालों के जवाब के लिए इस्तेमाल करें। Status meeting से पहले report का scope और rule जाँचें, उसे requirement के हिसाब से पढ़ें, और वे दो-तीन decisions साथ लाएँ जो वह दिखाती है। पक्का करें कि किस build पर क्या test हुआ उसकी history export हो सके: वह product की है, vendor की नहीं।

अभ्यास

Tool के raw records से release status निकालें

आपका काम

एक library app version 3.1 release करने वाला है। Test tool में target build 3.1.0-rc2 के लिए नीचे के records हैं। दिए गए rule के साथ हर story का status वैसे निकालें जैसे tool निकालेगा, और वह headline pass rate भी जो dashboard दिखाएगा।

फिर पता करें कि यह computed view क्या छिपाता है, अपने control actions लिखें, और go/no-go meeting के लिए हर story का एक-line status लिखें।

सामग्री
Library app, release 3.1. Target build: 3.1.0-rc2 on staging.
Rule: a story passes when every linked test passed on rc2 (latest result
counts) and no linked defect of severity Major or higher is open.

Stories: LIB-11 Borrow a book    LIB-12 Reserve a book
         LIB-13 Renew a loan     LIB-14 Pay an overdue fine

Results in the order they were recorded:
#  Test                    Story   Build  Result   Note
1  TC-01                   LIB-11  rc1    passed
2  TC-02                   LIB-11  rc1    failed   D-77 (Major) raised
3  TC-01                   LIB-11  rc2    passed
4  TC-02                   LIB-11  rc2    passed   D-77 fix confirmed
5  TC-03                   LIB-12  rc1    passed
6  TC-04                   LIB-12  rc2    blocked  D-80 (Major) open
7  TC-05                   LIB-13  rc2    failed   D-81 (Critical) open
8  TC-05                   LIB-13  rc2    passed   rerun on the same build
9  api/renew-overdue-loan  -       rc2    failed   automated (CI), not mapped
चरण
  1. हर linked test का rc2 पर सिर्फ़ latest result रखें; जिस test का rc2 पर कोई result नहीं, वह not run है।
  2. हर story पर rule लगाएँ, उसके linked defects समेत, और dashboard का headline pass rate निकालें।
  3. लिखें कि computed view क्या छिपाता है या कहाँ गलत है: scope, reruns, unmapped results, बिना tests वाली stories।
  4. Control actions और go/no-go meeting के लिए हर story का एक-line status लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

rc2 पर latest results: TC-01 passed, TC-02 passed, TC-04 blocked, TC-05 passed (rerun), TC-03 not run (उसका pass rc1 पर था)। Dashboard दिखाता है: 3 executed में से 3 passed, यानी 100% pass rate, साथ में 1 blocked और 1 not run। Failed automated test इसमें नहीं है क्योंकि वह map नहीं हुआ।

Story के हिसाब से: LIB-11 passed, बशर्ते D-77 tracker में close हो (वरना rule को अब भी एक open Major defect दिखेगा)। LIB-12 passed नहीं: TC-03 rc2 पर नहीं चला और TC-04, D-80 की वजह से blocked है। LIB-13 failed: D-81 (Critical) open है, latest result कुछ भी कहे। LIB-14 not covered: कोई linked test नहीं। 100% pass rate के पीछे चार में से सिर्फ़ एक story तैयार है।

Tool का view क्या छिपाता है: "सारे builds" वाले scope की report TC-03 को passed गिनेगी; "latest result गिना जाए" वाला rule उसी build पर TC-05 के fail के बाद pass को pass बना देता है, जो intermittent defect या flaky test की ओर इशारा है; CI का failure map होने तक दिखता ही नहीं; और LIB-14 कोई चिंता नहीं दिखाती जब तक report बिना tests वाली stories की list न दे।

Control actions: पक्का करें कि fix confirm होने के बाद D-77 tracker में close हो चुका है; TC-03 को rc2 पर चलाएँ; D-80 पर triage से decision माँगें; D-81 reproduce करें, और TC-05 के pass पर भरोसा करने से पहले उसके fail-pass पलटने की जाँच करें; api/renew-overdue-loan को map करें (उसका नाम LIB-13 की ओर इशारा करता है, उसके author से पक्का करें); LIB-14 के लिए tests लिखें, जैसे Requirements → Test Cases tool से, या test न करने की वजह दर्ज करें; और report का scope rc2 पर सेट करें।

Meeting के लिए status: "LIB-11 तैयार। LIB-12 rc2 पर test नहीं हुई, D-80 से blocked। LIB-13 failing, Critical D-81 open। LIB-14 untested। सिफ़ारिश: तैयार नहीं; D-80, D-81 और LIB-14 की coverage पर decisions चाहिए।"

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

क्या अलग test management tool चाहिए, या spreadsheet काफ़ी है?

एक tester और छोटे product के लिए spreadsheet काफ़ी हो सकती है, और ISTQB syllabus उसे test tool मानता है। मुश्किल तब आती है जब कई लोग एक साथ execute करें, और जब हर build की result history, requirements और defects से current रहने वाले links और audit trail चाहिए। जब reports हाथ से जोड़ने की लागत या history खोने का risk tool की लागत से ज़्यादा हो जाए, तब tool पर जाएँ।

Test management issue tracker के अंदर हो या अलग tool में?

दोनों set-ups आम हैं। Requirements और defects को टीम के tracker में रखकर tests को उनसे link करने से copies नहीं बनतीं, चाहे tests tracker के add-on में रहें या अलग tool में। फ़ैसला ज़रूरी integrations और reports के आधार पर करें, screens कहाँ हैं इस पर नहीं।

सबसे अच्छा test management tool कौन-सा है?

कोई एक tool सबके लिए सबसे अच्छा नहीं, और यह lesson किसी की सिफ़ारिश नहीं करता। Products की तुलना अपने process, stakeholders की ज़रूरी reports, tracker और CI से integration, permissions और audit की ज़रूरतों, लागत और export से करें, फिर असली release पर pilot के बाद तय करें। ISTQB Foundation syllabus test automation tools के लिए जिन risks की चेतावनी देता है वे यहाँ भी लागू हैं: अवास्तविक उम्मीदें, tool लाने और maintain करने की मेहनत का कम अनुमान, और ऐसे vendor पर निर्भरता जो tool बंद कर दे, बेच दे या कमज़ोर support दे।

क्या test management सिर्फ़ test manager का काम है?

नहीं। ISTQB test management को एक role मानता है जिसके tasks context पर निर्भर करते हैं, और agile टीमों में कुछ tasks टीम खुद संभालती है। Tester progress monitor करता है, control की ज़रूरत उठाता है और test completion में योगदान देता है, title हो या न हो।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021टेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
  • Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
टूल्स

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

Requirements → टेस्ट केस

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

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

प्रतिशत कैलकुलेटर

प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।

यूटिलिटीज़

XML फ़ॉर्मेटर

XML को मनचाहे इंडेंटेशन के साथ प्रिटी-प्रिंट करें और वापस मिनिफ़ाई भी करें।

फ़ॉर्मेटिंग

JSON से CSV

JSON ऑब्जेक्ट के ऐरे को CSV में बदलें, नेस्टेड कीज़ को समतल करते हुए।

JSON और डेटा

CSV को PDF में बदलें

CSV और TSV फ़ाइलों को ब्राउज़र में PDF तालिकाओं में बदलें: विभाजक पहचाना जाता है, हर पेज पर हेडर पंक्ति दोहराई जाती है, चौड़ी तालिकाओं के लिए लैंडस्केप स्वतः।

PDF रूपांतरण

और गहराई से

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

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