SDLC और STLC की पूरी समझ

Mutqan Soft की QA टीम द्वारा · अपडेट: 6 अक्टूबर 2026 · 18 मिनट पढ़ने का समय

सॉफ़्टवेयर डेवलपमेंट लाइफ़ साइकल (SDLC) गतिविधियों का वह क्रम है जो किसी प्रोडक्ट को आइडिया से चलते हुए सॉफ़्टवेयर तक ले जाता है और उसे चलाता रहता है: requirements, डिज़ाइन, implementation, integration, release और operation। सॉफ़्टवेयर टेस्टिंग लाइफ़ साइकल (STLC) टेस्ट गतिविधियों का क्रम है — analysis, planning, design, environment की तैयारी, execution और closure — जो उस सॉफ़्टवेयर की क्वालिटी का सबूत देता है। STLC कोई ऐसा चरण नहीं जो डेवलपमेंट ख़त्म होने पर शुरू हो; यह SDLC के साथ-साथ चलता है, और हर डेवलपमेंट गतिविधि के सामने एक टेस्ट गतिविधि होती है।

यह pillar गाइड बताती है कि दोनों लाइफ़ साइकल कैसे जुड़े हैं, हर डेवलपमेंट चरण में टेस्टर कहाँ शामिल होता है, इंडस्ट्री का शब्द “STLC” ISTQB की test process से कैसे मेल खाता है, और sequential, V-model, iterative, Scrum और DevOps डिलीवरी में टेस्टिंग कैसे बदलती है। इस विषय का संकरा पेज, सॉफ़्टवेयर टेस्टिंग लाइफ़ साइकल, STLC के हर चरण को गहराई से देखता है।

SDLC और STLC: हर शब्द का मतलब

SDLC बताता है कि सॉफ़्टवेयर कैसे बनता और मेंटेन होता है। अलग-अलग संगठनों और मॉडलों में इसके चरणों के नाम अलग होते हैं, पर काम हर जगह वही है: क्या बनाना है यह तय करना (requirements), कैसे बनाना है यह तय करना (architecture और design), उसे लिखना (implementation), हिस्सों को जोड़ना (integration), यूज़र तक पहुँचाना (release और deployment), और फिर चलाना, मॉनिटर करना और बदलना (operation और maintenance)। SDLC पहली release पर ख़त्म नहीं होता; यह तब ख़त्म होता है जब प्रोडक्ट retire किया जाता है।

STLC बताता है कि उस काम के भीतर टेस्टिंग कैसे संगठित होती है। ज़्यादातर ट्रेनिंग मटीरियल में पढ़ाए जाने वाले संस्करण में छह चरण हैं: requirement analysis, test planning, test case development, test environment setup, test execution और test cycle closure। हर चरण के इनपुट, आउटपुट और ऐसे मानदंड होते हैं जो बताते हैं कि वह कब शुरू हो सकता है और कब पूरा माना जाएगा।

एक बारीकी ज़रूरी है। “STLC” इंडस्ट्री का शब्द है जो कोर्स, इंटरव्यू और जॉब डिस्क्रिप्शन में इस्तेमाल होता है; यह ISTQB द्वारा परिभाषित शब्द नहीं है। ISTQB Certified Tester Foundation Level (CTFL) v4.0 सिलेबस एक test process बताता है जिसमें गतिविधियों के सात समूह हैं: test planning, test monitoring और test control, test analysis, test design, test implementation, test execution और test completion। ISO/IEC/IEEE 29119-2 संगठनात्मक, test management और dynamic test स्तरों पर test processes बताता है। सार वही है; नाम और चरणों के बीच की सीमाएँ अलग हैं। संक्षेप में:

Requirement analysis ≈ test analysis — तय करना कि क्या टेस्ट करना है (test conditions) और test basis में ही दोष ढूँढना।
Test planning ≈ test planning — साथ में test monitoring और test control, जिनका STLC में अपना कोई चरण नहीं और जो planning से completion तक चलते हैं।
Test case development ≈ test design (कैसे टेस्ट करना है: test cases, coverage items, डेटा की ज़रूरतें) और test implementation का ज़्यादातर हिस्सा (procedures, scripts, suites, डेटा)।
Test environment setup ≈ test implementation का environment वाला हिस्सा; ISO/IEC/IEEE 29119-2 इसे अलग process मानता है।
Test execution ≈ test execution, जिसमें defect reporting, confirmation testing और regression testing शामिल हैं।
Test cycle closure ≈ test completion।

डेवलपमेंट और टेस्टिंग लाइफ़ साइकल का संबंध

सबसे सरल सही तस्वीर है दो समानांतर ट्रैक जिनके बीच कड़ियाँ हैं। डेवलपमेंट का हर work product अपने चरण के टेस्ट काम को इनपुट देता है। Requirements, designs और API contracts वह test basis हैं जिसे test analysis और design पढ़ते हैं: requirement वह है जिसे test analysis पढ़ता है, API contract वह है जिससे integration tests निकलते हैं। Build, और बाद में चलता हुआ सिस्टम, test object है: वह चीज़ जिस पर test execution चलता है। और टेस्टिंग का हर आउटपुट डेवलपमेंट में वापस जाता है: review comment requirement बदलता है, defect report कोड बदलती है, test completion report release के फ़ैसले को जानकारी देती है।

टेस्टिंग डेवलपमेंट के साथ-साथ चलती है, उसके बाद नहीं: हर डेवलपमेंट आउटपुट अपने चरण के टेस्ट काम का test basis या test object है, और टेस्ट आउटपुट डेवलपमेंट में वापस जाते हैं।

डेवलपमेंट (SDLC):
1Requirements
आगे जाता है: Stories, specs और NFRs
टेस्टिंग (STLC):
Requirement analysis≈ test analysis; test planning की शुरुआत
वापस जाता है: Review comment requirement बदलता है
डेवलपमेंट (SDLC):
2Design
आगे जाता है: Architecture, API contracts और UI designs
टेस्टिंग (STLC):
Test analysis और designIntegration और system levels के लिए; environment की ज़रूरतें पहचानना
डेवलपमेंट (SDLC):
3Implementation
आगे जाता है: कोड, unit tests और builds
टेस्टिंग (STLC):
Test design और implementationTest data, environment setup, automated checks और CI में static analysis
डेवलपमेंट (SDLC):
4Integration
आगे जाता है: Integrated build
टेस्टिंग (STLC):
Test executionTest environment में deploy; smoke और integration tests
वापस जाता है: Defect report कोड बदलती है
डेवलपमेंट (SDLC):
5Release
आगे जाता है: पहले release candidate, फिर deployed version
टेस्टिंग (STLC):
Test execution और completionSystem, regression और acceptance execution; exit criteria का मूल्यांकन; deployment verification
वापस जाता है: Test completion report release के फ़ैसले को जानकारी देती है
डेवलपमेंट (SDLC):
6Operation
आगे जाता है: चलता हुआ सिस्टम और उसके बदलाव
टेस्टिंग (STLC):
Maintenance testingFixes के लिए regression testing; production signals का review

