मॉड्यूल 25 · प्रोफ़ेशनल QA और टेस्ट मैनेजमेंट

कंटीन्यूअस इम्प्रूवमेंट

Mutqan Soft QA टीम द्वारा · · 18 मिनट · उन्नत

Continuous improvement (निरंतर सुधार) का मतलब है कि team अपने काम करने का तरीका छोटे, नियमित कदमों में बदले और हर कदम को evidence से जाँचे, किसी बड़े reorganisation का इंतज़ार किए बिना। Testing में इसका दायरा पूरा test process है: काम testing तक कैसे पहुँचता है, tests कैसे design और run होते हैं, और team escaped defects से कैसे सीखती है।

उदाहरण: retrospective में दिखता है कि बहुत-सी stories testing के बाद reopen होती हैं। सबके लिए नया approval step जोड़ने की बजाय team दो sprints के लिए एक बदलाव आज़माती है, बदलाव से पहले और बाद में reopened stories गिनती है, और फिर तय करती है कि बदलाव रखना है या नहीं। Plan, do, check और act का यही loop इस lesson का केंद्र है।

यह क्यों ज़रूरी है

Process की problems चुपचाप दोहराती रहती हैं: वही देर से testing, वही unstable environment, उसी तरह के escaped defects, sprint दर sprint। हर दोहराव rework और देरी की कीमत लेता है, और team उसकी आदी हो जाती है। ISTQB Foundation syllabus v4.0 retrospectives को continuous improvement के लिए critical बताता है और ज़ोर देता है कि सुझाए गए improvements का follow-up हो। Follow-up के बिना वही शिकायतें लौटती हैं और लोग problems उठाना बंद कर देते हैं।

Tester देखता है कि काम कहाँ रुकता है, defects कहाँ से आते हैं और कौन-से checks नहीं हैं, और इसे साबित करने वाला बहुत-सा data उसी के पास होता है। इस नज़रिए को छोटे, measured बदलावों में बदलना testing को तेज़ और ज़्यादा असरदार बनाता है, और team को दिखाता है कि problem उठाने से कुछ होता है।

Retrospectives जो बदलाव तक ले जाएँ

Scrum और quality culture वाले lessons ने retrospective से परिचय कराया। ISTQB Foundation syllabus v4.0 ब्योरा जोड़ता है: यह अक्सर iteration या project के अंत में, release milestone पर या ज़रूरत पड़ने पर होता है; इसमें सिर्फ़ testers नहीं, developers, product owner और दूसरे लोग भी शामिल होते हैं; और यह पूछता है कि क्या सफल रहा और जारी रहना चाहिए, क्या बेहतर हो सकता है, और improvements को व्यवहार में कैसे लाया जाए। इसके results दर्ज किए जाते हैं, आम तौर पर test completion report के हिस्से के रूप में।

Retrospectives अक्सर evidence और follow-through में चूकते हैं। Tester दोनों में मदद करता है:

  • राय नहीं, तथ्य लाएँ: reopen हुई stories, testing के इंतज़ार के दिन, test environment का downtime, escaped defects।
  • तब तक "क्यों?" पूछें जब तक ऐसा cause न मिले जिसे team बदल सके; "testing हमेशा देर से होती है" एक symptom है।
  • एक या दो actions लेकर निकलें, हर एक का owner और तारीख़ हो, और अगला retrospective उन्हें जाँचकर शुरू करें।
  • Retrospective actions, postmortem actions और test completion की lessons learned के लिए एक ही improvement backlog रखें।

Process measures: बदलाव से पहले और बाद का evidence

Process measure बताता है कि काम कैसे बहता है, जैसे इंतज़ार, rework या feedback की रफ़्तार; यह product की quality नहीं मापता। Goal और उस सवाल से शुरू करें जो progress दिखाए, फिर measure चुनें; Goal-Question-Metric approach का यही विचार है।

कुछ भी बदलने से पहले कई sprints का baseline दर्ज करें, क्योंकि छोटी संख्याएँ ऊपर-नीचे होती हैं, और बाद में measure की definition वही रखें। हर quarter के incidents जैसे lagging measure की जगह ऐसा leading measure चुनें जो हफ़्तों में हिले, और एक balancing measure जोड़ें जो side effect पकड़ ले। Team का process मापें, लोगों को कभी नहीं: जैसा QA metrics और KPIs वाले lesson ने दिखाया, जो measure personal target बन जाए वह मापना बंद कर देता है।

  • इंतज़ार: "ready for test" से testing शुरू होने तक के दिन; test environment कितने घंटे उपलब्ध नहीं रहा।
  • Rework: testing के बाद reopen हुई stories का हिस्सा।
  • Feedback: commit से test result तक का समय; flaky tests की वजह से fail हुए pipeline runs।
  • Follow-through: तय तारीख़ तक पूरे हुए retrospective actions।

