सॉफ़्टवेयर टेस्टिंग लाइफ़ साइकल (STLC)

STLC क्या है — और क्या नहीं

STLC टेस्ट के काम का मॉडल है, कैलेंडर नहीं। Sequential प्रोजेक्ट में हर चरण हफ़्तों का हो सकता है और चरण ज़्यादातर क्रम से चलते हैं; दो हफ़्ते के sprint में छहों चरण हर story के लिए होते हैं, अक्सर कुछ ही दिनों में, और कई एक-दूसरे पर चढ़ जाते हैं। चरणों का तार्किक क्रम है — जो test डिज़ाइन ही नहीं हुआ उसे execute नहीं कर सकते — पर व्यवहार में वे iterative और overlapping होते हैं। CTFL v4.0 अपनी test activities के बारे में यही कहता है: वे अक्सर iterative या समानांतर रूप में चलती हैं, और उन्हें करने का तरीक़ा संदर्भ के हिसाब से ढाला जाता है।

चक्र nested भी होता है। एक release का test cycle होता है; उसके भीतर हर test level (component integration, system, acceptance) का अपना हो सकता है; और हर defect fix confirmation testing और regression testing का एक छोटा चक्र शुरू करता है। इसे lifecycle बनाने वाली बात यह है कि हर चक्र बंद होता है: कोई exit criteria जाँचता है, दर्ज करता है कि क्या टेस्ट हुआ और क्या नहीं, और hand-over करता है।

• डेवलपमेंट के बाद का चरण नहीं — requirements मौजूद होते ही requirement analysis शुरू हो जाता है।
• सिर्फ़ execution नहीं — analysis, design और तैयारी तय करते हैं कि execution कुछ ढूँढने लायक पाएगा या नहीं।
• Documentation की कवायद नहीं — कितना लिखा जाए यह संदर्भ पर निर्भर है: regulated सिस्टम को औपचारिक रिकॉर्ड चाहिए, छोटी product टीम के लिए एक पेज का plan काफ़ी हो सकता है।
• सिर्फ़ टेस्टर का नहीं — component tests डेवलपर चलाते हैं, acceptance प्रोडक्ट ओनर देते हैं, environments में operations मदद करता है।

STLC चरणों की ISTQB test process से मैपिंग

“STLC” इंडस्ट्री का शब्द है; ISTQB इसे परिभाषित नहीं करता। CTFL v4.0 सिलेबस सात गतिविधि-समूहों वाली test process बताता है, और ISO/IEC/IEEE 29119-2 test management processes (test strategy और planning, monitoring और control, completion) और dynamic test processes बताता है। यह टेबल तीनों शब्दावलियों को जोड़ती है ताकि आप job description, ISTQB परीक्षा और मानकों पर आधारित क्वालिटी सिस्टम के बीच आसानी से आ-जा सकें।

• Requirement analysis — ISTQB में: test analysis (क्या टेस्ट करना है); ISO/IEC/IEEE 29119-2 में: test design & implementation process के शुरुआती क़दम।
• Test planning — ISTQB में: test planning; 29119-2 में: test strategy & planning process।
• Test case development — ISTQB में: test design (कैसे टेस्ट करना है) और testware तैयार होने तक test implementation; 29119-2 में: test design & implementation process।
• Test environment setup — ISTQB में: test implementation का environment वाला हिस्सा; 29119-2 में: test environment & data management process।
• Test execution — ISTQB में: test execution; 29119-2 में: test execution process और test incident reporting process।
• Test cycle closure — ISTQB में: test completion; 29119-2 में: test completion process।
• Monitoring और control का STLC में कोई चरण नहीं: ये planning से completion तक चलते हैं, असल प्रगति की plan से तुलना करते हैं और सुधार के क़दम उठाते हैं।
• ISTQB test analysis (क्या टेस्ट करना है — प्राथमिकता वाली test conditions) को test design (कैसे टेस्ट करना है — test cases, coverage items, test data की ज़रूरतें, environment design) से अलग रखता है।
• ISTQB की test implementation में चलाने के लिए ज़रूरी सब कुछ आता है: test data, test procedures, manual और automated scripts, test suites, execution schedule, और बना हुआ व जाँचा हुआ test environment। STLC environment को अलग चरण में निकाल देता है।
• Test analysis ख़ुद test basis का भी दोषों के लिए मूल्यांकन करता है — वही विचार जो STLC के requirement analysis में है।

