मॉड्यूल 8 · Test execution

मैनुअल टेस्ट एक्ज़िक्यूशन

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

Manual test execution का मतलब है test case को खुद चलाना: उसके steps को बताए गए data के साथ करना, system क्या करता है यह देखना, इस actual result की तुलना test case में लिखे expected result से करना, और फिर नतीजा दर्ज करना। ISTQB Foundation syllabus v4.0 में test execution में शामिल है: execution schedule के अनुसार tests चलाना, actual results की expected results से तुलना करना, results log करना और anomalies, यानी उम्मीद से हटकर कुछ भी, का विश्लेषण करना।

उदाहरण के लिए, test case कहता है: expired promo code OLD5 लगाएँ; अपेक्षित है message "This code has expired" और subtotal 240.00 SAR पर बना रहे। इसे execute करने का मतलब है उसी exact message और उसी exact amount को जाँचना, build नोट करना, और दोनों अलग हों तो जो असल में दिखा वह लिखना।

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

Execution वह जगह है जहाँ team देखती है कि product असल में कैसा behave करता है, और पहले का सारा काम तभी फल देता है जब results पर भरोसा किया जा सके। एक नज़र डालकर "passed" किया गया step गलत amount या भ्रामक message को customers तक पहुँचा सकता है; बिना details वाला "failed" developer के घंटे अंदाज़ा लगाने में बर्बाद कर सकता है।

Tester के लिए सावधानी से किया गया run ऐसा evidence बनाता है जिस पर दूसरे फ़ैसले लेते हैं: release का फ़ैसला, defect report, fix के बाद retest। जो results बताते हैं कि क्या चला, किस build पर, किस data के साथ और क्या हुआ, उन पर भरोसा किया जा सकता है और उन्हें दोहराया जा सकता है; याद से लिखे results पर नहीं।

एक test case को step by step execute करना

Test case आपके पास एक test run के हिस्से के रूप में आता है: एक ख़ास build पर tests के एक set का एक execution। शुरू करने से पहले पूरा case पढ़ें, और जो अस्पष्ट हो वह अभी पूछें, आधे रास्ते में नहीं।

फिर उसे एक तय लय में पूरा करें:

  • Preconditions जाँचें और context नोट करें: build, environment, browser या device, account और data। अगर कोई precondition पूरी नहीं हो सकती, तो जुगाड़ न करें; दर्ज करें कि test क्यों नहीं चल सका।
  • एक step ठीक वैसे ही करें जैसा लिखा है, बताए गए data के साथ। अगर हटना पड़े, जैसे किसी field का नाम बदल गया हो, तो उसे दर्ज करें।
  • पूरा result देखें: screen, messages, amounts, अगला page, और कोई भी email जो इस step से आना चाहिए।
  • Actual result की expected result से तुलना करें। मेल खाए तो अगले step पर जाएँ; मेल न खाए तो कुछ और करने से पहले जो दिखा उसे capture करें।
  • आख़िरी step के बाद नतीजा दर्ज करें और case ने जो data बदला उसे साफ़ करें, ताकि अगला test एक ज्ञात state से शुरू हो।
एक manual test case execute करना: preconditions जाँचें, हर step करें और देखें, actual result की expected result से तुलना करें, फिर नतीजा दर्ज करें और script के बाहर जो दिखा उसका follow up करें। वैचारिक मॉडल
  1. 1पूरा test case पढ़ेंObjective, preconditions, data, expected results; जो अस्पष्ट हो वह पूछें
  2. 2Preconditions जाँचेंBuild, environment, device, account और data नोट करें

    शाखा: कोई precondition पूरी नहीं हो सकती: test न चलाएँ, कारण दर्ज करेंसावधानी

  3. 3अगला step करेंठीक जैसा लिखा है, बताए गए data के साथ
  4. 4Actual result देखेंपूरी screen: messages, amounts, अगला page, emails
  5. 5Expected result से तुलना करेंExact text, values और नतीजे वाली state

    दोहराता है: मेल खाता है: case के अगले step के लिए step 3 पर वापस

    शाखा: मेल नहीं खाता: actual result और evidence capture करें, फिर कारण खोजेंफ़ेल

  6. 6Result दर्ज करेंStatus, actual results, build, data, समय, evidence, defect IDs
  7. 7Wrap up और follow upData साफ़ करें; script के बाहर जो दिखा उसे report करें

