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

टेस्ट ऑटोमेशन पिरामिड

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

Test automation pyramid एक model है जो बताता है कि automated test suite की shape कैसी होनी चाहिए। Tests को size के हिसाब से layers में बाँटा जाता है: नीचे बहुत सारे छोटे, तेज़ और isolated tests, बीच में साथ मिलकर काम करने वाले हिस्सों के कम tests, और शिखर पर सिर्फ़ कुछ बड़े end-to-end tests। Mike Cohn ने इसे तीन layers (unit, service और UI tests) के साथ पेश किया था, और ISTQB Foundation syllabus v4.0 इसका इस्तेमाल यह दिखाने के लिए करता है कि अलग-अलग test goals automation के अलग-अलग levels से पूरे होते हैं।

"क्या automate करें और क्या नहीं" वाले lesson ने तय किया कि कोई check automate करने लायक है या नहीं; pyramid तय करता है कि किस level पर। Promo code के लिए इसका मतलब है: discount और date rules के लिए लगभग बारह unit tests, cart service और उसके database के लिए कुछ API tests, और browser में एक end-to-end test जो code लगाकर payment करता है।

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

Check कहाँ रहता है, यही उसकी लागत तय करता है। जो browser test login करता है, cart भरता है और discount पढ़ता है, वह मिनटों चल सकता है, उसे हर service और सही data चाहिए, और fail होने पर अक्सर गलत number की जगह "element नहीं मिला" बताता है। वही rule function के रूप में टेस्ट हो तो milliseconds में चलता है, सिर्फ़ एक कारण से fail होता है और टूटे हुए code की ओर इशारा करता है। जिस suite में ज़्यादातर महँगे tests हों, वह धीमा और flaky हो जाता है (यानी उसके tests code में कोई बदलाव न होने पर भी एक run में pass और अगले में fail होते हैं), टीम उसे हर बदलाव पर चलाना बंद कर देती है और वह तेज़ feedback खो देती है जिसके लिए automation बना था।

Tester के लिए pyramid उन फ़ैसलों की भाषा है जो हर sprint में होते हैं: कौन-से checks UI की जगह API से automate हों, developers से unit tests में क्या cover करने को कहें, और तेज़ी से बढ़ता UI suite जश्न मनाने वाली progress नहीं बल्कि report करने लायक risk क्यों है।

Layers और उनके बीच क्या बदलता है

Layers के नाम और संख्या अलग-अलग होते हैं। Cohn का pyramid unit, service और UI कहता है; एक आम version component, integration और end-to-end कहता है, और ISTQB syllabus बताता है कि दोनों इस्तेमाल होते हैं। Idea वही रहता है: test जितना ऊपर होगा, एक run में system का उतना बड़ा हिस्सा चलाएगा, और suite को ऐसे tests उतने ही कम चाहिए।

  • Unit या component tests (नींव, बहुत सारे): एक function, class या UI component, जिसकी dependencies ज़रूरत हो तो test doubles से बदली जाती हैं, जैसा component testing वाले lesson में था। हर test milliseconds में चलता है, और fail होने पर टूटी हुई unit का नाम बताता है। आम तौर पर developers इन्हें code के साथ लिखते हैं।
  • Integration, service या API tests (बीच, कम): किसी असली interface से साथ काम करते components या services, जैसे HTTP API, database या message queue। ये ऐसे interface defects पकड़ते हैं जो unit tests नहीं देख पाते, जैसे rename हुआ field या कभी save न होने वाला record, और हर test seconds में चलता है।
  • End-to-end या UI tests (शिखर, कुछ ही): असली interface और उसके पीछे के हर system से गुज़रती पूरी user journey। ये साबित करते हैं कि user के लिए हिस्से आपस में जुड़े हैं, लेकिन हर test को पूरा environment और test data चाहिए, वह seconds या मिनटों चलता है, और बदलाव से असंबंधित कारणों से भी fail हो सकता है।
Test automation pyramid की तीन layers: नींव में बहुत सारे तेज़ और isolated unit tests, बीच में कम API और integration tests, और शिखर पर कुछ end-to-end journeys।

