मॉड्यूल 2 · Software development lifecycle

वॉटरफ़ॉल और V-मॉडल

Mutqan Soft QA टीम द्वारा · · 19 मिनट · शुरुआती

Waterfall model एक sequential development lifecycle है: requirements, design, implementation, testing और deployment एक के बाद एक आते हैं, और हर phase पूरा होकर sign-off होने के बाद ही अगला शुरू होता है। मान लीजिए एक bank किसी supplier से loan portal बनवाता है: requirements तय होकर freeze होती हैं, फिर design, फिर महीनों की coding, और उसके बाद ही एक test phase software को पहली बार चलाता है।

V-model भी sequential है, लेकिन यह testing को शुरू से दिखाता है। इसका बायाँ हिस्सा लगातार ज़्यादा detailed specifications से होकर नीचे उतरता है, coding V की नोक पर है, और दायाँ हिस्सा test levels से होकर वापस ऊपर चढ़ता है। हर specification उस test level से जुड़ी है जो उसके against जाँच करता है, इसलिए portal के acceptance tests business requirements के साथ-साथ, coding से बहुत पहले design हो जाते हैं।

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

आज भी कई projects इसी तरह चलते हैं, ख़ासकर जब contract scope तय करता है, जब कोई regulator या customer हर phase का documented evidence चाहता है, या जब software किसी hardware या infrastructure project का हिस्सा हो। ऐसे project में आपको पता होना चाहिए कि आपका test basis कौन-से documents हैं, उन्हें कब review करना है, कौन-से test levels आपके हैं, और आपके phase के entry और exit criteria क्या हैं।

ये models उन risks को भी समझाते हैं जिनसे हर tester का सामना होता है। Strict waterfall में dynamic testing सबसे आख़िर में आती है, इसलिए पहले महीने में ग़लत समझी गई requirement महीनों बाद failure बनकर सामने आ सकती है, जब fix documents, design और code को छूता है। और जब development देर से चले पर release date न हिले, तो test phase सिकुड़ता है। यह जानकर आप counter-measures शुरुआत में ही माँग सकते हैं।

Waterfall के phases और उनमें testing की जगह

Phases के नाम organisations में अलग-अलग होते हैं, लेकिन एक typical waterfall project नीचे की list जैसा दिखता है। हर phase एक work product बनाता है, अक्सर एक document, जिसे review और approve करके अगले phase का fixed input बना दिया जाता है; बाद के बदलाव formal change control से होकर जाते हैं।

यहाँ testing की दो जगहें हैं। Dynamic testing software को चलाती है, इसलिए वह आख़िर के test phase का इंतज़ार करती है। Static testing work products को बिना चलाए जाँचती है, इसलिए वह पहले phase से शुरू हो सकती है: CTFL v4.0 बताता है कि sequential models में testers आमतौर पर शुरू में ही requirement reviews, test analysis और test design में हिस्सा लेते हैं।

  • Requirements: specification लिखी और sign-off होती है; tester उसे ambiguity, gaps और testability के लिए review करता है और test plan शुरू करता है।
  • Design: architecture और detailed design बनते हैं; tester उन्हें review करता है और test conditions व environment की ज़रूरतें पहचानता है।
  • Implementation: developers code लिखते हैं और अपने components टेस्ट करते हैं; tester test cases design करता है और test data व environment तैयार करता है।
  • Testing: test team integrated system पर tests execute करती है, defects report करती है और fixes पर confirmation और regression tests चलाती है।
  • Deployment और maintenance: release live होता है, अक्सर customer के formal acceptance के बाद, और बाद के हर change की अपनी testing चाहिए।

V-model: हर development level का एक test level

CTFL v4.0 waterfall और V-model दोनों को sequential development models के उदाहरण बताता है। V-model जो जोड़ता है वह one-to-one जोड़ी है: नीचे उतरते समय की हर specification के लिए ऊपर चढ़ते समय एक test level है, जो बने हुए software को उसके against जाँचता है।

