टेस्टर्स के लिए कानबान
Kanban (कानबान) काम को manage करने का एक तरीका है जो काम के flow को दिखाई देने लायक बनाता है और एक समय में चल रहे काम की मात्रा सीमित करता है; Kanban Guide इसे किसी process में value के flow को optimise करने की strategy कहती है। हर work item, जैसे कोई user story या defect fix, Kanban board पर एक card है, और board के columns वे states हैं जिनसे काम गुज़रता है, जैसे Ready, Develop, Test और Done।
किसी column पर WIP (work in progress) limit हो सकती है। अगर Test की limit 2 है और उसमें पहले से दो cards हैं, तो कोई तीसरा card अंदर नहीं धकेलता: टीम पहले उनमें से एक को पूरा करने में मदद करती है। Scrum के उलट, Kanban कोई sprint या role तय नहीं करता; जब भी capacity हो, काम लगातार pull किया जाता है।
यह क्यों ज़रूरी है
जो काम शुरू हुआ पर पूरा नहीं हुआ, उस पर मेहनत लगती है पर अभी कोई value नहीं मिलती, और वह ऐसे defects छिपाता है जिन्हें किसी ने देखा नहीं। Limits के बिना developers नई stories शुरू करते रहते हैं जबकि पूरा हुआ code testing के आगे queue में लगता जाता है; feedback कई दिन देर से पहुँचता है, और testing bottleneck लगती है जबकि वजह पहले के stages में है: बहुत ज़्यादा काम शुरू कर दिया गया।
Kanban इस समस्या को दिखाई देने लायक और ठीक करने लायक बनाता है: board दिखाता है कि काम कहाँ रुका है, WIP limits queues को बढ़ने से रोकती हैं, और flow metrics अंदाज़ों की जगह facts रखते हैं। क्योंकि टीम नया काम शुरू करने से पहले मौजूदा काम पूरा करती है, Kanban ISTQB CTFL v4.0 के whole-team approach को भी सहारा देता है, जिसमें quality सबकी ज़िम्मेदारी है, अंत का कोई stage नहीं।
काम दिखाएँ, WIP सीमित करें, flow manage करें
टीमें अक्सर Kanban को तीन आदतों में समेटती हैं: काम दिखाएँ, WIP सीमित करें और flow manage करें। Kanban Guide इन्हीं विचारों को तीन practices में रखती है: workflow को define और visualise करना; उसके items को सक्रिय रूप से manage करना, यानी WIP को control करना, items को बेवजह पुराना न होने देना और blocked काम को unblock करना; और workflow को सुधारना।
- Visualise: हर column workflow की एक state है, और टीम लिखती है कि item कहाँ started और कहाँ finished माना जाएगा। Explicit policies बताती हैं कि card को आगे बढ़ने से पहले क्या चाहिए, जैसे "Test में तभी आएगा जब test environment पर deploy हो चुका हो"। Kanban Guide इन फ़ैसलों को Definition of Workflow में इकट्ठा करती है, जिसमें यह भी लिखा होता है कि WIP कैसे control होगा, और एक service level expectation (SLE) भी होती है: पिछले cycle times पर आधारित अनुमान कि किसी item को start से finish तक कितना समय लगना चाहिए।
- WIP सीमित करें: WIP उन items की संख्या है जो शुरू हुए पर पूरे नहीं हुए, और हर column या पूरे board की limit इसे सीमित करती है।
- Pull करें, push नहीं: कोई item तभी शुरू करें जब capacity का साफ़ संकेत हो, जैसे limit के अंदर खाली जगह। आगे का column भरा हो तो मतलब है वहाँ मदद करें, कुछ नया शुरू न करें।
- Flow manage करें: जो cards हिलना बंद कर दें उन्हें पहचानें, रुकावट हटाएँ और सबसे पुराना card पहले पूरा करें। एक बार में एक policy या limit बदलें और देखें कि flow सुधरा या नहीं।
Testing एक column के रूप में बनाम built-in quality
पहला board अक्सर Backlog, Develop, Test, Done जैसा होता है। यह handover को पक्का कर देता है: developer card को finished कहता है, उसे Test में डालता है और अगली story शुरू कर देता है। Test एक queue बन जाता है, defect मिलने पर card ऐसे व्यक्ति के पास लौटता है जो अब दूसरे काम में व्यस्त है।
Quality को built-in करने का मतलब है कि testing हर column में होती है। Kanban कोई columns तय नहीं करता, इसलिए ये policies टीम ख़ुद तय करती है:
- Ready: card के testable acceptance criteria हैं, और developer व tester ने मुख्य test ideas पर सहमति बना ली है।
- Develop: unit और API checks code के साथ लिखे जाते हैं, और tester शुरुआती builds को explore करता है।
- Test: column की WIP limit है, और टीम का कोई भी सदस्य उससे testing का काम pull कर सकता है या tester के साथ pair कर सकता है।
- किसी card पर मिला defect उसके आगे बढ़ने से पहले उसी card पर ठीक होता है; finished काम में मिला defect एक नया card बनता है।
- Done: finished में tested शामिल है, जैसे Scrum में Definition of Done में होता है।
- 1BacklogRequests जिन पर टीम ने अभी commit नहीं कियाकोई limit नहीं
गेट: Ready में जगह खाली होने पर ही pull
- 2ReadyTestable acceptance criteria और test ideas पर सहमतिlimit 4
गेट: Develop में जगह खाली होने पर ही pull
- 3Developwork item शुरू होता हैUnit और API checks code के साथ; tester शुरुआती builds explore करता हैlimit 3
गेट: Test में जगह खाली होने पर ही pull
- 4Testटीम का कोई भी सदस्य testing का काम pull करता है या tester के साथ pair करता हैlimit 2
दोहराता है: Defect मिला: card आगे बढ़ने से पहले इसी पर ठीक
- 5Donework item पूरा होता हैFinished में tested शामिल
चरण 3–5 के दौरान Cycle time: Develop में आने (start) से Done तक पहुँचने (finish) तक
- Lead timeअक्सर Backlog में request से Done तक गिना जाता है, काम शुरू होने से पहले के इंतज़ार समेत
- Throughputहर हफ़्ते Done तक पहुँचने वाले cards
Worked example का उदाहरण board: हर टीम अपने columns, limits और policies ख़ुद तय करती है।
आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: User Story → टेस्ट सिनेरियो
Flow metrics: WIP, cycle time, lead time और throughput
Kanban Guide flow के चार measures बताती है। हर एक के लिए card की सिर्फ़ start और finish तारीख़ें चाहिए, जिन्हें tester board की history से पढ़ सकता है।
ये measures आपस में जुड़े हैं। किसी ठीक-ठाक stable अवधि में average cycle time लगभग average WIP को average throughput से भाग देने के बराबर होता है (Little’s Law)। 10 cards progress में और हर हफ़्ते 5 finished हों तो एक card को लगभग दो हफ़्ते लगते हैं; 5 cards progress में हों तो लगभग एक हफ़्ता। WIP सीमित करने से cycle time घटता है, बिना किसी के तेज़ काम किए।
- WIP: उन items की संख्या जो शुरू हुए पर पूरे नहीं हुए, किसी एक पल पर गिनी गई।
- Cycle time: item के start होने से finish होने तक बीता समय।
- Work item age: किसी अधूरे item के start होने से अब तक बीता समय। जो card ज़्यादातर finished cards से, या SLE से, पुराना हो, उसे आज मदद चाहिए।
- Throughput: प्रति इकाई समय, जैसे प्रति हफ़्ता, finish हुए items की संख्या।
- Lead time Kanban Guide में परिभाषित नहीं है। कई टीमें इसे request से delivery तक की अवधि के लिए इस्तेमाल करती हैं, जिसमें काम शुरू होने से पहले का इंतज़ार भी शामिल है; कुछ टीमें इसे cycle time ही मानती हैं। Numbers की तुलना से पहले start और end points तय कर लें।
Worked example: Test की queue खोलना
तीन developers और एक tester बिना WIP limits के काम करते हैं। पिछले चार हफ़्तों में उन्होंने 12 cards पूरे किए, यानी हर हफ़्ते 3 का throughput। सोमवार को 11 cards progress में हैं, उनमें से छह Test में, और सबसे पुराना 29 दिन का है (नीचे board देखें)। WIP कई हफ़्तों से लगभग इसी स्तर पर है, इसलिए Little’s Law लगभग 11 / 3 ≈ 3.7 हफ़्ते के average cycle time की ओर इशारा करता है।
"Tester को तेज़ test करना चाहिए" वाला निष्कर्ष गलत है: Test की queue बहुत ज़्यादा काम शुरू करने का लक्षण है। टीम यह करती है:
- Limits तय करती है: Ready के लिए 4, Develop के लिए 3 और Test के लिए 2। Board अपनी limits से ऊपर से शुरू होता है, इसलिए जब तक वह limits के अंदर न आ जाए, कोई नया card शुरू नहीं करता।
- जब तक Test भरा है, developers सबसे पुराने cards पर tester के साथ pair करते हैं, छूटे हुए API checks जोड़ते हैं और defects उन्हीं cards पर ठीक करते हैं जिन पर वे मिले।
- इस उदाहरण में चार हफ़्ते बाद लगभग 5 cards progress में हैं और throughput हर हफ़्ते 3 से 4 है, इसलिए अब Little’s Law लगभग 5 / 3.5 ≈ 1.4 हफ़्ते के average cycle time की ओर इशारा करता है।
BEFORE (no WIP limits; 3 developers, 1 tester)
Ready | Develop | Test | Done
S-50 | S-44 | S-31 age 29 d | 12 cards in the last 4 weeks
S-51 | S-45 | S-33 age 25 d | throughput: 3 per week
| S-46 | S-35 age 22 d |
| S-47 | S-38 age 18 d |
| S-48 | S-40 age 15 d |
| | S-42 age 11 d |
WIP = 5 + 6 = 11 cards -> average cycle time ~ 11 / 3 = 3.7 weeks
AFTER (WIP limits in brackets)
Ready [4] | Develop [3] | Test [2] | Done
Policies: - while Test is full, nobody starts a new card: help finish one
- a defect is fixed on the card where it was found
- a card is Ready only with agreed acceptance criteria and test ideasआम गलतियाँ
- Test column को बिना WIP limit वाली handover queue की तरह चलाना।
- "बस इस बार" कहकर WIP limits तोड़ना: limit तभी काम आती है जब भरा हुआ column लोगों का अगला कदम बदल दे।
- तय start और finish points के बिना cycle times की तुलना करना, या lead time और cycle time को आपस में मिला देना।
- Flow metrics से लोगों को judge करना, जैसे "tester का cycle time": ये पूरी टीम के system को बताते हैं।
- किसी card को Done में ले जाना जबकि उसका known defect अलग card बनकर backlog में इंतज़ार कर रहा हो।
QA का नज़रिया
Kanban टीम में tester board पर काम करता है, किसी test phase में नहीं। Board की daily review में Done के सबसे नज़दीक वाले cards से शुरू करें और पूछें: सबसे पुराना card कौन-सा है, उसे क्या रोक रहा है, और उसे पूरा करने में कौन मदद कर सकता है? जब Test अपनी limit पर हो, तो साफ़ कहें और किसी developer से कुछ नया शुरू करने की बजाय pair करने को कहें।
वह record करें जो flow को दिखाई देने लायक बनाए: कारण के साथ blocked marker, हर card के start होने की तारीख़, और defects उसी card से जुड़े हुए जिस पर वे मिले। Improvement की चर्चाओं में सबसे पुराने card की age या cycle time के trend जैसे facts लाएँ, और बदलावों को experiment के रूप में रखें: "दो हफ़्ते तक Test की limit 2 रहेगी", फिर numbers की तुलना करें।
अभ्यास
एक टीम के board का flow पढ़ें
नीचे दिए board data का इस्तेमाल करें। Card तब start होता है जब वह Develop में आता है; calendar days को finish date में से start date घटाकर गिनें (Date Difference Calculator से जाँच सकते हैं)।
Finished in the last two weeks (22 Sep to 5 Oct)
Card Started (entered Develop) Finished (entered Done)
P-11 15 Sep 22 Sep
P-12 16 Sep 26 Sep
P-14 18 Sep 25 Sep
P-15 22 Sep 2 Oct
P-17 24 Sep 3 Oct
P-18 25 Sep 1 Oct
Board on 6 Oct (no WIP limits; 3 developers, 1 tester)
Ready: P-25, P-26
Develop: P-21 (started 30 Sep), P-23 (started 2 Oct)
Test: P-16 (started 19 Sep), P-19 (started 26 Sep),
P-20 (started 29 Sep), P-22 (started 1 Oct)- हर finished card का cycle time, उनका average और हफ़्ते का throughput निकालें।
- 6 अक्टूबर को मौजूदा WIP और progress में हर card की age गिनें।
- बताएँ कि काम कहाँ रुका है और किस card को सबसे पहले मदद चाहिए।
- WIP limits, दो explicit policies और वे numbers सुझाएँ जिन पर आप नज़र रखेंगे।
मॉडल उत्तर दिखाएँ
Cycle times: P-11 7 दिन, P-12 10, P-14 7, P-15 10, P-17 9, P-18 6; average 49 / 6 ≈ 8 दिन। Throughput: दो हफ़्तों में 6 cards, यानी हर हफ़्ते 3।
WIP 6 है: Develop में 2 और Test में 4; P-25 और P-26 अभी start नहीं हुए। Ages: P-16 17 दिन, P-19 10, P-20 7, P-21 6, P-22 5, P-23 4।
काम Test में रुका है, जिसमें progress वाले 6 में से 4 cards हैं। P-16 किसी भी finished card से पुराना है: आज ही पता करें कि उसे क्या रोक रहा है, और उसे पूरा करने में मदद करें। Progress में 6 cards और हर हफ़्ते 3 finished होने पर Little’s Law हर card के लिए लगभग 2 हफ़्ते की ओर इशारा करता है, यानी कुछ न बदला तो cycle time बढ़ेगा।
एक ठीक शुरुआत: Test के लिए 2 और Develop के लिए 3, जिससे WIP की सीमा 5 हो जाती है, यानी आज के 6 से एक कम। Policies: जब तक Test भरा है, कोई नया card शुरू नहीं करता और developers वहाँ testing या defects ठीक करने में मदद करते हैं; card Ready में तभी आता है जब acceptance criteria और test ideas पर सहमति हो। दो से चार हफ़्ते तक सबसे पुराने card की age, average cycle time और throughput पर नज़र रखें।
अक्सर पूछे जाने वाले सवाल
क्या Kanban testing phase को ख़त्म कर देता है?
Kanban कोई columns तय नहीं करता; हर टीम अपना workflow ख़ुद define करती है। कई टीमें Test column रखती हैं, और यह ठीक है अगर उसकी WIP limit हो, पूरी टीम उससे pull कर सकती हो, और ज़्यादातर testing cards के वहाँ पहुँचने से पहले शुरू हो जाए। Kanban जो ख़त्म करता है वह है testing को अंत में एक अलग batch मानने का विचार।
Lead time और cycle time में क्या फ़र्क है?
Kanban Guide में cycle time item के start से finish तक चलता है। Lead time वहाँ परिभाषित नहीं है; टीमें इसे आम तौर पर request से delivery तक की लंबी अवधि के लिए इस्तेमाल करती हैं, जिसमें काम शुरू होने से पहले का इंतज़ार भी शामिल है। क्योंकि इस्तेमाल अलग-अलग है, हमेशा start और end points बताएँ।
WIP limit कैसे चुनूँ?
कोई formula नहीं है। आज हर column में जितने cards हैं उन्हें गिनें, limits उससे थोड़ी कम रखें, और तय करें कि column भरने पर लोग क्या करेंगे। कुछ हफ़्तों बाद cycle time और work item age देखकर review करें और बदलें। जो limit कभी छुई न जाए वह बहुत ऊँची है; जो सारा काम रोक दे वह बहुत नीची।
क्या Scrum टीम Kanban इस्तेमाल कर सकती है?
हाँ। Scrum टीम अपने sprints, Product Goal और Definition of Done रख सकती है और Kanban board, WIP limits व flow metrics जोड़ सकती है, ताकि पहले दिन सब कुछ शुरू करने की बजाय items sprint के अंदर पूरे हों।
संदर्भ
- The Kanban Guide (May 2025)value के flow को बेहतर बनाने की रणनीति के रूप में Kanban: workflow को परिभाषित व दृश्य बनाना, उसके items को सक्रिय रूप से संभालना, उसे सुधारना, और चार flow measures — WIP, throughput, work item age और cycle time।
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- Certified Tester Foundation Level Agile Tester (CTFL-AT)agile टीमों के भीतर टेस्टिंग पर ISTQB का foundation-level extension; ISTQB इसे बंद कर रहा है (अंग्रेज़ी परीक्षा 6 मई 2027 तक) और इसकी जगह CTFL v4.0 व CTAL-AT सुझाता है।
Mutqan tools से अभ्यास करें
दो तारीख़ों के बीच सटीक अंतर वर्ष, महीने, दिन, घंटे और कुल इकाइयों में निकालें।
किसी user story से Given/When/Then acceptance criteria और definition-of-done चेकलिस्ट जनरेट करें।
किसी user story से end-to-end टेस्ट सिनेरियो निकालें, वैकल्पिक और अपवाद flow सहित।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।