“End-to-end / UI tests” परत पर: कम tests: ज़्यादा असली, धीमे, ज़्यादा फैले हुए“Unit / component tests” परत पर: ज़्यादा tests: तेज़, isolated, सटीक

  1. 1End-to-end / UI testsकुछ ही · उदाहरण में 1असली interface और उसके पीछे की हर service से गुज़रती पूरी user journey

    हर test seconds से मिनटों तक; failure किसी भी हिस्से से आ सकता है

  2. 2Integration / API testsकम · उदाहरण में 5किसी असली interface से साथ काम करते components या services: HTTP API, database, message queue

    हर test seconds में; वे interface defects पकड़ता है जो unit tests नहीं देखते

  3. 3Unit / component testsबहुत सारे · उदाहरण में 12एक function, class या UI component, जिसकी dependencies के लिए test doubles

    हर test milliseconds में; failure टूटी हुई unit का नाम बताता है

संख्याएँ lesson के promo code example से हैं। Layers के नाम अलग-अलग होते हैं: Cohn का original pyramid unit, service और UI कहता है। Exploratory testing कोई layer नहीं है; लोग automated checks के ऊपर explore करते हैं।

नियम: सबसे निचले उस level पर टेस्ट करें जो defect पकड़ सके

Pyramid का practical इस्तेमाल एक placement rule है। हर check के लिए पूछें: जिस defect को यह निशाना बनाता है, वह सबसे पहले कहाँ दिखता है? Calculation, validation rule या date boundary unit test में दिखती है। जो data सही तरह save होना चाहिए, या दो services जिन्हें एक format पर सहमत होना है, उनके लिए integration या API test चाहिए। End-to-end test सिर्फ़ journey की अपनी खराबी के लिए चाहिए, जैसे गलत action से जुड़ा button या payment के बाद session खो देने वाला page।

इससे दो आदतें निकलती हैं। जब कोई end-to-end test या कोई व्यक्ति ऐसा defect पकड़े जिसे निचला test पकड़ सकता था, तो वह निचला test भी जोड़ें, ताकि gap वहाँ बंद हो जहाँ check सबसे सस्ता है। और एक check हर layer पर न दोहराएँ: अगर unit tests discount की boundaries पहले से cover करते हैं, तो UI test को सिर्फ़ एक value चाहिए जो दिखाए कि discount screen तक पहुँचता है।

Front-end component को अक्सर असली back end की जगह mocked API response के साथ टेस्ट किया जा सकता है, जिससे check pyramid के शिखर से उसकी नींव पर आ जाता है।

आज़माएँ: Mock API रिस्पॉन्स जनरेटर

Worked example: promo code के checks बाँटना

Requirement: "SAVE10 से 200.00 SAR या उससे ज़्यादा के orders पर 10% छूट मिलती है, अधिकतम 50.00 SAR, 1 से 31 मार्च 2027 तक (Riyadh समय), हर customer के लिए एक बार।" यह component testing वाले lesson का SAVE10 code है, अब अपने पूरे business rule के साथ। Boundary value analysis values देता है; pyramid तय करता है कि हर check कहाँ चलेगा।

Amounts, dates और पिछले इस्तेमाल के बारह checks unit tests में जाते हैं: ये pure rules हैं, और इनमें से ज़्यादातर boundary values हैं। API layer वह जोड़ती है जो अकेला function नहीं दिखा सकता: code असली database में ढूँढा जाता है, पहला इस्तेमाल record होता है ताकि दूसरा reject हो, और discount order पर save होता है। अकेला end-to-end test कोई boundary दोबारा नहीं जाँचता; वह साबित करता है कि customer के लिए field, cart, payment और confirmation जुड़े हुए हैं। अगर यही अठारह checks browser tests के रूप में लिखे जाते, तो हर एक login करता और cart भरता, और failure का message "500.10 पर 50.01 मिला" की जगह "element नहीं मिला" होता।

Rule: SAVE10 = 10% off orders from 200.00 SAR, at most 50.00 SAR off,
      valid 1 to 31 March 2027 (Riyadh time), once per customer

UNIT: discount and validity functions, test doubles for the rest     12 tests
  199.99 -> 0.00      200.00 -> 20.00     333.33 -> 33.33
  499.90 -> 49.99     500.00 -> 50.00     500.10 -> 50.00 (cap)
  28 Feb 23:59:59 -> invalid            1 Mar 00:00:00 -> valid
  31 Mar 23:59:59 -> valid              1 Apr 00:00:00 -> invalid
  first use -> valid                    earlier use by this customer -> invalid

