मॉड्यूल 22 · टेस्ट ऑटोमेशन के मूल सिद्धांत

टेस्ट ऑटोमेशन क्या है?

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 19 मिनट · मध्यम

ISTQB glossary के अनुसार test automation का मतलब है test activities को करने या उनमें मदद करने के लिए software का इस्तेमाल। ज़्यादातर teams में इसका मतलब automated test execution होता है: ऐसा code जो एक स्थिति तैयार करता है, product को किसी function, API या browser के ज़रिए चलाता है, actual result की तुलना पहले से लिखे expected result से करता है, और बिना किसी के देखे pass या fail report करता है। Manual regression case "registered user sign in कर सकता है" एक ऐसी script बन जाता है जो हर commit पर चलती है।

Tool support for testing वाले lesson में आपने tool categories और ISTQB के फ़ायदों व जोखिमों की सूचियाँ देखीं। यह lesson अंदर झाँकता है: एक automated test किन हिस्सों से बनता है, automation practice में team को क्या देता है, scripts बन जाने के बाद क्या गड़बड़ होता है, और ये scripts ऐसा software क्यों हैं जिसे maintenance चाहिए।

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

हर release नए regression checks जोड़ती है, और उन सबको हाथ से दोबारा चलाने में हर बार ज़्यादा समय लगता है, इसलिए teams या तो धीमी हो जाती हैं या दोबारा check करना छोड़ देती हैं, और regressions users तक पहुँच जाते हैं। Automation की मदद से team आज की features बनाते हुए भी कल का व्यवहार confirm करती रहती है। लेकिन बुरी तरह किया गया automation न होने से भी बुरा है: हमेशा red रहने वाले suite को सब अनदेखा करते हैं, और कुछ भी check न करने की वजह से हमेशा green रहने वाला suite ऐसा भरोसा देता है जो product ने कमाया ही नहीं।

भले आप कभी framework न बनाएँ, automation आपका रोज़ का काम बदल देता है: आप run results पढ़ते हैं, तय करते हैं कि red test product defect है, test defect है या environment problem, और साथियों की लिखी scripts review करते हैं।

एक automated test किन हिस्सों से बनता है

Automated test में अच्छे manual test case वाले ही हिस्से होते हैं, बस code के रूप में। वह preconditions तैयार करता है (arrange), steps करता है (act), actual और expected results की तुलना करके assert करता है, और cleanup करता है ताकि अगला test एक ज्ञात state से शुरू हो। Assertion इसका दिल है: precise expected result के बिना script सिर्फ़ यह साबित करती है कि कुछ crash नहीं हुआ। कुछ practitioners automated test को "check" कहते हैं, यह जताने के लिए कि वह सिर्फ़ वही verify करता है जो किसी ने पहले से तय किया था।

नीचे वही sign-in case Playwright में लिखे browser test के रूप में है; Selenium WebDriver और Cypress के tests का आकार भी यही होता है। अभी हर keyword समझना ज़रूरी नहीं: comments, steps और assertion पढ़ें। page.getByLabel('Email') जैसी line एक locator है, यानी वह तरीका जिससे test page पर कोई element ढूँढता है, यहाँ उसके दिखने वाले label से। Script उस चीज़ का सिर्फ़ एक हिस्सा है जिसे ISTQB Advanced Level Test Automation Engineering syllabus test automation solution कहता है: scripts और उन्हें चलाने व उनके results report करने के लिए ज़रूरी बाकी सब कुछ। इसका हर हिस्सा टूट सकता है:

Test scripts: हर test में एक behaviour, और नाम ऐसा जो वह rule बताए जिसे test check करता है।
Framework और runner, जो tests ढूँढता है, उन्हें चलाता है और हर result दर्ज करता है।
जिस interface को test चलाता है: एक function (unit level), एक HTTP API या user interface। निचले levels तेज़ होते हैं और कम टूटते हैं, जैसा test automation pyramid वाला lesson दिखाता है।
Test data और environment: test को जिन accounts, products और settings की ज़रूरत है, और वह system जिस पर test चलता है।
Trigger और report: आम तौर पर एक CI pipeline जो हर change पर suite चलाती है, और एक result जिसे कोई पढ़ता है।