यहाँ दो timings अहम हैं। किसी level का test analysis और design उसके matching development phase में ही, यानी specification लिखे जाते समय, शुरू हो जाता है, और testers हर draft को उपलब्ध होते ही review करते हैं; CTFL v4.0 दोनों को हर lifecycle के लिए अच्छी practices बताता है। Execution उल्टी दिशा में चलता है, coding के बाद नीचे से ऊपर: पहले component tests, आख़िर में acceptance tests। Tests का जल्दी design होना QA के लिए इस model का सबसे बड़ा फ़ायदा है, क्योंकि specification को ठोस tests में बदलना उसके vague या विरोधाभासी वाक्यों को जल्दी उजागर कर देता है।

Verification और validation वाले lesson की भाषा में: build को हर specification के against टेस्ट करना verification है, और असली user needs के against acceptance testing validation है। CTFL v4.0 integration को component integration और system integration testing में भी बाँटता है, जिसे test levels वाला lesson समझाता है।

  • Business और user requirements ↔ acceptance testing: क्या intended users system से अपना काम कर पाते हैं?
  • System requirements specification ↔ system testing: क्या पूरा system specification के अनुसार चलता है, performance जैसी non-functional requirements समेत?
  • Architectural design ↔ integration testing: क्या components, services और external systems अपने interfaces के ज़रिए साथ काम करते हैं?
  • Detailed design ↔ component testing (अक्सर unit testing कहा जाता है): क्या हर component अलग से वही करता है जो उसका design कहता है?
V-model में बाएँ हिस्से की हर specification एक test level का test basis है: requirements से acceptance, system specification से system, architecture से integration और detailed design से component testing। वैचारिक मॉडल
  1. बायाँ हिस्सा: specification:
    1Business और user requirementsUsers और business को क्या चाहिए

    आगे जाता है: इससे acceptance tests design होते हैं

    दायाँ हिस्सा: test level:
    Acceptance testingचौथे और आख़िर में execute: क्या users अपना काम कर पाते हैं?
  2. बायाँ हिस्सा: specification:
    2System requirements specificationपूरा system, non-functional requirements समेत

    आगे जाता है: इससे system tests design होते हैं

    दायाँ हिस्सा: test level:
    System testingतीसरे नंबर पर execute: पूरा system उसकी specification के against
  3. बायाँ हिस्सा: specification:
    3Architectural designComponents और उनके बीच के interfaces

    आगे जाता है: इससे integration tests design होते हैं

    दायाँ हिस्सा: test level:
    Integration testingदूसरे नंबर पर execute: interfaces और interactions
  4. बायाँ हिस्सा: specification:
    4Detailed designहर component के अंदर का design

    आगे जाता है: इससे component tests design होते हैं

    दायाँ हिस्सा: test level:
    Component testingसबसे पहले execute, coding के ठीक बाद

इसके बाद:Coding V की नोक पर है; फिर execution दाएँ हिस्से पर component testing से वापस acceptance testing तक चढ़ता है।

Conceptual model: documents के नाम organisation के हिसाब से बदलते हैं, और CTFL v4.0 integration को component integration और system integration testing में बाँटता है।

Worked example: outpatient booking system

Clinics का एक group fixed price पर outpatient booking system बनाने के लिए एक supplier से contract करता है, और हर phase के लिए signed-off document चाहिए। Project V-model अपनाता है, और tester coding के बाद नहीं, requirements phase में ही जुड़ता है।

जैसे-जैसे हर document approve होता है, tester उसके paired level के tests निकालता है और links दर्ज करता है, ताकि हर requirement का test हो और हर test किसी requirement तक trace हो। नीचे के चार items में से दो ने code बनने से पहले ही एक gap पकड़ लिया।

  • BR-2 "Patient online booking कर सके और reminder पाए" → acceptance test AT-2: pilot group के patients अपने phones से असली slots book करते हैं, और receptionists bookings को अपनी daily list में देखते हैं। इसे लिखते समय एक खुला सवाल उठा: जब कोई patient परिवार के किसी सदस्य के लिए booking करे, तो reminder किसके phone पर जाएगा?
  • SR-14 "एक slot सिर्फ़ एक patient book कर सकता है" → system test ST-14: दो sessions एक ही पल में एक ही slot book करते हैं; एक सफल होता है और दूसरे को "Slot no longer available" दिखता है।
  • AD-3 "Reminders एक external SMS gateway से जाते हैं" → integration test IT-3: gateway बंद हो तब भी booking save होनी चाहिए। Design में यह नहीं लिखा था कि reminder का क्या होगा, इसलिए tester ने coding से पहले design defect दर्ज किया।
  • DD-9 "canCancel() तभी true लौटाता है जब start में 24 घंटे से ज़्यादा बाकी हों" → developer के लिखे component tests CT-9: start से 24 घंटे 1 मिनट पहले, ठीक 24 घंटे पहले और 23 घंटे 59 मिनट पहले, और expected results क्रम से true, false और false।