सरल रूप: mismatch के बाद आगे के steps तभी चलाएँ जब failed step के बिना भी उनका मतलब बनता हो।

आज़माएँ: अस्थायी ईमेल

Expected और actual result की तुलना

Expected result वह behaviour है जिसका अनुमान test basis लगाता है, और यह execution से पहले test case में लिखा जाता है; जो भी सही behaviour बताता है, जैसे requirement, acceptance criterion या पिछला version, वह test oracle है। Actual result वह है जो system असल में करता है। तुलना exact होनी चाहिए: "This code is not valid" और "This code has expired" एक नहीं हैं, और 216.00 और 240.00 भी नहीं।

Expected result जो कुछ भी बताता है, सबकी तुलना करें: text, values, data की state, अगली screen। Mismatch एक anomaly है, अभी फ़ैसला नहीं। उसे defect कहने से पहले पक्का करें कि आपने step सही data और सही build के साथ सही किया, और expected result test basis से मेल खाता है। Expected result को system से मिलाने के लिए कभी edit न करें; अगर test case गलत है, तो यह दर्ज करें और उसे ठीक करवाएँ।

लंबे messages या JSON responses (वह structured data जो कई APIs लौटाते हैं) में expected और actual text को diff tool में paste करें: वह हर difference आपकी आँखों से ज़्यादा भरोसे से highlight करता है।

आज़माएँ: टेक्स्ट डिफ़ आज़माएँ: JSON डिफ़

जो हुआ उसे दर्ज करना

हर run वह बनाता है जिसे ISTQB test log कहता है: test execution के ज़रूरी details का समय-क्रम वाला record, जो आमतौर पर test management tool या shared spreadsheet में रखा जाता है। इसे testing के दौरान भरें, ताकि कोई और आपसे पूछे बिना आपका run समझ, दोहरा और retest कर सके।

  • कौन-सा test: test case ID और उसका version।
  • Context: build, environment, browser या device, test data या accounts, tester, तारीख़ और समय।
  • नतीजा: passed जब हर actual result अपने expected result से मेल खाया, failed जब कम से कम एक मेल नहीं खाया। Blocked जैसे दूसरे statuses test suites और test runs वाले पाठ में आते हैं।
  • हर उस step का पूरा actual result जो मेल नहीं खाया, सिर्फ़ "failed" शब्द नहीं।
  • Evidence और links: screenshot या log के references, और उठाए गए किसी भी defect report की ID।

Script से आगे भी चौकन्ने रहना

Test case बताता है कि क्या जाँचना है, यह नहीं कि क्या-क्या गलत हो सकता है। जब आप एक expected result पर ध्यान दे रहे होते हैं, उसी screen पर दूसरी problems दिख सकती हैं: ऐसा total जो जुड़ता नहीं, टूटा हुआ layout, धीमा response, browser console में error, किसी label में गलत भाषा। Script follow करें, लेकिन आँखें खुली रखें।

जब expected results के बाहर कुछ दिखे, तो case न छोड़ें। उसे तुरंत समय और आप क्या कर रहे थे, इसके साथ नोट करें, case पूरा करें, फिर उसे दोबारा आज़माएँ और अलग से report करें। इससे case का status नहीं बदलता, क्योंकि status सिर्फ़ उसके अपने expected results के बारे में है। अगर यह test cases में कोई gap दिखाता है, तो नया case या एक अतिरिक्त expected result सुझाएँ।

Test case की अपनी problems भी findings हैं: ऐसे steps जो अब screens से मेल नहीं खाते, पुराना data, या requirement के उलट expected result। इन्हें दर्ज करें ताकि अगले run से पहले case ठीक हो जाए।

Worked example: build 4.2.0 पर TC-07 चलाना

सारा staging पर TC-07 चलाती है। Steps 1, 3 और 4 मेल खाते हैं। Step 2 में code reject होता है, लेकिन message acceptance criterion से लिए गए expected text से अलग है। वह जाँचती है कि उसने OLD5 सही type किया और code expired के रूप में set है, screenshot लेती है, steps पूरे करती है और case को failed दर्ज करती है।