import { test, expect } from '@playwright/test';
import { testUser } from './test-data';

test('registered user can sign in', async ({ page }) => {
  // Arrange: start on the sign-in page with a known test account
  await page.goto('/login'); // resolved against baseURL in playwright.config.ts

  // Act: the steps of the manual test case
  await page.getByLabel('Email').fill(testUser.email);
  await page.getByLabel('Password').fill(testUser.password);
  await page.getByRole('button', { name: 'Sign in' }).click();

  // Assert: the expected result, decided before the test ran
  await expect(page.getByRole('heading', { name: 'My account' })).toBeVisible();

  // Clean up: nothing to undo, signing in changes no data
});

आज़माएँ: REST API टेस्टर आज़माएँ: REST रिक्वेस्ट जनरेटर

Automation team को क्या देता है

असली team में फ़ायदे ऐसे दिखते हैं। हर फ़ायदा तभी टिकता है जब expected results सही हों, क्योंकि script गलत expected result को भी उतनी ही वफ़ादारी से दोहराती है जितना सही को।

तेज़ regression feedback: suite हर change पर चलता है, इसलिए regression तब report होता है जब developer को code अभी याद होता है।
सटीक, दोहराने योग्य तुलना: response का हर field और हर total आख़िरी halala तक, हर run में; जबकि बीसवीं बार वही case चलाने वाला व्यक्ति सरसरी नज़र से देखने लगता है।
Scale: वही steps सैकड़ों data rows पर, कई browsers में, हर रात।
Quality gate: pipeline में automated check हर change पर टूटे हुए build को staging तक पहुँचने से पहले रोक सकता है, किसी व्यक्ति का इंतज़ार किए बिना।
Living documentation: "300.00 SAR या उससे ज़्यादा के orders की delivery free" नाम वाला test एक rule बताता है और हर run में दिखाता है कि वह अब भी सही है।
Tester का समय: scripted cases दोबारा चलाने में जाने वाले घंटे exploratory testing और नई features के tests design करने में लगते हैं।

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

Scripts बन जाने के बाद क्या गड़बड़ होता है

Tool support for testing वाले lesson के जोखिम automate करने के फ़ैसले से जुड़े हैं: अवास्तविक उम्मीदें, कम आँका गया effort, गलत tool। Suite बन जाने के बाद जोखिमों का दूसरा समूह सामने आता है, और उसका ज़्यादातर हिस्सा खुद scripts से आता है:

झूठा भरोसा: इतने कमज़ोर assertions कि fail हो ही न सकें। जो test सिर्फ़ यह check करता है कि cart page load हुआ, वह green रहता है जबकि उस page पर total गलत है।
Flaky tests: ऐसे tests जो product या test में कोई बदलाव हुए बिना कभी pass और कभी fail होते हैं, आम तौर पर timing, shared test data या अस्थिर environment की वजह से। कुछ झूठे alarms के बाद team red results पढ़ना बंद कर देती है, और उनके साथ असली regressions भी निकल जाते हैं।
Brittle scripts: बार-बार बदलने वाली details, जैसे CSS class या button की position, से बँधे tests हर redesign पर टूटते हैं, जबकि behaviour वही रहता है।
Slow suites: जब run में लोगों के इंतज़ार की हद से ज़्यादा समय लगता है, तो वे उसके बिना merge कर देते हैं और तेज़ feedback ख़त्म हो जाता है।
घिसे हुए tests: suite सिर्फ़ वही दोबारा check करता है जिसका किसी ने अनुमान लगाया था, इसलिए वह regressions पकड़ता है पर नए defects कम ही, और exploratory testing की जगह नहीं ले सकता।
एक ही owner: अगर framework सिर्फ़ एक व्यक्ति समझता है, तो उसके दूसरे काम पर जाते ही maintenance रुक जाती है।

Test automation के हर फ़ायदे के साथ एक जोखिम जुड़ा है: software की तरह maintain किया गया suite तेज़ और सटीक regression feedback देता है, जबकि अनदेखा suite शोर या झूठा भरोसा देता है।

फ़ायदा: software की तरह maintain किया गया suite

Version control में, reviewed, हर failure का triage

