रिस्क-आधारित टेस्टिंग

Product risk बनाम project risk

ISTQB Foundation syllabus दो तरह के risk को अलग करता है, और इन्हें मिलाना risk register के बेकार हो जाने का सबसे आम कारण है। Product risk (जो प्रोडक्ट की quality विशेषताओं से जुड़ा होता है) वह तरीका है जिससे प्रोडक्ट ख़ुद किसी ज़रूरत को पूरा करने में फ़ेल हो सकता है: checkout पर गलत total, धीमा search पेज, अकाउंट्स के बीच डेटा लीक। Project risk वह तरीका है जिससे प्रोजेक्ट डिलीवर करने में फ़ेल हो सकता है: test environment देर से मिलना, payment integration जानने वाला अकेला व्यक्ति छुट्टी पर जाना, किसी सप्लायर का API एक स्प्रिंट देर से आना।

टेस्टिंग product risk को सीधे कम करती है — टेस्ट यह पता लगाने का तरीका है कि जिस failure का डर है वह मौजूद है या नहीं। Project risk को test manager और डिलीवरी टीम planning, staffing और escalation से संभालते हैं; उनकी जगह test plan में है, लेकिन ज़्यादा test case लिखने से वे कम नहीं होते। इन्हें अलग-अलग owner वाली अलग सूचियों में रखें।

• Product risk के उदाहरण: GST/VAT की गलत गणना, logout पर session invalid न होना, बटन से बाहर निकलता अरबी या हिंदी टेक्स्ट, महीने के अंत के volume पर report का time out होना।
• Project risk के उदाहरण: दूसरी टीम के साथ साझा staging environment, test data की देर से डिलीवरी, payment provider के sandbox तक पहुँच न होना, अस्पष्ट acceptance criteria।

Risk कैसे पहचानें

Risk identification तब सबसे अच्छा काम करता है जब कमरे में कई दृष्टिकोण हों, क्योंकि हर रोल अलग failure देखता है। डेवलपर जानता है कि कौन-सा module नाज़ुक है, product owner जानता है कि कौन-सा failure ख़बर बन जाएगा, support जानता है कि ग्राहक पहले से किस बात की शिकायत करते हैं, और tester जानता है कि पिछली बार defect कहाँ इकट्ठा हुए थे।

• Risk workshop — product, development, testing, operations और ज़रूरत हो तो security और support के साथ 45 से 90 मिनट। फ़ीचर के flow पर कदम-दर-कदम चलें और हर कदम पर पूछें: यहाँ क्या गलत हो सकता है, और किसे पता चलेगा?
• Checklist — मिलते-जुलते फ़ीचर (payment, authentication, file upload, reporting) की risk सूची दोबारा इस्तेमाल करें ताकि workshop खाली पन्ने से शुरू न हो।
• Quality characteristics — ISO/IEC 25010 को prompt सूची की तरह इस्तेमाल करें: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility और safety। हर एक के लिए पूछें: क्या इस फ़ीचर के लिए यहाँ failure मायने रखता है?
• पिछले defect — पिछली रिलीज़ के defect को component और root cause के हिसाब से समूहित करें; जिन हिस्सों में escaped या reopened defect ज़्यादा थे वे फिर फ़ेल हो सकते हैं।
• Change impact — इस रिलीज़ में क्या नया या बदला है, उस पर क्या निर्भर है, और बदलाव कितना जटिल है। नया कोड, दोबारा लिखा कोड और कई लोगों द्वारा छुआ गया कोड ज़्यादा likelihood रखता है।
• Interview और expert review — regulated या विशेष domain में नियम जानने वालों (finance, compliance, clinical स्टाफ़) से पूछें कि अस्वीकार्य failure कैसा दिखता है।

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

Risk assessment: likelihood × impact

हर पहचाने गए product risk को दो रेटिंग मिलती हैं। Likelihood यह है कि failure के मौजूद होने और उपयोग में होने की संभावना कितनी है; यह जटिलता, नयापन, कमज़ोर requirements, समय के दबाव, कई integrations और defect के इतिहास के साथ बढ़ती है। Impact यह है कि failure होने पर कितना बुरा होगा: आर्थिक नुकसान, क़ानूनी या regulatory जोखिम, safety, प्रभावित यूज़र्स की संख्या, प्रतिष्ठा को नुकसान, workaround की उपलब्धता। Risk level दोनों को मिलाता है, अक्सर दो ordinal स्कोर के गुणनफल के रूप में।

