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

टेस्ट ऑटोमेशन आर्किटेक्चर

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

Test automation architecture आपके automated tests के पीछे का technical design है: कौन-से हिस्से मौजूद हैं, हर हिस्से की ज़िम्मेदारी क्या है, और वे आपस में और system under test (SUT) से कैसे जुड़ते हैं। ISTQB Advanced Level Test Automation Engineering syllabus (CTAL-TAE) architecture (यानी design) को test automation framework (वह code जो design को लागू करता है: test runner, libraries, test scripts और suites) से, और test automation solution (framework और वे tools और adapters जिनकी उसे किसी एक SUT के लिए ज़रूरत है) से अलग करता है।

अच्छा design तीन रोज़ के जवाबों में दिखता है। Sign-in page बदला: कितनी files edit करनी होंगी? एक। Suite को staging पर चलाना है: क्या बदलेगा? एक setting। रात में कोई test fail हुआ: क्या log बताता है क्यों? हाँ, दोबारा चलाए बिना। पिछले lesson के page objects से आगे बढ़कर यह lesson पूरे framework को देखता है।

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

Design के बिना बढ़ता हुआ suite वही locators, URLs, waits और sign-in steps हर file में copy करता है, इसलिए product का हर बदलाव copies की गिनती से गुणा हो जाता है। Maintenance नए tests का समय खा जाती है, suite product से पीछे रह जाता है, और team उस पर भरोसा करना छोड़ देती है।

Tester के लिए architecture तय करता है कि आप कुछ पढ़ने लायक lines में test जोड़ पाएँगे या नहीं, code बदले बिना environment बदल पाएँगे या नहीं, और red result समझ पाएँगे या नहीं। हो सकता है आप framework अकेले design न करें, पर आप उसे बढ़ाएँगे, review करेंगे और उसके trade-offs के साथ काम करेंगे।

तीन layers और एक नियम

CTAL-TAE framework को तीन layers में बताता है, जिनमें से हर एक के बदलने की अपनी वजह है, और layers की गिनती कम रखने की सलाह देता है: हर काम के लिए अलग layer design को समझना मुश्किल बना देती है।

इन्हें एक नियम जोड़ता है: calls सिर्फ़ नीचे की ओर जाती हैं। Syllabus कहता है कि test scripts को core libraries सीधे call नहीं करनी चाहिए, इसलिए test ख़ुद browser नहीं चलाता, URL नहीं बनाता और environment variable नहीं पढ़ता। Core के नीचे चुना गया tool, जैसे Playwright, Selenium WebDriver या कोई HTTP library, SUT से जुड़ता है; CTAL-TAE इसे test adaptation कहता है।

Test scripts: business की भाषा में test cases और suites, जैसे checkout.payWithSavedCard() और उसके बाद total पर assertion। ये तब बदलते हैं जब requirement बदलती है।
Business logic: वह सब जो इस SUT को जानता है, जैसे page objects, flows, API clients, test data builders और keywords। बदली हुई screen या endpoint यहीं, एक बार ठीक होती है।
Core libraries: वह सब जो SUT पर निर्भर नहीं, जैसे browser और HTTP setup, configuration loader, logger और retry helpers। उसी technology stack वाला कोई भी project इन्हें reuse कर सकता है; ये tools बदलने पर बदलती हैं।

Tool और SUT के ऊपर तीन layers वाला test automation framework: calls सिर्फ़ नीचे जाती हैं, इसलिए बदली हुई screen business logic में और tool का upgrade core libraries में ठीक होता है।

Calls सिर्फ़ नीचे जाती हैं

1Test scriptstests/Business की भाषा में test cases और suites, उनके assertions के साथ
Requirement बदलने पर बदलती है
2Business logicbusiness/Page objects, flows, API clients, data builders और keywords: वह सब जो इस SUT को जानता है
Screen या endpoint बदलने पर बदलती है
3Core librariescore/Configuration loader, logger, browser और HTTP setup, retries: SUT से जुड़ा कुछ नहीं
Tools बदलने पर बदलती है; उसी stack पर reusable
4Tool और SUTPlaywright, Selenium WebDriver या HTTP library एक environment में SUT को चलाती है (test adaptation)

Test scripts से Core libraries तक:अनुमति नहीं: Test का driver, logger या configuration को सीधे call करना