चरण 1–5 के दौरान Test monitoring और test control: STLC में इनका अपना कोई चरण नहीं; ये planning से completion तक चलते हैं।

डैश वाली कड़ियाँ डेवलपमेंट में वापस जाने वाले टेस्ट आउटपुट के उदाहरण हैं, पूरी सूची नहीं।

CTFL v4.0 इसे किसी भी lifecycle मॉडल के लिए अच्छी प्रैक्टिस के रूप में कहता है: हर डेवलपमेंट गतिविधि के लिए एक संबंधित टेस्ट गतिविधि होती है; हर test level के अपने विशिष्ट उद्देश्य होते हैं; किसी test level का test analysis और design संबंधित डेवलपमेंट चरण के दौरान ही शुरू होता है; और टेस्टर work products के review में उनका ड्राफ़्ट उपलब्ध होते ही शामिल होते हैं। जो टीम ये चार नियम मानती है, उसने असल में अपने STLC को SDLC के साथ जोड़ लिया है, नाम चाहे जो हों।

दायरा — SDLC पूरे प्रोडक्ट को आइडिया से retirement तक कवर करता है; STLC उसके भीतर verification और validation का काम कवर करता है।
आउटपुट — SDLC चलता हुआ सॉफ़्टवेयर और उसके दस्तावेज़ देता है; STLC testware देता है (test conditions, cases, डेटा, scripts, results, defect reports, status और completion reports) और क्वालिटी व बचे हुए risk का आकलन।
स्वामित्व — SDLC पूरी टीम का है, जिसे product और engineering लीड करते हैं; STLC आमतौर पर टेस्ट रोल लीड करते हैं, पर component tests डेवलपर के और acceptance प्रोडक्ट ओनर का होता है।
आवृत्ति — एक प्रोडक्ट का एक SDLC होता है जिसमें कई iterations होते हैं; STLC हर release, हर sprint और हर test level के लिए दोहराया जाता है, और हर defect fix confirmation और regression testing का एक छोटा चक्र शुरू करता है।
सफलता का पैमाना — SDLC के लिए यूज़र को दी गई वैल्यू; STLC के लिए सबूत कितना उचित भरोसा देता है और production तक कितने कम दोष पहुँचते हैं।

SDLC के हर चरण में QA कहाँ शामिल होता है

जो टेस्टर सिर्फ़ build तैयार होने पर जुड़ते हैं, वे failures तो ढूँढ सकते हैं पर दोषों को रोक नहीं सकते। नीचे की सूची बताती है कि हर डेवलपमेंट चरण में टेस्टर क्या करता है, और वह चरण किस तरह की समस्या पकड़ने के लिए सबसे उपयुक्त है।

Requirements — stories और specifications का review करें: अस्पष्टता, विरोधाभास, छूटे हुए error paths और testability; acceptance criteria सुझाएँ; product risks की सूची बनाएँ। आम findings: “उचित समय में refund” में कोई संख्या नहीं; आंशिक रूप से ship हुए order का क्या होगा, यह कहीं नहीं लिखा।
Design — architecture, API contracts और UI designs का testability के लिए review: क्या सर्विस mocked payment provider के साथ चल सकती है, क्या errors request id के साथ log होते हैं, क्या time zone और locale कॉन्फ़िगर हो सकते हैं? interface contracts से integration test conditions निकालें और non-functional लक्ष्य संख्या में माँगें (response time, accessibility स्तर, right-to-left layout)।
Implementation — फ़ीचर बनते समय ही test cases, test data और automated checks तैयार करें; component tests पर डेवलपर के साथ काम करें; सुनिश्चित करें कि static analysis और code review pipeline में चलते हैं। यहाँ टेस्टर का लक्ष्य यह है कि सौंपा गया पहला build ही स्पष्ट जाँचें पास कर ले।
Integration — component integration और system integration tests चलाएँ: API contracts, सर्विसों के बीच डेटा का प्रवाह, third-party timeouts और error responses को संभालना; हर integrated build पर smoke और regression suites चलाएँ।
Release — system और acceptance testing, release candidate पर पूरा regression, exit criteria का मूल्यांकन, go/no-go फ़ैसले में इनपुट, और deployment के ठीक बाद यह verification कि release target environment में काम कर रही है।
Operation — production signals (errors, latency, यूज़र रिपोर्ट) का review, hot-fixes की टेस्टिंग, platform, किसी dependency या डेटा के बदलने पर maintenance testing, और हर escaped defect को regression test में बदलना।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI Requirement गैप एनालाइज़र आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

SDLC ↔ STLC मैपिंग

यह टेबल हर डेवलपमेंट चरण को उन टेस्ट गतिविधियों से जोड़ती है जो उसके दौरान चलती हैं, उनसे बनने वाले test work products से, और उस test level से जिसे वे तैयार या execute करती हैं। इसे पंक्ति-दर-पंक्ति पढ़ें: किसी पंक्ति की टेस्ट गतिविधि तब शुरू होती है जब उसी पंक्ति का डेवलपमेंट आउटपुट मौजूद हो, तब नहीं जब पूरा प्रोजेक्ट उस पंक्ति तक पहुँचे।

