स्टेकहोल्डर कम्युनिकेशन
Stakeholder communication testing और उन सभी लोगों के बीच information का planned प्रवाह है जिनका product में कोई हित है: developers, product owner, release manager, sponsor, support और operations, और कभी-कभी client या compliance officer। यह तय करता है कि कौन-से facts किस तक, कब और किस रूप में पहुँचें, ताकि हर व्यक्ति अपना फ़ैसला समय पर ले सके।
उदाहरण: release से तीन दिन पहले payment sandbox बंद हो जाता है। Developer को एक घंटे के अंदर error चाहिए, product owner को उसी सुबह impact और options, और sponsor को product owner से सिर्फ़ एक वाक्य, वह भी तभी जब date बदले। Test reporting वाले lesson ने report को उसके reader से मिलाया था; यह lesson testing के आसपास के पूरे communication को कवर करता है, उन लोगों समेत जो कभी test report नहीं पढ़ते।
यह क्यों ज़रूरी है
कई release crises defect से कम और surprise से ज़्यादा पैदा होते हैं: sponsor को launch के दिन पता चलता है कि एक हिस्सा कभी टेस्ट ही नहीं हुआ, या support desk को किसी known issue का पता customers से चलता है। समय options भी छीन लेता है: release से दो हफ़्ते पहले scope या लोग बदले जा सकते हैं; release के दिन सिर्फ़ "risk के साथ ship करो" या "date आगे बढ़ाओ" बचते हैं।
Tester के लिए information की value तभी है जब वह फ़ैसला होने से पहले उस तक पहुँचे। जो tester problems जल्दी, facts और options के साथ उठाता है, उस पर भरोसा होता है और उसे planning में बुलाया जाता है; जिसकी ख़बर देर से आती है, उसे ऐसा gate माना जाता है जो सिर्फ़ "ready नहीं है" कहता है।
किसे क्या चाहिए, और कब
Stakeholder हर वह व्यक्ति है जो product और testing से मिलने वाले फ़ैसलों पर असर डालता है या उनसे प्रभावित होता है। अपना communication map organisation chart से नहीं, फ़ैसलों से बनाएँ: हर stakeholder के लिए लिखें कि वह कौन-सा फ़ैसला लेता है, उस फ़ैसले को कौन-सी information चाहिए (उससे ज़्यादा नहीं), updates का routine rhythm क्या है, और कौन-से triggers अगले update का इंतज़ार नहीं कर सकते।
कुछ teams पहले stakeholders को power/interest grid पर रखती हैं, जो project management का एक आम tool है: ज़्यादा power (फ़ैसले पर असर) और ज़्यादा interest का मतलब क़रीबी भागीदारी; ज़्यादा power और कम interest का मतलब छोटे summaries, ताकि वे संतुष्ट रहें; कम power पर ज़्यादा interest, जैसे support desk, का मतलब नियमित जानकारी; और दोनों कम हों तो कभी-कभार एक general update।
- चुप रहने वालों को भी list करें: support, operations, security, marketing जब launch date public हो, और external client।
- Information फ़ैसले से निकालें: launch का फ़ैसला लेने वाले sponsor को residual risk और हर option की cost चाहिए, test cases की गिनती नहीं।
- Triggers पहले से तय करें: किसी must-have feature में Blocker या Critical defect, आधे दिन तक बंद environment, या exit criteria पूरे न होने का अनुमान।
- तय करें कि किसे कौन बताएगा: tester decision owner को बताता है; marketing या client को date बदलने की बात product owner बताता है, tester नहीं।
| Stakeholder | उनका फ़ैसला | Testing से क्या चाहिए | Routine | तुरंत बताएँ जब |
|---|---|---|---|---|
| Developers और dev lead | पहले क्या fix हो, और कैसे | Defect IDs, steps, logs, failed और blocked tests | लगातार: tracker, chat, stand-up | कोई Blocker, या test environment बंद |
| Product owner | Priority, scope, date और कौन-से risks स्वीकार हों | Feature और risk के हिसाब से progress, severity के हिसाब से open defects, ज़रूरी फ़ैसले | रोज़ या हर sprint | किसी must-have feature, scope या date पर risk |
| Release या delivery manager | Release plan, लोग और coordination; go/no-go meeting का आयोजन | Plan के मुक़ाबले forecast, impediments, project risks | हर हफ़्ते, और go/no-go पर | Exit criteria पूरे न होने का अनुमान |
| Sponsor या senior management | Launch, budget और business risk | आसान शब्दों में status, residual risk, हर option की cost | हर milestone पर, एक page में | Date, budget या reputation पर risk, आम तौर पर product owner के ज़रिए |
| Support और operations | Release के लिए तैयारी और staffing कैसे हो | Known issues, workarounds, बदला हुआ behaviour, release और rollback का समय | हर release से पहले | कोई known issue ship होगा, या release का समय बदला |
| Client या compliance officer | Acceptance, या rules का पालन | Formal evidence और traceability | तय milestones पर | जैसा contract या regulation माँगे |
- Outlined column: वे triggers जो routine update का इंतज़ार नहीं करते
Illustrative map: roles और rhythm हर team में अलग होते हैं। अपना map test plan में तय करें और product owner व release manager के साथ review करें।
बुरी ख़बर जल्दी, options के साथ
Problem को confirm होते ही और उसका impact बता पाने पर उठाएँ, fix पता चलने पर नहीं। Uncertainty भी ख़बर है: "estimate 15:00 बजे आएगा" से owner plan कर पाता है, जबकि चुप्पी से वह मान लेता है कि सब ठीक है। कई teams "no surprises" नियम पर चलती हैं: किसी फ़ैसले के ज़िम्मेदार व्यक्ति को किसी problem का पहली बार पता meeting में या customer से नहीं चलना चाहिए।
जो status ऊपर से green रहता है जबकि नीचे काम बिगड़ रहा होता है, जिसे कुछ teams watermelon status कहती हैं (बाहर से green, अंदर से red), वह आम तौर पर छोटी देरियों से बनता है जिनमें से हर एक report करने लायक़ नहीं लगी। पहले से तय triggers amber होने को, यानी green और red के बीच के warning रंग पर जाने को, judgement नहीं, नियम बना देते हैं।
Problem के owner और decision के owner को पहले और अकेले में बताएँ, ताकि status meeting में कोई अचानक न घिरे। Testing mindset वाले lesson ने tone सिखाया था; escalation उसमें structure जोड़ता है, ताकि reader आपका analysis दोबारा करने की बजाय फ़ैसला ले सके:
- Headline: क्या risk में है और कौन-सा फ़ैसला चाहिए, एक वाक्य में।
- Facts: आपने क्या देखा, evidence क्या है और आप कितने निश्चित हैं।
- Reader की भाषा में impact: users, पैसा, date या reputation।
- Cost और risk के साथ options, risk स्वीकार करने समेत, और आपकी recommendation, आपकी राय के रूप में।
- किसे कब तक फ़ैसला लेना है, और आपका अगला update कब आएगा।
सही format चुनना
ISTQB Foundation syllabus आम साधन गिनाता है: team और दूसरे stakeholders से बातचीत, dashboards, email और chat, online documentation और formal test reports; और दूरी या time zones से बँटी teams के लिए ज़्यादा formal communication। चार सवालों से चुनें: बात कितनी urgent है, क्या इस पर चर्चा चाहिए, क्या इसका record ज़रूरी है, और reader के पास कितना समय है?
- जब ख़बर urgent, बुरी या आसानी से गलत समझी जाने वाली हो, तो पहले बात करें; फिर एक घंटे के अंदर लिखकर confirm करें।
- Team में जल्दी coordination के लिए chat; वहाँ लिए गए फ़ैसले scroll होकर खो जाते हैं, इसलिए उन्हें record में copy करें।
- Routine status और जिसका record ज़रूरी हो, उसके लिए email या लिखित update: subject में status, पहली line में headline (कुछ teams इसे BLUF कहती हैं, bottom line up front)। Client को एक page का summary PDF के रूप में भेजा जा सकता है।
- उन trends के लिए dashboards जिन्हें readers ख़ुद देखते हैं; dashboard किसी को यह बताने की जगह कभी नहीं लेता कि कोई problem उस पर असर डालती है।
- कई लोगों वाले फ़ैसलों के लिए meetings: triage, go/no-go, और Scrum में key stakeholders के साथ Sprint Review। Daily Scrum Developers का event है, stakeholders तक escalation का channel नहीं।
- स्वीकार किए गए risks के लिए decision log: क्या, किसने, कब और क्यों। अलग time zones में हर deadline उसके time zone के साथ लिखें।
आज़माएँ: Markdown फ़ॉर्मेटर आज़माएँ: वर्ड काउंटर आज़माएँ: Timezone कन्वर्टर आज़माएँ: Markdown को PDF में बदलें
Worked example: launch से दो दिन पहले Critical defect
एक grocery delivery app release 3.8 गुरुवार 10:00 बजे एक marketing campaign के साथ launch करता है। मंगलवार 11:20 बजे tester GR-214 confirm करता है: timeout के बाद card payment retry करने पर loyalty points दो बार कटते हैं। Fix के बाद retest और regression में लगभग एक दिन लगता है, इसलिए fix बुधवार 10:00 तक आना चाहिए।
11:30 बजे tester developer और product owner को एक साथ call करता है; 12:15 बजे नीचे वाला escalation product owner और release manager को जाता है। Tester company channel में post नहीं करता और marketing को नहीं लिखता: date की owner product owner है, और वही marketing और support को बताती है।
- 15:00 बजे estimate आता है: दो दिन। 15:30 बजे product owner option B चुनती है; release manager sponsor को बताता है, और support को known-issue note मिलता है।
- Tester फ़ैसला log करता है (3.8 में redemption बंद, fix 3.8.1 में, product owner, मंगलवार 15:30) और एक test जोड़ता है कि flag सच में redemption छिपाता है।
- बुधवार की go/no-go में कुछ भी नया नहीं होता: हर risk पहले ही अपने owner तक पहुँच चुका है।
To: Sara (product owner), Faisal (release manager)
Cc: Omar (development lead)
Subject: AT RISK - release 3.8 (गुरुवार 10:00), बुधवार 10:00 तक फ़ैसला चाहिए
Release 3.8 at risk है: आज एक Critical defect मिला है और fix का अभी
कोई estimate नहीं है।
Facts
- GR-214: timeout के बाद card payment retry करने पर loyalty points दो
बार कटते हैं। Build rc2 पर 4 में से 4 बार reproduce हुआ।
- हर वह customer प्रभावित है जो payment का कुछ हिस्सा points से देता है
और जिसकी पहली payment attempt timeout होती है।
- Checkout developer आज 15:00 बजे estimate देंगे।
Impact
- Campaign के दौरान customers के points कटेंगे; support tickets आएँगे।
- Fix के बाद: retest और checkout regression में लगभग 1 दिन।
Options
A. Fix, retest और गुरुवार को planned release, तभी जब fix बुधवार
10:00 तक आ जाए।
B. गुरुवार को release, points redemption feature flag से बंद; fix
3.8.1 में। Support को known-issue note चाहिए।
C. Release और campaign को रविवार तक आगे बढ़ाएँ।
मेरी recommendation: 15:00 के estimate के बाद तय करें; अगर fix बुधवार
10:00 तक नहीं आ सकता तो B चुनें।
अगला update: आज 15:30, estimate के बाद।आम गलतियाँ
- Problem उठाने से पहले fix या निश्चितता का इंतज़ार करना, जिससे decision owner के ज़रूरी दिन निकल जाते हैं।
- बिना options के escalate करना: "हमारे पास एक problem है" कहकर अपना analysis reader पर डाल देना।
- Decision owner को bypass करना, या किसी developer के defect को पहली बार status meeting में सबके सामने रखना।
- सबको एक ही message भेजना: sponsor को test counts, और logs चाहने वाले developer को एक line का summary।
- फ़ैसलों को call या chat में ही छोड़ देना, बिना यह record किए कि किसने कौन-सा risk स्वीकार किया।
- आख़िरी दिन तक status green रखना, क्योंकि हर देरी छोटी लगी।
QA का नज़रिया
Release की शुरुआत में communication map लिखें, test plan में या एक छोटे wiki page पर, और उसे product owner और release manager के साथ review करें। Triggers, channels और कौन किसे बताएगा, यह तय करने का सही समय यही शांत पल है।
Testing के दौरान हर "अगला update इतने बजे" वाला वादा निभाएँ, भले कुछ न बदला हो, और फ़ैसले होते ही दर्ज करें। Go/no-go में कुछ नया नहीं होना चाहिए। Release के बाद दो-तीन stakeholders से पूछें कि क्या उन्हें ज़रूरी जानकारी समय पर मिली, और map को सुधारें।
अभ्यास
Weekend से पहले मिली problem के लिए communication plan बनाएँ
आप एक private school group के school-fees portal पर अकेले tester हैं। Release 2.0 रविवार 08:00 बजे live होता है, जब parents को link वाला SMS मिलता है। अभी गुरुवार 13:00 है, release से पहले का आख़िरी working day।
Plan करें कि किसे क्या, कैसे और कब तक पता चले, और FEE-31 का escalation अधिकतम 150 शब्दों में लिखें।
Portal: school fees 2.0 · go-live रविवार 08:00 · सभी parents को SMS 08:00 बजे
अभी: गुरुवार 13:00 (शुक्रवार और शनिवार working days नहीं हैं)
Stakeholders
Khalid development lead
Huda product owner
Mona school group की finance manager (client; go-live approve करती हैं)
Support दो agents, रविवार 07:30 से
Tariq school group के head of IT (servers और SMS account चलाते हैं)
Findings
FEE-31 Critical: 3 में से 2nd instalment के बाद screen और PDF receipt
अब भी पूरी रकम बकाया दिखाते हैं। Database सही है।
Release candidate पर 3 में से 3 बार reproduce हुआ।
BLK-4 SMS link test blocked: SMS sandbox account set up नहीं है।
असली SMS रविवार 08:00 बजे हर parent को जाएगा।- पाँचों stakeholders का map बनाएँ: फ़ैसला, ज़रूरत, routine, triggers।
- तय करें कि हर finding के बारे में सबसे पहले किसे, किस format में और कितने बजे तक पता चले।
- FEE-31 का escalation लिखें।
- बताएँ कि आप क्या और कहाँ record करेंगे।
मॉडल उत्तर दिखाएँ
Map: Khalid तय करते हैं कि पहले क्या fix हो; उन्हें IDs, steps और logs चाहिए, रोज़ tracker में, और किसी भी Critical पर तुरंत। Huda scope और date की owner हैं; उन्हें impact और options रोज़ के summary में चाहिए, और go-live पर risk होते ही तुरंत। Mona go-live approve करती हैं; उन्हें Huda से milestones पर आसान शब्दों में status चाहिए, और date या instalment option बदले तो तुरंत। Support तय करता है कि रविवार के लिए तैयारी कैसे हो; उसे release से पहले known issues और workarounds चाहिए, और कोई known issue ship होना हो तो तुरंत। Tariq तय करते हैं कि deployment और SMS कैसे और कब हों; उन्हें deployment plan चाहिए, और deployment या SMS बदलने वाली हर बात तुरंत।
क्रम: 13:30 तक Khalid और Huda को एक साथ call करें; आज के बाद go-live से पहले कोई working day नहीं बचा, इसलिए सिर्फ़ email देर से पढ़ा जा सकता है। उसी call में Huda को BLK-4 एक open risk के रूप में बताएँ, क्योंकि बिना test हुआ link हर parent तक जाएगा। 14:00 बजे escalation Huda को भेजें, Khalid को copy में; Huda, Mona को बताती हैं। BLK-4 के लिए अभी Tariq को call करें: sandbox सिर्फ़ वही set up कर सकते हैं। Mona या parents से ख़ुद संपर्क न करें।
Escalation: "AT RISK: fees portal 2.0 (रविवार 08:00), आज 16:00 तक फ़ैसला चाहिए। FEE-31 (Critical): तीन में से दूसरी instalment के बाद screen और PDF receipt पूरी रकम बकाया दिखाते हैं; database सही है (release candidate पर 3 में से 3)। Impact: parents पहले से चुकाई गई instalments दोबारा pay कर सकते हैं; finance को refunds देने होंगे। Options: A) आज fix, मैं आज शाम retest करूँ (लगभग 3 घंटे), तभी जब fix 18:00 तक आए; B) instalments छिपाकर release, fix 2.0.1 में; C) go-live और SMS एक हफ़्ता आगे। Recommendation: Khalid 15:00 तक confirm करें कि fix 18:00 तक आ जाएगा तो A, नहीं तो B। अगला update: 15:30।"
Record: फ़ैसला, किसने और कब लिया, decision log में; BLK-4 open risk के रूप में, owner Tariq। Huda के साथ तय करें कि support को आज कौन बताएगा: B चुना जाए तो known-issue note, C चुना जाए तो नई date, क्योंकि support रविवार 07:30 से काम शुरू करता है और शुक्रवार और शनिवार working days नहीं हैं। BLK-4 का fallback, Tariq की सहमति से: रविवार 07:30 बजे असली SMS पहले कुछ staff phones पर भेजें और parents तक पहुँचने से पहले link जाँचें।
अक्सर पूछे जाने वाले सवाल
क्या stakeholder communication और test reporting एक ही हैं?
नहीं। Test reports उसका सिर्फ़ एक channel हैं। Stakeholder communication में escalations, बातचीत, meetings, dashboards और decision records भी आते हैं, और support या operations जैसे लोग भी, जो शायद कभी test report नहीं पढ़ते।
क्या tester को सीधे senior management तक escalate करना चाहिए?
आम तौर पर नहीं। Decision owner को बताएँ, जो अक्सर product owner या release manager होता है, और तय करें कि senior management को कौन बताएगा। अगर आपको लगे कि कोई गंभीर risk नज़रअंदाज़ हो रहा है, तो decision owner को खुलकर बताएँ कि आप इसे अगले level पर उठाएँगे, फिर अपने organisation का escalation path अपनाएँ।
Problem कब उठाना बहुत जल्दी माना जाएगा?
जब problem confirm हो जाए और आप उसका impact बता सकें, तब उठाएँ, भले cause या fix पता न हो। उससे पहले area के owner को छोटा-सा note ("मैं कुछ ऐसा जाँच रहा हूँ जो checkout पर असर डाल सकता है; 15:00 तक और बताऊँगा") उपयोगी है, लेकिन वह अभी बड़े audience के लिए ख़बर नहीं है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- The 2020 Scrum GuideScrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
Mutqan tools से अभ्यास करें
Markdown की फ़ॉर्मेटिंग (हेडिंग, सूचियाँ, टेबल, emphasis) सामान्य करें और रेंडर किया नतीजा देखें।
शब्द, वाक्य, पैराग्राफ़, पढ़ने का समय और कीवर्ड की आवृत्ति गिनें।
तारीख़ और समय को अलग-अलग timezone के बीच बदलें (रियाद, अम्मान, दिल्ली, UTC, न्यूयॉर्क, लंदन…)।
किसी तारीख़ में दिन, सप्ताह, महीने, वर्ष, घंटे और मिनट जोड़ें या घटाएँ।
Markdown (.md) फ़ाइलों को ब्राउज़र में PDF में बदलें: शीर्षक, सूचियाँ, तालिकाएँ, कोड ब्लॉक, उद्धरण, लिंक और चित्र एम्बेडेड फ़ॉन्ट से टाइपसेट।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।