Traceability: outpatient booking system (V-model)

Left arm (approved first)          Right arm (executed later)   Tests
BR-2   business requirement   <->  acceptance testing           AT-2
SR-14  system requirement     <->  system testing               ST-14.1  ST-14.2
AD-3   architectural design   <->  integration testing          IT-3.1   IT-3.2
DD-9   detailed design        <->  component testing            CT-9.1 .. CT-9.3

Designed:  AT -> ST -> IT -> CT   (as each document is approved)
Executed:  CT -> IT -> ST -> AT   (after coding, bottom-up)

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: Requirements → टेस्ट सिनेरियो

QA के लिए ताकतें और risks

कोई भी model अपने आप में अच्छा या बुरा नहीं है: हर एक कुछ contexts में फ़िट होता है और testing के लिए अनुमानित risks लाता है।

  • ताकत: स्थिर, approved test basis। Tests साफ़ तौर पर requirements तक trace होते हैं, और customer या auditor को coverage दिखाना आसान है।
  • ताकत: साफ़ gates। Entry और exit criteria, formal test plan और test completion report phases में स्वाभाविक रूप से फ़िट होते हैं; CTFL v4.0 बताता है कि sequential models में एक test level के exit criteria अक्सर अगले level के entry criteria का हिस्सा होते हैं।
  • V-model की ताकत: early test design हर specification की ambiguities और gaps उसके बनने से पहले पकड़ लेता है।
  • Risk: देर से feedback। Reviews से छूटे defects देर से सामने आते हैं, जब fix documents, design और code को छूता है। Counter: गहरे reviews और early test design।
  • Risk: दबा हुआ test phase। अगर coding देर से ख़त्म हो और date तय हो, तो testing का समय घटता है। Counter: test phase के लिए तय entry criteria और risk के हिसाब से प्राथमिकता वाले tests।
  • Risk: देर से validation और big-bang integration। Users शायद software पहली बार acceptance testing में देखें, और सब कुछ एक साथ integrate करने से failures का स्रोत छिप जाता है। Counter: prototypes, users के साथ walkthroughs और incremental integration।

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

आम गलतियाँ

  • यह मानना कि testing code आने पर शुरू होती है। दोनों models में reviews, test planning और test design पहले phases में ही शुरू हो जाते हैं।
  • Signed-off document को सही मान लेना। Approval का मतलब content पर सहमति है, defects का न होना नहीं; फिर भी उसे review करें।
  • V के दो क्रमों को मिला देना: tests specifications approve होते समय ऊपर से नीचे design होते हैं, लेकिन execute नीचे से ऊपर होते हैं।
  • हर level को उसके अपने test basis की जगह एक ही document के against टेस्ट करना।
  • छोटे किए गए test phase को चुपचाप मान लेना, बजाय यह बताने के कि कौन-से risks बिना टेस्ट रह जाएँगे।

QA का नज़रिया

Sequential project में सबसे पहले V में अपनी जगह साफ़ करें: कौन-से test levels आपके हैं, हर एक का test basis क्या है, हर phase का sign-off कौन करता है, और test phase के entry और exit criteria क्या हैं। Draft बनते ही requirements माँगें; review comments पर approval से पहले अमल करना सबसे सस्ता है।

शुरुआत से traceability दर्ज करें: हर requirement उसके tests से जुड़ी हो, और हर defect उस requirement से जिसे वह तोड़ता है। Change request आने पर यही links बताते हैं कि कौन-से tests update करके दोबारा चलाने हैं, और plan के against progress report करने से release का फ़ैसला calendar पर नहीं, तथ्यों पर टिका रहता है।

अभ्यास

किसी project के tests को V पर रखें

आपका काम