Requirements — डेवलपमेंट आउटपुट: stories, specs और NFRs। टेस्ट गतिविधियाँ: requirement analysis (≈ test analysis) और test planning की शुरुआत। Test work products: review findings, test conditions, risk list और test plan का ड्राफ़्ट। Test level: acceptance (योजना में)।
Design — डेवलपमेंट आउटपुट: architecture, API contracts और UI designs। टेस्ट गतिविधियाँ: integration और system levels के लिए analysis और design, और environment की ज़रूरतें पहचानना। Test work products: integration test conditions और environment requirements। Test level: integration और system (योजना में)।
Implementation — डेवलपमेंट आउटपुट: कोड, unit tests और builds। टेस्ट गतिविधियाँ: test design और implementation, test data, environment setup, automated checks और CI में static analysis। Test work products: test cases, scripts, डेटा और automated checks। Test level: component (डेवलपर)।
Integration — डेवलपमेंट आउटपुट: integrated build। टेस्ट गतिविधियाँ: test environment में deploy, smoke और integration tests का execution। Test work products: test logs और defect reports। Test level: component integration और system integration।
Release — डेवलपमेंट आउटपुट: पहले release candidate, फिर deployed version। टेस्ट गतिविधियाँ: system, regression और acceptance execution, monitoring और control, exit criteria का मूल्यांकन, deployment verification और test completion। Test work products: results, defects, status reports, go/no-go इनपुट और completion report। Test level: system और acceptance, साथ में production में smoke check।
Operation — डेवलपमेंट आउटपुट: चलता हुआ सिस्टम और उसके बदलाव। टेस्ट गतिविधियाँ: fixes के लिए maintenance और regression testing, और production signals का review। Test work products: अपडेटेड regression suite और सीखे गए सबक। Test level: जिस level को बदलाव छूता है।

SDLC phase      | Development output          | Test activities (STLC ~ ISTQB)              | Test work products                 | Test level
----------------|-----------------------------|---------------------------------------------|------------------------------------|---------------------------
Requirements    | Stories, specs, NFRs        | Requirement analysis ~ test analysis;       | Review findings, test conditions,  | Acceptance (planned)
                |                             | test planning starts                        | risk list, draft test plan         |
Design          | Architecture, API contracts,| Analysis and design for integration and     | Integration test conditions,       | Integration, system
                | UI designs                  | system levels; environment needs identified | environment requirements           | (planned)
Implementation  | Code, unit tests, builds    | Test design and implementation; test data;  | Test cases, scripts, data,         | Component (developers)
                |                             | environment set-up; automated checks;       | automated checks                   |
                |                             | static analysis in CI                       |                                    |
Integration     | Integrated build            | Deploy to test env; smoke and integration   | Test logs, defect reports          | Component integration,
                |                             | test execution                              |                                    | system integration
Release         | Release candidate, then     | System, regression and acceptance           | Results, defects, status reports;  | System, acceptance;
                | deployed version            | execution; monitoring and control;          | go/no-go input, completion report  | smoke in production
                |                             | exit-criteria evaluation; deployment        |                                    |
                |                             | verification; test completion               |                                    |
Operation       | Running system, changes     | Maintenance and regression testing for      | Updated regression suite,          | Whatever the change touches
                |                             | fixes; review of production signals         | lessons learned                    |

आज़माएँ: Requirements → टेस्ट केस

Shift-left और shift-right टेस्टिंग

Shift-left का मतलब है टेस्ट गतिविधियों को lifecycle में पहले ले जाना ताकि दोष तब मिलें जब उन्हें ठीक करना सबसे सस्ता हो। CTFL v4.0 इस approach को बताता है और आम प्रैक्टिस गिनाता है: टेस्टर के नज़रिए से specifications का review, कोड लिखे जाने से पहले test cases लिखना, तेज़ feedback के लिए continuous integration, dynamic testing से पहले static analysis, और जहाँ संभव हो component स्तर पर ही non-functional testing शुरू करना। सिलेबस लागत का पक्ष भी बताता है: shift-left के लिए प्रोजेक्ट की शुरुआत में अतिरिक्त ट्रेनिंग, मेहनत या लागत लग सकती है, जिससे बाद में मेहनत बचने की उम्मीद होती है। Shift-left एक स्थापित प्रैक्टिस है।

Shift-right का मतलब है टेस्टिंग और निगरानी को production तक बढ़ाना: बदलाव को पहले ट्रैफ़िक के छोटे हिस्से पर release करके baseline से तुलना करना (canary release, जैसा Google की SRE workbook बताती है), अधूरे फ़ीचर्स को feature flags के पीछे छिपाना, live endpoints पर synthetic checks चलाना, और हर deploy के बाद error rate और latency देखना। Canary releases और production monitoring लगातार deploy करने वाली टीमों में स्थापित प्रैक्टिस हैं; production में नियंत्रित fault-injection प्रयोग (जिन्हें अक्सर chaos engineering कहा जाता है) इससे एक क़दम आगे जाते हैं।

दोनों एक-दूसरे के पूरक हैं, विकल्प नहीं। Shift-left build तक पहुँचने वाले दोषों की संख्या घटाता है; shift-right उन दोषों का नुक़सान सीमित करता है जो फिर भी यूज़र तक पहुँच जाते हैं, और बताता है कि आपके pre-release tests ने कौन-से छोड़े। Production में टेस्टिंग कभी pre-release टेस्टिंग की जगह नहीं लेती, और इसके लिए सुरक्षा-उपाय चाहिए: अलग test accounts, test transactions में कोई असली personal data नहीं, और ऐसा flag या rollback जो बदलाव को मिनटों में बंद कर सके।

Shift-left के उदाहरण — sprint planning से पहले acceptance criteria का review; endpoint बनने से पहले OpenAPI दस्तावेज़ से API contract tests लिखना; हर pull request पर unit और static checks।
Shift-right के उदाहरण — 5% ट्रैफ़िक पर canary, और error rate baseline से ऊपर जाने पर automatic rollback; हर मिनट एक synthetic login check; सभी public APIs पर deploy के बाद health check।

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

Lifecycle मॉडल और हर मॉडल में टेस्टिंग का फ़र्क़

Lifecycle मॉडल तय करता है कि टेस्ट गतिविधियाँ कब हो सकती हैं, कितना लिखा जाता है और टेस्टिंग का सबसे बड़ा risk क्या है। टेस्ट गतिविधियाँ ख़ुद — analysis, design, execution, completion — हर मॉडल में होती हैं; बदलता है उनका समय और उनकी बारीकी।

