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

टेस्ट ऑटोमेशन स्ट्रैटेजी

Mutqan Soft QA टीम द्वारा · · 18 मिनट · मध्यम

Test automation strategy छोटे, लिखे हुए फ़ैसलों का वह set है जो team को बताता है कि वह testing को कैसे automate करती है: automation किसलिए है और क्या cover करता है, कौन-से tools इस्तेमाल होते हैं, tests का owner कौन है, वे कहाँ चलते हैं, किस data के साथ, results कैसे report होते हैं और suite का maintenance कैसे होता है। ISTQB glossary इसे दी गई constraints के भीतर test automation के long-term objectives हासिल करने की high-level plan बताती है। एक food-delivery team की strategy की एक line: "Developers pricing rules को unit tests में टेस्ट करते हैं; छह browser journeys हर रात चलती हैं, और red run का triage 10:00 बजे तक होता है।"

"क्या automate करें और क्या नहीं" और "टेस्ट ऑटोमेशन पिरामिड" वाले lessons ने फ़ैसले एक-एक check के स्तर पर लिए। Strategy उन फ़ैसलों को पूरी team के rules में बदलती है, और अक्सर test strategy का एक section या उसके बगल में रखा एक छोटा document होती है।

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

Strategy के बिना automation संयोग से बढ़ता है: browser scripts जो सिर्फ़ एक tester के laptop पर चलती हैं, दूसरे tool में API tests, nightly results जिन्हें कोई नहीं पढ़ता, एक ही account share करके एक-दूसरे को तोड़ते tests, और पहले redesign के बाद छोड़ दिया गया suite, क्योंकि उसके maintenance की plan किसी ने नहीं बनाई। CTFL v4.0 test automation के इन्हीं risks को गिनाता है, जिनमें unrealistic expectations, test scripts के maintenance की मेहनत का कम अनुमान, और किसी vendor या ऐसे open-source project पर निर्भरता शामिल है जिसे छोड़ा जा सकता है।

Tester के लिए strategy रोज़ के सवालों को बहस बनने से पहले सुलझा देती है: नया check कहाँ जाएगा, कौन-सा tool, run red होने पर क्या होगा और टूटा test कौन ठीक करेगा। इसी से आप दिखा पाते हैं कि automation risk और feedback time घटा रहा है, सिर्फ़ यह नहीं कि scripts मौजूद हैं।

सात फ़ैसले, एक क्रम में

Strategy सात सवालों का जवाब देती है: automation किसलिए है और क्या cover करता है (goals और scope), किससे (tools), कौन करेगा (ownership), कहाँ (environments), किस data से (test data), results लोगों तक कैसे पहुँचते हैं (reporting) और suite स्वस्थ कैसे रहता है (maintenance)।

फ़ैसले लगभग इसी क्रम में लें, क्योंकि हर जवाब पिछले जवाबों पर टिका है: scope तय करता है कि कौन-से tools फ़िट होते हैं, tool की language तय करती है कि tests कौन लिख और review कर सकता है, tools और test levels environments तय करते हैं, environments तय करते हैं कि data कैसे बनेगा, और reporting व maintenance के rules के लिए हर test का owner चाहिए। नतीजे को एक-दो पेज में रखें, जिन पर team का नया सदस्य अमल कर सके।

Test automation strategy के सात फ़ैसले, goals और scope से maintenance तक, हर फ़ैसला अपने ऊपर वालों पर टिका, और हर एक के बगल में food-delivery team का फ़ैसला।

हर फ़ैसला अपने ऊपर वाले फ़ैसलों पर टिका है

  1. 1Goals और scopeक्यों और क्या?ऐसा goal जो बाद में जाँचा जा सके; कौन-से checks किस level पर automate होंगे और क्या manual रहेगा

    Regression 4 की जगह 1 दिन में; 6 end-to-end journeys

  2. 2Toolsकिससे?Product, developers की language और CI से fit, पहले proof of concept में आज़माया

    Playwright with TypeScript; results JUnit XML में

  3. 3Ownershipकौन?हर तरह का test कौन लिखता, review और maintain करता है, और red run पर कौन कदम उठाता है

    Developers: unit tests; testers: API और end-to-end suites

  4. 4Environmentsकहाँ?हर suite कहाँ चलता है, और third parties को stub या sandbox से कैसे बदला जाता है

    हर pull request के लिए fresh environment; रात में staging

  5. 5Test dataकिस data से?हर test unique values के साथ अपना synthetic data खुद बनाता है

    Customer, restaurant और order API से बनते हैं

  6. 6Reportingकब, और कौन पढ़ता है?Suites कब चलते हैं, red result क्या रोकता है, और कौन कब तक triage करता है

    Pull-request set merge रोकता है; nightly result का triage 10:00 तक

  7. 7MaintenanceSuite स्वस्थ कैसे रहे?हर sprint में upkeep का समय, flaky tests का rule, tests delete करना, strategy का review

    Flaky test 2 working days में ठीक या quarantine

