मॉड्यूल 4 · टेस्ट प्रोसेस (STLC)

टेस्ट इम्प्लीमेंटेशन

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

Test implementation वह test activity है जो tests चलाने के लिए सब कुछ तैयार करती है। ISTQB Foundation syllabus v4.0 में यह test design के बाद आती है: test data जैसा testware बनाया या हासिल किया जाता है, test cases को test procedures और test suites में व्यवस्थित किया जाता है, test scripts लिखे जाते हैं, execution schedule तय होता है, और test environment बनाकर verify किया जाता है।

Analysis तय करती है कि क्या टेस्ट करना है और design तय करता है कि कैसे; implementation एक व्यावहारिक सवाल का जवाब देती है: क्या execution कल सुबह शुरू हो सकता है? किसी नए promo-code feature के लिए इसका मतलब है: क्रमबद्ध procedures, load किए गए promo codes और accounts, staging पर सही build और जुड़ा हुआ payment sandbox, और suites चलाने का तय क्रम।

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

Release में execution का समय आम तौर पर सबसे कम होता है। गायब test account, staging पर गलत build या किसी दूसरे suite का इंतज़ार करते suite की वजह से खोया हर घंटा defects ढूँढने में नहीं लगता। और जो environment वैसा नहीं जैसा आप सोचते हैं, वह झूठे results देता है: ऐसे tests जो product से असंबंधित कारणों से fail होते हैं, या ऐसे pass जो production में नहीं दोहराए जाएँगे।

Tester के लिए implementation वह जगह है जहाँ design दोहराने लायक बनता है: जिस procedure में set-up और wrap-up साफ़ लिखे हों, उसे कोई साथी चला सकता है, fix के बाद दोबारा चलाया और बाद में automate किया जा सकता है।

Implementation क्या बनाती है

Test design test cases, test data requirements और tests के लिए ज़रूरी environment पर ख़त्म होता है। Implementation इन्हें ठोस testware में बदलती है। ISTQB syllabus ये work products गिनाता है:

  • Test procedures: execution के क्रम में test cases, साथ में वे actions जो उनकी preconditions set up करते हैं और बाद में wrap up करते हैं।
  • Test scripts: step-by-step manual निर्देश या automated code जो tests चलाते हैं।
  • Test suites: procedures या scripts जो एक test run में साथ चलते हैं।
  • Test data: असली accounts, records, files और values जो data requirements पूरी करते हैं।
  • Test execution schedule: कौन-से suites किस क्रम में, कब और कहाँ चलेंगे।
  • Test environment elements: वह environment जिस पर tests चलते हैं, साथ में stubs और drivers जो उपलब्ध न होने वाले components की जगह लेते हैं (जैसा component testing वाले lesson में देखा), simulators जो किसी असली device या system की तरह व्यवहार करते हैं, और service virtualisation, जो पूरी dependent services की नकल करता है।
Test implementation designed test cases को procedures, suites और execution schedule में बदलती है, जबकि test data और environment तैयार होते हैं; execution readiness check के बाद ही शुरू होता है। वैचारिक मॉडल
  1. 1Design से आए test casesTest data requirements और environment की ज़रूरतों के साथInput
  2. 2Test procedures और scriptsExecution के क्रम में cases, set-up और wrap-up के साथ
    साथ-साथ तैयार होते हैं
    • 3Test data बनानाSeeded, दर्ज और restore होने लायक
    • 4Environment बनानाBuild, configuration, stubs, test accounts
  3. 5Test suitesएक test run के लिए समूहित procedures
  4. 6Test execution schedulePriority, dependencies और उपलब्ध resources के हिसाब से क्रम
  5. 7Readiness checkSmoke suite और readiness checklist, evidence के साथGate

    शाखा: कोई item fail: उसे ठीक करें या प्रभावित suites आगे खिसकाएँ, फिर दोबारा जाँचेंफ़ेल

इसके बाद:Test execution शुरू होता है, schedule के पहले suite से

सरल रूप: implementation, test design के साथ overlap होती है, और readiness check हर नए build पर दोहराया जाता है।

Procedures, suites और execution schedule