लिखित परिभाषाओं वाले qualitative scale इस्तेमाल करें ताकि दो लोग एक ही तरह स्कोर करें। आमतौर पर 1–4 का scale काफ़ी है; बारीक scale 6 और 7 के फ़र्क़ पर ऐसी बहस छेड़ते हैं जिसे कोई सुलझा नहीं सकता। परिभाषाएँ workshop से पहले तय करें, उसके दौरान नहीं। 1–5 का scale भी इसी तरह काम करता है — test strategy और test plan गाइड के Bustan Market उदाहरण यही इस्तेमाल करते हैं — बशर्ते हर register में लिखित परिभाषाओं और तय bands वाला एक ही scale हो, और अलग-अलग scale के स्कोर की आपस में तुलना कभी न की जाए। नीचे लिंक किया गया रिस्क-बेस्ड टेस्ट जनरेटर ऐसा ही एक अलग scale इस्तेमाल करता है: likelihood और impact 1 से 5 तक, bands Low (4 से कम), Medium (4–8), High (9–14) और Critical (15–25), और impact के आधार पर कोई न्यूनतम स्तर नहीं। इसलिए इस पेज के 1–4 वाले स्कोर सीधे न डालें, बल्कि risk को उसके scale पर दोबारा रेट करें; और अगर आपकी strategy में impact वाला कोई नियम है तो उसे जनरेटर के नतीजे पर ख़ुद लागू करें।

• नीचे के चार्ट में likelihood का scale: 1 Rare — सरल, बिना बदला और अच्छी तरह टेस्ट हुआ कोड; 2 Possible — मध्यम बदलाव; 3 Likely — जटिल या नया कोड; 4 Very likely — नया, जटिल और कमज़ोर requirements वाला कोड।
• Impact का scale: 1 Low — cosmetic समस्या, आसान workaround; 2 Medium — फ़ीचर कमज़ोर, कुछ यूज़र प्रभावित; 3 High — मुख्य flow टूटा या गलत डेटा; 4 Severe — पैसे, क़ानून, security या safety पर असर।
• Matrix में पंक्तियाँ likelihood हैं (ऊपर 4 से नीचे 1 तक) और कॉलम impact (1 से 4), और हर ख़ाने में गुणनफल और उसका level है। Bands: 1–3 Low, 4–6 Medium, 8–9 High, 12–16 Very high।
• नियम: जिस risk का impact 4 है वह गुणनफल चाहे जो हो, कम से कम High माना जाता है; इससे सिर्फ़ likelihood 1 और impact 4 वाला ख़ाना बदलता है, जिसका स्कोर 4 Medium से High हो जाता है।

Likelihood                      Impact
1 Rare     – simple, unchanged,   1 Low      – cosmetic, easy workaround
             well tested          2 Medium   – feature degraded, some users
2 Possible – moderate change      3 High     – core flow broken or wrong data
3 Likely   – complex or new code  4 Severe   – money, legal, security or
4 Very likely – new + complex +                 safety consequence
             weak requirements

                     IMPACT
               1 Low   2 Medium  3 High   4 Severe
LIKELIHOOD 4 |  4 M  |   8 H   |  12 VH |  16 VH |
           3 |  3 L  |   6 M   |   9 H  |  12 VH |
           2 |  2 L  |   4 M   |   6 M  |   8 H  |
           1 |  1 L  |   2 L   |   3 L  |   4 M  |

Bands: 1–3 Low · 4–6 Medium · 8–9 High · 12–16 Very high
Rule: any risk with Impact 4 is at least High, whatever the product.

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

Risk level से टेस्ट की प्राथमिकता और गहराई तक

Risk level दो चीज़ें तय करता है: टेस्टिंग का क्रम (ऊँचे risk पहले, ताकि समय ख़त्म होने पर बिना टेस्ट हुआ काम सबसे कम ख़तरनाक हो) और टेस्टिंग की गहराई (कितनी techniques, कितना coverage और कितनी स्वतंत्रता)। इस mapping को test strategy में लिख दें ताकि हर फ़ीचर पर गहराई पर दोबारा मोलभाव न हो।

• Very high — कई design techniques साथ में (boundary value analysis, decision table, state transition testing), negative और error-path टेस्ट, जहाँ risk non-functional हो वहाँ non-functional जाँच, हर build पर चलने वाला API स्तर का automated regression, दूसरे tester का exploratory session, और ख़ुद टेस्ट की review।
• High — हर अहम input पर boundary और negative टेस्ट, सभी acceptance criteria कवर, हर build पर या nightly automated regression, एक exploratory session।
• Medium — मुख्य negative cases के साथ सभी acceptance criteria कवर; nightly या release suite में regression; समय हो तो exploratory testing।
• Low — happy path और acceptance criteria की जाँच, या सिर्फ़ smoke test से कवर; हल्का टेस्ट करने का फ़ैसला दर्ज किया जाता है, चुपचाप नहीं लिया जाता।
• क्रम — testable build मिलते ही Very high risk से शुरू करें; Low risk को आख़िर में टेस्ट करें और सबसे पहले काटें।

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