उसे यह भी दिखता है कि rejected code के बाद VAT line page reload करने तक 0.00 SAR दिखा रही थी। TC-07 का कोई step VAT नहीं जाँचता, इसलिए वह इसे नोट करती है, case के बाद reproduce करती है और नया test case सुझाते हुए इसे अलग defect के रूप में report करती है।

TC-07   Expired promo code reject होता है (version 2)
Run:    build 4.2.0, staging, Chrome desktop, 2026-10-06 10:42, tester Sara
Data:   account cust-basic-01, cart CART-3 (240.00 SAR), code OLD5 (expired)

Step 1  Expected: cart में 3 items, subtotal 240.00 SAR
        Actual:   expected के अनुसार                              [passed]
Step 2  Expected: message "This code has expired", कोई discount line नहीं
        Actual:   message "This code is not valid", कोई discount line नहीं
        Evidence: tc07-step2.png                                 [failed]
Step 3  Expected: subtotal अब भी 240.00 SAR
        Actual:   240.00 SAR                                     [passed]
Step 4  Expected: reload के बाद कोई code applied नहीं
        Actual:   expected के अनुसार                              [passed]

Status:   failed (step 2), defect DEF-412 raised
Observed: step 2 के बाद VAT line reload तक 0.00 SAR दिखाती रही, दो बार देखा;
          TC-07 इसे नहीं जाँचता: DEF-413 में report किया, नया test case सुझाया

आज़माएँ: टेक्स्ट डिफ़

आम गलतियाँ

  • एक नज़र में step pass कर देना, message का exact text, amounts और नतीजे वाली state जाँचे बिना।
  • बिना actual result, build या data के "failed" दर्ज करना, जिससे कोई problem reproduce या fix का retest नहीं कर पाता।
  • चलते-चलते steps या data बदल देना, या system से मिलाने के लिए चुपचाप expected result edit कर देना, और इसे दर्ज न करना।
  • Execute करते समय की बजाय दिन के अंत में याद से results भरना।
  • Data, build और test basis से test case का मिलान जाँचे बिना हर mismatch को product defect के रूप में report करना।
  • किसी साफ़ दिखती problem को इसलिए अनदेखा करना कि "यह मेरे test case में नहीं है"।

QA का नज़रिया

असली team में आप आमतौर पर test management tool के अंदर किसी test run में आपको assign किए गए cases, execution schedule के क्रम में चलाते हैं। शुरू करने से पहले build और smoke test का pass होना पक्का करें। जल्दी बात करें: कोई failure दूसरे cases रोक दे तो तुरंत developer को बताएँ, और कोई expected result गलत लगे तो अकेले फ़ैसला करने की बजाय product owner से पूछें।

साथ-साथ दर्ज करें, और script से बाहर के observations व update चाहने वाले test cases पर अपने notes stand-up में या test lead के साथ share करें। कुछ teams cases को pairs में चलाती हैं, tester के साथ developer या दूसरा tester; ISTQB pair testing sessions को test execution के एक रूप के तौर पर बताता है।

अभ्यास

Profile test case का execution दर्ज करें

आपका काम

नीचे test case TC-21 है और उसे चलाते समय आपने जो देखा वह भी। Acceptance criterion कहता है: "Save करने के बाद नया display name पूरे app में तुरंत दिखता है।"

Execution record लिखें: हर step का result, overall status, actual results, report करने से पहले आप क्या जाँचेंगे, और script के बाहर जो दिखा उसका क्या करेंगे।

सामग्री
TC-21   Display name बदलना (version 1)
Pre:    account cust-basic-02 से logged in, display name "Lina Test"
Step 1  Profile खोलें।
        Expected: name field में "Lina Test" दिखता है
Step 2  नाम को "Lina Q." से बदलें और Save चुनें।
        Expected: message "Profile updated"; name field में "Lina Q." दिखता है
Step 3  Page reload करें।
        Expected: name field में अब भी "Lina Q." दिखता है
Step 4  Header menu खोलें।
        Expected: greeting "Hello, Lina Q." है