Test case बताता है कि क्या जाँचना है; test procedure बताता है कि कई cases किस क्रम में चलाने हैं और उनके आसपास क्या करना है। जिन cases की preconditions एक जैसी हों, वे साथ रहते हैं: एक procedure भरी हुई cart वाला logged-in customer एक बार set up करता है, अपने cases चलाता है और फिर सफ़ाई करता है, ताकि अगला procedure एक जानी-पहचानी स्थिति से शुरू हो।

Procedures को किसी मक़सद से suites में समूहित किया जाता है (smoke, feature, regression), और schedule इन suites को क्रम देता है। ISTQB तीन आम prioritisation strategies बताता है: risk-based (सबसे अहम risks वाले tests पहले), coverage-based (सबसे ज़्यादा coverage देने वाले tests पहले) और requirements-based (stakeholders जिन requirements को सबसे ऊपर रखते हैं, उनके tests पहले)। दो सीमाएँ लागू होती हैं: जिस test पर दूसरे निर्भर हों वह पहले चलता है, भले उसकी priority कम हो, और क्रम इस हिसाब से होना चाहिए कि लोग, tools और environments कब उपलब्ध हैं।

नीचे एक procedure तीन cases के लिए एक ही set-up इस्तेमाल करता है। Schedule तीनों नियम दिखाता है: smoke suite सबसे पहले, क्योंकि बाकी हर suite एक testable build पर निर्भर है; फिर promo suite, क्योंकि उसका risk सबसे ज़्यादा है; और checkout suite दोपहर के उस समय का इंतज़ार करता है जब payment sandbox booked है।

TP-PROMO-01  Apply and remove a promo code
  Set-up:   account cust-basic-01, cart baseline CART-3 (3 items, 240.00 SAR)
            promo codes loaded: SAVE10 (active, 10%), OLD5 (expired)
  Run:      TC-03  apply SAVE10   -> discount 24.00, subtotal 216.00
            TC-05  remove SAVE10  -> subtotal back to 240.00
            TC-07  apply OLD5     -> "This code has expired", subtotal unchanged
  Wrap-up:  empty the cart, reset the usage count of SAVE10

Execution schedule, staging, day 1
  09:00  Smoke suite (8 checks)       must pass before any other suite
  09:30  Promo suite TP-PROMO-01..03  highest risk: changes what customers pay
  13:00  Checkout regression suite    payment sandbox booked 13:00-17:00

Test data बनाना और environment तैयार करना

Design ने बताया कि tests को कौन-सा data चाहिए; implementation उसे बनाती या हासिल करती है: सही states में accounts, products और orders के लिए seed scripts या files, और एक दर्ज baseline जिसे runs के बीच restore किया जा सके, ताकि अलग result software से आए, बचे हुए data से नहीं। Synthetic या masked data को प्राथमिकता दें: test environment में copy किए गए असली customer records तब भी personal data ही रहते हैं।

फिर environment बनाया और verify किया जाता है, यानी मान नहीं लिया जाता बल्कि जाँचा जाता है: अपेक्षित build deploy है, व्यवहार पर असर डालने वाली configuration योजना के अनुसार set है, third-party services पहुँच में हैं या stub से बदली गई हैं, और हर test account login कर सकता है। फिर smoke test, यानी main functionality को cover करने वाला एक छोटा suite, दिखाता है कि system planned testing शुरू करने लायक काम कर रहा है।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी आज़माएँ: SQL डेटासेट जनरेटर आज़माएँ: फ़ेक यूज़र जनरेटर आज़माएँ: Mock API रिस्पॉन्स जनरेटर

Worked example: एक readiness checklist

Promo-code suites शुरू होने से पहले tester एक readiness checklist से गुज़रता है और हर item का result evidence के साथ दर्ज करता है, ताकि "मुझे लगता है हम तैयार हैं" ऐसी जाँचों में बदल जाए जिन्हें कोई भी दोहरा सके। कई टीमें ऐसी checklist को execution के entry criteria के रूप में इस्तेमाल करती हैं, यानी वे preconditions जो execution शुरू होने से पहले पूरी होनी चाहिए। ISTQB syllabus typical entry criteria में environments और test data की उपलब्धता, और smoke tests के pass होने को गिनाता है।