Layers के नाम ISTQB CTAL-TAE syllabus से हैं, जो layers कम रखने की सलाह देता है। Core config/ की files पढ़ता है; secrets CI के secret store से आते हैं।

shop-e2e/
  tests/                    test scripts: business terms and assertions
    delivery-fee.spec.ts
    refunds.spec.ts
  business/                 knows this SUT; calls core/, never tests/
    pages/                  page and component objects
    flows/                  user tasks across pages: signIn, placeOrder
    api/                    API clients for set-up and clean-up
    data/                   test data builders
  core/                     knows no SUT; reusable on the same stack
    config.ts               loads and validates configuration
    logger.ts               levels, redaction, run header
    browser.ts  http.ts     tool set-up, retries
  config/                   one file per environment, no secrets
    test.json  staging.json

Reusable components, और कब share न करें

CTAL-TAE reusable steps और user flows की library से बने tests को structured scripting कहता है। Component तब निकालें जब वही steps कई tests में हों और एक ही वजह से बदलें:

Flows: कई pages पर फैला एक user task, जैसे signIn(user) या placeOrder(cart)। Syllabus इसे flow model कहता है: page objects के ऊपर दूसरा facade (एक सरल interface जो details छिपाता है), ताकि steps कई tests में reuse हों।
API setup helpers और test data builders जो UI test के लिए ज़रूरी customer या product बनाते हैं, screens पर click करने से तेज़ और ज़्यादा भरोसेमंद तरीके से।
जो बनाने लायक नहीं: दस optional flags वाला helper, सैकड़ों methods वाली base class जिसे हर page inherit करे, या ऐसा मोटा wrapper जो tool को छिपा दे और उसके documentation को बेकार कर दे। Component दूसरी या तीसरी copy पर निकालें, पहली से पहले नहीं।

Configuration और logging

Configuration वह सब है जो runs के बीच बदलता है पर tests के बीच नहीं: base URLs, browser, timeouts, test accounts और feature toggles। हर environment के लिए एक file रखें, जिसे TEST_ENV=staging जैसा एक variable चुने, और secrets CI के secret store से लें, जो आम तौर पर उन्हें run को environment variables के रूप में देता है, committed file से कभी नहीं। Configuration को start पर एक बार core library में validate करें, ताकि कोई missing value 200 tests को एक-एक करके fail करने की बजाय एक साफ़ message के साथ run रोक दे।

Logging वह तरीका है जिससे fail हुआ run ख़ुद को समझाता है। CTAL-TAE छह levels बताता है: fatal उन errors के लिए जो run रोक सकती हैं, error जब कोई condition या interaction fail हो और उसके साथ test भी, warn किसी अनपेक्षित बात के लिए जो test नहीं रोकती, info यह दिखाने के लिए कि test क्या कर रहा है, debug उन details के लिए जो failure की जाँच में काम आती हैं, और trace उससे भी ज़्यादा detail के लिए। Syllabus यह भी बताता है कि framework को क्या record करना चाहिए; व्यवहार में इसका मतलब है:

Run header: environment, SUT build, browser और secrets छिपाकर effective configuration।
हर test के लिए: नाम, start और end time, info level पर मुख्य steps, और status: passed, failed, या SUT की बजाय ख़ुद automation की failure।
Reproduce करने के लिए: test के बनाए records के ids और कोई भी random value या seed; debug level पर request और response bodies।
Redaction: tokens, passwords और personal data छिपाए जाएँ, जैसे हर line लिखने से पहले लगाए गए pattern से।

// config/staging.json: committed, contains no secrets
{
  "baseUrl": "https://staging.shop.example",
  "browser": "chromium",
  "timeoutMs": 10000
}
// SHOP_API_TOKEN comes from the CI secret store; TEST_ENV=staging selects this file

// test log, info level
03:00:04 INFO  run env=staging build=4.18.2 browser=chromium token=***
03:02:11 INFO  [delivery-fee] orders of 300.00 SAR ship free: start
03:02:12 INFO  created customer C-58213 and product P-7781 via API
03:02:15 INFO  step: add P-7781 to cart, open checkout
03:02:18 ERROR delivery fee: expected 0.00, actual 7.50
03:02:18 INFO  saved screenshot and trace in results/delivery-fee/
03:02:18 INFO  [delivery-fee] end: failed after 7 s

आज़माएँ: JSON वैलिडेटर आज़माएँ: JSON Schema वैलिडेटर आज़माएँ: Regex टेस्टर