Sequential (waterfall) — चरण क्रम से चलते हैं और हर चरण अगले के शुरू होने से पहले ख़त्म होता है। Dynamic testing implementation के बाद एक test phase में केंद्रित होती है; test planning और documentation पहले से और आमतौर पर औपचारिक रूप में होते हैं। मुख्य risk देर है: requirements के दोष लिखे जाने के महीनों बाद मिलते हैं, और जब डेवलपमेंट देर से चलता है तो test phase ही दबती है। इसका उपाय है शुरुआती चरणों में static testing (requirements और design के reviews) करना, भले dynamic testing इंतज़ार करे।
V-model — अब भी sequential, पर हर डेवलपमेंट स्तर को एक test level से जोड़ता है: requirements को acceptance testing से, system specification को system testing से, architectural design को integration testing से, detailed design को component testing से। हर स्तर का test analysis और design तभी शुरू हो जाता है जब उसका डेवलपमेंट समकक्ष बनता है, जो shift-left का शुरुआती रूप है; execution फिर भी V के दाहिने हिस्से पर, कोड बनने के बाद होता है।
Iterative और incremental — प्रोडक्ट increments में बनता है, और हर increment अपने design, build और test से गुज़रता है। टेस्टिंग हर iteration में दोहराई जाती है, इसलिए बढ़ता regression suite मुख्य लागत बन जाता है; automation के बिना हर iteration पुराने व्यवहार की दोबारा जाँच में ज़्यादा और नए पर कम समय लगाता है।
Agile / Scrum — Scrum Guide एक महीने या उससे कम के Sprints, Definition of Done पूरा करने वाला Increment, और तीन accountabilities (Product Owner, Scrum Master, Developers) परिभाषित करता है, जिनमें टेस्टर का कोई अलग रोल नहीं: Increment बनाने वाला हर व्यक्ति Developer है, इसलिए टेस्टिंग Sprint के भीतर पूरी टीम की ज़िम्मेदारी है। Documentation हल्का होता है, acceptance criteria और Definition of Done exit criteria का काम करते हैं, और test-first प्रैक्टिस (TDD, ATDD, BDD) आम हैं। मुख्य risk यह है कि story टेस्टिंग पूरी हुए बिना “done” मान ली जाए, इसलिए टेस्टिंग को Definition of Done में शामिल किया जाता है। Agile testing quadrants — जिन्हें Brian Marick ने परिभाषित किया और Lisa Crispin व Janet Gregory ने अपनी किताब Agile Testing में बताया — टीम को यह जाँचने में मदद करते हैं कि business-facing, technology-facing, manual और automated टेस्टिंग सब मौजूद हैं।
DevOps और continuous delivery — हर बदलाव एक CI/CD pipeline से गुज़रता है जो build, deploy और automated tests चलाती है, इसलिए pipeline ही test execution का मुख्य इंजन है और quality gates उसी में रहते हैं। Releases छोटी और बार-बार होती हैं, जिससे हर एक का risk घटता है, और shift-right monitoring चक्र पूरा करती है। DORA के change fail rate और failed deployment recovery time यह बताने वाले उपयोगी संकेत हैं कि pipeline में टेस्टिंग अपना काम कर रही है या नहीं। CTFL v4.0 बताता है कि यूज़र के नज़रिए से manual testing फिर भी ज़रूरी है और pipeline को ख़ुद बनाना और मेंटेन करना पड़ता है। यहाँ मुख्य risk धीमी या flaky pipeline और ऐसे blind spots हैं जहाँ automated checks नहीं पहुँचते; pipeline का रिकॉर्ड ही documentation बन जाता है, और मुख्य प्रैक्टिस है तेज़ test suites के साथ production monitoring।

Model          | When dynamic testing runs        | Documentation      | Main testing risk                     | Key practice
---------------|----------------------------------|--------------------|---------------------------------------|------------------------------
Waterfall      | After implementation, one phase  | Formal, up front   | Requirement defects found late;       | Early reviews of requirements
               |                                  |                    | test phase squeezed                   | and design
V-model        | Per level, right side of the V   | Formal, per level  | Execution still late                  | Design tests per level early
Iterative      | Every iteration                  | Moderate           | Regression effort grows each round    | Automate regression
Scrum          | Inside every Sprint              | Light, just enough | "Done" without testing done           | Testing in Definition of Done
DevOps / CD    | On every change, in the pipeline | Pipeline as record | Slow or flaky pipeline; blind spots   | Fast suites + monitoring

पूरे lifecycle में entry और exit criteria

Entry criteria किसी गतिविधि को शुरू करने की पूर्व-शर्तें बताते हैं; exit criteria बताते हैं कि उसे पूरा घोषित करने से पहले क्या हासिल होना चाहिए। CTFL v4.0 बताता है कि agile टीमों में exit criteria को अक्सर Definition of Done और किसी user story के entry criteria को Definition of Ready कहा जाता है। एंड-टू-एंड QA pillar सामान्य overview देती है और टेस्टिंग लाइफ़ साइकल वाला पेज हर STLC चरण के मानदंड देता है; SDLC स्तर पर उपयोगी gates डेवलपमेंट चरणों के बीच के hand-overs हैं:

Requirements → design — दायरे की हर story के acceptance criteria हैं, error paths समेत; ambiguity review हो चुका है; खुले सवालों का एक owner और तारीख़ है।
Design → implementation — API contracts प्रकाशित हैं; non-functional लक्ष्य संख्याएँ हैं, विशेषण नहीं; test environment की ज़रूरतें तय हैं।
Implementation → integration — build हरा है; unit tests पास हैं; static analysis में कोई नया critical finding नहीं; बदलाव का code review हुआ है।
Integration → release — release candidate test environment में deploy होता है; smoke suite पास है; test data baseline लोड है। यही release candidate पर system और acceptance testing शुरू करने का gate है।
Release के भीतर, release candidate → production (go/no-go फ़ैसला) — नियोजित tests चले या स्पष्ट रूप से descope हुए; कोई खुला blocker या critical defect नहीं; regression suite हरा; बचे risks प्रोडक्ट ओनर ने लिखित में स्वीकार किए।
Release → operation — deployment verification पास; नए व्यवहार के लिए dashboards और alerts मौजूद; rollback का अभ्यास हो चुका है।

उदाहरण: एक फ़ीचर दोनों lifecycle से गुज़रता है

उदाहरण के लिए, रियाद का एक काल्पनिक ऑनलाइन स्टोर checkout पर SAR 200 से SAR 5,000 तक के orders के लिए एक बाहरी instalment provider के ज़रिए “4 किस्तों में भुगतान” जोड़ता है। हर SDLC चरण में टेस्टिंग यह करती है।