हर layer के बगल में: lesson की food-delivery app वाली एक पेज की strategy का फ़ैसला।

Goals, scope और tools

Goal ऐसे लिखें कि बाद में जाँचा जा सके: "release regression चार दिन की जगह एक दिन में" या "pull request को 15 मिनट में result"। फिर सबसे ऊँचे product risks से शुरू करके, frequency, determinism और stability वाले rule और pyramid के levels से scope तय करें: किस तरह के checks किस level पर automate होंगे, और क्या जान-बूझकर manual रहेगा, जैसे exploratory testing और usability पर फ़ैसला। जो scope से बाहर है उसका नाम भी लिखें, जैसे payment provider जिसे सिर्फ़ उसकी boundary पर टेस्ट किया जाता है।

Tools को popularity नहीं, fit के आधार पर चुनें, और commit करने से पहले पसंदीदा tool को एक proof of concept में आज़माएँ, यानी दो असली flows पर एक छोटा time-boxed pilot, एक आसान और एक मुश्किल:

  • Product fit: वे platforms, browsers और interfaces (web UI, mobile, API) जिन्हें टेस्ट करना है।
  • People fit: developers की अपनी language उन्हें tests review और ठीक करने देती है।
  • Pipeline fit: CI में headless (बिना दिखने वाली browser window के) चलता हो और results ऐसे format में लिखे जिसे CI platform पढ़ सके, जैसे JUnit XML।
  • भविष्य: active maintenance या vendor support, licence की लागत, और tool छोड़ दिए जाने पर बाहर निकलने का रास्ता।

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

Ownership, environments और test data

Ownership बताती है कि हर तरह के test को कौन लिखता, review करता और maintain करता है, और run fail होने पर कौन कदम उठाता है। एक आम बँटवारा: unit और component tests के owner developers हैं और वे उन्हें code के साथ लिखते हैं; API और end-to-end tests testers या automation engineers design करते हैं और developers उन्हें review करते हैं; सारा test code product code जैसे ही code review से गुज़रता है। Suite के हर हिस्से का एक नामित owner रखें, ताकि कोई एक व्यक्ति ही उसे समझने वाला अकेला न रहे।

Environments और data तय करते हैं कि red result पर भरोसा हो सकता है या नहीं: जो test इसलिए fail होता है कि किसी दूसरे test ने उसका data बदल दिया, वह team को failures नज़रअंदाज़ करना सिखाता है।

  • Environments: unit tests को environment नहीं चाहिए; API और end-to-end tests जहाँ संभव हो pipeline run के लिए बने environment में चलते हैं, और असली integrations के लिए shared staging environment रहता है।
  • Third parties: payment और SMS services शुरुआती stages में stubs या provider के sandbox से बदली जाती हैं, और असली integration बाद की एक छोटी stage में जाँचा जाता है।
  • Configuration और secrets: URLs हर environment की configuration से और secrets CI platform के secret store से आते हैं, test code से कभी नहीं।
  • Test data: हर test अपनी ज़रूरत का data API या seed script से unique values के साथ खुद बनाता है, ताकि parallel runs न टकराएँ; data synthetic होता है, production से कभी copy नहीं; और जहाँ result clock या random values पर निर्भर हो वहाँ उन्हें control किया जाता है।

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

Reporting और maintenance

Reporting की शुरुआत इससे होती है कि हर suite कब चलता है और उसका result क्या करता है: हर pull request पर एक तेज़ set जो red होने पर merge रोके, पूरा set हर रात (CI configuration में cron schedule, जैसे हर दिन 02:00 बजे के लिए 0 2 * * *; जाँचें कि वह कौन-सा time zone इस्तेमाल करता है), और हर release से पहले एक summary। हर result को कौन और कब तक पढ़ेगा, यह नाम से लिखें। Failure report से मिनटों में triage हो सके: test का नाम, fail हुआ step, expected और actual result, build, environment, और browser tests के लिए screenshot, trace या log। समय के साथ test counts नहीं, trends report करें: run की अवधि, flaky tests की दर और कारण के हिसाब से failures (product defect, test defect या environment की समस्या)।

