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

QA डॉक्यूमेंटेशन

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

QA documentation testing का लिखा हुआ हिस्सा है: वे records जिनसे दूसरे लोग काम को plan, review, दोहरा और अपने हाथ में ले सकते हैं। उदाहरण के लिए, हर दो हफ़्ते delivery-tracking app release करने वाली टीम हर release का एक पेज का test plan, test management tool में regression test cases, tracker में defect reports और एक छोटी completion report रख सकती है, और हर एक का reader और owner तय होता है।

Testware वाले lesson के आगे, यह lesson तय करता है कि कौन-से test work products लिखने लायक हैं, ISO/IEC/IEEE 29119-3 को नक्शे और lean documentation को अनुशासन की तरह इस्तेमाल करके।

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

Documentation की लागत दो बार लगती है: लिखने में और उसे current रखने में। बहुत कम हो तो knowledge एक ही दिमाग में रहता है, और जब client पूछता है कि release से पहले क्या test हुआ, तो कोई दिखा नहीं पाता। बहुत ज़्यादा हो तो documents पुराने पड़ जाते हैं: पिछले साल का scope बताने वाला 40 पेज का plan मदद से ज़्यादा भटकाता है।

सही documents tester के काम को reviewable, आसानी से सौंपने लायक और defensible बनाते हैं, क्योंकि scope cuts और accepted risks नाम और तारीख़ के साथ दर्ज होते हैं।

क्या लिखें: reader, उम्र, owner और बाध्यता

कोई document बनाने या रखने से पहले चार सवाल पूछें। इसे कौन पढ़ेगा, और उससे क्या decide करेगा या क्या करेगा? क्या यह एक बार का record है, जैसे एक test run का log, या living document जिसे current रहना है, जैसे regression suite? इसका owner कौन है? क्या कोई contract, regulator या test policy इसे माँगती है, और किस रूप में?

अगर कोई इसे decide करने या कुछ करने के लिए नहीं पढ़ेगा, तो इसे न लिखें। ज़रूरी document तय template पर चलता है, living document को owner और update का trigger चाहिए, और कम उम्र वाले note के लिए checklist काफ़ी है। मकसद के हिसाब से टीमें आम तौर पर यह लिखती हैं:

  • दिशा: यहाँ testing क्यों और कैसे होती है (test policy, test practices या plan में strategy का section)।
  • Plans: scope, risks, schedule और testing कब पूरी मानी जाएगी।
  • Design और execution: test cases या charters, data और environment की ज़रूरतें, run results।
  • Findings और reports: evidence के साथ defect reports, progress और completion reports।
  • Decisions: scope cuts, छोड़े गए exit criteria और accepted risks, साथ में किसने और कब decide किया।
  • टीम का knowledge: test data कैसे मिले, environments कैसे reset हों और suites कैसे चलें; औपचारिक नहीं, पर नए testers को सबसे पहले यही चाहिए।
QA document लिखने से पहले: decide या काम करने वाला reader न हो तो न लिखें, जो fact किसी दूसरे source में है उसे link करें, और सिर्फ़ लंबे चलने वाले या ज़रूरी items owner वाले documents बनें।
प्रश्न 1: क्या कोई इसे decide करने या कुछ करने के लिए पढ़ेगा?

  • उत्तर: नहीं

    परिणाम: इसे न लिखेंकोई इसका इस्तेमाल नहीं करेगा

  • उत्तर: हाँ

    प्रश्न 2: क्या कोई दूसरा source इसे पहले से रखता है?Story, tracker, test tool

    • उत्तर: हाँ

      परिणाम: उसी source को link करेंदो copies अलग-अलग बदलती जाती हैं

    • उत्तर: नहीं

      प्रश्न 3: क्या इसे current रहना है, या कोई contract, regulator या policy इसे माँगती है?

      • उत्तर: नहीं

        परिणाम: सबसे हल्का रूपChecklist या छोटा note

      • उत्तर: हाँ

        परिणाम: Owner वाला documentज़रूरी: तय रूप। Living: update का trigger

ISO/IEC/IEEE 29119-3: document types एक नज़र में

ISO/IEC/IEEE 29119-3:2021 उस documentation के templates और examples देता है जो ISO/IEC/IEEE 29119-2 के test processes से बनता है, और उन्हें नीचे दिए तीन tiers में रखता है। Part 3 के पहले edition (2013) ने IEEE 829-2008 की जगह ली थी।

इसकी तीन बातें सबसे अहम हैं। Documentation काग़ज़ पर या electronic हो सकता है, जैसे test tool या spreadsheet के records। Documents के नाम बदले जा सकते हैं, उन्हें जोड़ा या बाँटा जा सकता है, और टीम अपनी ज़रूरत का set चुनती है; tailored conformance का मतलब है उस set को दर्ज करना और जो छोड़ा गया उसका कारण देना। और इसे किसी भी lifecycle में अपनाया जा सकता है, agile और DevOps समेत। इसे जानकारी की checklist मानें, हर template को अलग document बनाने का आदेश नहीं।

  • Organisational: test policy (organisation क्यों टेस्ट करता है, objectives, training, ethics, testing की value कैसे मापी जाती है) और organizational test practices (projects में testing कैसे होती है; पहले edition में इसे organizational test strategy कहा जाता था)।
  • Test management: test plan (context और scope, stakeholders, risk register, project की test strategy, activities और estimates, staffing और schedule); test status report (ISTQB की test progress report); और test completion report, यानी test summary report।
  • Dynamic test: test model specification (tests किससे निकाले गए, जैसे requirements statements, partitions या decision table; 2021 edition ने test conditions की जगह test models का concept रखा, और एक model में test conditions अब भी हो सकती हैं), test case और procedure specifications, test data और environment requirements और readiness reports, actual और test results, test execution log, और incident report, जिसे defect report या bug report भी कहते हैं।
ISO/IEC/IEEE 29119-3 test documentation को तीन tiers में रखता है: organisational (test policy, test practices), test management (plan, status और completion reports) और dynamic testing (specifications, logs, incident reports)।

“Organisational test documentation” परत पर: कम ही बदलता है“Dynamic test documentation” परत पर: हर feature और test run के साथ बदलता है

  1. 1Organisational test documentationपूरा organisationTest policy · organizational test practices

    यहाँ हम क्यों और कैसे टेस्ट करते हैं

  2. 2Test management documentationएक project या productTest plan, जिसके भीतर test strategy है · test status report · test completion report

    Testing का plan, फिर उसकी progress और completion की report

  3. 3Dynamic test documentationTest design और executionTest model, test case और test procedure specifications · test data और environment requirements और readiness reports · actual results और test results · test execution log · incident report

    Incident report: इसे defect या bug report भी कहते हैं

नाम और contents tailor किए जा सकते हैं, और कोई item अलग document की जगह test tool का record भी हो सकता है।

Lean documentation: उतना ही, जितना और जब चाहिए

Manifesto for Agile Software Development "working software over comprehensive documentation" को महत्व देता है, यह मानते हुए कि documentation की भी value है। Lean test documentation यही संतुलन लागू करता है: वही लिखें जो reader को चाहिए, जब चाहिए, सबसे हल्के रूप में जो काम कर दे, और वह नहीं जो कोई बेहतर source पहले से रखता है।

Lean का मतलब "कुछ न लिखना" नहीं: contracts, regulators, audits, distributed टीमें और लंबे चलने वाले products ज़्यादा formality को सही ठहराते हैं। आपने जो स्तर चुना, उसे test strategy में दर्ज करें।

  • Link करें, copy नहीं: plan story के acceptance criteria को link करता है; copies अलग-अलग बदल जाती हैं।
  • हर fact का एक घर: risks register में, defects tracker में, results test tool में; reports उन्हें point करती हैं।
  • सबसे हल्का रूप जो काम करे: stable areas के लिए checklists, नए features के लिए charters और session notes, scripted cases वहाँ जहाँ exact steps और data मायने रखते हैं, जैसे payments।
  • हर build पर चलने वाले पढ़ने लायक automated tests आज के behaviour को document करते हैं और उसके बदलते ही fail होते हैं, इसलिए चुपचाप पुराने नहीं पड़ते।
  • Calendar से नहीं, decision बदलने पर update करें; जिन documents का कोई owner नहीं, उन्हें archive करें।

Worked example: documentation set को छाँटना