आज़माएँ: प्रतिशत कैलकुलेटर आज़माएँ: तारीख़ अंतर कैलकुलेटर

छोटे experiments: plan, do, check, act

ज़्यादातर process बदलाव अनुमान होते हैं, इसलिए हर बदलाव को plan-do-check-act (PDCA) cycle के साथ एक छोटे experiment की तरह चलाएँ; यह cycle Walter Shewhart और W. Edwards Deming के नाम से जुड़ा है। शुरू करने से पहले experiment लिख लें ताकि बाद में result का मनचाहा अर्थ न निकाला जाए, और एक बार में एक ही चीज़ बदलें।

  • Plan: problem और उसका evidence, एक hypothesis ("अगर हम…, तो…, क्योंकि…"), एक बदलाव, measure और उसका baseline, एक balancing measure, एक timebox और एक decision rule।
  • Do: बदलाव का सबसे छोटा version, कुछ stories या एक team पर, पूरे timebox तक चलाएँ।
  • Check: result की तुलना baseline और decision rule से करें, और side effects देखें।
  • Act: बदलाव अपनाएँ और उसे standard बनाएँ, जैसे Definition of Done या किसी checklist में; या उसे adapt करके एक और cycle चलाएँ; या छोड़ दें और जो सीखा वह दर्ज करें।

Worked example: testing के बाद कम stories reopen

Clinic appointment booking web app बनाने वाली team sprints 10 से 12 की समीक्षा करती है: पूरी हुई 24 में से 9 stories (37.5%) testing के बाद reopen हुईं। Tester ने वजहें छाँटीं, और 9 में से 6 ऐसे business rules से आईं जिन पर किसी ने चर्चा नहीं की थी, जैसे एक ही समय पर दो appointments की booking।

Plan: अगर product owner, एक developer और tester development से पहले हर story के लिए examples पर सहमत हों, तो कम stories reopen होंगी, क्योंकि rules coding से पहले तय हो जाते हैं। बदलाव: दो sprints तक हर story के लिए 20 मिनट का example session। Measure: reopened stories (baseline 37.5%); balancing measure: हर sprint में पूरी हुई stories (baseline 8)। Rule: बदलाव अपनाएँ अगर दोनों sprints में कुल 3 से ज़्यादा stories reopen न हों और हर sprint में कम से कम 7 stories पूरी हों।

  • Do: team 16 stories के लिए sessions करती है, और tester reopen की वजहें पहले वाली categories में ही दर्ज करता है।
  • Check: 16 में से 3 stories (18.75%) reopen हुईं, उनमें से सिर्फ़ 1 बिना चर्चा वाले rule की वजह से, और हर sprint में 8 stories पूरी हुईं। Rule पूरा हुआ। सोलह stories छोटा sample है, लेकिन वजहें वैसे ही बदलीं जैसा hypothesis ने कहा था।
  • Act: team session अपनाती है, Definition of Ready में "examples agreed" जोड़ती है, गिनती जारी रखती है, और backlog से अगली problem उठाती है।
Worked example का एक plan-do-check-act cycle: development से पहले examples पर सहमति के बाद reopened stories 24 में से 9 से घटकर 16 में से 3 रह गईं, इसलिए team ने बदलाव अपनाया।
  1. 1PlanHypothesis, measure, baseline और decision ruleDevelopment से पहले examples पर सहमति; baseline 24 में से 9 reopen (37.5%)
  2. 2Doसबसे छोटा version, एक timebox तकदो sprints में 16 stories में से हर एक के लिए 20 मिनट का example session
  3. 3CheckBaseline और rule से तुलना16 में से 3 reopen (18.75%); हर sprint में 8 stories पूरीRule पूरा
  4. 4ActAdopt, adapt या abandonAdopt: "examples agreed" Definition of Ready में जुड़ता है

चरण 1 पर वापस अगला cycle: improvement backlog की अगली problem

सोलह stories छोटा sample है: बदलाव अपनाने के बाद भी team गिनती जारी रखती है।

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: प्रतिशत कैलकुलेटर

Test process सुधारने के models

