प्रोजेक्ट रिस्क मैनेजमेंट
Project risk management वह तरीका है जिससे test manager किसी release की testing को तब भी संभव बनाए रखता है जब उसके आसपास का project गड़बड़ाने लगे। Project risk एक अनिश्चित घटना है जो, अगर हो जाए, तो product की quality पर नहीं बल्कि project के schedule, budget या scope पर असर डालती है। उदाहरण: payment provider का shared sandbox (उसकी सेवा का test version) test window के दौरान कई दिन down रह सकता है, जिससे हर payment test रुक जाए।
इसे manage करना एक loop है जो पूरी release में चलता है: हर risk को सटीक रूप से लिखें, उसकी likelihood और impact आँकें, response चुनें, उसे एक owner और ज़रूरत हो तो एक trigger दें, उसे risk log (जिसे risk register भी कहते हैं) में रखें, तय बिंदुओं पर review करें, और go/no-go मीटिंग में, जहाँ release owners तय करते हैं कि release होगी या नहीं, बताएँ कि क्या अब भी खुला है।
यह क्यों ज़रूरी है
जब कोई project risk बिना planning के हो जाता है, तो नुकसान आम तौर पर testing झेलती है। Environment एक हफ़्ता देर से आता है, release date नहीं खिसकती, और test window चुपचाप सिकुड़ जाती है। तब जिन product risks को testing को कम करना था, उनकी testing कम गहराई से होती है, और यह किसी ने जानबूझकर तय नहीं किया होता।
Test manager के लिए risk log शिकायतों को फ़ैसलों में बदल देता है: "हमारे पास अब भी test data नहीं है" एक दर्ज risk बन जाता है जिसका owner, deadline और fallback होता है, और वह तब उठाया जाता है जब कुछ करने का समय बचा हो। Go/no-go पर यही log दिखाता है कि project की समस्याओं ने testing को कैसे बदला, इससे पहले कि कोई production में यह कमी खोजे।
Project risk और वह कहाँ से आता है
Risk-Based Testing guide से एक recap: ISTQB CTFL v4.0 product risks, यानी वे तरीके जिनसे product अपने users को निराश कर सकता है (गलत total, data leak), को project risks से अलग करता है, यानी वे तरीके जिनसे project समय पर, budget में या पूरे scope के साथ deliver करने में fail हो सकता है। Testing product risk को सीधे कम करती है, क्योंकि test डर वाले failure को users तक पहुँचने से पहले पकड़ सकता है; ज़्यादा test cases लिखने से देर से आने वाला environment जल्दी नहीं आता। दोनों तरह के risks likelihood और impact से आँके जाते हैं, जो risk level देते हैं, और अलग-अलग owners वाली अलग सूचियों में रखे जाते हैं।
हर risk को cause, event और effect के रूप में लिखें ताकि response के पास काम करने लायक कुछ हो: payment sandbox दूसरे clients के साथ shared है (cause), इसलिए हो सकता है वह हमारी test window में उपलब्ध न हो (event) और payment tests रुक जाएँ (effect)। निश्चित घटना, जैसे fixed go-live date, risk नहीं बल्कि एक constraint है जिसके हिसाब से plan करना है।
Syllabus project risks को organisational, people, technical और supplier issues में बाँटता है। Testing में ये आम तौर पर चार जगह दिखते हैं:
- Environments: दूसरी टीम के साथ shared staging, production से अलग test environment, test window के दौरान down sandbox।
- Staffing: कोई integration जानने वाला अकेला व्यक्ति, दूसरे project में भेजा गया tester, ऐसा test type जो किसी ने पहले नहीं किया।
- Suppliers: third-party API का देर से आना या बिना सूचना बदल जाना, outsourced टीम का delivery चूक जाना।
- Schedule: देर से आए builds, retesting के लिए समय न छोड़ने वाला estimate, fixed release date जो test window को ही buffer बना देती है।
Response चुनना
Risk का analysis हो जाने के बाद CTFL v4.0 (section 5.2.4) संभावित responses के चार उदाहरण देता है: testing से risk mitigation, risk acceptance, risk transfer और contingency plan। वह section product risks के बारे में है; project risks पर भी यही options लागू होते हैं, बस वहाँ mitigation का मतलब tests नहीं बल्कि management action है। Risk management की सामान्य practice एक पाँचवाँ option भी जोड़ती है: avoidance।
Options को मिलाया जा सकता है, और शुरुआत का एक उपयोगी नियम उन्हें rating से जोड़ता है: likelihood बढ़े तो ज़्यादा mitigation, impact बढ़े तो contingency plan या transfer जोड़ें, और दोनों ऊँचे हों तो avoidance पर विचार करें और escalate करें। व्यवहार में:
- Acceptance: risk छोटा है, या response की लागत नुकसान से ज़्यादा है। किसने accept किया यह दर्ज करें और नज़र रखते रहें; acceptance एक नाम वाला फ़ैसला है, चुप्पी नहीं।
- Transfer: risk को ऐसे पक्ष को सौंपें जो उसे बेहतर संभाल सके, जैसे load test को तय तारीख़ तक चलाने के लिए contract पर ली गई specialist firm। तब उस firm की delivery आपके log में एक supplier risk बन जाती है।
- Contingency plan: अभी तय करें कि risk होने पर आप क्या करेंगे (mock पर testing, किसी tester को उधार लेना, low-risk tests टालना), और वह trigger तय करें जो इसे शुरू करेगा।
- Mitigation: likelihood या impact घटाने के लिए अभी कदम उठाएँ: environment जल्दी book करें, अकेले expert के साथ दूसरे tester को जोड़ें, छोटे और जल्दी builds माँगें।
- Avoidance: plan बदलकर cause को ही हटा दें, जैसे किसी unready supplier पर निर्भर feature को अगली release में ले जाना; इससे scope बदलता है, इसलिए फ़ैसला product owner करता है।
| Likelihood | Impact | ||
|---|---|---|---|
| Low | Medium | High | |
| High | Mitigate या acceptबार-बार पर छोटा: सस्ता हो तो mitigate करें | Mitigatelikelihood घटाने के लिए अभी कदम उठाएँ | Avoid, या mitigate + contingency plan या transferescalate करें: date, scope या budget |
| Medium | Accept और monitorकिसने accept किया, दर्ज करें | Mitigate या contingency planदोनों की लागत की तुलना करें | Mitigate + contingency plantrigger पहले से तय करें |
| Low | Acceptlog में दर्ज करें | Accept और monitorहर review पर फिर से rate करें | Contingency plan या transferदुर्लभ पर गंभीर: सिर्फ़ accept न करें |
- Accept: फ़ैसला दर्ज करें और नज़र रखें
- लागत उचित हो तो response दें
- अभी response दें: risk होने से पहले कदम उठाएँ या तैयारी करें
- Escalate: फ़ैसला test team के अधिकार से ऊपर है
- कम likelihood, ऊँचा impact: दुर्लभ होने पर भी उसकी planning करें
- पाँच responses
- Accept दर्ज फ़ैसले से उसे स्वीकार करें, फ़ैसला किसने लिया यह लिखें
- Transfer बेहतर स्थिति वाला पक्ष उसे उठाता है, आम तौर पर contract से
- Contingency plan अभी तैयार, सिर्फ़ trigger चलने पर शुरू
- Mitigate likelihood या impact घटाने के लिए अभी कदम
- Avoid plan बदलें ताकि cause ही न रहे
यह शुरुआती बिंदु है, नियम नहीं: हर response की लागत और कौन कदम उठा सकता है, यह भी चुनाव तय करते हैं।
Testing से mitigation
जब कोई project risk किसी product risk पर पड़ता है, जैसे देर से आया build जो किसी high-risk feature का बचा समय काट दे, तो testing build को जल्दी नहीं ला सकती, लेकिन यह तय करती है कि बचा हुआ effort कहाँ जाएगा; जो untested रह जाता है वह residual risk है जिसे report करना है। CTFL v4.0 testing से product risks को mitigate करने के लिए ये actions बताता है:
- ऐसे testers चुनें जिनके पास उस risk type के लिए ज़रूरी अनुभव और skills हों।
- Independence का सही स्तर रखें: high-risk हिस्से को वह व्यक्ति टेस्ट करे जिसने उसे बनाया नहीं।
- Reviews और static analysis करें, जो environment तैयार होने से पहले भी काम करते हैं।
- उपयुक्त test techniques और coverage levels लगाएँ, जैसे pricing rules के लिए decision tables।
- प्रभावित quality characteristics के लिए test types लगाएँ, जैसे capacity risk के लिए performance tests।
- Regression testing समेत dynamic testing करें, ताकि जल्दबाज़ी के fixes पहले से चलती चीज़ों को न तोड़ें।
आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: रिग्रेशन सिनेरियो जनरेटर
Triggers, owners और risk log
Contingency trigger एक observable शर्त है, पहले से तय, जो fallback शुरू करती है, जैसे: "payment build दिन 5 के अंत तक test environment में नहीं है"। Trigger के बिना टीम तब तक इंतज़ार और उम्मीद करती रहती है जब तक fallback इस्तेमाल करने का समय ही न बचे।
हर risk का एक owner होता है: कोई टीम नहीं, एक नामित व्यक्ति, जो उस पर नज़र रखता है, response लागू करता है और status बताता है, और जो अक्सर QA के बाहर से होता है (builds के लिए development lead, environments के लिए operations lead, suppliers के लिए vendor manager)। Escalation का नियम भी तय करें: जब response को date, scope या budget पर फ़ैसला चाहिए, तो owner उसे options और फ़ैसले की तारीख़ के साथ project manager या product owner के पास ले जाए।
Log को पूरी release के दौरान बनाए रखें:
- Risks test planning में उठाएँ, और नए risks उसी दिन जोड़ें जिस दिन वे दिखें।
- Log को तय बिंदुओं पर review करें: साप्ताहिक status मीटिंग, हर test cycle का अंत, और go/no-go से पहले।
- बदलाव तारीख़ों के साथ दर्ज करें: re-rating, चले हुए triggers, फ़ैसले और उन्हें किसने लिया।
- जब कोई risk हो जाए, उसे issue के रूप में चिह्नित करें और testing पर उसका असर track करें; risk को तभी close करें जब सबूत हो या acceptance दर्ज हो।
Worked example: risk log से go/no-go तक
एक काल्पनिक clinic booking app, release 2.4, third-party provider के ज़रिए online payment और SMS reminders जोड़ता है; test window 15 working days की है और go-live date fixed है। Release के दौरान दो contingency triggers चले। इस section के अंत में दिया log पाँचों project risks को go/no-go मीटिंग के समय की स्थिति में दिखाता है।
Go/no-go पर test manager log को पढ़कर नहीं सुनाता। Report का project-risk हिस्सा तीन सवालों के जवाब देता है:
- क्या हुआ और testing पर उसका क्या असर पड़ा: sandbox outage (likelihood Low आँकी गई थी, पर High impact की वजह से contingency plan तैयार था) को mock और 8 key flows की retest से संभाला गया; देर से आए build ने contingency plan शुरू कर दिया।
- क्या untested रह गया: reports module का regression, जिसके product risks Low हैं। Product owner ने दिन 7 को इसे लिखित में accept किया, और यह residual risk में दर्ज है।
- मीटिंग को क्या तय करना है: इस residual risk के साथ release की पुष्टि, और टाले गए regression को release के बाद पहले हफ़्ते में चलाना।
Project risk log - Clinic booking 2.4 - go/no-go पर status (दिन 15)
PR1 Shared payment sandbox -> हमारी window में down -> payment tests रुके
L Low | I High Contingency: provider mock पर testing, बाद में retest
Trigger: sandbox 4 working hours से ज़्यादा down Owner: test lead
दिन 6: TRIGGERED। दिन 11: 8 key flows sandbox पर retest हुए। CLOSED
PR2 SMS gateway सिर्फ़ Omar जानता है -> वह उपलब्ध नहीं -> SMS tests रुके
L Medium | I Medium Mitigation: दिन 1 से 3 तक Huda, Omar के साथ pair
Owner: QA manager दिन 3: test notes लिखे गए। CLOSED
PR3 Payment build देर से -> test window सिकुड़ी -> regression कटा
L High | I High Mitigation: दो छोटे drops
Contingency: Low-risk regression टालना
Trigger: दिन 5 के अंत तक build test में नहीं Owner: test manager
दिन 6: TRIGGERED, escalate किया। दिन 7: product owner ने reports-module
regression को release के बाद पहले हफ़्ते तक टालना accept किया। ISSUE, open
PR4 टीम में load-test skills नहीं -> peak-hour test नहीं हुआ
L High | I High Transfer: specialist firm, report दिन 12 तक
Owner: QA manager दिन 12: report मिली। CLOSED
PR5 Insurer API का test environment नहीं -> eligibility check टेस्ट नहीं हो सकता
L High | I High Avoidance: eligibility check release 2.5 में भेजा गया
Owner: product owner दिन 2: फ़ैसला हुआ। CLOSEDआम गलतियाँ
- Project और product risks को एक ही सूची में मिला देना, या देर से आ रहे environment का जवाब ज़्यादा test cases से देना।
- निश्चित बातों को risk के रूप में दर्ज करना: fixed go-live date या तय छुट्टी एक constraint है जिसके हिसाब से plan करना है, अनिश्चित घटना नहीं।
- Trigger के बिना contingency plan लिखना, जिससे किसी को पता नहीं होता कि कब switch करना है और fallback बहुत देर से शुरू होता है।
- किसी टीम ("Dev", "QA") को या किसी को भी owner न बनाना, और उन फ़ैसलों को escalate करने का कोई नियम न होना जो test team नहीं ले सकती।
- Testing घटाकर project risk को चुपचाप झेल लेना, जिससे go/no-go report खोई हुई coverage को छिपा लेती है।
- Kick-off पर log लिखकर फिर कभी review न करना, या सबूत या दर्ज acceptance के बिना risks close कर देना।
QA का नज़रिया
Project risk सूची test planning के दौरान शुरू करें, project manager, development lead, product owner और environments चलाने वाले व्यक्ति के साथ एक छोटे session में। दो सवाल पूछें: कौन-सी बात testing को plan के मुताबिक़ होने से रोक सकती है, और अगर ऐसा हुआ तो हम क्या खोएँगे? जवाबों को cause, event और effect के रूप में दर्ज करें, और session ख़त्म होने से पहले owners तय कर लें।
फिर log को ज़िंदा रखें: हर हफ़्ते उसका review करें, कोई trigger चले तो उसी दिन fallback की लागत के साथ बताएँ, और जो risks आप नहीं संभाल सकते उन्हें निजी सूची में रखने के बजाय project manager के log में भेजें। Go/no-go पर हर हुए project risk को उन product risks से जोड़ें जिन्हें उसने कम टेस्ट होने दिया, ताकि release owner residual risk सोच-समझकर accept कर सके।
अभ्यास
Registration portal के लिए project risk log बनाएँ
आप नीचे दी गई release के test manager हैं। Planning notes से एक project risk log बनाएँ, फिर go/no-go report का project-risk हिस्सा draft करें।
Student registration portal, release 3.1
Test window: 10 working days। Go-live fixed है: registration 1 सितंबर को खुलता है।
Planning मीटिंग के notes:
1. Student information system (SIS) टीम नया course API "लगभग दिन 3" तक देगी;
उनकी पिछली दो deliveries देर से आई थीं।
2. Fee-payment integration सिर्फ़ Rana ने टेस्ट किया है; वह दिन 7 और 8 को छुट्टी पर है।
3. Accessibility audit एक external firm करती है; उसने अभी start date confirm नहीं की।
4. टीम में किसी ने पहले registration-day traffic का load test नहीं किया।- Facts और constraints को risks से अलग करें; हर risk को cause, event और effect के रूप में लिखें।
- Likelihood और impact को High, Medium या Low आँकें, और response चुनें, ज़रूरत हो तो options मिलाकर।
- हर contingency plan को जाँचने लायक trigger दें, हर risk को एक owner, और सबसे गंभीर risk को escalation का नियम।
- मान लें कि course API दिन 6 को आता है, और go/no-go report का project-risk हिस्सा कुछ वाक्यों में लिखें।
मॉडल उत्तर दिखाएँ
ये risks नहीं हैं: fixed go-live date और Rana की छुट्टी निश्चित हैं, इसलिए आप उनके हिसाब से plan करते हैं। Fixed date का मतलब है कि schedule risks test scope पर पड़ेंगे।
R1: course API दिन 3 के बाद आ सकता है (SIS टीम पहले देर कर चुकी है), जिससे course tests के लिए बहुत कम समय बचेगा। L High, I High। Mitigate: API contract और एक early partial drop लें। Contingency: contract से बने mock पर testing; trigger: दिन 3 के अंत तक API test environment में नहीं। यह सबसे गंभीर risk है क्योंकि course registration ही release का मुख्य हिस्सा है और date नहीं खिसक सकती, इसलिए escalation का नियम इसी को मिलता है: अगर दिन 5 के अंत तक भी API नहीं आया, तो product owner feature टालने और low-risk regression टालने में से चुनता है। Owner: test lead।
R2: दिन 7 और 8 के fee-payment fixes को integration जानने वाला कोई retest नहीं कर पाएगा। L High, I Medium। Mitigate: दिन 1 से 3 तक दूसरा tester Rana के साथ pair करता है और दोनों test notes लिखते हैं। Owner: QA manager। R3: accessibility firm इतनी देर से शुरू करे कि go-live से पहले audit न हो। L Medium, I High। Mitigate: तारीख़ वाली लिखित booking। Contingency: मुख्य flows पर in-house checklist pass; trigger: दिन 2 तक start date नहीं। Owner: QA manager।
R4: अनुभव के बिना peak-traffic load test ख़राब तरीके से होगा या होगा ही नहीं। L High, I High। इसे एक specialist firm को transfer करें जिसकी report दिन 8 तक देय हो, और firm की delivery को supplier risk के रूप में log करें। Owner: QA manager।
Go/no-go: "R1 हुआ: API दिन 6 को आया। Contingency दिन 4 से शुरू हुई, इसलिए course tests पहले mock पर, फिर दिन 6 से 10 तक असली API पर चले। हमने दिन 5 को escalate किया, और product owner ने low-risk timetable pages का regression टालना accept किया, जो अब residual risk में दर्ज है।" फिर R2 से R4 का status इसी तरह, हर एक के सबूत के साथ बताएँ, और ज़रूरी फ़ैसला: इस residual risk को accept करके release।
अक्सर पूछे जाने वाले सवाल
Project risk संभालना project manager का काम है या test manager का?
दोनों का। Project का risk log project manager के पास होता है। Test manager testing के लिए risks पहचानता है, जो test team के अधिकार में हैं उन्हें संभालता है, और बाक़ी को प्रस्तावित response और escalation की तारीख़ के साथ project manager को सौंपता है।
Mitigation और contingency plan में क्या फ़र्क है?
Mitigation अभी किया जाता है, risk हो या न हो, ताकि वह कम संभावित या कम नुकसानदेह बने। Contingency plan अभी तैयार किया जाता है, लेकिन लागू सिर्फ़ तब होता है जब risk हो जाए और उसका trigger चल जाए।
Risk हो जाने के बाद उसका क्या होता है?
वह issue बन जाता है: ऐसी चीज़ जिसे हल करना है, जिसका अनुमान नहीं लगाना। Risk entry को उसके इतिहास के साथ रखें, testing पर उसका असर दर्ज करें, और issue को close होने तक track करें। कुछ टीमें risks, assumptions, issues और dependencies को एक ही RAID log में रखती हैं।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesटेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
किसी तारीख़ में दिन, सप्ताह, महीने, वर्ष, घंटे और मिनट जोड़ें या घटाएँ।
CSV और TSV फ़ाइलों को ब्राउज़र में PDF तालिकाओं में बदलें: विभाजक पहचाना जाता है, हर पेज पर हेडर पंक्ति दोहराई जाती है, चौड़ी तालिकाओं के लिए लैंडस्केप स्वतः।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।