एक नई QA lead FleetTrack में आती है, जो छह developers और दो testers वाला एक काल्पनिक delivery-tracking product है। उसे विरासत में मिलते हैं: 45 पेज का master test plan, जो आठ महीने पहले आख़िरी बार update हुआ; spreadsheet में 1,200 test cases (कई हटाई गई screens के); हर हफ़्ते आधा दिन खाने वाली status report; और test data की कोई guide नहीं। एक constraint तय है: client का contract हर release के लिए signed completion report माँगता है, जो दिखाए कि कौन-सी requirements test हुईं।

वह readers और उनकी ज़रूरतों को 29119-3 items से जोड़ती है और नीचे का map product owner और development lead के साथ तय करती है:

  • Plan के लंबे चलने वाले हिस्से (levels, types, tools, defect workflow, standard exit criteria) एक practices page पर गए, जो कम ही बदलता है; release plans में सिर्फ़ scope, risks, schedule और उनके अपने criteria रहते हैं।
  • हटाई गई screens के cases retire हुए, duplicates merge हुए और regression set test tool में गया; stable low-risk areas checklists बन गए।
  • Status report एक dashboard और पाँच lines का note बन गया: headline, blockers, ज़रूरी decisions।
  • Completion report formal ही रहा क्योंकि contract उसे माँगता है: Markdown में लिखा जाता है, signature के लिए PDF में export होता है, और उसकी traceability हाथ से रखे matrix की जगह test cases पर लगे requirement IDs से आती है।
  • नहीं लिखा गया: अलग test policy (practices page की शुरुआत में मकसद का छोटा statement है, जिसकी standard अनुमति देता है), procedure specifications (steps cases और automation में हैं) और readiness reports (plan के entry criteria उन्हें cover करते हैं)।
FleetTrack documentation map (fictional), agreed in sprint 31

Item (29119-3 name)        Form and place                 Owner    Update trigger
Org. test practices        wiki page, about 4 pages       QA lead  quarterly review
Test plan (with strategy)  1 page per release, wiki       QA lead  scope, dates, risks
Test models, test cases    regression set in test tool;   testers  feature changes
                           charters for new features
Test data and environment  how-to page: accounts, seed    testers  environment changes
  requirements             scripts, reset steps
Execution log, results     test tool runs, CI report      tool     every run
Incident reports           defect tracker                 finder   until closed
Test status report         dashboard + 5-line note        QA lead  weekly
Test completion report     2 pages, signed PDF            QA lead  each release

Not written: a separate test policy (a purpose statement opens the practices page),
separate test procedure specifications and readiness reports,
and a traceability matrix kept by hand

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

आम गलतियाँ

  • Template का हर section सिर्फ़ इसलिए भरना कि वह मौजूद है, जिससे boilerplate ज़रूरी lines को छिपा देता है।
  • Requirements या steps को कई documents में copy करना, जब तक किसी को पता न रहे कि कौन-सी copy सही है।
  • Kick-off पर ऐसा plan लिखना जिसका न कोई owner है, न कोई उसे update करता है।
  • "Lean" को "कुछ न लिखना" समझना: decisions, accepted risks और defect reproduce करने के steps हमेशा दर्ज होने चाहिए।
  • जिन stable areas के लिए checklist काफ़ी है, उनका हर step script करना, जिससे maintenance value से भारी पड़ता है।
  • ISO/IEC/IEEE 29119-3 को ज़रूरी documents की list मानना, न कि ऐसी checklist जिसे आप tailor कर सकते हैं।

QA का नज़रिया

जब आप किसी टीम में आएँ, और फिर हर retrospective पर, documentation set review करें: किसे क्या चाहिए था जो नहीं मिला, और क्या किसी ने नहीं पढ़ा? इसे product owner और development lead के साथ तय करें, और जहाँ शामिल हों वहाँ compliance या client के साथ भी।

जब कोई "documentation" माँगे, तो पूछें कि वह किसके लिए है: auditor को सबूत चाहिए कि requirements test हुईं और risks किसी अधिकृत व्यक्ति ने accept किए, developer को reproduce होने लायक defect report चाहिए। उसी reader के लिए लिखें और हर living page पर तारीख़ डालें।

अभ्यास

नए contract के लिए lean documentation set बनाएँ

आपका काम

आप चार developers और एक product owner वाली टीम के अकेले tester हैं, जो meal-ordering web app बना रही है। Stories में acceptance criteria हैं और CI में एक automated API suite चलता है; इसके अलावा कुछ लिखा नहीं है। Hospital group का नया contract हर release की completion report माँगता है, जो दिखाए कि कौन-सी requirements test हुईं।