Improvement शुरू करने के लिए model ज़रूरी नहीं। फिर भी कुछ organisations कई teams में gaps को व्यवस्थित ढंग से खोजने के लिए अपने test process को किसी published model से assess करती हैं। Models के दो परिवार हैं, और analytical approaches दोनों के पूरक हैं:

  • Process reference models maturity मापते हैं। TMMi (Test Maturity Model integration) एक staged model है जिसमें Initial से Optimization तक पाँच maturity levels हैं; TPI NEXT test process के हर key area को अलग से assess करता है।
  • Content reference models, जैसे Critical Testing Processes (CTP) और Systematic Test and Evaluation Process (STEP), मुख्य test activities की अच्छी practices बताते हैं, बिना maturity scale के।
  • Analytical approaches आपके अपने data से शुरू होते हैं, जैसे defects का causal analysis या Goal-Question-Metric।

आम गलतियाँ

  • Retrospective को बिना owners और तारीख़ों वाले दस actions के साथ ख़त्म करना, और फिर उन्हें कभी न जाँचना।
  • एक साथ कई चीज़ें बदलना, जिससे कोई नहीं बता पाता कि किस बदलाव ने मदद की।
  • Baseline न होना, या बीच में measure गिनने का तरीका बदल देना।
  • एक sprint के बाद ही सफलता घोषित कर देना, जबकि छोटी संख्याएँ ऊपर-नीचे होती हैं।
  • Process measure को लोगों का target बना देना, जैसे हर tester के मिले bugs की संख्या।
  • Team की असली problems सुलझाने की बजाय maturity level के पीछे भागना।

QA का नज़रिया

असली team में evidence अक्सर tester के पास होता है: defect tracker, test management tool और pipeline history दिखाते हैं कि काम कहाँ रुकता है और defects कहाँ से आते हैं। हर retrospective से पहले दो-तीन numbers और एक ठोस उदाहरण तैयार करें। Improvement backlog पर Scrum Master या test manager के साथ, experiments पर developers और product owner के साथ, और operations के साथ काम करें ताकि postmortem actions भी उसी list में आएँ।

हर experiment card को उसके result और decision के साथ रखें, ताकि team याद रखे कि कोई practice क्यों है और जब वह मदद करना बंद कर दे तो उसे छोड़ सके। काम के सवाल: "अगर यह काम करे तो हमें क्या दिखेगा?", "क्या बिगड़ सकता है?" और "कौन-सा पुराना action अब भी खुला है?"

अभ्यास

Retrospective notes को एक experiment में बदलें

आपका काम

Insurance claims portal बनाने वाली team ने sprint 14 का retrospective किया और "क्या ठीक नहीं रहा" में लिखा: testing हमेशा sprint के आख़िरी तीन दिनों में होती है; मंगलवार को staging फिर down था; दो defects production में escape हुए, दोनों claim status emails में; meetings बहुत ज़्यादा हैं। पिछले तीन sprints का data नीचे है।

शुरुआत के लिए एक problem चुनें, data से अपने चुनाव को सही ठहराएँ, और उसके लिए experiment card लिखें। फिर बताएँ कि बाक़ी problems का क्या होना चाहिए।

सामग्री
Insurance claims portal - data for the sprint 14 retrospective (2-week sprints)

                                            Sprint 12   Sprint 13   Sprint 14
Stories finished                                  9           8           9
Stories reopened after testing                    3           4           3
Average days a story waited for testing         2.5         3.0         2.8
Staging unavailable (hours)                       6          11           9
Defects escaped to production                     1           0           2
Open actions from earlier retrospectives          2           4           6
चरण
  1. चिह्नित करें कि कौन-से numbers स्थिर हैं, कौन बढ़ रहे हैं और कौन घट रहे हैं।
  2. Hypothesis को "अगर हम…, तो…, क्योंकि…" के रूप में, एक बदलाव के साथ लिखें।
  3. तीनों sprints पर baseline निकालें, एक balancing measure चुनें और decision rule तय करें।
  4. तय करें कि हर बची problem कहाँ जाएगी।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Data पढ़ना: reopened stories और इंतज़ार के दिन स्थिर हैं, staging downtime और escaped defects ऊपर-नीचे होते हैं, और पिछले retrospectives के खुले actions 2 से बढ़कर 6 हो गए हैं।

पहला अच्छा चुनाव देर से testing है: data हर sprint में इसकी पुष्टि करता है, और संभव है कि यही reopened stories को बढ़ाता हो। अगर team environment पर असर डाल सकती है तो staging downtime भी ठीक विकल्प है।