फ़ीडबैक:: Regression तब report, जब code अभी याद हो
तुलना:: हर run में एक ही तरह सटीक checks
Green run:: लिखे गए checks pass हुए
Red run:: Triage: product defect, test defect या environment
Product में बदलाव:: Shared helper में एक edit
Tester का समय:: Exploratory testing और नए tests के लिए खाली

जोखिम: बिना maintenance छोड़ा गया suite

एक बार record, कभी review नहीं, red results अनदेखे

फ़ीडबैक:: इतना धीमा कि लोग उसके बिना merge कर देते हैं
तुलना:: गलत expected result, उतनी ही वफ़ादारी से दोहराया गया
Green run:: कमज़ोर assertions: total गलत, फिर भी green
Red run:: Flaky failures team को red अनदेखा करना सिखाते हैं
Product में बदलाव:: दर्जनों copied scripts में वही fix
Tester का समय:: Scripts दोबारा चलाने और ठीक करने में ख़र्च

Automation code भी software है और उसे maintenance चाहिए

Test suite एक program है जो दूसरे program को टेस्ट करता है। उसकी requirements (जिन test cases को वह implement करता है), design, dependencies और अपने defects होते हैं, जैसे गलत expected result, छूटा हुआ wait या ऐसा test जो किसी दूसरे test के चलने के बाद ही pass होता है। वह product जितना ही लंबा चलता है और product बदलने पर हर बार बदलता है।

Maintenance चार दिशाओं से आती है: product बदलता है (button का नाम बदला, नया mandatory field, बदला हुआ API response), tools बदलते हैं (browser, framework और runtime upgrades), data और environments बदलते हैं, और tests के अपने defects सामने आते हैं। जिन teams के suites उपयोगी बने रहते हैं, वे test code से product code जैसा ही व्यवहार करती हैं:

Product code के साथ version control; behaviour का change और उसके test का change एक साथ जाते हैं।
Tests का भी code review: नाम, assertions, duplication, fixed waits।
हर step एक ही बार लिखा जाए, एक shared helper में (इस module में आगे, page object में), ताकि UI का एक बदलाव मतलब एक edit।
Data, URLs और secrets configuration में; script में असली password कभी नहीं।
हर failure का triage करके उसे product defect, test defect या environment problem के रूप में दर्ज करना; green होने तक दोबारा चलाते रहना कभी नहीं।
हर sprint में maintenance का समय plan करना, और जो tests अब कुछ भी protect नहीं करते उन्हें हटाना।

Worked example: एक redesign, 37 red tests

एक team के पास 120 browser tests हैं। Designers sign-in page को दो steps में बाँट देते हैं, पहले email और "Continue" button, फिर password, और button का नाम "Sign in" से बदलकर "Log in" कर देते हैं। Nightly run में 37 failures दिखते हैं। कोई कुछ भी दोबारा चलाए, उससे पहले tester triage करता है: failures ठीक वही 37 tests हैं जो sign in करते हैं, सभी sign-in step पर रुकते हैं, और उनमें से हर test file में sign-in lines की अपनी copy है। Product ठीक काम कर रहा है; tests पुराने पड़ गए हैं।

37 files को patch करने में लगभग पूरा दिन लगता और अगले redesign पर फिर यही करना पड़ता, इसलिए team steps को एक helper में ले जाती है, जो एक बार बदला और एक बार review होता है। Fix के बाद 36 tests pass होते हैं। एक test आगे जाकर अब भी fail होता है: "Remember me" browser restart के बाद user को signed in नहीं रखता। Tester इसे हाथ से reproduce करता है और product defect report करता है, और suite ठीक इसी काम के लिए है।

// Before: these three lines were copied into 37 test files
//   await page.getByLabel('Email').fill(testUser.email);
//   await page.getByLabel('Password').fill(testUser.password);
//   await page.getByRole('button', { name: 'Sign in' }).click();

// After: one helper (sign-in.ts) that every test calls; the next redesign means one edit
import type { Page } from '@playwright/test';
import type { TestUser } from './test-data';

export async function signIn(page: Page, user: TestUser) {
  // Step 1: email, then "Continue". Step 2: password, then the renamed button.
  await page.getByLabel('Email').fill(user.email);
  await page.getByRole('button', { name: 'Continue' }).click();
  await page.getByLabel('Password').fill(user.password);
  await page.getByRole('button', { name: 'Log in' }).click();
}