API / INTEGRATION: cart service with its real database                5 tests
  apply SAVE10 to a 250.00 cart     -> accepted, discount 25.00
  apply an expired code             -> rejected, PROMO_EXPIRED
  apply an unknown code             -> rejected, PROMO_UNKNOWN
  same customer applies it again    -> rejected, PROMO_ALREADY_USED
  place the order                   -> discount 25.00 saved on the order

END-TO-END: browser, all services, test payment                       1 test
  log in, add 250.00 SAR of items, apply SAVE10, see -25.00,
  pay with a test card, confirmation shows 225.00

आज़माएँ: बाउंड्री नंबर डेटासेट जनरेटर आज़माएँ: OpenAPI → टेस्ट केस

Anti-pattern: आइसक्रीम कोन

Ice-cream cone उल्टा pyramid है: unit tests की पतली नोक, कुछ integration tests, automated UI tests की चौड़ी पट्टी, और सबसे ऊपर manual regression testing का बड़ा scoop। यह नाम Alister Scott ने लोकप्रिय किया, और "The Practical Test Pyramid" चेतावनी देता है कि ऐसा suite maintain करना मुश्किल है और चलने में बहुत ज़्यादा समय लेता है।

Cone आम तौर पर अनजाने में बढ़ता है: automation वे लोग शुरू करते हैं जिनकी पहुँच सिर्फ़ UI तक है, हर fix हुए bug के लिए नया browser test जुड़ता है, और कोई नहीं पूछता कि unit tests पहले से क्या cover करते हैं। इससे निकलना धीरे-धीरे होता है: हर धीमे या flaky UI test के लिए वह defect लिखें जो उसे पकड़ना चाहिए, उस check को सबसे निचली ऐसी layer पर ले जाएँ जो उसे पकड़ सके, हर critical flow के लिए एक journey रखें, और developers के साथ तय करें कि कौन-से rules unit tests के ज़िम्मे हैं।

टीम की pipeline में दिखने वाले लक्षण:

  • Regression run घंटों लेता है, इसलिए हर बदलाव पर चलने की जगह रात में चलता है।
  • ज़्यादातर failures timeouts और missing elements हैं, और लोग जाँच करने की जगह suite दोबारा चला देते हैं।
  • एक page का एक बदलाव एक साथ दर्जनों tests तोड़ देता है।
  • हर release से पहले manual regression अब भी कई दिन लेता है, क्योंकि automation पर किसी को भरोसा नहीं।

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

एक और shape: टेस्टिंग ट्रॉफी

Pyramid अकेला model नहीं है। Kent C. Dodds ने JavaScript web applications के लिए testing trophy सुझाई: नींव में static analysis (type checking और linting), फिर unit tests, फिर सबसे बड़ी layer के रूप में integration tests, और शिखर पर end-to-end tests का छोटा हिस्सा। उनका तर्क है कि test software के इस्तेमाल के तरीके से जितना मिलता-जुलता हो, उतना ज़्यादा भरोसा देता है, और integration tests इस भरोसे और tests को चलाने व maintain करने की लागत के बीच सबसे अच्छा संतुलन देते हैं।

दोनों shapes जितने अलग दिखते हैं, उतने हैं नहीं। दोनों end-to-end layer को छोटा रखते हैं, दोनों ice-cream cone को नकारते हैं, और दोनों कहते हैं कि हर check वहाँ रखें जहाँ वह अपनी लागत के हिसाब से सबसे ज़्यादा भरोसा दे। फ़र्क "integration" के मतलब में है: front-end application में यह mocked API के साथ एक साथ render हुए कुछ components हो सकते हैं, जो असली browser या back end के बिना तेज़ी से चल सकते हैं। Shape अपने system के architecture से चुनें, और उसे feedback time और escape होने वाले defects से परखें, किसी तस्वीर से मिलान करके नहीं।

Pyramid, ice-cream cone और testing trophy साथ-साथ: सबसे ज़्यादा tests किस layer में, end-to-end layer कितनी बड़ी, और ज़्यादातर checks कैसे चलते हैं।

Test pyramidModel

बहुत सारे unit tests, कम integration tests, कुछ ही end-to-end tests

सबसे बड़ी layer:
Unit tests
End-to-end layer:
छोटी
ज़्यादातर checks कैसे चलते हैं:
Isolated unit tests, milliseconds में
नाम किसने दिया:
Mike Cohn

Ice-cream coneAnti-pattern

कम unit tests, बहुत सारे UI tests, और ऊपर manual regression का बड़ा scoop