Regression टेस्ट चुनने में risk का उपयोग

पूरा regression suite शायद ही कभी release window में समाता है, इसलिए हर रिलीज़ में चुनाव होता है। Risk-आधारित regression selection, change impact analysis को risk register के साथ जोड़ता है: बदले हुए कोड और उस पर निर्भर हिस्सों के टेस्ट पहले चलते हैं, प्रभावित हिस्सों के risk level के अनुसार भार देकर।

• क्या बदला, उसकी सूची बनाएँ — commits, pull requests, release notes, database migrations, configuration और dependency upgrades।
• Dependencies ट्रेस करें — कौन-सी screens, APIs, jobs, reports और shared components बदली हुई चीज़ को call करते या पढ़ते हैं; कोई shared utility या database table अपनी फ़ाइल के नाम से कहीं ज़्यादा छूता है।
• Core हमेशा चलाएँ — smoke और critical-path टेस्ट का एक तय सेट (sign-in, payment, मुख्य business transaction) बदलाव चाहे जो हो, हर build पर चलता है।
• प्रभावित टेस्ट जोड़ें — बदले हुए और निर्भर हिस्सों से जुड़े टेस्ट, सबसे ऊँचा risk पहले।
• बचा समय भरें — बिना छुए हिस्सों के risk level के हिसाब से, Medium और Low हिस्सों को रिलीज़ दर रिलीज़ घुमाते हुए ताकि कोई लंबे समय तक बिना टेस्ट न रहे।
• जो नहीं चला उसे दर्ज करें — न चुने गए टेस्ट residual risk statement का हिस्सा हैं।

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

उदाहरण: checkout फ़ीचर का risk register

उदाहरण के लिए, एक काल्पनिक ऑनलाइन स्टोर saved cards, discount codes और 3-D Secure के साथ नया checkout जोड़ता है। Workshop ने नीचे का register बनाया। स्कोर ऊपर के 1–4 scale पर हैं, नीचे लिंक किए गए रिस्क-बेस्ड टेस्ट जनरेटर के 1–5 scale पर नहीं; ये संख्याएँ जनरेटर में डालने पर level अलग आते हैं (R4 Medium आएगा, क्योंकि जनरेटर में Impact-4 नियम नहीं है)। "test response" वह है जिसके लिए plan हर risk पर प्रतिबद्ध है।

• Register संक्षेप में (likelihood × impact = स्कोर, level): R1 कार्ड से पैसा कटा पर order नहीं बना, capture के बाद gateway timeout से — 3 × 4 = 12, Very high; R2 discount और VAT साथ आने पर गलत total — 3 × 4 = 12, Very high; R3 double submit से दो orders — 2 × 4 = 8, High; R4 किसी दूसरे यूज़र का saved card दिखना (broken access control) — 1 × 4 = 4, Impact-4 नियम से High; R5 mobile Safari पर 3-D Secure challenge फ़ेल — 2 × 3 = 6, Medium; R6 confirmation email 5 मिनट से ज़्यादा देर से — 2 × 2 = 4, Medium; R7 receipt PDF में अरबी पता कटना — 3 × 1 = 3, Low।
• काम का क्रम: पहले R1 और R2, फिर R3 और R4, फिर R5 और R6, और आख़िर में R7।
• R1 और R2 को सबसे ज़्यादा मेहनत मिलती है: हर एक पर दो techniques, pipeline में automated API टेस्ट, और payment failures पर एक exploratory session।
• R4 की likelihood कम है लेकिन impact गंभीर है; सिर्फ़ 4 के स्कोर से यह Medium होता, पर Impact-4 नियम इसे High कर देता है ताकि स्कोर संभावित डेटा breach को छिपा न दे।
• R7 को एक test case मिलता है; schedule खिसके तो यही सबसे पहले कटता है, और यह कटौती residual risk statement में लिखी जाती है।

Feature: Checkout v2 (saved cards, discount codes, 3-D Secure)   Release 5.3

ID  Risk                                            L  I  Score Level  Test response
R1  Card charged but no order created               3  4  12    VH     State transitions of payment; gateway
    (gateway timeout after capture)                                     timeout/5xx via mock; retry and
                                                                        reconciliation check; exploratory
R2  Wrong total when discount and VAT combine       3  4  12    VH     Decision table promo x VAT x rounding;
    (e.g. 99.99 SAR, 10% code, 15% VAT)                                boundary amounts 0.01 / max; API tests
R3  Double submit creates two orders                2  4   8    H      Double click, browser back, network
                                                                        retry; idempotency key verified
R4  Another user's saved card visible              1  4   4    H*     Two-account authorization tests;
    (broken access control)                                            added to security regression
