टेस्ट केस प्रायोरिटी
Test case priority किसी test case का सापेक्ष महत्व है: यह तय करती है कि कौन-से test cases पहले चलेंगे और समय कम हो तो कौन-से छोड़े जा सकते हैं। ISTQB Foundation syllabus इसे test case prioritization कहता है।
उदाहरण: एक release clinic booking app में card payment जोड़ता है। "Deposit भरें और confirmed booking पाएँ" P1 है और पहली सुबह चलता है; "Help page के links खुलते हैं" P3 है और सिर्फ़ तब चलता है जब समय बचे।
यह क्यों ज़रूरी है
Exhaustive testing असंभव है, इसलिए test cases खत्म होने से पहले समय खत्म हो जाता है। Priorities के बिना cases उसी क्रम में चलते हैं जिसमें लिखे गए, और payments या personal data वाले cases release के दिन भी बाकी रह सकते हैं। Priorities के साथ scope घटाना हादसा नहीं, फ़ैसला बनता है: जो untested रह जाता है वह सबसे कम ख़तरनाक हिस्सा होता है, और सबको पता होता है कि वह क्या है।
Priority reporting का औज़ार भी है: "सभी 4 P1 cases pass हुए; 1 P3 case नहीं चला" product owner को एक line में बता देता है कि release का फ़ैसला किस आधार पर है।
Priority क्या तय करती है और क्रम को क्या बदलता है
Priority execution का क्रम और छाँटने का क्रम तय करती है, और हर cycle में review होती है, क्योंकि risk इस पर निर्भर है कि उस build में क्या बदला। जैसा test implementation वाले lesson में आया था, ISTQB Foundation syllabus (v4.0) test execution schedule में test cases को क्रम देने के तीन तरीके और उन्हें बदलने वाली दो constraints बताता है:
- Risk-based: सबसे अहम risks को cover करने वाले cases पहले चलते हैं। यह lesson यही तरीका इस्तेमाल करता है।
- Coverage-based: सबसे ज़्यादा coverage देने वाले cases पहले चलते हैं, या हर अगला case अब तक न मिली सबसे ज़्यादा coverage जोड़ता है।
- Requirements-based: क्रम उन priorities के हिसाब से चलता है जो stakeholders ने उन requirements को दी हैं जिनसे cases trace होते हैं।
- Dependencies: अगर किसी high-priority case को पहले किसी lower-priority case की ज़रूरत हो, जैसे उसका data बनाने के लिए, तो lower-priority case पहले चलता है।
- Resources: सिर्फ़ किसी time window में उपलब्ध environment, device या व्यक्ति cases को आगे या पीछे कर देता है।
Priority, severity और criticality
Severity defects की चीज़ है: ISTQB glossary इसे किसी component या system के development या operation पर defect के असर की मात्रा के रूप में परिभाषित करता है। Priority किसी item को दिया गया business महत्व का स्तर है; test case के लिए यह बताती है कि उसे कितनी जल्दी चलाना है और क्या उसे छोड़ा जा सकता है।
Test case की कोई severity नहीं होती, क्योंकि अभी कुछ fail नहीं हुआ। उसकी criticality होती है: जिस area को वह cover करता है वहाँ failure कितना बुरा होगा। कुछ teams इसे ढीले तौर पर "severity" कहती हैं। Priority इस impact को इस build में failure की likelihood से जोड़ती है, इसलिए दोनों अलग हो सकते हैं:
- ऊँची criticality, कम priority: password reset critical है, लेकिन वह नहीं बदला और उसका automated check इस build पर pass हुआ, इसलिए manual case P2 हो सकता है।
- कम criticality, ऊँची priority: दोबारा लिखा गया SMS reminder गलत हो तो छोटी समस्या है, लेकिन template नया है और उसमें गलतियों की संभावना है, इसलिए उसका case P3 नहीं, P2 है।
Risk के आधार पर क्रम: impact × likelihood
हर test case को, या जिस risk को वह cover करता है उसे, दो लिखित scales पर आँकें, ratings गुणा करें और score को priority में बदलें। शुरुआत के लिए तीन levels काफ़ी हैं; risk-based testing guide पूरे features के लिए चार इस्तेमाल करता है। हर project में एक ही लिखित scale रखें।
| Likelihood | Impact | ||
|---|---|---|---|
| 1 Low | 2 Medium | 3 High | |
| 3 High | P2score 3 | P1score 6 | P1score 9 |
| 2 Medium | P3score 2 | P2score 4 | P1score 6 |
| 1 Low | P3score 1 | P3score 2 | P2score 3 |
- P1: score 6–9, हर cycle में सबसे पहले चलता है
- P2: score 3–4, हर full cycle में P1 के बाद चलता है
- P3: score 1–2, समय हो तो चलता है और सबसे पहले छाँटा जाता है
- Impact
- 3 High — पैसा, personal data, क़ानूनी जोखिम या बहुत से users के लिए टूटा core flow
- 2 Medium — कोई feature कमज़ोर या workaround मौजूद
- 1 Low — cosmetic या कम इस्तेमाल होने वाला
- Likelihood
- 3 High — नया या बदला code, जटिल logic, नया integration या defects का इतिहास
- 2 Medium — बदलाव से अप्रत्यक्ष रूप से छुआ गया
- 1 Low — बिना बदला और stable
तीन levels वाला उदाहरण scale: हर team अपनी परिभाषाएँ और bands test plan में लिखती है।
- Impact: High यानी पैसा, personal data, क़ानूनी जोखिम या बहुत से users के लिए टूटा core flow; Medium यानी कोई feature कमज़ोर या workaround मौजूद; Low यानी cosmetic या कम इस्तेमाल होने वाला।
- Likelihood: High यानी नया या बदला code, जटिल logic, नया integration या defects का इतिहास; Medium यानी बदलाव से अप्रत्यक्ष रूप से छुआ गया; Low यानी बिना बदला और stable।
पाठ संस्करण
Score = impact x likelihood, each rated 1 Low, 2 Medium, 3 High
IMPACT
1 Low 2 Medium 3 High
LIKELIHOOD 3 High | 3 P2 | 6 P1 | 9 P1 |
2 Medium| 2 P3 | 4 P2 | 6 P1 |
1 Low | 1 P3 | 2 P3 | 3 P2 |
Score 6-9 -> P1 Score 3-4 -> P2 Score 1-2 -> P3P1, P2 और P3 की परंपराएँ
कोई standard इन labels को तय नहीं करता: teams और tools P1 से P3, P0 से P3, या Critical, High, Medium और Low इस्तेमाल करते हैं। ज़रूरी है test plan में लिखी परिभाषा। एक आम परंपरा:
- P1, ज़रूर चलाएँ: core business flows और high-risk बदलाव। हर cycle में सबसे पहले चलते हैं; failure आम तौर पर release रोक देता है।
- P2, चलाने चाहिए: medium risk वाले अहम functions। हर full cycle में P1 के बाद चलते हैं; सिर्फ़ product owner की सहमति से छोड़े जाते हैं।
- P3, चला सकते हैं: low-risk, stable या cosmetic areas। समय होने पर या बारी-बारी से चलते हैं; सबसे पहले छाँटे जाते हैं, और छाँटना test report में दर्ज होता है।
- कुछ teams उन गिने-चुने smoke checks के लिए P0 जोड़ती हैं जो तय करते हैं कि build टेस्ट करने लायक है भी या नहीं।
- P1 test case, P1 defect नहीं है: defect पर label बताता है कि उसे कितनी जल्दी ठीक करना है; test case पर, कि उसे कितनी जल्दी चलाना है।
Worked example: clinic booking का एक release
एक clinic booking web app का release 3.2 booking के समय card से deposit जोड़ता है, reschedule screen को redesign करता है और Arabic SMS reminder template दोबारा लिखता है; और कुछ नहीं बदला। इस section के अंत की table आँके गए आठ test cases को execution order में दिखाती है।
- Shared payment sandbox सिर्फ़ 09:00 से 13:00 तक खुला है, इसलिए दोनों payment cases सबसे पहले चलते हैं।
- TC-BOOK-02 ऐसी visit book करता है जिसमें deposit नहीं लगता। उसका अपना logic नहीं बदला, लेकिन वह उसी booking flow से होकर जाता है जिसे deposit वाले बदलाव ने छुआ: likelihood Medium, और High impact के साथ फिर भी P1।
- TC-SCH-01 का impact High है पर वह नहीं बदला: P1 नहीं, P2। TC-SMS-02 का impact Low है पर वह नया है: P3 नहीं, P2।
- TC-SMS-02 को वह phone number चाहिए जो TC-PRO-05 set करता है, इसलिए TC-PRO-05 उससे ठीक पहले चलता है और P3 ही रहता है: constraint क्रम बदलती है, label नहीं।
- अगर cycle दो दिन से घटकर एक दिन की हो जाए, तो product owner की सहमति से TC-HLP-01 छोड़ा जाता है और "नहीं चला" के रूप में report होता है।
Release 3.2: test cases, execution order में
# ID Impact Likelihood Score Pri Test case
1 TC-PAY-01 High High 9 P1 Deposit भरा, booking confirmed
2 TC-PAY-04 High High 9 P1 Card decline: न booking, न charge
3 TC-BOOK-02 High Medium 6 P1 बिना deposit वाली booking (अप्रत्यक्ष बदलाव)
4 TC-RES-03 Medium High 6 P1 नई screen पर reschedule
5 TC-SCH-01 High Low 3 P2 Doctor के खाली slots दिखते हैं
6 TC-PRO-05 Medium Low 2 P3 Profile में phone number update
7 TC-SMS-02 Low High 3 P2 Reminder SMS, नया Arabic template
8 TC-HLP-01 Low Low 1 P3 Help page के links खुलते हैंआम गलतियाँ
- लगभग हर चीज़ को P1 देना, जिससे label यह बताना बंद कर देता है कि पहले क्या चलाना है या क्या छाँटना है।
- किसी defect की severity या priority को test case की priority के रूप में copy करना।
- सिर्फ़ impact आँकना: critical लेकिन stable और बिना बदला area अभी-अभी दोबारा लिखे गए medium-impact area के बाद आ सकता है।
- Priorities एक बार तय करके कभी review न करना, जबकि risk हर बदलाव के साथ खिसकता है।
- Dependencies और environment windows को नज़रअंदाज़ करना, जिससे बारी आने पर P1 case चल ही नहीं पाता।
- यह दर्ज करने की बजाय कि क्या नहीं चला और किसने सहमति दी, P3 cases को चुपचाप छोड़ देना।
QA का नज़रिया
आम तौर पर tester priorities प्रस्तावित करता है: product owner या business analyst impact बताते हैं, developers बताते हैं कि क्या बदला, और test plan की परिभाषाएँ test lead के पास होती हैं। Label के साथ impact और likelihood भी दर्ज करें, ताकि कोई भी देख सके कि case P2 क्यों है और अगली cycle में उसे दोबारा आँक सके।
Execution के दौरान progress priority के हिसाब से report करें, जैसे "P1: 4 में से 4 चले, 1 fail"। तथ्य बदलें तो दोबारा आँकें: किसी एक screen में defects का cluster उसे छूने वाले हर case की likelihood बढ़ा देता है।
अभ्यास
Grocery shop के एक release की priorities तय करें
एक grocery web shop का release 2.8 checkout पर promo-code field जोड़ता है; और कुछ नहीं बदला। Material के हर test case को आँकें, इस lesson की matrix से P1, P2 या P3 दें, और execution order लिखें।
फिर तय करें कि cycle आधी हो जाए तो आप क्या छोड़ेंगे, और इसे कैसे report करेंगे।
Release 2.8: checkout पर नया promo-code field। और कुछ नहीं बदला।
TC-01 Valid promo code order total को सही तरह घटाता है
TC-02 Expired promo code reject होता है और total नहीं बदलता
TC-03 Order place करें और card से pay करें (payment नहीं बदला; बदले checkout से होकर)
TC-04 Order history में discount की line दिखती है
TC-05 नया delivery address save करें (बिना बदला)
TC-06 Products को नाम से search करें (बिना बदला)
Constraints
- Payment sandbox सिर्फ़ सुबह उपलब्ध है।
- TC-03 को saved delivery address चाहिए, जो TC-05 बनाता है।- हर case का impact और likelihood आँकें।
- गुणा करें और हर score को P1, P2 या P3 में बदलें।
- Dependency और sandbox window के हिसाब से cases को क्रम दें, कोई label बदले बिना।
- चिह्नित करें कि सबसे पहले क्या छाँटेंगे, और test report के लिए एक line लिखें।
मॉडल उत्तर दिखाएँ
TC-01: impact High (गलत totals से पैसे का नुकसान) × likelihood High (नया code) = 9, यानी P1। TC-02: High × High = 9, P1; expired code स्वीकार होना बिना अनुमति का discount है। TC-03: High × Medium (payment code नहीं बदला; order सिर्फ़ बदले हुए checkout से होकर जाता है) = 6, P1। Likelihood को High आँकें तो 9 मिलता है और priority वही P1 रहती है।
TC-04: Medium × Medium (बदला हुआ order data पढ़ता है) = 4, P2। TC-05: High × Low = 3, P2; बिना बदला, लेकिन address के बिना कोई order नहीं। TC-06: Medium (search के बिना भी customers shop browse कर सकते हैं) × Low = 2, P3।
क्रम: setup के लिए TC-05, फिर सुबह की sandbox window में TC-03, फिर TC-01, TC-02, TC-04 और TC-06। TC-05 सिर्फ़ इसलिए पहले चलता है कि TC-03 को उसकी ज़रूरत है; वह P2 ही रहता है।
आधे समय में पहले TC-06 छाँटें, फिर ज़रूरत हो तो TC-04, P1 कभी नहीं, और report करें: "P3 case TC-06 नहीं चला; risk product owner ने स्वीकार किया।"
अक्सर पूछे जाने वाले सवाल
Test case की priority कौन तय करता है?
आम तौर पर tester प्रस्तावित करता है, क्योंकि वह test cases को जानता है। Inputs दूसरों से आते हैं: impact के लिए product owner या business analyst, और क्या बदला इसके लिए developers। Test plan की परिभाषाएँ test lead या test manager की ज़िम्मेदारी हैं, और असहमति भी वही सुलझाते हैं।
क्या test case priority और defect priority एक ही हैं?
नहीं। दोनों business महत्व बताती हैं, लेकिन अलग चीज़ों का। Defect priority बताती है कि किसी ज्ञात defect को कितनी जल्दी ठीक करना है। Test case priority बताती है कि test case कितनी जल्दी चलाना है और क्या इस cycle में उसे छोड़ा जा सकता है। Fail होने वाला P1 test case किसी भी priority का defect दे सकता है।
क्या ratings के लिए रिस्क-बेस्ड टेस्ट जनरेटर इस्तेमाल कर सकते हैं?
हाँ। यह features को likelihood और impact पर 1 से 5 के scale पर आँकता है, अपने Critical, High, Medium और Low levels के साथ, और एक ranked plan बनाता है। इस lesson के 1 से 3 वाले scores copy करने की बजाय उसके scale पर आँकें, फिर उसके levels को अपनी team की P1 से P3 परिभाषाओं से जोड़ें।
क्या P3 test cases delete कर देने चाहिए?
सिर्फ़ P3 होने की वजह से नहीं। जब उसका area बदलता है तो P3 case P1 बन सकता है। किसी case को तभी हटाएँ या merge करें जब वह पुराना पड़ चुका हो या किसी दूसरे case को दोहराता हो; अगला lesson, reusable और regression test cases पर, यह maintenance सिखाता है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।