सबसे बड़ी layer:
UI tests और manual regression
End-to-end layer:
बड़ी
ज़्यादातर checks कैसे चलते हैं:
Browser runs और manual passes, घंटों या दिनों में
नाम किसने दिया:
Alister Scott ने चेतावनी के रूप में लोकप्रिय किया

Testing trophyVariant

नींव में static analysis, ज़्यादातर integration tests, कुछ ही end-to-end tests

सबसे बड़ी layer:
Integration tests
End-to-end layer:
छोटी
ज़्यादातर checks कैसे चलते हैं:
साथ टेस्ट होते components, अक्सर mocked API के साथ
नाम किसने दिया:
Kent C. Dodds, JavaScript web applications के लिए

आम गलतियाँ

  • Pyramid को हर layer के लिए fixed percentage split मानना, जबकि यह एक दिशा है: ज़्यादातर checks नीचे, शिखर पर कुछ ही।
  • हर acceptance criterion के लिए end-to-end test लिखना, उन rules के लिए भी जिन्हें unit या API test milliseconds में जाँच सकता है।
  • एक ही check हर layer पर दोहराना, जिससे एक defect कई tests fail करता है और हर बदलाव पर कई updates लगते हैं।
  • UI test से मिले defect को fix करना, लेकिन वह निचला test न जोड़ना जो उसे पहले पकड़ लेता।
  • Exploratory testing को cone का वह हिस्सा मानना जिसे हटाना है: घटना चाहिए scripted regression checks का manual दोहराव, exploration नहीं।
  • Developers से कभी न पूछना कि उनके unit tests कौन-से rules cover करते हैं, और फिर वही checks browser से दोहराना।

QA का नज़रिया

टीम में pyramid planning और review की बातचीत में दिखता है। Story refine होते समय उसके checks लिखें और developers के साथ तय करें कि हर check किस layer का है: rules और calculations unit tests में, contracts और data API tests में, और हर critical flow के लिए end-to-end एक journey। यह फ़ैसला test cases के साथ लिखें, जैसे "level" field में, ताकि अगला व्यक्ति वही check browser से न जोड़े।

समय के साथ suite की shape पर नज़र रखें। काम के signals: commit से result तक का समय, कितने failures defects की जगह environment या timing से आते हैं, और कौन-से escaped defects निचला test पकड़ सकता था। इन्हें retrospective में लाएँ, और जब नया UI test प्रस्तावित करें, तो बताने को तैयार रहें कि वह ऐसा क्या पकड़ता है जो कोई निचला test नहीं पकड़ सकता।

अभ्यास

Ice-cream cone बन चुके checkout suite को नया आकार दें

आपका काम

एक टीम के checkout regression suite में 2 unit tests, 3 API tests और नीचे दिए 10 browser tests हैं; सिर्फ़ browser tests हर run में लगभग 40 मिनट लेते हैं और अक्सर timeouts पर fail होते हैं। Rules: अगर VAT से पहले items का total 150.00 SAR या ज़्यादा है तो delivery free है, वरना 15.00 SAR; items और delivery दोनों पर 15% VAT लगता है; cash on delivery सिर्फ़ 1,000.00 SAR तक के order totals पर मिलता है।

Suite को pyramid का आकार दें: हर check को सबसे निचली ऐसी layer पर रखें जो उसका defect पकड़ सके, तय करें कि कौन-सी end-to-end journeys बचेंगी, और लिखें कि developers से क्या पूछना है।

सामग्री
checkout.spec (browser): each test logs in, fills a cart, opens checkout

B1   item total 149.99            -> delivery fee 15.00
B2   item total 150.00            -> free delivery
B3   item total 150.01            -> free delivery
B4   items 100.00 + delivery 15.00 -> VAT 17.25
B5   items 200.00, free delivery  -> VAT 30.00
B6   order total 1,000.00         -> cash on delivery offered
B7   order total 1,000.01         -> cash on delivery not offered
B8   pay by test card             -> order confirmed
B9   choose cash on delivery      -> order confirmed, "awaiting payment"
B10  delivery service unavailable -> error message on the checkout page
चरण
  1. हर browser test के लिए लिखें कि वह कौन-सा defect पकड़ने के लिए है।
  2. वह सबसे निचली layer चुनें जो उस defect को देख सके: unit, API या integration, या end-to-end।
  3. End-to-end tests सिर्फ़ उन journeys के लिए रखें जो browser और back end के बीच टूट सकती हैं, और एक journey से कई assertions cover करें।
  4. Developers और product owner के लिए सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Unit: B1 से B7 numbers पर rules हैं। ये जिन defects को निशाना बनाते हैं, वे हैं: free delivery की गलत threshold (B1 से B3), गलत calculate हुआ या delivery पर न लगा VAT (B4, B5), और cash on delivery की गलत limit (B6, B7)। इन्हें delivery fee, VAT और payment options वाले functions के unit tests में ले जाएँ, जहाँ और boundaries जोड़ना सस्ता है: जैसे 0.01, और ऐसा total जिसके VAT में rounding लगे, ताकि rounding rule तय हो।

