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

रिक्वायरमेंट्स ट्रेसेबिलिटी

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

Requirements traceability का मतलब है हर requirement को उससे निकले testware से जोड़ना — test conditions, test cases, test results और उनसे मिले defects — और इन links को up to date रखना। ISTQB glossary traceability को वह हद बताता है जिस तक दो या ज़्यादा work products के बीच संबंध स्थापित किया जा सके; tester के लिए सबसे ज़रूरी संबंध test basis और tests के बीच का है।

एक ठोस उदाहरण: किसी online shop के coupon feature की requirement REQ-2 कहती है कि expired coupon एक साफ़ message के साथ reject हो। Test case TC-03 में दर्ज है Traces to: REQ-2। इस एक link से आप दो सवालों का जवाब सेकंडों में दे सकते हैं: REQ-2 को कौन-से tests जाँचते हैं, और TC-03 क्यों मौजूद है? ऐसे सारे links एक table में रखें, तो आपके पास requirements traceability matrix है।

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

Links के बिना coverage सिर्फ़ अंदाज़ा है। "212 tests pass हुए" कहने वाली release report product owner को यह नहीं बताती कि refund rules टेस्ट हुए भी या नहीं। Traceability के साथ report हर requirement के लिए बता सकती है कि किसके passing tests हैं, किसके failing और किसका कोई test नहीं। ISTQB Foundation syllabus बताता है कि अच्छी traceability क्या संभव बनाती है: coverage का आकलन, changes के impact का पता लगाना, audits को आसान बनाना, IT governance criteria पूरे करने में मदद, और test reports को stakeholders के लिए समझने लायक बनाना।

Tester के लिए यह सुरक्षा भी है। जब release से दो दिन पहले कोई requirement बदलती है, तो traceability "क्या दोबारा टेस्ट करना है?" को बहस की जगह एक lookup बना देती है। जब कोई defect production तक पहुँच जाता है, तो links दिखाते हैं कि requirement कभी टेस्ट ही नहीं हुई थी, या टेस्ट हुई थी पर test से problem छूट गई — team के लिए ये दो बिल्कुल अलग सबक हैं।

Requirements-to-test mapping: ट्रेसेबिलिटी मैट्रिक्स

Requirements traceability matrix (RTM) links को एक table में रखती है: हर requirement की एक row, हर test case का एक column, और जहाँ कोई test किसी requirement को cover करता है वहाँ एक निशान। Teams अक्सर latest result और open defects भी जोड़ती हैं, या links को test management tool में रखकर matrix को report के रूप में निकालती हैं। शुरुआत के लिए एक spreadsheet काफ़ी है; ज़रूरी यह है कि हर link test लिखते समय दर्ज हो, release से पहले याददाश्त से दोबारा न बनाया जाए।

इस lesson का चलता हुआ उदाहरण एक online shop का coupon feature है, चार requirements और पाँच test cases के साथ। हर test case का "Traces to" field source है; matrix उसी से बनती है।

  • उसी level पर trace करें जिस पर आप टेस्ट करते हैं: अलग-अलग requirements या acceptance criteria, पूरे features या epics नहीं।
  • हर test case को design करते समय उसमें requirement की id लिखें, और automated tests के नाम या tags में भी।
Requirements
REQ-1  हर order पर एक ही coupon code
REQ-2  Expired coupon "यह coupon expire हो चुका है" message के साथ reject होता है
REQ-3  Percentage discount items subtotal पर लगता है, delivery पर नहीं
REQ-4  Invoice email में discount अपनी अलग line में दिखता है

Test cases, हर एक का [Traces to] field
TC-01  [REQ-1, REQ-3]  200.00 SAR की basket पर valid 10% coupon लगाना
TC-02  [REQ-1]         उसी order पर दूसरा coupon लगाना
TC-03  [REQ-2]         कल expire हुआ coupon लगाना
TC-04  [REQ-3]         100.00 SAR basket + 15.00 SAR delivery fee पर 10% coupon लगाना
TC-05  [कोई नहीं]       Coupon code छोटे अक्षरों (lower case) में डालना

इन fields से बनी matrix
RTM     TC-01  TC-02  TC-03  TC-04  TC-05
REQ-1     x      x
REQ-2                   x
REQ-3     x                    x
REQ-4

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

Forward और backward traceability