किसी item के fail होने का मतलब "शुरू करो और उम्मीद रखो" नहीं है। पहले run में payment sandbox का timeout हुआ: promo suite, जो payment तक पहुँचता ही नहीं, समय पर शुरू हुआ, checkout regression suite रुका रहा, और समस्या sandbox के owner को भेज दी गई।

  • Build: version 4.2.0 staging पर है और release notes से मेल खाता है।
  • Configuration: promo_codes flag on है, prices SAR में हैं, और time zone production से मेल खाता है, क्योंकि codes की expiry उसी पर निर्भर है।
  • Test data: cart baselines और SAVE10 व OLD5 codes load हैं; restore script एक बार चल चुकी है।
  • Accounts: हर role (customer, support agent) का एक test account login कर सकता है, और guest checkout बिना account के काम करता है।
  • Integrations: payment sandbox जवाब देता है (पहले run में fail); SMS service की जगह एक stub है जो messages दर्ज करता है।
  • Testware: procedures TP-PROMO-01 से 03 review हो चुके हैं, अपने test cases से traced हैं और एक test run के रूप में load हैं।
  • Observability: testers application logs और browser console पढ़ सकते हैं।
  • Smoke suite: इस build पर सभी 8 checks pass होते हैं।

आज़माएँ: API हेल्थ चेकर

आम गलतियाँ

  • Set-up, wrap-up या क्रम के बिना test cases को tool में copy कर देना, जिससे एक failure ऐसा data छोड़ देता है जो अगले cases बिगाड़ देता है।
  • Execution वाले दिन हाथ से test data बनाना, बिना किसी record के और बिना restore करने के तरीक़े के।
  • यह मान लेना कि environment तैयार है क्योंकि पिछले sprint में तैयार था, बजाय हर बार build, configuration और integrations verify करने के।
  • सिर्फ़ priority से schedule बनाना, जिससे high-priority suite उस data का इंतज़ार करता है जिसे सिर्फ़ कम priority वाला suite बनाता है।
  • Smoke test छोड़ देना और एक घंटे के failed और blocked tests के बाद पता चलना कि deployment टूटा हुआ है।

QA का नज़रिया

असली टीम में implementation design के साथ overlap होती है और पहले test cases स्थिर होते ही शुरू हो जाती है। Environment और data के requests जल्दी भेजें, क्योंकि उन्हें दूसरे पूरा करते हैं: developers या DevOps engineers builds deploy करते और environments configure करते हैं, database owner seed scripts चला सकता है, और test lead schedule पर सहमति बनाता है।

जो तैयार किया उसे दर्ज करें: test cases से traced procedures और suites, data baseline और उसे restore करने का तरीक़ा, test हो रहा build और configuration, और readiness का तारीख़ के साथ result। Execution से पहले पूछें: हम ठीक-ठीक कौन-सा build टेस्ट कर रहे हैं? Stub क्या simulate नहीं करता? अगर कोई run data बिगाड़ दे तो उसे restore कौन करेगा? अगला lesson, test monitoring और test control, इन्हीं records से शुरू होता है।

अभ्यास

Password reset के tests implement करें

आपका काम

Test design ने एक web app के "Forgot password" के लिए छह test cases दिए: TC-1 registered email के लिए reset link माँगना; TC-2 unregistered email के लिए माँगना (वही neutral message); TC-3 link खोलकर नया valid password set करना; TC-4 ऐसा link खोलना जिसकी 30 मिनट की validity बीत चुकी हो; TC-5 इस्तेमाल हो चुका link दोबारा इस्तेमाल करना; TC-6 नए password से login करना।

इन्हें implement करें: procedures बनाएँ, उनका क्रम तय करें, test data और environment elements की सूची बनाएँ, और कम से कम छह items की readiness checklist लिखें।