Scripting approaches और उनकी maintenance लागत

CTAL-TAE tests लिखने के कई तरीके उनके फ़ायदों और कमियों के साथ बताता है; नीचे के पाँच मोटे तौर पर सबसे कम शुरुआती निवेश से सबसे ज़्यादा तक के क्रम में हैं। Syllabus test-driven और behaviour-driven development भी cover करता है; BDD का अपना lesson इसी module में आगे है।

Capture/playback: tool SUT पर manual actions record करके script बनाता है। शुरुआत जल्दी होती है, पर कुछ भी reuse नहीं होता, recording उसी SUT version पर निर्भर रहती है जिससे वह capture हुई, और screen बदलते ही दोबारा record करना पड़ता है। यह कम बदलने वाले SUT पर छोटे scope के लिए ठीक है।
Linear scripting: हर test के लिए एक script, steps ऊपर से नीचे, कोई shared library नहीं। Recording से edit करना आसान, पर हर बदलाव हर copy में दोहराना पड़ता है। Spike या गिने-चुने tests के लिए ठीक।
Structured scripting: tests business logic layer के reusable steps और flows call करते हैं। इसके लिए programming skills और शुरुआती निवेश चाहिए; उसके बाद बदलाव एक जगह ठीक होता है।
Data-driven: structured scripts जिन्हें CSV, spreadsheet या JSON files की rows से data मिलता है। नया case एक row की लागत है और test analysts बिना code के cases जोड़ सकते हैं; लागत data को manage करने में चली जाती है।
Keyword-driven: test, user के नज़रिए से नाम दिए गए keywords की table है, जैसे Add Product To Cart, उनके data के साथ। यह अक्सर data-driven testing पर बनता है, और ISO/IEC/IEEE 29119-5 इसी के लिए है। Programming न जानने वाले लोग tests बना सकते हैं, पर keyword library को design और maintain करना scope बढ़ने के साथ भारी होता जाता है, और छोटे system के लिए यह बड़ा effort है।

पाँच scripting approaches साथ-साथ: test किससे बनता है, product बदलने पर maintenance की लागत क्या है, और हर approach कब फ़िट है।

Approach	Test क्या है	Product बदलने पर	कब फ़िट है
Capture/playback	Manual actions की recording	प्रभावित tests दोबारा record करें	कम बदलने वाले SUT पर छोटा scope
Linear scripting	ऊपर से नीचे script, कोई shared code नहीं	बदले हुए steps की हर copy edit करें	Spike या गिने-चुने tests
Structured scripting	Reusable steps और flows की calls	एक component edit करें	लंबे समय का suite, जिसे programmers maintain करें
Data-driven	Structured script और data की rows	एक component edit करें; नया case एक row है	वही steps, कई input combinations
Keyword-driven	Keywords और उनके data की table	Keyword edit करें; keyword library का एक owner चाहिए	Stable domain में कई non-programmers tests लिखते हैं

ISTQB CTAL-TAE syllabus में दिए फ़ायदों और कमियों पर आधारित। असली suites approaches मिलाते हैं, जैसे structured, data-driven code के ऊपर keyword-driven tests।

आज़माएँ: CSV डेटासेट जनरेटर

Worked example: keywords से बना checkout suite

एक retailer के पास दो automation engineers और पाँच testers हैं जो business rules जानते हैं पर code नहीं लिखते। Delivery fee के rules हर तिमाही बदलते हैं और testers को cases ख़ुद जोड़ने होते हैं, इसलिए team keyword-driven framework चुनती है। Robot Framework, Python में लिखा एक open-source framework, इस approach का एक उदाहरण है; यहाँ कुछ भी उस पर निर्भर नहीं है।

Testers नीचे जैसी tables लिखते हैं, "300.00 SAR या उससे ज़्यादा के orders की delivery free है" वाले rule की boundary values के साथ। Keywords engineers के पास रहते हैं, और वे business logic हैं जो API client और page objects पर बनी है। यह इसलिए फ़िट है कि programming न जानने वाले कई लोग stable domain vocabulary में tests लिखते हैं, और keywords के लिए एक engineer तय है। जो दो developers पहले से code में tests लिखते हैं, उनके लिए keywords बस एक और layer जोड़ेंगे जिसे test fail होने पर पढ़ना पड़ेगा।