Forward traceability हर requirement को उसके tests तक, और आगे उनके results और defects तक ले जाती है। Matrix में आप row के साथ-साथ पढ़ते हैं, और सवाल है "क्या हमने जो वादा किया वह सब टेस्ट हुआ?"। Coupon उदाहरण में REQ-4 की row खाली है: invoice email को कोई टेस्ट नहीं करता, इसलिए कोई report दावा नहीं कर सकती कि REQ-4 काम करती है।

Backward traceability हर test case या defect को उस requirement तक वापस ले जाती है जिससे वह आया। Matrix में आप column में नीचे की ओर पढ़ते हैं, और सवाल है "यह test क्यों मौजूद है?"। TC-05 का column खाली है: lower-case coupon codes का एक test, जिसे कोई requirement नहीं माँगती। दोनों दिशाओं में follow किए जा सकने वाले links रखने को bidirectional traceability कहते हैं; matrix उन्हीं निशानों से दोनों readings देती है। ISTQB syllabus इन दिशाओं को कोई नाम नहीं देता: forward, backward और bidirectional industry में प्रचलित terms हैं।

हर gap team के लिए एक सवाल है, अपने-आप होने वाला fix नहीं:

Coupon feature की traceability matrix दोनों तरफ़ से पढ़ी गई: rows के साथ forward पढ़ने पर REQ-4 का कोई test नहीं; columns में नीचे backward पढ़ने पर TC-05 किसी requirement तक trace नहीं होता।
Requirement / test caseTC-01valid 10% couponTC-02दूसरा couponTC-03कल expire हुआTC-04delivery पर discount नहींTC-05lower-case codeForward: test करते हैंrow पढ़ें
REQ-1हर order पर एक couponlinkedlinkedकोई link नहींकोई link नहींकोई link नहीं2 tests
REQ-2expired coupon reject होता हैकोई link नहींकोई link नहींlinkedकोई link नहींकोई link नहीं1 test
REQ-3discount items पर, delivery पर नहींlinkedकोई link नहींकोई link नहींlinkedकोई link नहीं2 tests
REQ-4invoice email में discount lineकोई link नहींकोई link नहींकोई link नहींकोई link नहींकोई link नहींकोई test नहीं
Backward: trace होता हैcolumn पढ़ेंREQ-1, REQ-3REQ-1REQ-2REQ-3कोई requirement नहींपूछने लायक 2 gaps
  • linked: test इस requirement को जाँचता है
  • gap: team के लिए सवाल, अपने-आप होने वाला fix नहीं

हर निशान test case के Traces to field से आया है; आख़िरी column और आख़िरी row दो readings हैं, अलग data नहीं।

  • बिना test वाली requirement (REQ-4): उसके लिए test design करें, या दर्ज करें कि यहाँ टेस्ट क्यों नहीं हो रही — scope से बाहर है, किसी दूसरे test level पर cover है, या ऐसा risk है जिसे product owner स्वीकार करता है।
  • बिना requirement वाला test (TC-05): या तो कोई requirement छूट गई है — case-insensitive codes शायद ठीक वही हैं जो business चाहता है, तो पूछें और उसे लिखवाएँ — या test ऐसी चीज़ जाँचता है जिसकी किसी को ज़रूरत नहीं, और उसे retire करना चाहिए।
  • ऐसा defect जो किसी requirement तक trace नहीं होता: अक्सर कोई अलिखित उम्मीद; उसे defect triage में उठाएँ ताकि requirement जोड़ी या साफ़ की जाए।

Worked example: बदली हुई requirement का impact analysis

Impact analysis का मतलब है किसी change के build और release होने से पहले यह पता लगाना कि वह किस-किस चीज़ पर असर डालेगा; जल्दी किया जाए तो यह तय करने में भी मदद कर सकता है कि change किया जाए या नहीं। Traceability इसके testing वाले हिस्से को तेज़ और समझाने लायक बनाती है। Coupon feature ship होने के एक महीने बाद product owner change request CR-12 लाता है: "Coupon discount की सीमा हर order पर 50.00 SAR है।" यह REQ-3 को बदलता है।

पहले पुरानी और नई wording की तुलना करें, ताकि ठीक-ठीक दिखे कि क्या बदला। फिर बदली हुई requirement को forward follow करें, हर प्रभावित test को backward पढ़ें ताकि दिखे कि वह और क्या cover करता है, तय करें कि हर test वैसा ही रहेगा, बदलेगा या उसके साथ नए tests जुड़ेंगे, और उन चीज़ों के बारे में पूछें जो matrix नहीं दिखा सकती।

  • Matrix ने काम को "coupons दोबारा टेस्ट करो" की जगह एक requirement, अपने expected results बनाए रखने वाले दो मौजूदा tests, और तीन नए tests तक सीमित कर दिया।
  • REQ-4 पर असर matrix नहीं दिखा सकती थी: उसमें दर्ज links होते हैं, हर वह जगह नहीं जहाँ discount इस्तेमाल होता है। Developer से पूछें कि कौन-सा code और कौन-सी screens discount पढ़ती हैं।