Maintenance plan किया जाता है, खाली समय पर नहीं छोड़ा जाता। Strategy उसके rules लिखती है:

  • हर sprint में upkeep का समय, और tests उसी pull request में update हों जिसमें product change है।
  • Flaky test ठीक किया जाता है या quarantine में भेजा जाता है, यानी एक अलग run जो merge नहीं रोकता, जैसा Martin Fowler का non-determinism वाला article सुझाता है। तय करें कि tests वहाँ कितने समय और कितनी संख्या में रह सकते हैं, और red suite को green होने तक बार-बार न चलाएँ।
  • जो tests अब किसी चीज़ की रक्षा नहीं करते वे delete होते हैं; framework और browser upgrades अपने अलग change में जाते हैं।
  • Strategy का भी तय schedule पर review होता है, जैसे हर तिमाही, और जब product या team बदले।

आज़माएँ: Cron एक्सप्रेशन जनरेटर

Worked example: food-delivery app के लिए एक पेज

पाँच developers और दो testers एक food-delivery web app और उसकी REST API बनाते हैं और हर दो हफ़्ते release करते हैं। आज regression का मतलब है चार दिन में चलने वाले 300 manual test cases, और 40 browser scripts जिन्हें एक tester ने record किया है और अपने laptop पर चलाती है। यह रही उनकी एक पेज की strategy।

हर line किसी level, व्यक्ति, जगह या समय का नाम लेती है, इसलिए नया सदस्य उस पर अमल कर सकता है, और goal मापने लायक है, इसलिए तिमाही review उसे जाँच सकता है।

Automation strategy: food-delivery web app और REST API (हर तिमाही review)

Goals         Release regression 4 की जगह 1 दिन में; pull-request result 15 मिनट में।
Scope         Unit: pricing, delivery-fee और promo rules।
              API: orders, payments, menus, cancellations।
              End to end, 6 journeys: sign-up, card order, cash on delivery,
              cancellation, restaurant accepts, courier delivers।
              जान-बूझकर manual: exploratory sessions, Arabic और English layout review।
              40 recorded scripts बदले जाएँगे, जैसे के तैसे migrate नहीं होंगे।
Tools         Playwright with TypeScript (developers की language), API और browser
              tests के लिए; CI में results JUnit XML में। 3 दिन के proof of concept
              के बाद चुना गया।
Ownership     Developers: unit tests। Testers: API और end-to-end suites, जिन्हें
              developers review करते हैं। हर feature area का एक नामित owner।
Environments  Pull request: unit और API tests fresh environment में, payment और SMS
              stubbed। Nightly: सारे suites, 6 journeys समेत, staging पर, payment
              provider के sandbox के साथ।
Test data     हर test API से अपना customer, restaurant और order बनाता है, unique
              names के साथ। सिर्फ़ synthetic data। Promo tests में clock fixed।
Reporting     Red होने पर pull-request set merge रोकता है। Nightly result का triage
              area owner 10:00 बजे तक करता है। हर महीने: duration, flaky rate और
              कारण के हिसाब से failures।
Maintenance   Tests उसी pull request में बदलते हैं जिसमें code। Flaky test 2 working
              days में ठीक या quarantine; quarantine में अधिकतम 5।
              हर sprint में upkeep का समय planned।

आम गलतियाँ

  • Goal और scope की जगह tool से शुरुआत करना ("हम Selenium इस्तेमाल करते हैं"), जबकि tool को उन्हीं की सेवा करनी है।
  • एक बार लंबा document लिखना और फिर कभी review न करना।
  • पूरे suite का owner एक ही व्यक्ति को बनाना, जिससे उसके न होने पर maintenance रुक जाता है।
  • Shared environments और accounts पर tests चलाना, और फिर data collisions का दोष "flaky tests" पर डालना।
  • Success को feedback time, flaky rate और escaped defects की जगह automated tests की गिनती से नापना।
  • Maintenance का कोई समय plan न करना, जिससे पहले redesign के बाद suite बिगड़ने लगता है।

QA का नज़रिया

Tester आम तौर पर strategy अकेले नहीं लिखता, उसमें योगदान देता है: आप risks, regression scope और जो manual रहना चाहिए वह लाते हैं; developers और automation engineers tools और pipeline की जानकारी लाते हैं। Refinement में हर story को इसके सामने जाँचें: कौन-सा level, कौन owner, कौन-सा data, और क्या environment उस check को support करता है।

इसके काम करने के सबूत रखें: run की अवधि, flaky rate, maintenance के घंटे और escaped defects। हर review में "और automation" माँगने की जगह ठोस बदलाव सुझाएँ, जैसे किसी धीमी journey को API layer पर ले जाना या एक stub जोड़ना।

अभ्यास

Automation strategy के draft की review करें