आपने जो देखा (build 3.9.1, staging, Chrome desktop):
Step 1  name field में "Lina Test"
Step 2  message "Profile updated"; name field में "Lina Q.";
        profile picture ग़ायब हो गई और reload के बाद ही वापस आई
Step 3  name field में "Lina Q."
Step 4  greeting "Hello, Lina Test"
चरण
  1. हर observation की उसके expected result से तुलना करें और हर step को passed या failed चिह्नित करें।
  2. Overall status तय करें और mismatch report करने से पहले क्या जाँचना है, यह लिखें।
  3. Run के context समेत record लिखें, और script के बाहर वाले observation का क्या करना है, यह तय करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Steps 1, 2 और 3 passed। Step 4 failed: expected "Hello, Lina Q.", actual "Hello, Lina Test"। Overall status failed है।

Report करने से पहले step 4 एक बार दोहराएँ और build (3.9.1) व account (cust-basic-02) पक्का करें। Acceptance criterion नया नाम हर जगह तुरंत माँगता है, इसलिए expected result test basis पर टिका है: failure report करें, जैसे "Profile update के बाद header greeting पुराना display name दिखाता है"।

दर्ज करें: TC-21 version 1, build 3.9.1, staging, Chrome desktop, account, आपका नाम, तारीख़ और समय, status failed, actual greeting, header का screenshot और defect ID।

ग़ायब profile picture TC-21 के expected results के बाहर है, इसलिए इससे status नहीं बदलता। इसे समय के साथ नोट करें, case के बाद reproduce करने की कोशिश करें, दोहराए तो अलग से report करें, और step 2 के लिए "profile picture दिखती रहती है" को अतिरिक्त expected result के रूप में सुझाएँ।

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

क्या पहले failed step पर ही रुक जाना चाहिए?

ज़रूरी नहीं। अगर बाक़ी steps failed step पर निर्भर नहीं हैं, तो आगे बढ़ें और हर result दर्ज करें, क्योंकि वे और जानकारी दे सकते हैं। अगर वे उस पर निर्भर हैं, तो रुकें और बाक़ी steps को not executed दर्ज करें। अपनी team की convention follow करें और record में लिखें कि आपने क्या किया।

क्या failed test एक खराब test है?

नहीं। Passed और failed तुलना के बारे में बताते हैं, test या tester की quality के बारे में नहीं: test तब fail होता है जब उसका actual result expected result से मेल नहीं खाता। जो failed test असली defect सामने लाता है, उसने ठीक अपना काम किया है। Test को खराब बनाता है गलत expected result या ऐसा step जिसे कोई follow न कर सके।

अगर मुझे लगे कि test case का expected result गलत है तो?

उसे test basis, जैसे requirement या acceptance criterion, से मिलाकर देखें और product owner या case लिखने वाले से पूछें। जो असल में दिखा वह दर्ज करें, और यह भी कि expected result पर सवाल है। Execution के दौरान अपने आप expected result edit न करें; अगर वह गलत है, तो test case ठीक करके फिर review होता है, और उसके बाद test दोबारा चलाया जाता है।

यह exploratory testing से कैसे अलग है?

यहाँ बताया गया manual test execution पहले से design किए गए test cases follow करता है, जिनके expected results run से पहले लिखे होते हैं। Exploratory testing में आप product के बारे में सीखते हुए tests को एक साथ design, execute और evaluate करते हैं, अक्सर एक test charter के सहारे। Script से आगे problems देखना scripted testing के अंदर exploration की एक छोटी ख़ुराक है; पूरा exploratory session एक अलग technique है जिसके अपने पाठ हैं।

संदर्भ

  • 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 टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
  • 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 रिपोर्ट।
टूल्स

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

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

JSON डिफ़

दो JSON डॉक्यूमेंट की सिमैंटिक तुलना करें और जोड़ी गई, हटाई गई तथा बदली गई वैल्यू हाइलाइट करें।

JSON और डेटा

अस्थायी ईमेल

एक डिस्पोज़ेबल ईमेल पता बनाएँ और आने वाले संदेश उसी पेज पर पढ़ें। उपयोग बंद करते ही पता अपने आप छोड़ दिया जाता है।

यूटिलिटीज़ नया

और गहराई से

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

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