चरण
  1. एक जैसी preconditions वाले cases को procedures में समूहित करें और हर एक का set-up और wrap-up लिखें।
  2. Dependencies लिखते हुए procedures का क्रम तय करें।
  3. Data और environment elements की सूची बनाएँ, इसमें यह भी कि reset emails कैसे मिलेंगे, फिर checklist लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Procedures: TP-1 "Reset माँगना" (set-up: एक registered account और एक unregistered address; wrap-up: captured emails साफ़ करें) TC-1 और TC-2 चलाता है। TP-2 "Reset link इस्तेमाल करना" (set-up: registered account के लिए नया link) TC-3, TC-6, फिर TC-5 चलाता है, जिसमें इस्तेमाल हो चुका link reject होना चाहिए; wrap-up: baseline password वापस करें। TP-3 "Expired link" (set-up: दूसरा seeded account जिसका link 30 मिनट से पुराना हो, ताकि यह TP-2 में दख़ल न दे; wrap-up: clock या validity setting में किया गया कोई भी बदलाव वापस करें) TC-4 चलाता है।

क्रम: TP-1 पहले, क्योंकि यह साबित करता है कि reset emails पहुँचते हैं; फिर TP-2, जिसके cases एक-दूसरे पर निर्भर हैं। TP-3 को 30 मिनट से पुराना link चाहिए: session की शुरुआत में link माँगें और 30 मिनट बीतने पर TC-4 चलाएँ, या developers से links expire करने का तरीक़ा पूछें, जैसे छोटी validity setting या control की जा सकने वाली clock, ताकि यह कभी भी चल सके।

Data और environment: known baseline password वाले दो seeded accounts, example.com जैसे reserved domain पर test addresses, email capture service या उसका stub ताकि reset emails कभी किसी असली व्यक्ति तक न पहुँचें, links expire करने का तरीक़ा या इंतज़ार का समय, और staging पर test हो रहा build।

Checklist: build deploy और दर्ज है; email capture एक test message प्राप्त करता है; दोनों seeded accounts login करते हैं; password restore काम करता है; link expiry simulate की जा सकती है, या 30 मिनट का इंतज़ार schedule में है; testers logs पढ़ सकते हैं; login और reset page का smoke check pass होता है।

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

Test case और test procedure में क्या फ़र्क़ है?

Test case एक जाँच के लिए preconditions, inputs, steps, expected results और postconditions बताता है। Test procedure execution के क्रम में test cases का sequence है, साथ में वे actions जो उनसे पहले preconditions set up करते हैं और बाद में wrap up करते हैं। अक्सर एक procedure एक ही set-up वाले कई cases चलाता है।

क्या test implementation का मतलब automated tests लिखना है?

नहीं। जब tests automated हों, तो automated test scripts लिखना implementation का हिस्सा है, लेकिन implementation में manual procedures, test data, suites, execution schedule और environment भी आते हैं। जिस टीम के पास कोई automation नहीं, वह भी अपने tests implement करती है।

Test implementation STLC के phases से कैसे मेल खाती है?

STLC industry का model है, ISTQB का term नहीं। इसका "test case development" phase test design और implementation के ज़्यादातर हिस्से को cover करता है, और "test environment setup" phase implementation का environment वाला हिस्सा है जिसे अलग दिखाया गया है। काम वही है; सिर्फ़ grouping अलग है।

Test environment की ज़िम्मेदारी किसकी है?

यह टीम पर निर्भर है। अक्सर developers, DevOps या platform engineers इसे बनाते और deploy करते हैं, और testers verify करते हैं कि यह उनके planned tests के लिए तैयार है। जिसने भी बनाया हो, readiness checklist चलाकर उसका result दर्ज किए बिना execution शुरू नहीं होना चाहिए।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021टेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
टूल्स

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

टेस्ट डेटा फ़ैक्टरी

सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।

टेस्ट डेटा

SQL डेटासेट जनरेटर

किसी भी dialect के लिए वास्तविक जैसी टेस्ट पंक्तियों के साथ SQL seed स्क्रिप्ट (CREATE TABLE + INSERT) जनरेट करें।

टेस्ट डेटा

फ़ेक यूज़र जनरेटर

टेस्ट अकाउंट के लिए फ़ेक यूज़र रिकॉर्ड (नाम, username, ईमेल, पासवर्ड, avatar seed, role) जनरेट करें।

टेस्ट डेटा

फ़ेक ईमेल जनरेटर

सुरक्षित रिज़र्व्ड डोमेन (example.com, test) और plus-addressing वैरिएंट के साथ टेस्ट ईमेल पते जनरेट करें।

टेस्ट डेटा

API हेल्थ चेकर

एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।

API टेस्टिंग

और गहराई से

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

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

इस topic से पहले