API या integration: एक test जो जाँचे कि checkout API किसी दिए गए cart के लिए fee, VAT और payment options लौटाता है, ताकि साबित हो कि वह इन functions का इस्तेमाल करता है (हर एक की एक value काफ़ी है), और B10 के लिए एक test जिसमें delivery service की जगह error लौटाने वाला stub हो, यह जाँचने के लिए कि checkout crash होने की जगह तय error देता है। Page पर दिखने वाला message checkout page के component test से mocked error response के साथ cover हो सकता है।

End-to-end: B8 और B9 रखें, यानी card और cash on delivery की journeys, क्योंकि हर एक browser, checkout, payment और order services से गुज़रती है। हर एक confirmation page पर total भी जाँचे, ताकि calculation का user को दिखने वाला नतीजा एक बार जाँचा जाए।

नतीजा: दस browser tests की जगह लगभग दस unit और component tests (move किए गए सात checks, दो नई boundaries और error message का component test), दो API tests और दो end-to-end tests। सवाल: क्या मौजूदा unit tests इनमें से कोई rule पहले से cover करते हैं? Fee और VAT server पर calculate होते हैं या browser में (अगर browser में, तो front-end का unit या component test भी चाहिए)? 1,000.00 SAR की limit VAT से पहले है या बाद? क्या test environment delivery service के fail होने को simulate कर सकता है?

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

क्या unit, integration और end-to-end tests का कोई सही ratio है?

नहीं। Pyramid दिशा देता है, quota नहीं: ज़्यादातर checks नीचे, शिखर पर कुछ ही। असली ratio architecture पर निर्भर है: business rules से भरी service में ज़्यादातर unit tests होंगे, और दूसरे systems को जोड़ने वाली पतली layer को ज़्यादा integration tests चाहिए। Suite को feedback time, flaky tests की संख्या और escape होने वाले defects से परखें।

क्या unit tests लिखना tester का काम है?

आम तौर पर developers इन्हें code के साथ लिखते हैं, जैसा component testing वाले lesson में था। Tester review करता है कि वे क्या cover करते हैं, boundary और negative cases सुझाता है, और ऊपर की layers में उन्हें दोहराने से बचता है। कुछ टीमों में testers भी इन्हें लिखते हैं।

Manual और exploratory testing pyramid में कहाँ आती है?

Automated pyramid के बाहर। कुछ जाने-माने versions manual या exploratory testing को pyramid के ऊपर एक बादल की तरह दिखाते हैं: automation वह जाँचता है जिसका आपने अनुमान लगाया था, exploration वह खोजता है जिसका नहीं लगाया। Pyramid जिसे घटाता है वह scripted regression checks का manual दोहराव है।

Pyramid या trophy: मेरी टीम कौन-सा अपनाए?

तस्वीर नहीं, तर्क अपनाएँ: हर check वहाँ रखें जहाँ वह अपने दिए भरोसे के हिसाब से सबसे सस्ता हो। Front-end वाली JavaScript applications, जहाँ components के integration tests तेज़ हैं, अक्सर trophy जैसी दिखती हैं; business rules से भरी back-end services pyramid जैसी। दोनों में end-to-end layer छोटी रहती है।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018ऑटोमेटेड टेस्ट पोर्टफ़ोलियो में unit, integration, contract और UI टेस्ट का संतुलन कैसे रखें — व्यापक रूप से उद्धृत व्याख्या।
  • Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
टूल्स

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

OpenAPI → टेस्ट केस

OpenAPI / Swagger स्पेसिफ़िकेशन से संरचित टेस्ट-केस मैट्रिक्स (positive, negative, auth, boundary) बनाएँ।

ऑटोमेशन

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

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

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

और गहराई से

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

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