स्टेट ट्रांज़िशन टेस्टिंग
State transition testing एक black-box test design technique है, उस व्यवहार के लिए जो पहले हुई घटनाओं पर निर्भर करता है। इसमें आप system को, या उसकी किसी एक चीज़ — जैसे account, order या document — को states और उन events के रूप में मॉडल करते हैं जो उसे states के बीच ले जाते हैं, फिर उसी model से test cases निकालते हैं। One-time code वाले sign-in में account Signed out, Code sent, Signed in या Locked होता है: गलत code पहली दो बार user को Code sent में रखता है और तीसरी बार account lock कर देता है। Input वही है, नतीजा अलग, क्योंकि state अलग है।
Equivalence partitioning ने उन input values को group किया था जिनके साथ system को एक जैसा व्यवहार करना चाहिए। State model यही काम history के लिए करता है: clicks के हर क्रम को आज़माने की बजाय आप उन गिनी-चुनी states को टेस्ट करते हैं जिनमें system हो सकता है, उनके बीच के allowed moves को, और मना किए गए moves के refuse होने को।
यह क्यों ज़रूरी है
कई गंभीर defects किसी ख़ास history के बाद ही दिखते हैं: cancel हुआ order जो फिर भी ship हो जाए, locked account जो सही code स्वीकार कर ले, session जो sign-out के बाद भी बचा रहे। हर input अपने आप में valid है, इसलिए एक बार में एक input जाँचने वाली techniques इन्हें नहीं पकड़तीं।
State model workflow को coverage items — states और transitions — की एक सीमित list में बदल देता है, ताकि आप ठीक-ठीक बता सकें कि क्या टेस्ट हुआ। Model बनाते समय gaps भी जल्दी दिखते हैं: state और event का हर ऐसा combination जिसे किसी ने तय नहीं किया, production का failure नहीं, product owner के लिए सवाल बन जाता है।
States, events, transitions और guards
State वह स्थिति है जिसमें मॉडल किया गया object तब तक रहता है जब तक कुछ होता नहीं। Event वह है जो होता है: कोई click, कोई message आना, timer ख़त्म होना। Transition किसी event से होने वाला state का बदलाव है; ISTQB इसे instantaneous मानता है। यह कोई action करा सकता है, जैसे SMS भेजना, और इस पर guard condition हो सकती है जो transition होने के लिए true होनी चाहिए।
Transition का label event [guard] / action के रूप में लिखा जाता है, जो हिस्से मौजूद न हों उन्हें छोड़कर। Guards तब मायने रखते हैं जब एक ही event अलग-अलग states तक ले जा सके: "गलत code [पहली या दूसरी गलत कोशिश]" user को Code sent में रखता है, जबकि "गलत code [तीसरी गलत कोशिश]" account lock कर देता है। Attempt count जैसा guard असल में एक boundary है, इसलिए उसके दोनों तरफ़ टेस्ट करें। Examples यह requirement इस्तेमाल करते हैं:
- User code माँगता है; system SMS से 6-digit code भेजता है, जो 5 मिनट तक valid है।
- सही code से user sign in हो जाता है, और एक code सिर्फ़ एक बार काम करता है। Sign out करने पर session ख़त्म होता है।
- गलत code के बाद user फिर कोशिश कर सकता है; लगातार तीसरा गलत code account को 30 मिनट के लिए lock कर देता है, जिसके बाद user नया code माँग सकता है।
State diagram और state table
State diagram, जिसे state transition diagram भी कहते हैं, states को boxes और valid transitions को label वाले arrows के रूप में दिखाता है। Sign-in requirement के लिए इसमें चार states (S1 से S4) और सात transitions (T1 से T7) हैं। Team के साथ review करना आसान है, लेकिन यह सिर्फ़ वही दिखाता है जो allowed है।
| # | से | तक | Event [guard] / action |
|---|---|---|---|
| 1 | S1 Signed outशुरुआत | S2 Code sent | E1 code माँगना / SMS से 6-digit code भेजना |
| 2 | S2 Code sent | S3 Signed in | E2 सही code / session शुरू करना |
| 3 | S2 Code sent | S2 Code sent | E3 गलत code [पहली या दूसरी गलत कोशिश] / बची हुई कोशिशें दिखानावैकल्पिक पथ |
| 4 | S2 Code sent | S4 Locked | E3 गलत code [लगातार तीसरी गलत कोशिश]वैकल्पिक पथ |
| 5 | S2 Code sent | S1 Signed outशुरुआत | E4 code expire होना (भेजने के 5 मिनट बाद)वैकल्पिक पथ |
| 6 | S3 Signed in | S1 Signed outशुरुआत | E5 sign out / session ख़त्म करना |
| 7 | S4 Locked | S1 Signed outशुरुआत | E6 lock ख़त्म होना (30 मिनट बाद)वैकल्पिक पथ |
सिर्फ़ valid transitions दिखाए गए हैं। नीचे की state table बाक़ी state और event जोड़ियाँ दिखाती है: invalid transitions, और एक gap जिसे requirement ने खुला छोड़ा है।
State table वही model grid में रखती है: हर state की एक row, हर event का एक column, और हर cell में transition और उसकी target state। यह मना की गई चीज़ें भी दिखाती है: खाली cell, जो नीचे dash से दिखाई गई है, एक invalid transition है, जहाँ system को event refuse या ignore करके अपनी state में रहना चाहिए। ISTQB syllabus हर event और guard की जोड़ी को अलग column देता है, तो E3 के दो columns बनते; यह table जगह बचाने के लिए E3 के दोनों guards एक ही cell में रखती है।
Table भरते समय gaps सामने आते हैं। Requirement नहीं बताती कि पहला code valid रहते हुए user दूसरा code माँगे तो क्या होगा, इसलिए cell S2 × E1 में test नहीं, product owner के लिए सवाल है।
E1 E2 E3 E4 E5 E6
request correct wrong code sign lock
code code code expires out ends
S1 Signed out T1: S2 - - - - -
S2 Code sent ? T2: S3 T3: S2 [1st,2nd] T5: S1 - -
T4: S4 [3rd]
S3 Signed in - - - - T6: S1 -
S4 Locked - - - - - T7: S1
- invalid transition: refused, the state does not change
? not specified in the requirement: ask the product ownerCoverage: सभी states, valid transitions और सभी transitions
यहाँ test case किसी ज्ञात start state से शुरू होने वाला events का sequence है, हर event के बाद expected state और action के साथ; एक test case आम तौर पर कई transitions cover करता है। ISTQB Foundation syllabus तीन coverage criteria पर चर्चा करता है। हर criterion अपने से पहले वाले से ज़्यादा मज़बूत है: बाद वाले criterion का 100% पहले वालों का 100% पक्का करता है।
- All states coverage: coverage items states हैं। दो test cases, E1 फिर E2 और E1 के बाद तीन बार E3, 100% तक पहुँचते हैं, फिर भी ये सिर्फ़ T1 से T4 चलाते हैं: 7 में से 4 valid transitions (57%)। Code expiry, sign-out और lock का ख़त्म होना untested रह जाते हैं।
- Valid transitions coverage, जिसे 0-switch coverage भी कहते हैं: coverage items एक-एक valid transition हैं, T1 से T7। यह सबसे ज़्यादा इस्तेमाल होने वाला criterion है, और इसका 100% हर state को भी exercise करता है।
- All transitions coverage: coverage items state table के सारे transitions हैं; हर valid transition चलाया जाता है और हर invalid आज़माया जाता है। Syllabus इसे mission-critical और safety-critical software के लिए minimum के रूप में सुझाता है।
Worked example: one-time code के test cases
Valid transitions coverage के लिए हर test case S1 से शुरू करें और events जोड़ते जाएँ जब तक हर transition न चल जाए। तीन test cases काफ़ी हैं। एक लंबा sequence भी सातों transitions cover कर सकता है, क्योंकि T5, T6 और T7 तीनों S1 पर लौटते हैं, लेकिन तब sequence में शुरू का कोई failure उसके बाद के हर transition को रोक देता है। TC-03 में पहले दो गलत codes T3 चलाते हैं, क्योंकि guard true है, और तीसरा T4 चलाता है।
हर expected result state और action के रूप में लिखें, सिर्फ़ screen message नहीं: दूसरे गलत code के बाद user अब भी S2 में है और देखता है कि एक कोशिश बची है। TC-02 और TC-03 को 5 और 30 मिनट रुकना पड़ता है, इसलिए जल्दी पूछें कि test environment में ये समय छोटे किए जा सकते हैं या clock set की जा सकती है।
Every test case starts in S1 Signed out.
ID Events and resulting states Covers
TC-01 E1 -> S2 E2 -> S3 E5 -> S1 T1 T2 T6
TC-02 E1 -> S2 E4 -> S1 T1 T5
TC-03 E1 -> S2 E3 -> S2 E3 -> S2 E3 -> S4 E6 -> S1 T1 T3 T4 T7
Valid transitions coverage: 7 of 7 (100%)
All states coverage: 4 of 4 (100%)Invalid transitions टेस्ट करना
इस table की 17 खाली cells में से पाँच trigger नहीं हो सकतीं: lock सिर्फ़ S4 में ख़त्म हो सकता है, और expire सिर्फ़ unused code होता है, जो सिर्फ़ S2 और S4 में मौजूद होता है। इन पाँचों को not testable mark करें और कारण लिखें; बाक़ी 12 वे invalid transitions हैं जिन्हें all transitions coverage के लिए आज़माना है।
हर test case में सिर्फ़ एक आज़माएँ: अगर पहली कोशिश गलती से accept हो जाए, तो system उस state में नहीं रहता जो अगली कोशिश मानकर चलती है, और एक defect दूसरे को छिपा देता है (ISTQB इसे defect masking कहता है, जिसे fault masking भी कहते हैं)। Expected result यह है कि event refuse हो और state न बदले; state को अगले event से या API के ज़रिए पक्का करें। Security के लिहाज़ से सबसे अहम कोशिशों से शुरू करें:
- S4 × E2: lock के दौरान, expire होने से पहले सही code डालें। Expected: अब भी Locked, कोई session नहीं।
- S3 × E2: sign in के बाद वही code फिर से submit करें। Expected: refuse, session सिर्फ़ एक।
- S1 × E2: expire हो चुका code (T5 के बाद) डालें। Expected: refuse, user अब भी Signed out।
- S4 × E1: lock के दौरान नया code माँगें। Expected: कोई SMS नहीं जाता, अब भी Locked।
- S4 × E4: account lock रहते हुए code के expire होने का इंतज़ार करें। Expected: अब भी Locked; Signed out में जाने से user 30 मिनट पूरे होने से बहुत पहले नया code माँग सकेगा।
आम गलतियाँ
- सिर्फ़ happy path मॉडल करना और timeouts, cancellations, expiry और Locked जैसी error states से बाहर निकलने का रास्ता भूल जाना।
- 100% all states coverage को काफ़ी मान लेना: sign-in model में उस तक पहुँचने वाले दो test cases सात में से तीन transitions untested छोड़ देते हैं।
- जिन events को state को refuse करना चाहिए उन्हें कभी न आज़माना, या एक test case में कई आज़माना, जिससे पहला गलत नतीजा बाक़ी को छिपा देता है (defect masking)।
- Guard वाले transition को guard के सिर्फ़ एक तरफ़ टेस्ट करना: पहली गलत कोशिश, लेकिन तीसरी कभी नहीं।
- State की बजाय message जाँचना: "request refused" message दिखे और order फिर भी Shipped में चला जाए, तो यह failure है।
QA का नज़रिया
State transition testing test analysis में शुरू होती है: requirement में status, "के बाद", "जब तक", "सिर्फ़ तब" और "अब नहीं" जैसे शब्द state model का संकेत हैं। Diagram का sketch बनाएँ, table बनाएँ, और खाली व संदिग्ध cells product owner के पास ले जाएँ। Developers से पूछें कि code असल में कौन-से transitions allow करता है; यह अक्सर requirement से अलग होता है।
State table को test cases के साथ testware के रूप में रखें, states, events और transitions की स्थायी IDs के साथ, और coverage इन्हीं शब्दों में report करें: "7 में से 7 valid transitions, 12 में से 9 invalid transitions आज़माए गए"। Fail हुए transition की defect report में start state, event, expected state और actual state लिखें।
अभ्यास
Expense claim workflow मॉडल करें
एक expense tool की requirement: "Claim Draft के रूप में शुरू होता है; Draft रहते हुए उसका owner उसे delete कर सकता है या review के लिए submit कर सकता है। Manager submitted claim को approve करता है या comments के साथ Draft में लौटा देता है। 5,000 SAR से ज़्यादा के claim को manager के बाद Finance की approval भी चाहिए। Finance approved claims का payment करता है।"
State model बनाएँ, 100% valid transitions coverage के लिए कम से कम test cases design करें, और वे invalid transitions चुनें जिन्हें आप सबसे पहले आज़माएँगे। फिर अपने transitions State Transition Generator में डालें, हर line में एक, जैसे Draft --submit--> Submitted, और उसकी state table और invalid-transition tests को अपने जवाब से मिलाएँ।
मॉडल उत्तर दिखाएँ
States: S1 Draft (start), S2 Submitted, S3 Awaiting Finance, S4 Approved, S5 Paid (end), S6 Deleted (end)। Transitions: T1 S1 → S2 submit; T2 S2 → S1 return; T3 S2 → S4 approve [amount ≤ 5,000]; T4 S2 → S3 approve [amount > 5,000]; T5 S3 → S4 Finance approves; T6 S4 → S5 pay; T7 S1 → S6 delete।
तीन test cases सातों transitions और छहों states cover करते हैं: TC-01 (1,200 SAR) submit, return, delete — T1, T2, T7; TC-02 (5,000.00 SAR) submit, approve, pay — T1, T3, T6; TC-03 (5,000.01 SAR) submit, approve, Finance approves, pay — T1, T4, T5, T6। दोनों amounts guard के दोनों तरफ़ टेस्ट करती हैं।
सबसे पहले आज़माने वाले invalid transitions, हर test case में एक: S2 में claim का payment (approve नहीं हुआ); S5 में claim का फिर से payment (double payment); S2 वाले claim को Finance का approve करना, manager को छोड़कर; S4 में claim delete करना। हर एक refuse होना चाहिए और state नहीं बदलनी चाहिए।
सवाल: क्या Finance claim लौटा सकता है, और किस state में? लौटाए गए claim की amount बदले तो क्या guard फिर से जाँचा जाता है?
अक्सर पूछे जाने वाले सवाल
क्या state diagram और flowchart एक ही हैं?
नहीं। Flowchart किसी process के steps क्रम से दिखाता है। State diagram वे स्थितियाँ दिखाता है जिनमें कोई object हो सकता है और वे events जो उसे उनके बीच ले जाते हैं, इसलिए एक ही event अलग-अलग states में अलग नतीजे दे सकता है। कई workflows को दोनों चाहिए: user के रास्ते के लिए flowchart, और object के status के लिए state model।
0-switch और 1-switch coverage में क्या फ़र्क है?
0-switch coverage हर single valid transition चलाता है। 1-switch coverage लगातार आने वाले valid transitions का हर जोड़ा चलाता है, जैसे T3 के बाद T2: पहले गलत code, फिर सही code। ऊपर के तीन test cases यह जोड़ा कभी नहीं चलाते, इसलिए वे ऐसा defect नहीं पकड़ेंगे जिसमें एक गलत कोशिश code को invalid कर दे। 1-switch के लिए ज़्यादा test cases चाहिए और यह Foundation syllabus के तीन criteria से आगे जाता है। State Transition Generator दोनों के लिए test cases बना सकता है।
State transition testing कब इस्तेमाल करें?
जब भी किसी event का जवाब इस पर निर्भर हो कि पहले क्या हुआ: status field वाली हर चीज़ (orders, claims, tickets), accounts और sessions, subscriptions, multi-step wizards, modes वाले devices, और API resources जिनका status बदलता है। जब नतीजा सिर्फ़ मौजूदा inputs के combination पर निर्भर हो, तब decision table बेहतर है।
क्या हर invalid transition टेस्ट करना ज़रूरी है?
पूरे all transitions coverage के लिए हर उस invalid transition को आज़माना ज़रूरी है जो trigger हो सकता है। Mission-critical और safety-critical software के बाहर teams आम तौर पर risk से चुनती हैं: वे जिन्हें user या API client trigger कर सकता है, और वे जो पैसा, data या access बदल सकते हैं। जिन्हें छोड़ें, उन्हें और उनका कारण दर्ज करें।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
states और events परिभाषित करें, फिर transition तालिका, वैध/अमान्य transition टेस्ट और 0-switch/1-switch coverage जनरेट करें।
फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।
संख्यात्मक और लंबाई की constraints के लिए boundary value (min-1, min, min+1, nominal, max-1, max, max+1) जनरेट करें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।