CR-12: coupon discount की सीमा हर order पर 50.00 SAR (REQ-3 को बदलता है)

1. REQ-3 से forward: TC-01, TC-04
2. इन tests से backward: TC-01 REQ-1 को भी cover करता है; कोई भी edit वह check रखे
3. Review: TC-01 में discount 20.00 और TC-04 में 10.00 है, दोनों सीमा से कम।
   दोनों के expected results नहीं बदलते।
4. REQ-3 के लिए नए tests:
   TC-06  400.00 का 10%: discount 40.00 (सीमा से कम)
   TC-07  500.00 का 10%: discount 50.00 (ठीक सीमा पर)
   TC-08  800.00 का 10%: discount 50.00, 80.00 नहीं (सीमा से ऊपर)
5. Matrix से आगे: REQ-4 (invoice email) में सीमा के बाद वाला amount दिखना चाहिए,
   और उसका अब भी कोई test नहीं, तो TC-09 जोड़ें। Developer से पूछें कि और कौन-सा
   code discount पढ़ता है।
6. नए build पर TC-01, TC-04 और TC-06 से TC-09 चलाएँ, साथ में team के चुने regression
   tests भी, और नए links matrix में जोड़ें।

आज़माएँ: टेक्स्ट डिफ़ आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

आम गलतियाँ

  • हर link test case लिखते समय दर्ज करने की बजाय matrix को आख़िर में, किसी audit या report के लिए बनाना। याददाश्त से दोबारा बनाई गई matrix अंदाज़ा भर है।
  • पूरे feature या epic तक trace करना: तब एक happy-path test पूरे "Coupons" को covered दिखा देता है, जबकि उसके चार में से तीन rules बिना test के हैं।
  • Link को पर्याप्त testing का सबूत मान लेना। भरा हुआ cell बताता है कि test मौजूद है, यह नहीं कि वह सही values जाँचता है या इस build पर pass हुआ।
  • बिना requirement वाले tests को बिना पूछे delete कर देना, या उन्हें नज़रअंदाज़ करना: हर एक या तो छूटी हुई requirement है या पुराना पड़ चुका test, और कौन-सा है यह product owner तय करता है।
  • Links को पुराना पड़ने देना: requirements बाँटी जाती हैं, नए नंबर पाती हैं या हटती हैं, और matrix अब भी पुरानी ids की ओर इशारा करती है, तो impact analysis गलत जवाब देता है।

QA का नज़रिया

असली team में traceability ज़्यादातर एक आदत है, document नहीं: requirement या acceptance criterion की id हर test condition और test case पर, automated tests के नाम या tags में, और हर defect report पर जाती है। Team के साथ तय करें कि links कहाँ रहेंगे — test management tool, issue tracker या एक shared sheet — ताकि एक ही source हो जिसे developers और product owner भी पढ़ सकें।

Links को तब इस्तेमाल करें जब वे मायने रखते हैं। Refinement में ऐसी ids और acceptance criteria माँगें जिन्हें tests reference कर सकें। Release से पहले requirement के हिसाब से report करें: "REQ-3: 5 linked tests, सब build 58 पर pass; REQ-2: उसका इकलौता test fail, defect D-41 open"। Change request आने पर retest effort का estimate देने से पहले forward और backward check करें। Matrix को उतना ही detailed रखें जितना team maintain करेगी।

अभ्यास

Class booking feature को trace करें और एक change का analysis करें

आपका काम

एक gym app में नीचे दी गई चार requirements और छह test cases हैं; हर test की requirement brackets में है। Traceability matrix बनाएँ, उसे forward और backward पढ़ें, और हर gap को उस action या सवाल के साथ लिखें जो वह माँगता है।

फिर product owner CR-4 लाता है: free cancellation अब class से 24 की जगह 12 घंटे पहले ख़त्म होगा। Matrix से तय करें कि कौन-से tests review करने हैं, कौन-से जोड़ने हैं और क्या पूछना है।

सामग्री
REQ-1  एक member एक दिन में ज़्यादा से ज़्यादा 2 classes book कर सकता है
REQ-2  Class शुरू होने से 1 घंटा पहले booking बंद हो जाती है
REQ-3  Class से 24 घंटे पहले तक cancellation free है; उसके बाद fee लगती है
REQ-4  भरी हुई class में waiting list पर जगह मिलती है

TC-01  [REQ-1, REQ-2]  एक ही दिन की 2 classes book करना, हर एक 3 घंटे पहले
TC-02  [REQ-1]         उसी दिन तीसरी class book करने की कोशिश
TC-03  [REQ-2]         Class शुरू होने से 30 मिनट पहले book करने की कोशिश
TC-04  [REQ-3]         Class से 30 घंटे पहले cancel: कोई fee नहीं
TC-05  [REQ-3]         Class से 2 घंटे पहले cancel: fee लगती है
TC-06  [कोई नहीं]       Class page पर instructor की photo दिखती है
चरण
  1. Matrix बनाएँ: हर requirement की row, हर test case का column, हर link का निशान।
  2. हर row (forward) और हर column (backward) पढ़ें; gaps की list बनाएँ।
  3. CR-4 के लिए REQ-3 को forward follow करें, देखें कि वे tests और क्या cover करते हैं, और हर test को unchanged, update या new चिह्नित करें।
  4. नोट करें कि matrix क्या नहीं बता सकती और आप किससे पूछेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Matrix: REQ-1 → TC-01, TC-02; REQ-2 → TC-01, TC-03; REQ-3 → TC-04, TC-05; REQ-4 → कोई test नहीं। Column TC-06 → कोई requirement नहीं।

Forward gap: REQ-4 का कोई test नहीं। एक test design करें (member भरी हुई class की waiting list में जुड़ता है और किसी के cancel करने पर जगह पाता है), या दर्ज करें कि यहाँ टेस्ट क्यों नहीं हो रही। Backward gap: TC-06 किसी चीज़ तक trace नहीं होता। Product owner से पूछें कि instructor photos की कोई requirement छूट गई है या test को retire करना चाहिए।

CR-4 का impact: REQ-3 से TC-04 और TC-05 मिलते हैं, जो और कुछ cover नहीं करते। दोनों के expected results वही रहते हैं (30 घंटे पहले अब भी free, 2 घंटे पहले अब भी fee), इसलिए उन्हें review करें, दोबारा न लिखें। 20 घंटे पहले cancel करने वाला test जोड़ें, जो अब free है पर पहले fee लगती थी, और 12 घंटे की सीमा के आसपास tests, जब product owner confirm कर दे कि ठीक 12 घंटे पहले cancel करना अब भी free है या नहीं।

Matrix से आगे पूछें: क्या booking confirmation, reminders या terms page में "24 घंटे" लिखा है? क्या change से पहले book हुई classes पुराना rule ही मानेंगी? फिर नए build पर REQ-3 के tests चलाएँ और नए tests की ids matrix में जोड़ें।

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

क्या agile teams को अब भी traceability matrix चाहिए?

उन्हें traceability चाहिए, ज़रूरी नहीं कि अलग spreadsheet। Team के tools में test cases, automated tests और defects को user stories और उनके acceptance criteria से link करने पर वही जवाब मिलते हैं, और matrix उन links से निकलने वाली report बन जाती है। उसका size और formality product के risk और किसी regulatory ज़रूरत के हिसाब से होनी चाहिए।

Traceability और test coverage में क्या फ़र्क़ है?

Traceability work products के बीच links का set है। Requirements coverage उन links से निकाला गया एक measure है: कितनी requirements के tests किसी build पर चले, और कितनी के tests pass हुए। Traceability के बिना requirements coverage निकाला ही नहीं जा सकता; और उसके साथ भी आपको आँकना पड़ता है कि linked tests काफ़ी हैं या नहीं।

Bidirectional traceability क्या है?

ऐसे links जिन्हें दोनों दिशाओं में follow किया जा सके: हर requirement से उसके tests तक (forward) और हर test या defect से वापस उसकी requirement तक (backward)। यह अलग document नहीं है: अगर हर test case उस requirement को दर्ज करता है जिसे वह cover करता है, तो वही links दोनों सवालों का जवाब देते हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • 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 रिपोर्ट।
टूल्स

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

Requirements → टेस्ट केस

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

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

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

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

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

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

AI टेस्ट कवरेज एनालाइज़र

Mutqan AI से requirements या किसी user story की तुलना मौजूदा टेस्ट केस से करके अनटेस्टेड हिस्से खोजें।

टेस्ट ऑप्टिमाइज़ेशन AI

और गहराई से

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

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