Requirements — टेस्टर का review तीन सवाल पूछता है जिनका story ने जवाब नहीं दिया: SAR 999.99 को चार भुगतानों में कैसे बाँटा जाएगा (rounding से बचा halala — रियाल का सौवाँ हिस्सा — किसके हिस्से जाएगा)? Provider मना करे तो shopper क्या देखेगा? दो किस्तें चुकने के बाद आंशिक refund कैसे होगा? जवाब acceptance criteria बन जाते हैं।
Design — provider के API contract का review होता है; टेस्टर sandbox account और decline व timeout responses के लिए mock माँगता है, और यह नियम भी कि checkout हार मानने से पहले कितना इंतज़ार करेगा।
Implementation — boundary values (199.99, 200.00, 5,000.00, 5,000.01), provider responses की equivalence classes (approved, declined, timeout, malformed) और payment व refund को सबसे ऊपर रखने वाली risk ranking के साथ test cases डिज़ाइन होते हैं; endpoints बनते ही API checks automate होते हैं।
Integration — tests provider sandbox पर चलते हैं: approval, decline, 30 सेकंड का timeout, duplicate callback। एक defect मिलता है: “Provider callback दो बार आने पर order हमेशा के लिए PENDING में रहता है।”
Release — पूरे checkout का regression, exit criteria का मूल्यांकन (कोई खुला critical defect नहीं, सभी high-risk conditions पास), फिर पहले 5% ट्रैफ़िक पर release, और instalment error rate की तुलना card-payment baseline से।
Operation — production में peak hours पर provider timeouts की छोटी दर दिखती है; टेस्टर retry path के लिए regression test और timeout rate के लिए monitoring check जोड़ता है।

आज़माएँ: बाउंड्री वैल्यू एनालिसिस आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

इस विषय का नक़्शा और आगे कहाँ जाएँ

यह pillar lifecycle से जुड़े सवालों का प्रवेश-बिंदु है। सॉफ़्टवेयर टेस्टिंग लाइफ़ साइकल वाला पेज हर STLC चरण को गहराई से देखता है — काम, work products, हर चरण के entry और exit criteria — और उसे ISTQB test process और ISO/IEC/IEEE 29119-2 से मैप करता है। संबंधित pillars पड़ोसी विषय कवर करते हैं: static testing और reviews (कोई कोड चलने से पहले requirements और designs का review कैसे होता है), test strategy, test planning और risk-based testing (मेहनत कैसे तय और क्रमबद्ध होती है), defect lifecycle और triage (रिपोर्ट होने के बाद defect का क्या होता है), और CI/CD testing के साथ smoke, sanity और regression testing और deployment verification (pipeline के भीतर चक्र कैसे चलता है)।

Test levels, test types और release gates की पूरी तस्वीर के लिए एंड-टू-एंड क्वालिटी एश्योरेंस pillar देखें; क्या automate करें और क्या manual रखें, इसके लिए manual बनाम automated testing की तुलना देखें। किसी भी टीम के लिए एक छोटी self-check:

टेस्टर डेवलपमेंट शुरू होने से पहले requirements का review करते हैं, पहले build के बाद नहीं।
हर डेवलपमेंट चरण की एक नामित टेस्ट गतिविधि और owner है।
Hand-overs के लिए entry और exit criteria मौजूद हैं, और किसी मानदंड को छोड़ना एक स्पष्ट, दर्ज फ़ैसला है।
Regression suite हर integrated build पर अपने-आप चलता है।
हर release के बाद production signals का review होता है और escaped defects regression tests बनते हैं।

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

SDLC और STLC में क्या फ़र्क़ है?

SDLC सॉफ़्टवेयर बनाने और चलाने की पूरी प्रक्रिया है — requirements, design, implementation, integration, release और operation। STLC उसके भीतर टेस्टिंग गतिविधियों का क्रम है — requirement analysis, test planning, test case development, environment setup, execution और closure। SDLC प्रोडक्ट बनाता है; STLC उसकी क्वालिटी का सबूत देता है।

क्या STLC, SDLC का हिस्सा है?

हाँ। STLC, SDLC के भीतर और उसके समानांतर चलता है: test analysis requirements के साथ, test design design और implementation के साथ, execution integration और release के साथ शुरू होता है, और operation के दौरान maintenance testing चलती रहती है। यह डेवलपमेंट ख़त्म होने के बाद शुरू होने वाला चरण नहीं है।

क्या ISTQB “STLC” शब्द इस्तेमाल करता है?

नहीं। STLC इंडस्ट्री का शब्द है। ISTQB CTFL v4.0 सिलेबस सात गतिविधि-समूहों वाली test process बताता है — test planning, test monitoring और control, test analysis, test design, test implementation, test execution और test completion — जो अलग नामों और सीमाओं के साथ वही काम कवर करती है।

SDLC में टेस्टिंग कब शुरू होनी चाहिए?

जैसे ही review करने लायक कोई work product हो — आमतौर पर requirements का पहला ड्राफ़्ट। Requirements और designs का review static testing है; यह कोई कोड लिखे जाने से पहले ही अस्पष्टताएँ और छूटे केस पकड़ता है, जब उन्हें ठीक करना सबसे सस्ता होता है।

Agile में टेस्टिंग waterfall से कैसे अलग है?

Waterfall में dynamic testing implementation के बाद एक चरण में केंद्रित होती है, और औपचारिक documentation पहले से प्लान होता है। Scrum में टेस्टिंग हर Sprint के भीतर पूरी टीम की ज़िम्मेदारी के रूप में होती है, documentation हल्का होता है, और Definition of Done exit criteria का काम करता है। Agile में regression automation कहीं ज़्यादा अहम है क्योंकि वही व्यवहार हर Sprint में दोबारा जाँचा जाता है।

Shift-left और shift-right टेस्टिंग में क्या फ़र्क़ है?

Shift-left टेस्टिंग को पहले ले जाता है — requirements review, कोड से पहले tests, CI में तेज़ checks — ताकि दोष रोके जा सकें। Shift-right टेस्टिंग को production तक बढ़ाता है — canary releases, feature flags, monitoring और synthetic checks — ताकि pre-release टेस्टिंग से छूटी चीज़ें पकड़ी जाएँ और उनका असर सीमित हो। परिपक्व टीमें दोनों करती हैं।

Scrum में टेस्टिंग की ज़िम्मेदारी किसकी है?

पूरी Scrum Team की। Scrum Guide में टेस्टर की कोई अलग accountability नहीं है: Developers एक उपयोग योग्य Increment बनाते हैं जो Definition of Done पूरा करता है, और टेस्टिंग उसी का हिस्सा है। कई टीमों में फिर भी Developers के बीच टेस्टिंग विशेषज्ञ होते हैं, जो test analysis, exploratory testing और automated suite की क्वालिटी लीड करते हैं।

संदर्भ

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-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022सॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।
The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
DORA's software delivery performance metricsDORA (Google Cloud)DORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।
Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly Mediaबदलाव को पहले ट्रैफ़िक के छोटे हिस्से पर रिलीज़ करना और पूरी तरह फैलाने से पहले baseline से तुलना करना — SRE में deployment verification।