# tests/delivery_fee.robot, written by the testers
*** Settings ***
Resource    ../keywords/checkout.resource

*** Test Cases ***
Orders of 300.00 SAR ship free
    Sign In As New Customer
    Add Test Product To Cart    price=300.00
    Delivery Fee Should Be    0.00

Orders of 299.99 SAR pay 7.50 SAR
    Sign In As New Customer
    Add Test Product To Cart    price=299.99
    Delivery Fee Should Be    7.50

# keywords/checkout.resource (excerpt), maintained by the automation engineers
*** Keywords ***
Add Test Product To Cart
    [Arguments]    ${price}    ${quantity}=1
    ${sku}=    Create Product Via API    price=${price}
    Open Product Page    ${sku}
    Add To Cart    quantity=${quantity}

आम गलतियाँ

Tests को driver call करने, URLs बनाने या environment variables पढ़ने देना, जिससे एक बदलाव का मतलब हर test edit करना हो जाता है।
पहले दस tests के यह दिखाने से पहले कि असल में क्या दोहराया जाता है, layers, wrappers और keywords बना देना।
Tool को इतना मोटा wrap करना कि उसका documentation लागू ही न रहे।
Environment values code में hard-code करना और secrets repository में commit करना।
ऐसे logs जो failure diagnose करने के लिए बहुत कम हों, info level पर इतने भरे हों कि वजह दब जाए, या जिनमें tokens और personal data हों।
Keywords design और maintain करने के लिए किसी को तय किए बिना keyword-driven testing चुनना।

QA का नज़रिया

Framework को ऐसा product मानें जिसके users वे लोग हैं जो tests जोड़ते हैं। नई team में कुछ भी लिखने से पहले उसकी structure पढ़ें: tests, page objects और flows कहाँ रहते हैं, environment कैसे चुना जाता है, और failure log कैसा दिखता है। Code review में architecture के सवाल पूछें: क्या यह test business layer के नीचे पहुँच रहा है? क्या यह helper किसी मौजूदा helper की नक़ल है? क्या इस value की जगह configuration में है?

फ़ैसले वहाँ लिखें जहाँ team उन्हें ढूँढ सके, जैसे framework repository में छोटा README: layers, naming rules, नया environment कैसे जोड़ें और कौन-सा scripting approach इस्तेमाल होता है। Test repairs कहाँ होते हैं, इस पर नज़र रखें: कई test files में एक ही edit किसी missing component की ओर इशारा करता है।

अभ्यास

Linear suite के लिए architecture design करें

आपका काम

एक team आपसे अपनी hotel booking site के UI suite का review माँगती है, जिसका ब्योरा नीचे है। Target architecture प्रस्तावित करें: कौन-सी चीज़ किस layer में जाएगी, configuration और logging कैसे काम करेंगे, और हर ज़रूरत के लिए कौन-सा scripting approach फ़िट है। हर फ़ैसले के लिए बताएँ कि वह कौन-सी maintenance लागत हटाता है।

सामग्री

Suite: 85 linear UI tests, हर test की अपनी file, कोई shared code नहीं।
हर test इन lines से शुरू होता है:

  await page.goto('https://test.booking.example/login');
  await page.fill('#email', 'qa.team@booking.example');
  await page.fill('#password', 'Booking-2026');
  await page.click('#login-btn');
  await page.waitForTimeout(3000);

Facts:
- 60 tests वही 6 search lines दोहराते हैं; उनमें से 25 फिर test card से pay करते हैं।
- Suite को हर रात "test" पर, और हर release से पहले "staging" पर चलना है।
- CI failures में सिर्फ़ "Timeout 30000ms exceeded" और stack trace दिखता है।
- दो business analysts बिना code लिखे booking-price cases जोड़ना चाहते हैं।

चरण

हर दोहराए गए step को किसी layer में रखें।
तय करें कि क्या configuration में जाएगा और secrets कहाँ से आएँगे।
लिखें कि अगली CI failure को दोबारा चलाए बिना diagnose करने के लिए log में क्या होना चाहिए।
मौजूदा tests और analysts के cases के लिए scripting approach चुनें।

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

मॉडल उत्तर

Layers: tests/ में 85 tests रहते हैं, हर एक सिर्फ़ अपने steps और assertions तक सिमटा हुआ। business/ में login, search, results और payment pages के page objects, flows signIn, searchHotel और payByTestCard, और हर run के लिए नया test account बनाने वाला API client जाता है। core/ में configuration loader, logger और browser setup जाता है। Sign-in का बदलाव 85 edits से घटकर एक रह जाता है, search का 60 से एक।