एक municipality online building-permit portal के लिए एक supplier से contract करती है। Scope तय है, हर phase के लिए signed-off document चाहिए, और project V-model अपनाता है। नीचे के चार अंश approved work products से लिए गए हैं, बाएँ हिस्से के हर level से एक; coding ख़त्म होने के बाद testing को चार हफ़्ते मिलते हैं, और launch date तय है।

हर work product के लिए बाएँ हिस्से पर उसका level, जुड़ा हुआ test level और एक test idea लिखें। फिर execution का क्रम लिखें, और plan के दो QA risks, हर एक के counter-measure के साथ।

सामग्री
A  "नागरिक building permit के लिए online apply कर सकें और municipality office गए
   बिना उसका status देख सकें।"
B  "जब तक हर mandatory document upload न हो, application submit नहीं हो सकती;
   missing documents नाम से दिखाए जाते हैं।"
C  "Portal property ownership की जाँच national land registry service से करता है।"
D  "calculateFee(area) हर square metre के 2 SAR लौटाता है, और minimum fee 200 SAR है।"
चरण
  1. हर work product (A से D) को V के बाएँ हिस्से पर उसके level से मिलाएँ।
  2. जुड़ा हुआ test level बताएँ और उसके लिए एक test idea लिखें।
  3. लिखें कि चारों test levels किस क्रम में execute होंगे।
  4. Plan में दो QA risks पहचानें और हर एक का counter-measure बताएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

A business requirement है (यह बताता है कि नागरिकों को क्या हासिल करना है) → acceptance testing: असली applicants अपनी properties के लिए apply करते हैं और office गए बिना decision तक status देखते हैं, और municipality staff पुष्टि करता है कि वह applications process कर सकता है।

B system requirement है (पूरे system का ऐसा behaviour जिसे user देख सकता है) → system testing: एक mandatory document के बिना submit करें; submission रुकता है और उस document का नाम दिखता है; उसे upload करने के बाद submission सफल होता है।

C architectural design है (यह एक external system के साथ interface बताता है) → integration testing: land registry "owner not found" लौटाए या जवाब ही न दे; portal साफ़ message दिखाता है और ownership को confirmed नहीं मानता। अगर design इस पर चुप है, तो सवाल अभी उठाएँ।

D detailed design है (एक function का logic) → component testing: calculateFee(50) 200 लौटाता है (minimum, क्योंकि 50 × 2 = 100) और calculateFee(150) 300 लौटाता है; यह भी पूछें कि 0 या negative area पर क्या होना चाहिए।

Execution का क्रम: component, integration, system, acceptance। Test design उल्टी दिशा में चलता है: acceptance tests A के लिखे जाते समय ही design हो सकते थे, B, C और D के बनने से पहले।

Risks, उदाहरण के लिए: fixed launch से पहले दबा हुआ test phase (counter: entry criteria अभी तय करें और tests को risk के हिसाब से प्राथमिकता दें); देर से validation, क्योंकि नागरिक portal पहली बार acceptance testing में देखते हैं (counter: design के दौरान कुछ applicants के साथ prototype walkthrough)।

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

क्या waterfall model आज भी इस्तेमाल होता है?

हाँ, उन contexts में जहाँ यह फ़िट होता है: fixed-scope contracts, regulated या safety-related systems जिन्हें हर phase का documented evidence चाहिए, और hardware या infrastructure से बँधे projects जो देर से नहीं बदल सकते। कई organisations models मिलाते भी हैं, जैसे पूरी योजना sequential और build phase के अंदर iterative development।

क्या V-model बस testing जोड़ा हुआ waterfall है?

यह अब भी sequential है, लेकिन test work का समय बदल देता है। सादे waterfall में test analysis और design test phase तक टाले जा सकते हैं; V-model में हर test level अपनी counterpart specification लिखे जाते समय plan और design होता है, जो early testing के principle का साथ देता है।

क्या V-model में हर level एक ही team करती है?

नहीं। आमतौर पर component testing developers करते हैं और integration testing developers या testers; system testing कोई independent test team कर सकती है, और acceptance testing आदर्श रूप से intended users या customer के प्रतिनिधि करते हैं। कौन क्या करेगा, यह test plan में तय होता है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
टूल्स

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

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

टेस्ट डिज़ाइन

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

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

टेस्ट डिज़ाइन

और गहराई से

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

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