आपका काम

एक clinic booking web app में patients appointments book करते हैं, reception staff doctors के schedules संभालता है और SMS reminders भेजे जाते हैं; हर दो हफ़्ते release होता है, और manual regression में तीन दिन लगते हैं। नीचे दिए QA lead के strategy draft को सात फ़ैसलों के हिसाब से review करें, फिर ऐसे दोबारा लिखें कि हर फ़ैसला specific हो।

सामग्री
Clinic booking web app: automation strategy (draft)

1. हम सारे regression tests automate करेंगे।
2. Tool: Selenium, क्योंकि यह सबसे popular है।
3. Ahmed सारे automated tests लिखेगा और maintain करेगा।
4. Tests shared QA server पर test patient account से चलेंगे।
5. हर run के बाद results email किए जाएँगे।
चरण
  1. Draft की हर line को उस फ़ैसले या उन फ़ैसलों से जोड़ें जिन्हें वह cover करती है, और लिखें कि किन फ़ैसलों की कोई line नहीं है।
  2. हर line के बारे में पूछें: क्या नया सदस्य इस पर अमल कर सकता है, और क्या गलत हो सकता है?
  3. हर कमज़ोर या गायब फ़ैसले को ऐसे दोबारा लिखें कि उसमें कोई level, व्यक्ति, जगह या समय हो।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Goals और scope (line 1): "सारे regression tests" न goal है न scope। बेहतर: "Goal: release regression तीन दिन की जगह एक दिन में। Booking rules (double booking नहीं, slots opening hours के अंदर) unit और API tests में; चार end-to-end journeys: book, reschedule, cancel, reception का slot block करना। जान-बूझकर manual: exploratory sessions और Arabic layout review।"

Tools (line 2): popularity कोई कसौटी नहीं है। Booking और reception calendar पर proof of concept के बाद चुनें, developers की language, CI में headless runs और ऐसे results के आधार पर जिन्हें CI platform पढ़ सके।

Ownership (line 3): सब कुछ एक व्यक्ति पर होने का मतलब है कि उसके न होने पर maintenance रुक जाएगा। Unit tests के owner developers; API और end-to-end tests के owner testers, जिन्हें developers review करते हैं; हर area का एक नामित owner।

Environments और data (line 4): shared server और एक shared patient से tests आपस में टकराते हैं। हर pull request के लिए fresh environment लें, हर test को API से अपना patient और doctor बनाने दें, SMS provider को stub करें और reminder tests में clock fix करें।

Reporting (line 5) और maintenance (गायब): ऐसा email जिस पर कोई कदम न उठाए, reporting नहीं है। Pull-request set merge रोकता है; area owner nightly result का triage 10:00 बजे तक करता है; flaky tests दो working days में ठीक या quarantine होते हैं; हर sprint में upkeep का समय plan होता है; strategy का review हर तिमाही होता है।

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

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

नहीं। Test strategy पूरी testing को cover करती है, manual और automated दोनों: levels, types, techniques, environments, risks और reporting। Automation strategy उसका automation वाला हिस्सा है और अक्सर उसका एक section होती है। दोनों में तालमेल होना चाहिए; जैसे test strategy का risk approach तय करता है कि automated checks सबसे पहले किसकी रक्षा करें।

Automation strategy कौन लिखता है?

आम तौर पर test lead या automation engineer draft लिखता है और पूरी team उस पर सहमत होती है, क्योंकि tests और pipeline का एक हिस्सा developers का होता है। Testers risks, regression scope और जो manual रहना चाहिए वह जोड़ते हैं। जिस strategy पर team कभी सहमत नहीं हुई, उसका पालन कोई नहीं करता।

यह कितनी लंबी होनी चाहिए?

जितनी छोटी हो सके, पर specific रहे; किसी product team के लिए एक-दो पेज आम तौर पर काफ़ी हैं। हर फ़ैसले में कोई level, व्यक्ति, जगह या समय होना चाहिए। Folder structure, coding conventions और locator rules जैसी details framework के अपने documentation में जाती हैं, जिन्हें आगे के lessons cover करते हैं।

Strategy कब बदलनी चाहिए?

तय schedule पर review करें, जैसे हर तिमाही, और तब भी जब कुछ बड़ा बदले: mobile app जैसा नया platform, नई team, नया CI system, या ऐसा goal जिसके बारे में numbers दिखाएँ कि वह पूरा नहीं हो रहा। क्या बदला और क्यों, यह दर्ज करें।

संदर्भ

  • Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
टूल्स

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

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

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

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

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

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

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

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

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

टेस्ट डेटा

और गहराई से

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

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