अभ्यास

बैंक फ़ीचर की समस्याओं को SDLC में पीछे तक ट्रेस करें

आपका काम

आप एक काल्पनिक बैंक की QA टीम में शामिल हुए हैं। उसके mobile app ने अभी "Scheduled transfers" फ़ीचर लॉन्च किया है। यह फ़ीचर एक sequential (waterfall) प्रोजेक्ट में बना, और टेस्टर पहले build से ही जुड़े, उससे पहले नहीं। नीचे दिए project log में पाँच समस्याएँ दर्ज हैं, P1 से P5। आपके team lead एक छोटा retrospective माँगते हैं: हर समस्या को टेस्टिंग कहाँ पकड़ सकती थी, और SDLC के हर चरण में टेस्टिंग को क्या करना चाहिए था?

इस गाइड की SDLC ↔ STLC मैपिंग और entry व exit criteria का इस्तेमाल करें। हर टेस्ट गतिविधि का नाम उसके आम STLC नाम से भी लिखें और ISTQB CTFL v4.0 की test process गतिविधि के नाम से भी। काग़ज़ और पेन काफ़ी हैं; लगभग 30 मिनट रखें।

सामग्री

Project: "Scheduled transfers", एक काल्पनिक बैंक का mobile app
Model: sequential (waterfall), go-live की तारीख़ पहले से तय

हफ़्ते 1–3 — Requirements
  Story: "ग्राहक किसी saved beneficiary को one-off या monthly transfer schedule
  कर सकता है। Transfer चुनी गई तारीख़ पर चलता है।" Business इसे sign off करता है।
  QA को नहीं बुलाया जाता।

हफ़्ते 4–6 — Design
  Payment service, core banking system को call करेगी, जो transfers सिर्फ़
  business days (रविवार से गुरुवार, public holidays छोड़कर) पर execute करता है।
  API contract लिखा जाता है। QA का कोई review नहीं।

हफ़्ते 7–12 — Implementation
  कोड लिखा जाता है; developers "next run date" की गणना के unit tests लिखते हैं।

हफ़्ता 13 — Integration
  QA को पहला build मिलता है और वह test cases लिखना शुरू करता है।

हफ़्ता 14 — System testing
  P1: शुक्रवार की तारीख़ वाला one-off transfer कभी execute नहीं होता। कोई message नहीं।
  P2: 31 तारीख़ पर set monthly transfer 30 दिन वाले महीनों और फ़रवरी में skip होता है।
  P3: Run date पर balance कम हो तो transfer चुपचाप नहीं होता;
      ग्राहक को कुछ नहीं बताया जाता।
  P4: Test environment में core banking system का कोई stub नहीं, इसलिए transfer
      करने वाला हर test तीन दिन तक blocked रहता है।
  P1 ठीक किया जाता है (शुक्रवार और शनिवार की तारीख़ें अगले रविवार पर चली जाती हैं)
  और दोबारा टेस्ट होता है। P2 और P3 severity "Minor" के साथ खुले रहते हैं।

हफ़्ता 15 — Release
  Go-live की तारीख़ तय है, इसलिए टेस्टिंग रुक जाती है। कोई exit criteria तय नहीं थे।

हफ़्ता 18 — Operation
  P5: Public holiday की तारीख़ वाले transfers execute नहीं होते और ग्राहकों को
      नहीं बताया जाता। शिकायतें call centre तक पहुँचती हैं।

चरण

P1 से P5 तक हर समस्या के लिए वह SDLC चरण बताएँ जिसमें उसके पीछे की गलती हुई, और वह सबसे पहला SDLC चरण जिसमें कोई टेस्ट गतिविधि उसे पकड़ सकती थी।
हर समस्या के लिए उस टेस्ट गतिविधि का नाम लिखें (STLC नाम और ISTQB नाम), और बताएँ कि वह static testing (review) है या dynamic testing (सॉफ़्टवेयर चलाना); dynamic testing के लिए test level भी लिखें।
प्रोजेक्ट की टेस्टिंग को चरण-दर-चरण, Requirements से Operation तक, दोबारा लिखें: हर चरण में एक या दो टेस्ट गतिविधियाँ और हर गतिविधि से बनने वाला test work product। बताएँ कि कौन-से क़दम shift-left हैं और कौन-से shift-right, और यह भी कि QA अब P5 के बारे में क्या करता है।
हफ़्ते 15 के go/no-go फ़ैसले के लिए जो exit criteria होने चाहिए थे वे लिखें, बताएँ कि उनमें से कौन-से पूरे हुए, और टेस्टिंग को क्या सिफ़ारिश करनी चाहिए थी।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

साझा जड़: किसी टेस्टर ने story का review नहीं किया, इसलिए उसकी कमियाँ — non-business days (जिनका नियम design में पता था), महीने के आख़िरी दिन और कम balance वाला path — कभी requirement या उसके acceptance criteria तक नहीं पहुँचीं। P1, P2, P3 और P5 की शुरुआत test basis के defects से होती है, जिन्हें static testing कोई कोड लिखे जाने से पहले ही पकड़ सकती थी। ISTQB की सटीक भाषा में, हफ़्ते 14 में टेस्टरों ने P1, P2 और P3 के रूप में जो देखा वे failures थे; उनके पीछे के defects story और कोड में थे। Log में वे दोनों risks भी दिखते हैं जो गाइड sequential मॉडल के लिए बताती है: requirements के defects देर से मिलना और test phase का दब जाना।

P1 (शुक्रवार का transfer नहीं चलता)। गलती Requirements में हुई: story कहती है "चुनी गई तारीख़ पर चलता है", पर non-business days का कोई नियम नहीं देती। Design में यह गलती दोहराई गई, जब core banking की यह सीमा पता थी पर story में वापस नहीं जोड़ी गई। सबसे पहला मौक़ा: Requirements चरण में story का review — STLC की भाषा में requirement analysis, ISTQB की भाषा में test analysis; यह static testing है। पूछने लायक सवाल: "अगर चुनी गई तारीख़ business day न हो तो क्या होगा?" हफ़्ते 4–6 में API contract का design review दूसरा मौक़ा था, वह भी static। इसे पकड़ने वाला dynamic test शुक्रवार की तारीख़ के साथ एक system test है।