// In each test: await signIn(page, testUser);

आम गलतियाँ

Automation को ख़त्म होने वाला project मानना: scripts एक बार record करना और उनकी maintenance के लिए कोई समय न रखना।
ऐसे manual case को automate करना जिसका expected result अस्पष्ट है, जिससे ऐसा check बनता है जो fail हो ही नहीं सकता।
Green run पर भरोसा करना, यह पढ़े बिना कि उसके assertions असल में क्या check करते हैं।
हर failure का triage करने के बजाय failed tests को pass होने तक दोबारा चलाना।
Test code को version control और review से बाहर रखना, hard-coded URLs, waits और passwords के साथ।
सफलता को automated tests की संख्या से नापना, न कि उनके पकड़े regressions और उन पर लगे effort से।

QA का नज़रिया

जब किसी story का refinement हो, पूछें कि उसके कौन-से checks automate होंगे, किस level पर, और उनकी maintenance कौन करेगा; test case में precise expected result आपका योगदान है, भले script developer लिखे। Test code को उन्हीं pull requests में review करें जिनमें वह product code है जिसे वह cover करता है।

जब run red हो, किसी के दोबारा चलाने से पहले triage करें, और हर failure को product defect, test defect या environment problem के रूप में दर्ज करें। Flaky tests और maintenance पर लगे घंटों का हिसाब रखें; आगे क्या automate करना है यह तय करते समय team को यही records चाहिए। जब आप report करें कि "automated regression pass हुआ", तो बताएँ कि suite क्या cover करता है और क्या नहीं।

अभ्यास

Automated test को code की तरह review करें

आपका काम

एक साथी ने नीचे दिया manual case automate किया है। Script को वैसे review करें जैसे product code करते हैं: हर समस्या लिखें, बताएँ कि वह क्यों मायने रखती है, और fix सुझाएँ।

फिर सुधारे गए test के तीन failures को product defect, test defect या environment problem में classify करें।

सामग्री

Manual case TC-CART-01: cart में product जोड़ना
Preconditions: test customer के रूप में signed in; product 1042 stock में; cart खाली
Steps: product 1042 खोलें; "Add to cart" पर click करें
Expected: cart badge 1 दिखाए; cart में product 1042, quantity 1, 49.00 SAR

test('test1', async ({ page }) => {
  await page.goto('https://staging.shop.example/login');
  await page.fill('#email', 'sara.qa@example.com');
  await page.fill('#pwd', 'secret123');
  await page.click('text=Sign in');
  await page.waitForTimeout(5000);
  await page.click('#product-1042');
  await page.click('.btn-primary');
  await expect(page.locator('.cart-count')).toBeVisible();
});

सुधारे गए test के failures:
A. सिर्फ़ सोमवार 08:00 के staging redeploy के दौरान fail: connection refused।
B. Redesign के बाद button का label "Add to basket" हो गया; product सही काम करता है।
C. खाली cart में एक item जोड़ने पर badge 2 दिखाता है; हाथ से भी reproduce होता है।

चरण

Script की manual case से तुलना करें: कौन-सी preconditions और expected results रखे गए, और कौन-से छूट गए?
नाम, data, waits और locators जाँचें।
जाँचें कि test लगातार दो बार, और किसी दूसरी machine पर चल सकता है या नहीं।
तीनों failures classify करें और हर एक के लिए अगला कदम बताएँ।

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

मॉडल उत्तर

नाम: test1 कुछ नहीं बताता। Rule के नाम पर रखें, जैसे "खाली cart में stock वाला product जोड़ने पर वह एक बार, अपनी कीमत पर दिखता है"।

Data और secrets: staging URL, असली जैसा दिखने वाला personal account और उसका password hard-coded हैं। Configured base URL, setup में बना test customer और environment से आने वाला secret इस्तेमाल करें।

Wait: waitForTimeout(5000) हर बार पाँच seconds लेता है और staging धीमा हो तो फिर भी fail होता है। इसकी जगह किसी condition का इंतज़ार करें; waits और synchronization वाला lesson यह सिखाता है।

