क्वालिटी कल्चर
Quality culture साझा आदतों और अपेक्षाओं का वह समूह है जो तय करता है कि टीम रोज़ के काम में quality के साथ कैसा व्यवहार करती है: कौन इसके लिए ज़िम्मेदार महसूस करता है, समस्याएँ कितनी जल्दी उठाई जाती हैं, और कुछ गलत होने के बाद क्या होता है। मज़बूत quality culture में quality पूरी टीम की ज़िम्मेदारी होती है, और हर failure को किसी को दोष देने की वजह नहीं, सीखने लायक जानकारी माना जाता है।
उदाहरण के लिए, एक tester बताती है कि नया payment flow धीमे network पर कभी आज़माया नहीं गया। एक टीम जवाब देती है "समय नहीं है, ship कर दो", और risk release के फ़ैसले तक कभी नहीं पहुँचता; दूसरी टीम पूछती है कि क्या गलत हो सकता है और एक घंटे की जाँच पर सहमत होती है। Skills वही हैं; culture तय करता है कि जानकारी इस्तेमाल होगी या नहीं।
यह क्यों ज़रूरी है
Testing जानकारी देती है, और जानकारी risk तभी घटाती है जब लोग उस पर काम करें। जहाँ बुरी ख़बर अनचाही हो और defects लोगों के ख़िलाफ़ गिने जाएँ, वहाँ समस्याएँ अक्सर तब तक छिपी रहती हैं जब तक customers उन्हें न ढूँढ लें, और defect जितनी देर से मिले, rework, incidents और खोए भरोसे के रूप में उतना महँगा पड़ता है।
Tester के लिए culture काम का स्वरूप ही तय करता है। जहाँ quality "QA का काम" हो, वहाँ tester sprint के अंत में gatekeeper बन जाता है, जिसके पास समय कम होता है और जिसे हर escaped defect के लिए दोषी ठहराया जाता है। जहाँ पूरी टीम quality की ज़िम्मेदारी लेती है, वहाँ tester refinement से शुरू करता है और defects सिर्फ़ ढूँढने में नहीं, रोकने में भी मदद करता है।
Whole-team approach: पूरी टीम का तरीका
टेस्टिंग रोल्स और ज़िम्मेदारियाँ वाले lesson में ISTQB Foundation syllabus v4.0 का whole-team approach आया था। Syllabus यह भी बताता है कि यह क्यों काम करता है: टीम के सदस्य एक workspace साझा करते हैं, physical या virtual, जिससे communication आसान होता है; यह approach team dynamics, communication और collaboration को बेहतर बनाता है, और टीम अपनी सारी अलग-अलग skills project के फ़ायदे के लिए इस्तेमाल कर पाती है।
Business representatives और developers के साथ मिलकर काम करते हुए testers testing का ज्ञान बाकी टीम तक पहुँचाते हैं और product के बनने के तरीके पर असर डालते हैं।
इस तरह quality का काम roles में और पूरे lifecycle में बँट जाता है:
- Development से पहले: product owner, एक developer और एक tester हर story के examples और acceptance criteria पर सहमत होते हैं, जिसे कुछ टीमें "three amigos" session कहती हैं।
- Planning में: टीम product risks को साथ मिलकर आँकती है और तय करती है कि हर risk को कितनी गहराई से टेस्ट करना है।
- Release के बाद: support और operations incidents व complaints साझा करते हैं, जो नए test ideas बनते हैं।
आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर
Psychological safety और blameless postmortems
टीम quality की ज़िम्मेदारी तभी बाँट सकती है जब लोग समस्याएँ उठाने में सहज हों। शोधकर्ता Amy Edmondson इसे psychological safety कहती हैं: टीम के सदस्यों का साझा विश्वास कि इस टीम में आपसी जोखिम उठाना सुरक्षित है, जैसे कोई बुनियादी सवाल पूछना, गलती मानना या किसी senior से असहमत होना। Testers को इसकी ज़रूरत है क्योंकि testing स्वभाव से बुरी ख़बर देती है, और वे judgements की बजाय facts बताकर इसे बनाने में मदद करते हैं।
इस safety की सबसे कड़ी परीक्षा तब होती है जब कोई गंभीर failure users तक पहुँचता है। तब कई टीमें postmortem लिखती हैं, जिसे Google की Site Reliability Engineering book किसी incident का लिखित record बताती है: उसका impact, उसे काबू में करने या सुलझाने के लिए उठाए गए कदम, उसके root causes, और उसे दोबारा होने से रोकने वाले follow-up actions। Blameless postmortem मानता है कि हर व्यक्ति ने अपने पास मौजूद जानकारी के आधार पर नेक इरादे से काम किया, और contributing causes systems और processes में ढूँढता है, सज़ा देने के लिए किसी व्यक्ति में नहीं। Tester आम तौर पर तीन हिस्सों में मदद करता है:
- Timeline: failure कब शुरू हुआ, कैसे और कब पता चला, और कब सुलझा।
- Causes: error से defect और defect से failure तक की कड़ी पर चलें, और पूछें कि error क्यों संभव हुआ और defect पहले क्यों नहीं पकड़ा गया।
- Actions: ठोस बदलाव, हर एक का owner और due date, जिनका पूरे होने तक follow-up होता है।
स्वस्थ quality culture के संकेत
Culture रोज़ की practice में दिखता है। समाजशास्त्री Ron Westrum ने संगठनों को इस आधार पर बाँटा कि वे जानकारी के साथ कैसा व्यवहार करते हैं: pathological culture में संदेशवाहक को सज़ा मिलती है और failure का नतीजा बलि का बकरा ढूँढना होता है; bureaucratic culture में संदेशवाहक को अनदेखा किया जाता है; generative culture में संदेशवाहक को प्रशिक्षित किया जाता है और failure का नतीजा जाँच-पड़ताल होता है। Software delivery पर DORA का research इसी model का इस्तेमाल करता है। Tester अक्सर संदेशवाहक होता है, इसलिए इन संकेतों पर ध्यान दें:
- Testers refinement में हिस्सा लेते हैं, और acceptance criteria development शुरू होने से पहले review होते हैं।
- साझा Definition of Done में testing शामिल है, और समय कम होने पर testing हटाई नहीं जाती। 2020 Scrum Guide इसे Increment की उस स्थिति का औपचारिक वर्णन बताता है जब वह product के लिए ज़रूरी quality measures पूरे करता है।
- Fail हुए build या test की पहले जाँच होती है; उसे अनदेखा नहीं किया जाता, न pass होने तक दोबारा चलाया जाता है।
- Metrics सीखने के लिए इस्तेमाल होते हैं, लोगों की ranking के लिए कभी नहीं: bug-count targets नहीं, हर developer के defects की गिनती नहीं।
- Retrospectives ऐसे actions के साथ ख़त्म होते हैं जो सच में पूरे होते हैं, हर sprint की उन्हीं शिकायतों के साथ नहीं। Scrum में Sprint Retrospective का उद्देश्य quality और effectiveness बढ़ाने के तरीकों की योजना बनाना है।
कमज़ोर quality cultureWestrum: pathological या bureaucratic
Quality testers का काम है
- Testers कब जुड़ते हैं:
- Development के बाद, build जाँचने के लिए
- बुरी ख़बर:
- संदेशवाहक को सज़ा या अनदेखी; बिना टेस्ट हुए risks report नहीं होते
- Escaped defect के बाद:
- किसने छोड़ा? और ज़्यादा sign-offs
- Root cause:
- कोई व्यक्ति, या "human error"
- Definition of Done:
- समय कम होने पर testing हटा दी जाती है
- Fail हुआ build या test:
- अनदेखा, या pass होने तक दोबारा चलाया जाता है
- Metrics:
- लोगों की ranking: bug-count targets, हर developer के defects
- Retrospectives:
- हर sprint वही शिकायतें
मज़बूत quality cultureWestrum: generative
Quality पूरी टीम का काम है
- Testers कब जुड़ते हैं:
- Refinement में, code बनने से पहले
- बुरी ख़बर:
- संदेशवाहक प्रशिक्षित; risks release के फ़ैसले तक पहुँचते हैं
- Escaped defect के बाद:
- Owner और तारीख़ वाले actions के साथ blameless postmortem
- Root cause:
- Error क्यों संभव हुआ और पहले क्यों नहीं पकड़ा गया
- Definition of Done:
- साझा, और testing शामिल
- Fail हुआ build या test:
- पहले जाँच होती है
- Metrics:
- सीखने के लिए इस्तेमाल
- Retrospectives:
- Actions जो सच में पूरे होते हैं
ये संकेत हैं, score नहीं: ज़्यादातर टीमों में दोनों columns की कुछ बातें दिखती हैं।
Worked example: एक escaped defect, दो cultures
एक release के बाद Arabic interface इस्तेमाल करने वाले customers checkout पूरा नहीं कर पाते: right-to-left layout में "Pay now" button छोटे phones पर screen से बाहर चला जाता है। Support दो घंटे बाद इसकी रिपोर्ट करता है और टीम release को roll back कर देती है।
Team A में manager group chat में पूछता है कि इसे किसने टेस्ट किया, और फिर नया नियम आता है: "हर release पर QA sign-off करेगा"। बाकी कुछ नहीं बदलता, और अगले sprint में लोग कम शंकाएँ उठाते हैं, क्योंकि अब शंका का नतीजा दोष होता है।
Team B blameless postmortem करती है। Timeline दिखाती है कि failure टीम ने नहीं, customers ने पकड़ा। हर contributing cause को एक action मिलता है, और एक action tester का भी है:
- Designs और acceptance criteria सिर्फ़ English को cover करते थे। Action: refinement checklist में right-to-left layout जोड़ना (product owner और tester)।
- Story sprint की आख़िरी दोपहर को merge हुई। Action: work in progress सीमित करना ताकि stories पहले पूरी हों (पूरी टीम)।
- छोटी screens पर right-to-left layout के लिए कोई regression check नहीं था। Action: एक check जोड़ना (tester और developer)।
- किसी एक भाषा में पूरे हुए checkouts घटने पर कोई alert नहीं आया। Action: monitoring जोड़ना (operations)।
आम गलतियाँ
- लोगों को आँकने के लिए defect counts इस्तेमाल करना, जैसे हर tester के ढूँढे bugs या हर developer के defects: तब लोग causes ठीक करने की बजाय गिनती पर बहस करने या समस्याएँ छिपाने लगते हैं।
- Escaped defect पर "इसे किसने टेस्ट किया?" पूछकर प्रतिक्रिया देना: तब लोग कम शंकाएँ उठाते हैं और गलतियाँ छिपाते हैं, और अगली समस्या और भी देर से सामने आती है।
- "Blameless" को "कोई follow-up नहीं" समझना: owner और तारीख़ वाले actions के बिना postmortem कुछ नहीं बदलता।
- किसी व्यक्ति, या "human error", को root cause बताना। सवाल वहीं से शुरू होते हैं, वहाँ ख़त्म नहीं होते।
- टकराव से बचने के लिए बिना टेस्ट हुए risk पर चुप रहना, जिससे release का फ़ैसला उसके बिना हो जाता है।
QA का नज़रिया
Culture घोषणाओं से नहीं, छोटी और बार-बार की practices से बदलता है। Refinement में risks और examples के बारे में पूछें, defects को product के बारे में facts की तरह report करें, और जब कोई defect escape हो, तो postmortem की timeline बनाने में मदद करें और testing के लिए कम से कम एक action सुझाएँ, जैसे कोई छूटा हुआ regression check।
Record करें कि आपने कौन-से risks उठाए और क्या तय हुआ, क्या टेस्ट नहीं हुआ और क्यों, और follow-up actions की स्थिति। Job interviews में ऐसे सवाल पूछें जो culture दिखाएँ: "आपके पिछले postmortem के बाद क्या बदला?" और "जब कोई tester कहता है कि release तैयार नहीं है, तब क्या होता है?"
अभ्यास
Incident note को blameless रूप में दोबारा लिखें
नीचे दिया गया incident note एक failed release के बाद team chat में पोस्ट हुआ था। इसे एक छोटे blameless postmortem के रूप में दोबारा लिखें: summary, impact, timeline, contributing causes, और owner role के साथ follow-up actions। फिर note में कमज़ोर quality culture के दो संकेत पहचानें, और retrospective में पूछने के लिए एक सवाल लिखें। आप इसे Markdown में लिखकर Markdown फ़ॉर्मेटर tool में preview कर सकते हैं।
Incident note, सोमवार को team chat में पोस्ट हुआ
ओमर ने गुरुवार 17:40 पर QA को बताए बिना coupon change merge किया।
लीना ने 20 मिनट टेस्ट किया और यह छूट गया कि expired coupons अब भी चलते हैं।
Customers ने पूरे weekend expired coupons इस्तेमाल किए। Finance ने सोमवार को पकड़ा।
QA पहले भी चीज़ें छोड़ चुका है। अब से हर release पर QA sign-off करेगा,
और ओमर को हर change के लिए manager की approval चाहिए।- नाम और judgements हटाएँ; रखें कि क्या हुआ, कब और किसके साथ।
- हर fact के लिए पूछें कि error क्यों संभव हुआ और वह पहले क्यों नहीं पकड़ा गया।
- हर cause को owner role वाले एक action में बदलें।
मॉडल उत्तर दिखाएँ
Summary: coupon नियमों का एक change, जो गुरुवार 17:40 पर merge हुआ और weekend से पहले release हुआ, expired coupons स्वीकार करता रहा। Finance की एक जाँच ने सोमवार को समस्या पकड़ी।
Impact: weekend के orders को ऐसी छूट मिली जो business का इरादा नहीं थी। समस्या tests या monitoring से नहीं, finance की जाँच से पकड़ी गई।
Timeline: गुरुवार 17:40, change merge हुआ; लगभग 20 मिनट testing हुई और change release हुआ; पूरे weekend orders ने expired coupons स्वीकार किए; सोमवार, finance ने समस्या पकड़ी। Release और fix का सही समय deployment log से लें।
Contributing causes (review में पुष्टि करनी है): testing के तय समय के बिना देर से merge; acceptance criteria में expired coupons का ज़िक्र नहीं; regression suite में expiry check नहीं; orders में coupon validity की monitoring नहीं।
Actions: coupon expiry के नियम acceptance criteria में जोड़ना (product owner और tester); हर release से पहले merge cut-off तय करना (टीम); expired, अभी लागू न हुए और valid coupon के cases regression suite में जोड़ना (tester और developer); expired coupon वाले orders पर alert (operations)।
Culture के संकेत: system की failure के लिए लोगों के नाम लेकर उन्हें दोष दिया गया है, और इलाज पहले के सहयोग की बजाय और ज़्यादा gatekeeping है। Retrospective का सवाल: "किस चीज़ से हममें से कोई भी इसे customers से पहले पकड़ पाता?"
अक्सर पूछे जाने वाले सवाल
टीम कैसे जाने कि उसका quality culture बेहतर हो रहा है?
किसी एक number को नहीं, behaviour और trends को देखें। उपयोगी संकेत: कितने defects users तक पहुँचते हैं और उन्हें किसने पकड़ा, टीम ने या customers ने; fail हुआ build कितनी देर तक ठीक नहीं होता; और postmortems व retrospectives के कितने actions सच में पूरे होते हैं। लोगों की ranking करने वाले metrics से बचें, जैसे bug-count targets या हर developer के defects: ये causes ठीक करने की बजाय समस्याएँ छिपाने और गिनती पर बहस करने को बढ़ावा देते हैं।
क्या blameless postmortem और retrospective एक ही हैं?
नहीं। Postmortem किसी एक ख़ास incident का विश्लेषण करता है, आम तौर पर उसके कुछ समय बाद, और actions के साथ एक लिखित record बनाता है। Retrospective एक नियमित meeting है जिसमें टीम किसी अवधि, जैसे एक sprint, में अपने काम करने के तरीके पर बात करती है। Postmortem के actions का follow-up अक्सर retrospectives में होता है।
अगर मेरी टीम defects के लिए लोगों को दोष देती है तो मैं क्या करूँ?
अपने व्यवहार से शुरू करें: दोषी नहीं, facts बताएँ, और causes को processes और systems की भाषा में लिखें। अगले incident review के लिए blameless format सुझाएँ, timeline और owner वाले actions के साथ, और retrospective में पूछें कि किस चीज़ से कोई भी समस्या को पहले पकड़ पाता। बदलाव धीरे-धीरे आता है; एक अच्छी तरह चलाया गया review अक्सर बहस से ज़्यादा असर करता है।
क्या psychological safety का मतलब है कि किसी की आलोचना नहीं होती?
नहीं। इसका मतलब है कि लोग अपमान या सज़ा के डर के बिना समस्याएँ उठा सकते हैं, सवाल पूछ सकते हैं और गलतियाँ मान सकते हैं। काम का आलोचनात्मक review होता रहता है और standards ऊँचे रहते हैं; आलोचना काम और process पर होती है, व्यक्ति पर नहीं।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)Blameless postmortems: किन घटनाओं पर postmortem ज़रूरी है, उसमें क्या दर्ज होता है — प्रभाव, root causes और follow-up कार्य — और उसमें दोष देने को क्यों बाहर रखा जाता है।
- The 2020 Scrum GuideScrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
Mutqan tools से अभ्यास करें
किसी user story से Given/When/Then acceptance criteria और definition-of-done चेकलिस्ट जनरेट करें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
Markdown की फ़ॉर्मेटिंग (हेडिंग, सूचियाँ, टेबल, emphasis) सामान्य करें और रेंडर किया नतीजा देखें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।