R5  3-D Secure challenge fails on mobile Safari      2  3   6    M      Target devices: happy + cancel path
R6  Confirmation email delayed over 5 minutes       2  2   4    M      One end-to-end check; alert in staging
R7  Arabic address truncated on receipt PDF          3  1   3    L      One case in localisation pass

* raised from Medium to High by the Impact-4 rule.
Order of work: R1, R2 -> R3, R4 -> R5, R6 -> R7.

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

रिलीज़ के दौरान risk mitigation और monitoring

टेस्टिंग कई mitigation में से एक है। ऊँचे risk को design बदलकर (duplicate order के विरुद्ध idempotency key), exposure सीमित करके (feature flag या staged rollout), या production में failure को जल्दी पकड़कर (payment reconciliation पर monitoring और alert) भी कम किया जा सकता है। Risk register में सिर्फ़ टेस्ट नहीं, mitigation का नाम भी होना चाहिए।

रिलीज़ आगे बढ़ने के साथ risk बदलते हैं। तय बिंदुओं पर दोबारा स्कोर करें — पहले test cycle के बाद, हर अहम defect के बाद, go/no-go मीटिंग से पहले। किसी हिस्से में defects का जमावड़ा उसकी likelihood बढ़ाता है; गहरे टेस्ट का साफ़ run उसे घटाता है। खुले High और Very high risk की संख्या को समय के साथ ट्रैक करना एक सरल risk burn-down देता है जिसे stakeholders समझते हैं।

• जब टेस्टिंग कोई नया failure mode दिखाए तो risk जोड़ें; अगले workshop का इंतज़ार न करें।
• हर defect को उस risk से लिंक करें जिसकी वह पुष्टि करता है, ताकि register सिर्फ़ राय नहीं, सबूत दिखाए।
• Risk तभी बंद करें जब उसके planned टेस्ट चलकर pass हो गए हों, या owner ने उसे औपचारिक रूप से स्वीकार किया हो।

Residual risk की रिपोर्टिंग

Residual risk वह है जो टेस्टिंग के बाद बचता है: हल्के ढंग से टेस्ट हुए risk, न चले टेस्ट, खुले defect, और वे हिस्से जिन्हें किसी ने नहीं जाँचा। इसकी रिपोर्टिंग test report का सबसे उपयोगी काम है, क्योंकि इससे रिलीज़ के owner बचे हुए risk को production में खोजने के बजाय जानते-बूझते स्वीकार करते हैं।

Residual risk — Checkout v2, release 5.3

Reduced:   R1, R2, R3, R4 — planned tests executed and passed; no open defects
Partial:   R5 — tested on 2 of 4 target devices (Android tablet and
           older iOS not available); owner: product manager, accepted
Open:      R6 — defect CHK-214 (email delayed up to 12 min under load)
           open, severity Major; mitigation: alert on queue length
Not tested: R7 — cut for schedule; one known cosmetic issue possible
Out of scope: refunds flow (unchanged this release; smoke only)

Recommendation: release with the R5 and R6 conditions above accepted in writing.

आज़माएँ: AI टेस्ट कवरेज एनालाइज़र

रिस्क-आधारित टेस्टिंग की सीमाएँ

• स्कोर subjective होते हैं। ख़ासकर likelihood एक अनुमान है; अलग-अलग समूह एक ही risk को अलग स्कोर देते हैं, और workshop की सबसे ऊँची आवाज़ बाक़ी सबको anchor कर सकती है। पहले अलग-अलग स्कोर करें, फिर फ़र्क़ पर चर्चा करें।
• झूठी सटीकता (false precision)। दो ordinal संख्याओं का गुणा एक ऐसी संख्या देता है जो सटीक दिखती है पर है नहीं: 12 ठीक-ठीक 8 से 50% ज़्यादा जोखिम भरा नहीं है। स्कोर को sort और band करने में इस्तेमाल करें, उनसे प्रतिशत या औसत कभी न निकालें।
• अज्ञात risk अज्ञात ही रहते हैं। Register में सिर्फ़ वे failures होते हैं जिनकी किसी ने कल्पना की। किसी सूचीबद्ध risk से न जुड़ा exploratory testing समय रखें।
• Register पुराने पड़ जाते हैं। प्रोजेक्ट की शुरुआत में लिखा और कभी अपडेट न हुआ register झूठा भरोसा देता है। तय बिंदुओं पर दोबारा स्कोर करें।
• Low risk का मतलब no risk नहीं। Low-risk हिस्सों को भी न्यूनतम जाँच मिलती है, और रिलीज़ दर रिलीज़ बार-बार टालना अपने आप में risk है।
• नौकरशाही। छोटे बदलाव के लिए उन्हीं दो सवालों — कितनी संभावना, कितना बुरा — के साथ पाँच मिनट की बातचीत काफ़ी है; यह तरीका छोटा भी किया जा सकता है।

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021टेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022सॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।