Locators: #pwd, #product-1042 और .btn-primary implementation details पर टिके हैं। Labels, roles और visible names को प्राथमिकता दें, और sign-in lines को shared helper में ले जाएँ।

Assertion: "badge दिख रहा है" किसी भी expected result को सटीक रूप से check नहीं करता: badge 0 या 2 दिखाए, या cart में गलत product हो, तब भी pass होता है। Assert करें कि badge 1 दिखाए, और cart में product 1042, quantity 1, 49.00 SAR पर हो।

Preconditions: script sign in तो करती है, पर बाकी दो preconditions छोड़ देती है। Cart को कुछ भी खाली नहीं करता, इसलिए दूसरा run पहले से पड़े item के साथ शुरू होता है, और कुछ भी यह पक्का नहीं करता कि product 1042 stock में है। Setup में नया test customer बनाएँ या cart खाली करें, test data में stock तैयार करें, और बाद में cleanup करें।

Failures: A environment problem है; इसे दर्ज करें और runs को redeploy window से बाहर schedule करें। B test defect है, क्योंकि test पुराना पड़ गया है: पुष्टि करें कि नया label जानबूझकर है, फिर locator को एक ही जगह update करें। C product defect है, जिसे मज़बूत assertion ने पकड़ा; steps, expected count 1 और actual count 2 के साथ report करें।

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

क्या test automation के लिए programmer होना ज़रूरी है?

ऐसा automation करने के लिए जिसकी maintenance हो सके, आपको basic level पर code पढ़ना और लिखना आना चाहिए। Record-and-playback और low-code tools typing कम करते हैं, tests को design, review और maintain करने की ज़रूरत नहीं। Programming basics for test automation वाला lesson ये basics सिखाता है; तब तक precise test cases और सावधान triage भी automation के काम का हिस्सा हैं।

क्या test automation और automated testing एक ही हैं?

Teams आम तौर पर दोनों शब्द automated test execution के लिए इस्तेमाल करती हैं। ISTQB की test automation की परिभाषा ज़्यादा व्यापक है: test activities को करने या उनमें मदद के लिए software का कोई भी इस्तेमाल, जैसे test data generate करना, environments तैयार करना या reports बनाना।

क्या automation manual testing से ज़्यादा defects पकड़ता है?

वह अलग तरह के defects पकड़ता है। Automated suite जाने-पहचाने behaviour को तेज़ी से दोबारा check करता है और regressions पकड़ता है; नए defects ज़्यादातर नए test design और exploratory testing से मिलते हैं। उसका मुख्य मूल्य तेज़ और बार-बार की पुष्टि में है, खोज में नहीं।

कितनी maintenance की उम्मीद रखें?

कोई सार्वभौमिक आँकड़ा नहीं है: यह इस पर निर्भर है कि product कितनी बार बदलता है और suite कैसे design किया गया है। इसलिए इसे नापें: हर sprint में tests ठीक करने में लगे घंटे और उनकी वजह दर्ज करें। अगला lesson इन्हीं numbers को एक ईमानदार ROI calculation में इस्तेमाल करता है।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।
Best Practices — PlaywrightMicrosoft (Playwright)यूज़र को दिखने वाला व्यवहार टेस्ट करें, टेस्ट अलग-थलग रखें, मज़बूत locator और web-first assertions अपनाएँ, और trace से डिबग करें।

टेस्ट ऑटोमेशन क्या है?

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

एक automated test किन हिस्सों से बनता है

Automation team को क्या देता है

Scripts बन जाने के बाद क्या गड़बड़ होता है

Automation code भी software है और उसे maintenance चाहिए

Worked example: एक redesign, 37 red tests

आम गलतियाँ

QA का नज़रिया

अभ्यास

Automated test को code की तरह review करें

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

संदर्भ

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

REST API टेस्टर

REST रिक्वेस्ट जनरेटर

टेस्ट केस जनरेटर

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

और गहराई से

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

इस topic से पहले

अगले topics

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

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

एक automated test किन हिस्सों से बनता है

Automation team को क्या देता है

Scripts बन जाने के बाद क्या गड़बड़ होता है

Automation code भी software है और उसे maintenance चाहिए

Worked example: एक redesign, 37 red tests

आम गलतियाँ

QA का नज़रिया

अभ्यास

Automated test को code की तरह review करें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

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