P2 (छोटे महीनों में 31 तारीख़ skip)। गलती Requirements में हुई ("monthly" उन दिनों के लिए परिभाषित नहीं जो हर महीने में नहीं होते) और Implementation में दोहराई गई (developers ने सवाल उठाने के बजाय यह कमी अपनी पसंद से भर दी, इसलिए उनके unit tests उसी पसंद को जाँचते थे, किसी तय नियम को नहीं)। सबसे पहला मौक़ा: Requirements review (requirement analysis ≈ test analysis; static), इस सवाल के साथ: "29, 30 या 31 तारीख़ वाला monthly transfer छोटे महीने में क्या करेगा?" अगला मौक़ा: Implementation में test case development (≈ test design): 30 दिन वाले महीने में 31 तारीख़ का, या leap या non-leap साल की फ़रवरी का test case expected result के बिना नहीं लिखा जा सकता, और उसे लिखते ही वह सवाल उठता है जो story ने खुला छोड़ा था। ये tests dynamic हैं: developers के unit tests में component tests, फिर build मिलने पर system tests।

P3 (कम balance पर transfer चुपचाप नहीं होता)। गलती Requirements में हुई: error path ग़ायब है और किसी notification का ज़िक्र नहीं। सबसे पहला मौक़ा: Requirements review (static; requirement analysis ≈ test analysis), जिससे ऐसा acceptance criterion निकलना चाहिए: "अगर run date पर balance कम हो, तो transfer नहीं होता और ग्राहक को सूचना भेजी जाती है।" फिर कम balance वाले account के साथ system और acceptance testing में dynamic checks आते हैं। P3 को Minor दर्ज करना उसे कम आँकना है: चुपचाप न होने वाला भुगतान ग्राहक के पैसों को छूता है, इसलिए उसकी severity कम से कम Major है, और उसकी जगह go/no-go चर्चा में है।

P4 (core banking system का stub नहीं)। यह product defect नहीं, test planning की कमी है। गलती Design में हुई: किसी ने test environment की ज़रूरतें तय नहीं कीं। सबसे पहला मौक़ा: Design में, जब architecture का testability के लिए review होता है ("क्या payment service, core banking system के stub के साथ चल सकती है?") और environment की ज़रूरतें test plan में दर्ज होती हैं। Design review static testing है; test planning (STLC और ISTQB दोनों में यही नाम) एक management गतिविधि है — दोनों में कोई सॉफ़्टवेयर नहीं चलता। फिर stub Implementation में बनता है (test environment setup ≈ test implementation का environment वाला हिस्सा), और उसका उपलब्ध होना integration testing का entry criterion बनता है।

P5 (public holidays)। वही गलती जो P1 के पीछे थी, Requirements में; P1 का जल्दबाज़ी वाला fix सिर्फ़ weekends को कवर करता था। सबसे पहला मौक़ा: वही Requirements review जो P1 को पकड़ता (static)। Release से पहले आख़िरी मौक़ा हफ़्ते 14 में था, जब P1 ठीक हुआ: टेस्टर ने शुक्रवार वाला केस confirm किया (confirmation testing), पर यह नहीं पूछा कि और कौन-से non-business days होते हैं। "Run date business day नहीं है" के test analysis से दो test conditions निकलनी चाहिए थीं — weekend की तारीख़ और public holiday की तारीख़ — और हर एक का अपना test; P5 को पकड़ने वाला dynamic test, public holiday की तारीख़ के साथ एक system test है। P5 production तक पहुँच गया, इसलिए यह escaped defect है।

चरण-दर-चरण, प्रोजेक्ट को ऐसे चलना चाहिए था। Requirements, Design और Implementation के क़दम shift-left हैं, और production में होने वाली जाँचें — go-live के ठीक बाद deployment verification और Operation में monitoring — shift-right।

Requirements (हफ़्ते 1–3): requirement analysis ≈ test analysis। Story का review (static testing) और non-business days, महीने के आख़िरी दिन, कम balance और notifications पर सवाल; जवाबों को acceptance criteria में बदलना; product risks की सूची (पैसा गलत दिन जाए या जाए ही नहीं); test planning की शुरुआत। Work products: review findings, acceptance criteria, test conditions, risk list और test plan का ड्राफ़्ट।

Design (हफ़्ते 4–6): requirement analysis ≈ test analysis, अब integration और system levels के लिए design documents पर, और environment के लिए test planning। API contract और architecture का testability के लिए review (static testing)। Non-business day पर या कम balance के साथ transfer आने पर core banking system क्या जवाब देता है? क्या test environment उसका stub इस्तेमाल कर सकता है? क्या टेस्टर भविष्य की run date simulate करने के लिए system date सेट कर सकता है? Environment की ज़रूरतें test plan में दर्ज होती हैं। Work products: integration test conditions और environment requirements (stub, सेट की जा सकने वाली तारीख़, holiday list का test data)।

Implementation (हफ़्ते 7–12): test case development ≈ test design और test implementation। हर तरह की तारीख़ के test cases (business day, weekend, public holiday, छोटे महीनों में 29, 30 और 31 तारीख़, leap और non-leap साल की फ़रवरी) और कम balance के लिए; test data (कम balance वाले accounts, saved beneficiaries); stub के साथ test environment setup; developers के unit tests में महीने के आख़िरी दिन। Work products: test cases, test data, stub और automated checks।

Integration (हफ़्ता 13): test execution (STLC और ISTQB दोनों में यही नाम)। Integrated build को test environment में deploy करना, smoke test चलाना, फिर payment service और stub के बीच integration tests (transfer accept, तारीख़ business day न होने से reject, कम balance से reject)। Work products: test logs और defect reports।

Release (हफ़्ते 14–15; log का "System testing" वाला हफ़्ता इसी चरण में आता है): test execution, test monitoring और test control, और test cycle closure ≈ test completion। Release candidate पर system और acceptance testing, जिसमें business acceptance criteria जाँचता है; हर fix की confirmation testing और उसके बाद scheduling और transfers की regression testing; plan के मुक़ाबले progress की monitoring और control; exit criteria का मूल्यांकन और test completion report, go/no-go फ़ैसले के इनपुट के रूप में; go-live के ठीक बाद deployment verification। Work products: test results, defect reports, status reports, go/no-go इनपुट और test completion report।