Configuration: base URL, browser और timeouts config/test.json और config/staging.json में, जिन्हें TEST_ENV चुनता है; hard-coded email और password code से हटते हैं, account API client या CI secret store से आता है, और missing value run रोक देती है। तब staging पर चलाने की लागत 85 URLs edit करने की बजाय एक variable है। तीन seconds का fixed wait हटता है: flows conditions का इंतज़ार करते हैं, जैसे waits और synchronization वाले lesson में।

Logging: secrets छिपाकर run header; हर test के लिए नाम, times, status, current step और बनाए गए records के ids; failure पर URL, screenshot और trace। तब अकेला timeout message ऐसा पढ़ा जाता है: step: pay by test card; Pay button not visible on /checkout/payment after 30 s, और वजह दोबारा चलाए बिना मिल जाती है।

Approach: मौजूदा suite के लिए structured scripting। Analysts के लिए सस्ता पहला कदम nights, guests, season और expected price वाली data-driven CSV है जो एक structured test को data दे, क्योंकि हर नया price case बस एक row की लागत है; keywords जोड़ना तभी फ़ायदेमंद है जब उन्हें नए flows ख़ुद बनाने हों और कोई engineer उन्हें maintain करे।

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

क्या Playwright या Selenium test automation framework है?

CTAL-TAE की भाषा में ये tools और libraries हैं जिन पर framework बनता है। आपका framework वह code है जो आपकी team इनके चारों ओर लिखती है: test scripts, business logic और core libraries, runner और उसकी configuration के साथ। Playwright Test जैसे runners core का कुछ हिस्सा पहले से देते हैं, जैसे fixtures, configuration files और reporters, और यह उन हिस्सों को दोबारा न बनाने की अच्छी वजह है।

क्या छोटे project को तीनों layers चाहिए?

उसे separation चाहिए, ज़रूरी नहीं कि तीन folders। बीस tests के साथ कुछ page objects, एक configuration file और runner के built-in features काफ़ी हो सकते हैं। Duplication या उलझन दिखे तब structure जोड़ें; syllabus ख़ुद layers कम रखने की सलाह देता है।

क्या keyword-driven testing और BDD एक ही हैं?

नहीं, हालाँकि दोनों programming न जानने वालों को tests पढ़ने देते हैं। Keyword-driven tests data के साथ actions की tables हैं। BDD scenarios Given/When/Then वाक्य हैं जिन पर business representatives, developers और testers सहमत होते हैं, और BDD जितना test format है उतनी ही collaborative development practice भी। BDD और Gherkin वाला lesson इसे cover करता है।

Log और test report में क्या फ़र्क है?

Log run के दौरान framework और SUT ने जो किया उसका विस्तृत, समय-क्रम वाला record है, जो failures diagnose करने के लिए लिखा जाता है। Report फ़ैसला लेने वालों के लिए results का सार है: क्या pass हुआ, क्या fail हुआ और trend क्या है। अच्छा report हर failed test को उसके log और artefacts से जोड़ता है; automation reporting और debugging वाला lesson reports को cover करता है।

संदर्भ

Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।
ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।

टूल्स

और गहराई से

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

इस topic से पहले

पेज ऑब्जेक्ट मॉडल

अगले topics

टेस्ट आइसोलेशन और पैरलल एक्ज़ीक्यूशन

टेस्ट ऑटोमेशन आर्किटेक्चर

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

तीन layers और एक नियम

Reusable components, और कब share न करें

Configuration और logging

Scripting approaches और उनकी maintenance लागत

Worked example: keywords से बना checkout suite

आम गलतियाँ

QA का नज़रिया

अभ्यास

Linear suite के लिए architecture design करें

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

संदर्भ

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

JSON वैलिडेटर

JSON Schema वैलिडेटर

Regex टेस्टर

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

और गहराई से

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

इस topic से पहले

अगले topics

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

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

तीन layers और एक नियम

Reusable components, और कब share न करें

Configuration और logging

Scripting approaches और उनकी maintenance लागत

Worked example: keywords से बना checkout suite

आम गलतियाँ

QA का नज़रिया

अभ्यास

Linear suite के लिए architecture design करें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

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