Documentation set का प्रस्ताव दें: हर item का 29119-3 नाम, रूप और जगह, owner और update trigger। फिर बताएँ कि आप क्या नहीं लिखेंगे, और क्यों।

चरण
  1. Readers लिखें और यह कि हर एक को क्या चाहिए।
  2. हर ज़रूरत को 29119-3 item से जोड़ें; देखें कि क्या कोई source उसे पहले से रखता है।
  3. सबसे हल्का रूप और जगह चुनें, copy की बजाय link करें।
  4. Living items को owner और update trigger दें; लिखें कि आप क्या नहीं लिखेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Readers: टीम, product owner, hospital group (completion report और test हुई requirements) और आगे आने वाले testers।

Test plan और उसकी strategy: हर release का एक wiki page (scope, top risks, API suite समेत levels और types, entry और exit criteria, environments), जिसके owner आप हैं और जिसे scope, dates या risks बदलने पर update करते हैं।

Test models और cases: acceptance criteria test model का काम करते हैं (requirements statements standard के examples में से एक हैं) और link किए जाते हैं, copy नहीं। Cases सिर्फ़ regression और high-risk flows के लिए लिखें, जैसे order cancel करना; नई stories के लिए charters इस्तेमाल करें।

Test data और environments का how-to page; logs और results test tool और CI से; incident reports tracker में; status sprint review और dashboard से। Completion report formal है, उसके owner आप हैं, वह हर release के लिए लिखी जाती है, और उसकी traceability tests पर लगे story IDs से आती है।

नहीं लिखा जाएगा: अलग test policy और organizational test practices (टीम एक ही है, इसलिए plan की strategy इन्हें cover करती है), procedure specifications, readiness reports और हाथ से रखा traceability matrix; ये फ़ैसले और उनके कारण plan में दर्ज करें।

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

क्या ISO/IEC/IEEE 29119-3 ज़रूरी है?

सिर्फ़ तब, जब कोई contract, regulator या आपका organisation conformance माँगे। Standard ख़ुद tailored conformance, electronic records और बदले हुए नाम और contents की अनुमति देता है, इसलिए कई टीमें इसके templates को भरने वाले forms की बजाय checklist की तरह इस्तेमाल करती हैं।

क्या agile टीमों को अब भी test plan चाहिए?

उन्हें planning की जानकारी (scope, risks, approach और criteria) चाहिए, ज़रूरी नहीं कि लंबा document। इसका बड़ा हिस्सा backlog और Definition of Done में रहता है, और बाकी हर sprint या release के एक पेज में आ जाता है। ISO/IEC/IEEE 29119-3 कहता है कि इसे agile और DevOps lifecycles में अपनाया जा सकता है, और products के इर्द-गिर्द बनी टीमें जहाँ "project" लिखा है वहाँ "product" पढ़ सकती हैं।

क्या automated tests documentation हैं?

आंशिक रूप से। हर build पर चलने वाला पढ़ने लायक test बताता है कि system आज क्या करता है, और उसके बदलते ही fail होता है। लेकिन वह यह दर्ज नहीं करता कि behaviour क्यों ज़रूरी है, जान-बूझकर क्या test नहीं हुआ या कौन-से risks accept किए गए; इनके लिए अब भी कुछ लिखी हुई lines चाहिए।

संदर्भ

  • ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021टेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Manifesto for Agile Software DevelopmentThe Agile Manifesto authors · 2001agile software development के चार मूल्य, जैसे विस्तृत documentation से ऊपर चलता हुआ software, और योजना पर चलने से ऊपर बदलाव का जवाब देना।
टूल्स

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

Requirements → टेस्ट केस

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

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

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

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

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

टेस्ट केस जनरेटर

फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।

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

Markdown फ़ॉर्मेटर

Markdown की फ़ॉर्मेटिंग (हेडिंग, सूचियाँ, टेबल, emphasis) सामान्य करें और रेंडर किया नतीजा देखें।

फ़ॉर्मेटिंग

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

Markdown (.md) फ़ाइलों को ब्राउज़र में PDF में बदलें: शीर्षक, सूचियाँ, तालिकाएँ, कोड ब्लॉक, उद्धरण, लिंक और चित्र एम्बेडेड फ़ॉन्ट से टाइपसेट।

PDF रूपांतरण

और गहराई से

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

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