Operation (हफ़्ता 16 से आगे): production signals का review — due scheduled transfers की तुलना रोज़ उनसे जो execute या notify हुए (shift-right), और ग्राहकों की शिकायतें। P5 के लिए: holiday की तारीख़, expected और actual result के साथ defect report; holiday तारीख़ों के साथ fix की confirmation testing; scheduling की regression testing; holidays के लिए एक स्थायी regression test; और जब भी holiday list बदले, maintenance testing। कुछ public holidays हिजरी कैलेंडर पर चलते हैं, इसलिए उनकी ग्रेगोरियन तारीख़ें हर साल बदलती हैं: यह list ऐसा डेटा है जिसे अपडेट करना पड़ता है। Work products: defect reports, अपडेटेड regression suite और सीखे गए सबक।

हफ़्ते 15 के go/no-go फ़ैसले के exit criteria, और क्या वे पूरे हुए: (1) सभी नियोजित tests चले, या दर्ज फ़ैसले से descope हुए — पूरा नहीं: tests तीन दिन blocked रहे और फिर टेस्टिंग बस रुक गई। (2) कोई खुला blocker या critical defect नहीं, और हर खुला major defect प्रोडक्ट ओनर ने लिखित में स्वीकार किया — असल में पूरा नहीं: P2 और P3 खुले हैं और Minor दर्ज हैं, जबकि दोनों का मतलब है ऐसा भुगतान जो होता ही नहीं। (3) सभी high-risk test conditions पास: weekend और public holiday की तारीख़ें, महीने के आख़िरी दिन, कम balance — पूरा नहीं: holidays कभी टेस्ट नहीं हुए, और P2 व P3 खुले हैं। (4) आख़िरी fix के बाद release candidate पर regression suite हरा — पूरा नहीं: P1 के fix की सिर्फ़ confirmation testing हुई। (5) बचे risks लिखित में स्वीकार, और फ़ीचर बंद करने का तरीक़ा तैयार (feature flag या rollback) — दर्ज नहीं।

सिफ़ारिश: हफ़्ते 15 में scheduled transfers के लिए no-go। Release का फ़ैसला टेस्टरों का नहीं, प्रोडक्ट ओनर और business का होता है, लेकिन टेस्टिंग के इनपुट में साफ़ लिखा होना चाहिए कि कोई भी exit criterion पूरा नहीं हुआ, और बचे risks के नाम होने चाहिए: पैसा अपेक्षित तारीख़ पर ट्रांसफ़र नहीं होता, और ग्राहकों को बताया नहीं जाता। उचित विकल्प: फ़ीचर टालना, या app को release करना पर scheduled transfers को feature flag के पीछे बंद रखना, जब तक P2 और P3 ठीक न हों और holiday तारीख़ें टेस्ट न हो जाएँ।

अपना जवाब जाँचें: अगर आपने P1, P2, P3 और P5 को पकड़ने का सबसे पहला मौक़ा Requirements चरण में static review को, और P4 का Design चरण में test planning को दिया है, तो आपने इस गाइड का मुख्य विचार पकड़ लिया है: डेवलपमेंट का हर work product टेस्टिंग को इनपुट देता है (requirements, designs और API contracts test basis के रूप में; builds और चलता हुआ सिस्टम test object के रूप में), और टेस्टिंग requirements का पहला ड्राफ़्ट मौजूद होते ही शुरू हो जाती है।

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

टूल्स

Mutqan Soft

Mutqan Soft कैसे मदद कर सकता है

Mutqan Soft की एक सेवाक्वालिटी सिस्टम निर्माणलिखित, काम करने वाली टेस्ट कार्यप्रणाली: एंट्री और एग्ज़िट मानदंड, रिलीज़ गेट और मापने योग्य गुणवत्ता संकेतक।Mutqan Soft की एक सेवामैनुअल टेस्टिंगऐसे इंजीनियरों द्वारा फ़ंक्शनल, एक्सप्लोरेटरी और कम्पैटिबिलिटी टेस्टिंग जो टेस्ट केस और डिफ़ेक्ट रिपोर्ट खुद लिखते हैं।

SDLC और STLC की पूरी समझ

SDLC और STLC: हर शब्द का मतलब

डेवलपमेंट और टेस्टिंग लाइफ़ साइकल का संबंध

SDLC के हर चरण में QA कहाँ शामिल होता है

SDLC ↔ STLC मैपिंग

Shift-left और shift-right टेस्टिंग

Lifecycle मॉडल और हर मॉडल में टेस्टिंग का फ़र्क़

पूरे lifecycle में entry और exit criteria

उदाहरण: एक फ़ीचर दोनों lifecycle से गुज़रता है

इस विषय का नक़्शा और आगे कहाँ जाएँ

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

संदर्भ

अभ्यास

बैंक फ़ीचर की समस्याओं को SDLC में पीछे तक ट्रेस करें

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

इस गाइड में बताए गए टूल्स

AI Requirement अस्पष्टता डिटेक्टर

AI Requirement गैप एनालाइज़र

एक्सेप्टेंस क्राइटेरिया जनरेटर

Requirements → टेस्ट केस

रिस्क-बेस्ड टेस्ट जनरेटर

बाउंड्री वैल्यू एनालिसिस

रिग्रेशन सिनेरियो जनरेटर

Mutqan Soft कैसे मदद कर सकता है

और गाइड

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

एंड-टू-एंड प्रोडक्ट क्वालिटी एश्योरेंस

स्टैटिक टेस्टिंग

टेस्ट स्ट्रैटेजी: एक व्यावहारिक गाइड

मैनुअल बनाम ऑटोमेटेड टेस्टिंग

टेस्ट प्लान कैसे लिखें

SDLC और STLC: हर शब्द का मतलब

डेवलपमेंट और टेस्टिंग लाइफ़ साइकल का संबंध

SDLC के हर चरण में QA कहाँ शामिल होता है

SDLC ↔ STLC मैपिंग

Shift-left और shift-right टेस्टिंग

Lifecycle मॉडल और हर मॉडल में टेस्टिंग का फ़र्क़

पूरे lifecycle में entry और exit criteria

उदाहरण: एक फ़ीचर दोनों lifecycle से गुज़रता है

इस विषय का नक़्शा और आगे कहाँ जाएँ

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

संदर्भ

अभ्यास

बैंक फ़ीचर की समस्याओं को SDLC में पीछे तक ट्रेस करें

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

इस गाइड में बताए गए टूल्स

Mutqan Soft कैसे मदद कर सकता है

और गाइड

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

एंड-टू-एंड प्रोडक्ट क्वालिटी एश्योरेंस

स्टैटिक टेस्टिंग

टेस्ट स्ट्रैटेजी: एक व्यावहारिक गाइड

मैनुअल बनाम ऑटोमेटेड टेस्टिंग

टेस्ट प्लान कैसे लिखें