Industry STLC phase      | ISTQB CTFL v4.0 test activity             | ISO/IEC/IEEE 29119-2 process
-------------------------|-------------------------------------------|------------------------------------------
Requirement analysis     | Test analysis ("what to test")            | Test design & implementation (first steps)
Test planning            | Test planning                             | Test strategy & planning
(runs throughout)        | Test monitoring and test control          | Test monitoring & control
Test case development    | Test design ("how to test")               | Test design & implementation
                         | Test implementation (testware ready)      |
Test environment set-up  | Test implementation (environment ready)   | Test environment & data management
Test execution           | Test execution                            | Test execution; test incident reporting
Test cycle closure       | Test completion                           | Test completion

चरण 1 — Requirement analysis (test analysis)

टेस्टर test basis पढ़ता है — user stories, specifications, designs, API contracts, लागू नियम — और दो सवालों के जवाब देता है: यहाँ क्या टेस्ट किया जा सकता है, और basis में ही क्या गलत या अधूरा है। आउटपुट है risk के हिसाब से प्राथमिकता वाली test conditions की सूची, और requirements में सवालों व दोषों की सूची।

उदाहरण के लिए, “ग्राहक shipping से पहले order cancel कर सकते हैं” से टेस्टर ये conditions निकालता है: pending order cancel करना; shipped order cancel करने की कोशिश; आंशिक रूप से shipped order cancel करना; refund की राशि और तरीक़ा; भेजा गया notification; और किसी दूसरे ग्राहक का order cancel करने की कोशिश। इनमें से दो का जवाब story में नहीं है, इसलिए कोई test case लिखने से पहले वे सवाल बन जाते हैं।

• काम — scope में और scope से बाहर के फ़ीचर तय करना; test conditions निकालना; untestable कथनों को चिह्नित करना; छिपी non-functional ज़रूरतें सामने लाना (performance, security, accessibility, अरबी और RTL); requirements traceability matrix शुरू करना; product risk को likelihood × impact से आँकना।
• Entry criteria — scope के लिए requirements या backlog items उपलब्ध हैं; प्रोडक्ट ओनर या analyst सवालों के जवाब दे सकते हैं।
• Exit criteria — scope की हर requirement की test conditions हैं या एक दर्ज खुला सवाल; अस्पष्टताओं का जवाब मिल गया या उन्हें risk के रूप में स्वीकार किया गया; traceability matrix शुरू हो गई।
• आम दोष — “REQ-14: refund ‘उचित समय में’ — कोई संख्या नहीं”; “REQ-22 और REQ-31 इस पर विरोधाभासी हैं कि guest users cancel कर सकते हैं या नहीं”।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: Requirements → टेस्ट सिनेरियो

चरण 2 — Test planning

Planning scope, approach, संसाधन, schedule और वे मानदंड तय करती है जो चक्र ख़त्म करेंगे। Test plan दस्तावेज़ की बनावट test plan गाइड में है और संगठन-स्तर की approach test strategy गाइड में; यहाँ अहम यह है कि design शुरू होने से पहले planning को क्या तय कर देना चाहिए।

अनुमान किसी घोषित तकनीक से आने चाहिए, अंदाज़े से नहीं। CTFL v4.0 चार तकनीकें बताता है: ratios पर आधारित estimation, extrapolation, Wideband Delphi और three-point estimation। Project risks (देर से आया build, उपलब्ध न होने वाला sandbox, छुट्टी पर गया टेस्टर) plan में contingency के साथ होने चाहिए, उन product risks के बगल में जो test priorities तय करते हैं।

• Plan तय करता है — scope और बाहर रखी चीज़ें; test levels और types; हर risk स्तर के लिए approach; entry और exit criteria; environments और test data; roles; schedule और estimates; tools; risks और contingencies; reporting की आवृत्ति।
• Entry criteria — scope इतना ज्ञात है कि अनुमान लगाया जा सके; test strategy या policy उपलब्ध है; टीम और timeline ज्ञात हैं।
• Exit criteria — plan की समीक्षा उन stakeholders ने की और उसे मंज़ूर किया जो उस पर काम करेंगे; आगे के चरणों के entry और exit criteria तय हैं; environment और data के अनुरोध भेजे जा चुके हैं।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर

चरण 3 — Test case development (design और implementation)

Test conditions, test design techniques के ज़रिए test cases बनती हैं: specification-based design के लिए equivalence partitioning, boundary value analysis, decision tables और state transition testing; experience-based design के लिए error guessing, exploratory और checklist-based testing। एक अच्छा test case कैसे लिखें, यह test case गाइड में है। फिर implementation cases को procedures और suites में संगठित करता है, test data बनाता है, automated scripts लिखता है और execution का क्रम तय करता है। Requirement से condition और condition से case तक traceability बनी रहती है।

नीचे का उदाहरण REQ-07 (“shipment से पहले order cancel किया जा सकता है”) से निकले पाँच test cases दिखाता है, हर एक के साथ वह technique या risk जिससे वह आया: PENDING order cancel करने पर status CANCELLED और पूरा refund (valid equivalence partition); SHIPPED order cancel करने पर 409 (invalid partition); किसी दूसरे ग्राहक का order cancel करने की कोशिश पर 403 और status में कोई बदलाव नहीं (security); एक साथ आए दो cancel requests पर सिर्फ़ एक refund (concurrency); और 0.01 व 99,999.99 SAR की सीमा वाली राशियों का सटीक refund (boundary value analysis)।

• Entry criteria — plan मंज़ूर है; scope का test basis design के लायक स्थिर है; design techniques तय हैं।
• Exit criteria — हर high-risk condition का कम से कम एक test case है; cases का peer review हुआ है; test data तैयार है; automated checks commit हो चुके हैं; traceability matrix में scope की कोई requirement बिना coverage के नहीं; suites और execution का क्रम तय है।

REQ-07  Order can be cancelled before shipment
  TC-07-01  Cancel order in status PENDING      -> status CANCELLED, full refund        (EP valid)
  TC-07-02  Cancel order in status SHIPPED      -> 409 "Order already shipped"          (EP invalid)
  TC-07-03  Cancel another customer's order     -> 403, no state change                 (security)
  TC-07-04  Two cancel requests in parallel     -> one refund only                      (concurrency)
  TC-07-05  Refund for totals SAR 0.01 and 99,999.99 -> exact amounts refunded           (BVA)

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: बाउंड्री वैल्यू एनालिसिस आज़माएँ: टेस्ट डेटा फ़ैक्टरी

चरण 4 — Test environment setup

Test environment वह सब कुछ है जिस पर test चलता है: servers या devices, test हो रहा build, configuration, network, databases और उनका डेटा, test accounts, third-party sandboxes या mocks, और नतीजे देखने के tools। इसे आमतौर पर test case development के समानांतर तैयार किया जाता है, और execution शुरू होने से पहले एक छोटे smoke test से जाँचा जाता है। जो environment production से किसी अहम तरीक़े से अलग हो, वह झूठे pass और झूठे fail देता है।

• Readiness checklist — test हो रहा version deploy और दर्ज है; जहाँ व्यवहार पर असर हो वहाँ configuration production से मेल खाता है (feature flags, locale, time zone); data baseline लोड है और restore हो सकता है; third parties sandbox या mock में हैं, उनकी failures समेत; हर role के लिए test account है; टेस्टर logs पढ़ सकते हैं।
• Entry criteria — environment की ज़रूरतें plan में हैं; infrastructure, sandboxes और test accounts के access का अनुरोध भेजा जा चुका है। Deploy करने लायक build इस चरण को पूरा करने के लिए चाहिए, शुरू करने के लिए नहीं।
• Exit criteria — smoke test पास है; readiness checklist पर sign-off है; data baseline माँगने पर restore हो सकता है।
• आम दोष — “Staging UTC पर चलता है जबकि production Asia/Riyadh इस्तेमाल करता है; ‘आज के orders’ फ़िल्टर तीन घंटे खिसक जाता है।”

आज़माएँ: API हेल्थ चेकर आज़माएँ: Mock API रिस्पॉन्स जनरेटर

चरण 5 — Test execution और defect management

Execution tests को नियोजित क्रम में चलाता है, वास्तविक और अपेक्षित परिणामों की तुलना करता है, और हर नतीजे को passed, failed, blocked या not run के रूप में दर्ज करता है। हर failure का विश्लेषण होता है — product defect, test defect, या environment/data की समस्या — और product defects reproducible steps, सबूत, severity और priority के साथ रिपोर्ट होते हैं। Fixed defects दोबारा टेस्ट होते हैं (confirmation testing) और बदलाव के आसपास के हिस्से फिर जाँचे जाते हैं (regression testing)।

Execution के दौरान monitoring और control रोज़ होते हैं: प्रगति की plan से तुलना होती है, और test lead कमियों पर क़दम उठाता है — priorities बदलना, अस्थिर हिस्से पर exploratory session जोड़ना, या blocker को escalate करना। इसके बाद defect reports उस defect lifecycle और triage से गुज़रती हैं जो उनकी अपनी गाइड में हैं; रिपोर्ट कैसे लिखें यह bug report गाइड बताती है।

नीचे का उदाहरण Release 3.8 के system test के 10 में से छठे दिन की रोज़ की status report है: 260 में से 205 tests चले (79%) — 188 pass, 17 fail, 7 blocked और 48 अभी नहीं चले; खुले defects में 0 blocker, 2 critical, 6 major और 9 minor हैं; और 44 में से 41 high-risk requirements का कम से कम एक test pass हुआ है। Report blocker का नाम (payment sandbox हर card type के लिए 503 लौटाता है) और उठाए गए क़दम भी बताती है। ध्यान दें कि यह सिर्फ़ चलाए गए test cases नहीं, cover हुआ risk भी दिखाती है।

• Entry criteria — environment के exit criteria पूरे हैं और smoke test पास हुआ; test cases और डेटा तैयार हैं; test हो रहे build के release notes हैं।
• Exit criteria — नियोजित tests चले या स्पष्ट फ़ैसले से descope हुए; सभी failures का विश्लेषण हुआ और defects दर्ज हुए; कोई खुला blocker या critical defect नहीं (या दर्ज risk acceptance); regression suite हरा है।

Cycle: Release 3.8 — system test, day 6 of 10
Executed: 205 / 260 (79%)   Passed: 188   Failed: 17   Blocked: 7   Not run: 48
Open defects: Blocker 0 · Critical 2 · Major 6 · Minor 9
High-risk requirements with a passed test: 41 / 44
Blocked by: DEF-311 payment sandbox returns 503 for all card types
Actions: refunds exploratory session moved to day 7; retest DEF-298 and DEF-301 today

आज़माएँ: AI बग विवरण जनरेटर आज़माएँ: AI बग गंभीरता सुझाव आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

चरण 6 — Test cycle closure (test completion)

Closure तब होता है जब exit criteria पूरे हों या stakeholders रुकने का फ़ैसला करें। CTFL v4.0 test completion के काम गिनाता है: सुनिश्चित करना कि अनसुलझे defects change requests या backlog items बनें, रखने लायक testware पहचानकर archive या hand over करना, environment को तय स्थिति में बंद करना, सीखों के लिए test activities का विश्लेषण करना, और test completion report बनाकर साझा करना।

• Completion report में — plan के मुक़ाबले की गई टेस्टिंग और कोई विचलन; exit criteria के विरुद्ध क्वालिटी का आकलन; खुले defects और उनका risk; बचे हुए risks; मुख्य माप (requirement coverage, severity के हिसाब से defects, पिछली release से escape हुए defects); एक सिफ़ारिश, जबकि release का फ़ैसला stakeholders का ही रहता है।
• Entry criteria — execution पूरा हुआ या फ़ैसले से रोका गया; exit criteria का मूल्यांकन हो चुका है।
• Exit criteria — report जारी हुई; testware archive हुआ; regression suite में नए tests और हर escaped defect शामिल है; retrospective से निकले सुधार-कामों के owners हैं।

आज़माएँ: AI टेस्ट कवरेज एनालाइज़र

हर चरण के entry और exit criteria एक नज़र में

मानदंड तभी काम करते हैं जब वे मापने योग्य हों और किसी को छोड़ना चुपचाप चूक नहीं बल्कि दिखने वाला फ़ैसला हो। Agile टीमों में यही विचार Definition of Ready (story के लिए entry) और Definition of Done (exit) के रूप में आता है।

• Requirement analysis — entry: scope की stories या specs उपलब्ध हैं और सवालों के लिए प्रोडक्ट ओनर मिल सकता है। Exit: scope की हर requirement की test conditions हैं या एक दर्ज खुला सवाल।
• Test planning — entry: scope और timeline ज्ञात हैं, strategy उपलब्ध है। Exit: plan मंज़ूर है, entry/exit criteria तय हैं, environment और डेटा के अनुरोध भेजे जा चुके हैं।
• Test case development — entry: plan मंज़ूर है और scope का test basis स्थिर है। Exit: high-risk conditions कवर हैं, cases का review हुआ है, डेटा और automated checks तैयार हैं, RTM अपडेट है।
• Environment setup — entry: environment की ज़रूरतें plan में हैं और access के अनुरोध भेजे जा चुके हैं। Exit: smoke test पास है, data baseline restore हो सकता है, third parties sandbox या mock में हैं।
• Test execution — entry: smoke test पास है; cases, डेटा और release notes तैयार हैं। Exit: नियोजित tests चले या फ़ैसले से descope हुए, कोई खुला blocker या critical defect नहीं, regression suite हरा है।
• Test cycle closure — entry: execution पूरा हुआ या फ़ैसले से रोका गया। Exit: completion report जारी हुई, testware archive हुआ, सीखों से निकले कामों के owners हैं।

Phase                  | Entry criteria (example)                          | Exit criteria (example)
-----------------------|---------------------------------------------------|------------------------------------------------
Requirement analysis   | Stories/specs available for the scope;            | Every in-scope requirement has test conditions
                       | product owner reachable for questions             | or a logged open question
Test planning          | Scope and timeline known; strategy available      | Plan approved; entry/exit criteria agreed;
                       |                                                   | environment and data requested
Test case development  | Plan approved; test basis stable for the scope    | High-risk conditions covered; cases reviewed;
                       |                                                   | data and automated checks ready; RTM updated
Environment set-up     | Environment spec in plan; access requested        | Smoke test passes; data baseline restorable;
                       |                                                   | third parties sandboxed or mocked
Test execution         | Smoke passed; cases, data, release notes ready    | Planned tests run or descoped by decision;
                       |                                                   | 0 open Blocker/Critical; regression green
Test cycle closure     | Execution complete or stopped by decision         | Completion report issued; testware archived;
                       |                                                   | lessons learned have owners

Sprint और pipeline में STLC, और आम गलतियाँ

Scrum में चक्र हर story और हर sprint के लिए चलता है: backlog refinement ही requirement analysis है और Definition of Ready उसका exit; sprint planning में sprint के पैमाने पर test planning शामिल है; design और automation sprint के दौरान होते हैं; pipeline environment देती है; execution लगातार चलता है; sprint review और retrospective closure का काम करते हैं। CI/CD में pipeline हर बदलाव पर environment setup और ज़्यादातर execution automate करती है, और इंसानी मेहनत analysis, design, exploratory testing और production signals पढ़ने पर जाती है।

• Analysis के सवालों के जवाब आने से पहले tests डिज़ाइन करना — जवाब आने पर cases दोबारा लिखे जाते हैं।
• Exit criteria लिखे गए पर deadline के दबाव में अनदेखे — खुले risk के साथ release तभी जायज़ है जब वह स्पष्ट और दर्ज फ़ैसला हो।
• Traceability नहीं — कोई नहीं बता सकता कि कौन-सी requirements अनटेस्टेड हैं।
• Environment setup build आने तक टालना — execution की खिड़की ठीक setup के समय जितनी सिकुड़ जाती है।
• Closure छोड़ देना — escaped defects कभी regression suite में नहीं आते और वही सबक फिर सीखने पड़ते हैं।
• Cover हुए risk की जगह चलाए गए test cases की गिनती को प्रगति मानना।

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021टेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021टेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।