Card: stories testing से पहले औसतन लगभग 2.8 दिन इंतज़ार करती हैं (2.5, 3.0 और 2.8 का औसत)। Hypothesis: अगर team development में work in progress (WIP) को तीन stories तक सीमित करे, तो stories को testing के लिए कम इंतज़ार करना पड़ेगा, क्योंकि developers अगली story शुरू करने से पहले एक story पूरी करते हैं, इसलिए stories sprint के अंत में एक साथ आने की बजाय एक-एक करके tester तक पहुँचती हैं। बदलाव: दो sprints तक यही limit। Measure: इंतज़ार के औसत दिन, baseline 2.8। Balancing: हर sprint में पूरी हुई stories, baseline लगभग 9 (तीन sprints में 26), और reopened stories, baseline 26 में से 10 (38%)। Rule: अपनाएँ अगर इंतज़ार 1.5 दिन से कम हो जाए, हर sprint में कम से कम 8 stories पूरी हों और 38% से ज़्यादा stories reopen न हों; adapt करके एक और cycle चलाएँ अगर इंतज़ार घटे पर 1.5 दिन या उससे ज़्यादा रहे, या कोई balancing measure बिगड़े; छोड़ दें अगर इंतज़ार न घटे।

बढ़ते खुले actions (2, 4, 6) बताते हैं कि follow-through fail हो रहा है: हर retrospective में ज़्यादा से ज़्यादा दो actions तय करें, हर एक का owner और तारीख़ हो, अगली बार पहले उन्हें जाँचें, और छह खुले actions को साफ़ तौर पर बंद करें या हटा दें।

Claim emails के escaped defects incident feedback से गुज़रते हैं: postmortem, test gaps और नए regression tests। Staging downtime अगले candidate के रूप में improvement backlog में रहता है और एक owner के साथ project risk log में भी जाता है, क्योंकि यह test execution के लिए ख़तरा है। "Meetings बहुत ज़्यादा हैं" पर अभी data नहीं है, इसलिए अगले retrospective में पूछें कि कौन-सी meetings और कितनी लंबी।

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

Retrospective और postmortem में क्या फ़र्क है?

Retrospective नियमित रूप से होता है, sprint, iteration या release के अंत में, और इस बारे में होता है कि team ने कैसे काम किया, चाहे कुछ गलत हुआ हो या नहीं। Postmortem किसी एक incident से शुरू होता है और उसी घटना का analysis करता है। दोनों blameless होने चाहिए, और दोनों के actions एक ही improvement backlog में जाते हैं। कुछ organisations project के अंत वाले retrospective को भी post-mortem या post-project meeting कहती हैं, इसलिए पक्का कर लें कि किसकी बात हो रही है।

क्या improve करने के लिए team को TMMi या TPI NEXT चाहिए?

नहीं। ज़्यादातर teams के लिए retrospectives, कुछ process measures और छोटे experiments काफ़ी हैं। Model तब मदद करता है जब organisation कई teams में व्यवस्थित assessment चाहती हो या उसे किसी customer या auditor को तय process दिखाना हो। तब भी model का सुझाया हर बदलाव छोटे, measured कदम के रूप में लाना बेहतर है।

अगर experiment काम न करे तो?

तो आपने कम कीमत में कुछ सीखा। Result और आपकी राय में उसके fail होने की वजह दर्ज करें, बदलाव छोड़ें या adapt करें, और problem को improvement backlog में रखें। Experiment सच में तभी fail होता है जब उससे कुछ न सीखा जाए, जैसे जब baseline न हो या decision rule result आने के बाद तय किया गया हो।

एक साथ कितने experiments चलाएँ, और उन्हें कितनी बार review करें?

एक साथ एक या दो, team की रफ़्तार के हिसाब से: Scrum में हर Sprint Retrospective में review करें, Kanban या continuous flow में तय अंतराल पर, जैसे हर दो हफ़्ते। जितने ज़्यादा experiments साथ चलेंगे, यह बताना उतना मुश्किल होगा कि किस बदलाव का क्या असर हुआ।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
  • Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
टूल्स

Mutqan tools से अभ्यास करें

प्रतिशत कैलकुलेटर

प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।

यूटिलिटीज़

तारीख़ अंतर कैलकुलेटर

दो तारीख़ों के बीच सटीक अंतर वर्ष, महीने, दिन, घंटे और कुल इकाइयों में निकालें।

यूटिलिटीज़

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा