एंड-टू-एंड टेस्टिंग
End-to-end (E2E) testing एक पूरी user journey को उसके पहले step से final outcome तक जाँचती है, उन सभी systems से होकर जिनसे वह गुज़रती है: user interface, back-end services और database, और payment provider या email service जैसे external systems। ISTQB glossary इसे business processes को शुरू से अंत तक, production जैसी परिस्थितियों में टेस्ट करना बताती है।
उदाहरण: किसी online store में एक E2E test customer के रूप में sign in करता है, payment provider के sandbox में test card से दो products खरीदता है, और पुष्टि करता है कि order paid के रूप में save हुआ, confirmation email पहुँचा, warehouse को order मिला और आख़िर में customer को order shipped दिखता है। हो सकता है हर system अपने tests में pass हो चुका हो; E2E test यह पूछता है कि क्या वे user के लिए मिलकर काम करते हैं।
यह क्यों ज़रूरी है
कई गंभीर failures systems के अंदर नहीं, उनके बीच होती हैं: order paid हो जाता है, लेकिन warehouse को कभी ख़बर नहीं मिलती। हर component और API अपने tests में pass हो सकता है, फिर भी customer purchase पूरी नहीं कर पाता। जो user देखता है, वह सिर्फ़ पूरी journey follow करने वाला test ही देखता है।
Business के लिए sign-up, checkout और payment जैसी critical journeys वहीं हैं जहाँ failures का सीधा असर revenue और भरोसे पर पड़ता है। Tester के लिए E2E tests इस बात का सबसे मज़बूत सबूत हैं कि release इस्तेमाल लायक है, और यही tests बनाने और चलाते रहने में सबसे महँगे भी हैं। किस journey को E2E test चाहिए, यह तय करना एक बुनियादी skill है।
एक end-to-end test क्या cover करता है
E2E test एक journey से परिभाषित होता है, किसी screen या component से नहीं। यह वहाँ से शुरू होता है जहाँ user शुरू करता है और वहाँ ख़त्म होता है जहाँ user का goal पूरा होकर दिखाई देता है: order ship हो गया, पैसा दूसरे account में पहुँच गया। इसकी असली value hand-offs पर रखे checks में है, यानी वहाँ जहाँ journey एक system से अगले system में जाती है।
- शुरुआत और अंत: एक actor, एक goal, और एक final outcome जिसे check किया जा सके।
- Systems: front end, back-end services, database, message queues और third-party services; आपके अपने systems उन्हीं versions में जिन्हें आप release करने वाले हैं।
- Checkpoints: हर hand-off के बाद की state, जैसे order status, payment reference या भेजा गया email।
End-to-end testing बनाम system testing
ISTQB Foundation syllabus में system testing एक test level है जो एक पूरे system के overall behaviour और capabilities पर focus करती है, और अक्सर उसके अंदर के end-to-end tasks की functional testing भी शामिल करती है। जिन हिस्सों पर यह निर्भर है उन्हें simulate किया जा सकता है, और दूसरे systems व external services के साथ interfaces एक अलग level, system integration testing, का focus हैं। ISTQB glossary end-to-end testing को test level नहीं, बल्कि एक test type कहती है: इसका scope एक business process तय करता है, जो इसमें शामिल हर system से गुज़रता है, उन systems समेत जो आपकी team के नहीं हैं।
दोनों overlap करते हैं, और E2E tests अक्सर system testing, system integration testing या acceptance testing के दौरान चलते हैं। कुछ teams किसी भी automated browser test को "E2E" कहती हैं, चाहे वह back end mock करके सिर्फ़ एक page cover करता हो; जब आप यह term सुनें, तो पूछें: क्या real था और क्या simulated?
- Scope: एक पूरा system, बनाम एक business journey, वह जहाँ भी जाए।
- पड़ोसी systems: system testing में simulate किए जा सकते हैं; E2E testing में real, या सबसे नज़दीकी उपलब्ध विकल्प जैसे provider का sandbox।
- आम defects: system के अंदर गलत behaviour, बनाम systems के बीच टूटे hand-offs, मेल न खाते data formats और छूटे हुए steps।
Worked example: cart से shipment तक एक online order
एक online store में आपकी team का बनाया web shop (front end और order service) है, test mode में payment provider है, दूसरी team का warehouse system है, और एक email service है। Journey: एक registered customer दो products खरीदता है और order ship होता है। एक ही order number हर check को जोड़ता है।
- ग्राहक ब्राउज़र
- वेब शॉप front end + order service
- पेमेंट प्रोवाइडर test mode (sandbox)
- वेयरहाउस सिस्टम दूसरी टीम का
- 1 ग्राहक से वेब शॉप तक: Sign in करें, cart में 2 × A और 1 × B जोड़ें Check 1: subtotal 190.00 SAR
- 2 ग्राहक से वेब शॉप तक: Checkout करें, provider के test card से pay करें
- 3 वेब शॉप से पेमेंट प्रोवाइडर तक: Payment authorise करने का request
190.00 SAR - 4 पेमेंट प्रोवाइडर से वेब शॉप तक: Approved + payment reference जवाब
- 5 वेब शॉप से ग्राहक तक: Confirmation page जवाब Check 2: order number दिखता है
- 6 वेब शॉप आंतरिक रूप से: Order को PAID save करना, stock घटाना Check 3: payment reference saved; stock A 8, B 2
- 7 वेब शॉप से ग्राहक तक: Confirmation email जवाब Check 4: test inbox में वही order number
- 8 वेब शॉप से वेयरहाउस सिस्टम तक: Order को picking के लिए भेजना Check 5: warehouse में वही 3 items
- 9 वेयरहाउस सिस्टम से वेब शॉप तक: Shipped + tracking number जवाब Step 6: warehouse system में shipped mark किया गया
- 10 वेब शॉप से ग्राहक तक: Order page पर "Shipped" जवाब Check 6: status और tracking number दिखते हैं
परिणाम: हर check किसी hand-off के बाद की state पढ़ता है, इसलिए fail होने वाला पहला check उस system या connection की ओर इशारा करता है जहाँ journey टूटी।
- नीचे दिए test case के checks 3 से 6 इसे end-to-end बनाते हैं: हर check किसी hand-off के दूसरी तरफ़ की state पढ़ता है (payment से order service, order service से email, order service से warehouse, और warehouse से वापस web shop)। सिर्फ़ checks 1 और 2 होते, तो test बस यह दिखाता कि customer की screen पर क्या लिखा है।
- अगर check 5 fail हो और check 3 pass, तो order service से warehouse तक के hand-off पर शक करें, और bug report में दोनों observations लिखें।
E2E-01 Registered customer दो products खरीदता है और order ship होता है
Preconditions:
- customer e2e.0412@example.com मौजूद और verified है
- product A (75.00 SAR, stock 10) और product B (40.00 SAR, stock 3)
web shop और warehouse system दोनों में मौजूद हैं
- payment provider test mode में है
- test environment से जाने वाले emails एक test inbox में पहुँचते हैं
Steps और checks:
1. Sign in करें, cart में 2 x A और 1 x B जोड़ें।
Check: subtotal 190.00 SAR।
2. Checkout करें और approved payment वाले provider के test card से pay करें।
Check: confirmation page पर order number दिखता है।
3. Check: order service में order PAID है, payment reference के साथ;
A का stock 8 और B का stock 2 है।
4. Check: उसी order number वाला confirmation email test inbox में है।
5. Check: warehouse system को वही 3 items वाला order मिल गया है।
6. Warehouse system में order को shipped mark करें।
Check: customer के order page पर "Shipped" और tracking number दिखता है।E2E tests कम क्यों रखें
E2E tests test pyramid के शिखर पर होते हैं। यह model ISTQB syllabus और martinfowler.com पर "The Practical Test Pyramid" में बताया गया है। Pyramid एक healthy test suite की तस्वीर है: नीचे बहुत सारे छोटे, तेज़ और isolated tests (component tests), बीच में कम integration tests, और शिखर पर सिर्फ़ कुछ E2E tests; अलग-अलग models में layers की संख्या और नाम अलग होते हैं। Pyramid में test जितना ऊपर होगा, एक run में उतना ज़्यादा cover करेगा, और उतना ही धीमा, कम isolated और maintain करने में महँगा होगा। जब कोई E2E test fail होता है, तो कारण उन systems में से किसी में भी हो सकता है जिनसे वह गुज़रा।
इसलिए हर rule को सबसे निचले level पर टेस्ट करें जहाँ वह टेस्ट हो सकता है, और business के लिए सबसे अहम journeys के लिए E2E tests का एक छोटा set रखें।
- Risk से चुनें: कोई journey E2E test की हक़दार तब है जब उसकी failure users को किसी अहम goal तक पहुँचने से रोके या पैसों का नुकसान करे।
- Main path और सिर्फ़ कुछ ज़रूरी alternatives cover करें, जैसे declined payment।
- जब कोई E2E test ऐसा defect पकड़े जिसे किसी lower-level test ने नहीं पकड़ा, तो और E2E tests जोड़ने की बजाय उसके लिए एक तेज़ lower-level test जोड़ें, जैसे component या API test।
Test data और environment की चुनौतियाँ
E2E testing की मेहनत का बड़ा हिस्सा data और environments में जाता है। Data कई systems में एक साथ consistent होना चाहिए, और हर run उसे बदल देता है: stock घटता है और orders जमा होते जाते हैं। Environment में हर system compatible versions में होना चाहिए; shared environments अक्सर busy या एक version पीछे होते हैं, और third-party sandboxes धीमे या unavailable हो सकते हैं।
- हर test जिस data की ज़रूरत रखता है उसे हर run में unique values के साथ बनाएँ, जैसे customer का नया email, बजाय ऐसे records दोबारा इस्तेमाल करने के जिन्हें दूसरे बदलते हैं।
- Payments के लिए provider का sandbox और उसके published test cards इस्तेमाल करें; असली cards या असली customer data कभी नहीं।
- किसी condition का इंतज़ार करें, जैसे email का पहुँचना, एक time limit के साथ; कभी तय सेकंडों तक नहीं।
- Failure report करने से पहले जाँचें कि environment healthy था: sandbox outage product defect नहीं है।
आम गलतियाँ
- हर check E2E tests में डाल देना: field validation, price rules और error messages lower levels पर सस्ते और ज़्यादा भरोसेमंद हैं।
- Back end या किसी अहम integration को mock करके test को "end to end" कहना, और test report में यह न बताना।
- सिर्फ़ आख़िरी screen check करना: customer को "Order confirmed" दिखता है जबकि warehouse को order कभी मिला ही नहीं।
- Shared, पहले से मौजूद data पर निर्भर रहना जिसे दूसरे लोग या पिछले runs बदल देते हैं।
- Emails और messages के लिए fixed waits लगाना: लंबा wait test को धीमा करता है, छोटा wait उसे flaky बनाता है।
QA का नज़रिया
असली team में tester आम तौर पर critical journeys की list रखता है, साथ में यह भी कि हर journey किन systems और teams से गुज़रती है। यह list product owner के साथ तय करें, जो जानता है कि business के लिए क्या अहम है, और उन teams के साथ जो environments, sandboxes और test accounts संभालती हैं। अक्सर journeys पहले system या acceptance testing के दौरान manually चलाई जाती हैं; फिर stable और high-value journeys pipeline में automate की जाती हैं।
हर run के लिए शामिल systems और उनके versions, क्या real था और क्या simulated, test data, और वह checkpoint जहाँ failure हुई, record करें। हर checkpoint पर evidence की तुलना "checkout टूटा हुआ है" जैसी अस्पष्ट बात को ऐसे defect में बदल देती है जिसे सही team ठीक कर सके।
अभ्यास
Clinic booking journey के लिए E2E test design करें
एक clinic app में patient appointment book कर सकता है। Journey mobile app और booking service (आपकी team), doctor scheduling system (दूसरी team), 50.00 SAR fee के लिए test mode में payment provider, और confirmation भेजने वाले SMS provider से गुज़रती है।
Main journey के लिए एक E2E test case लिखें जिसमें हर hand-off पर check हो, ज़रूरी test data और environment लिखें, और ऐसे दो checks बताएँ जो इस test में नहीं होने चाहिए।
- Journey को एक वाक्य में लिखें: actor, goal, final outcome।
- Systems और उनके बीच के hand-offs list करें।
- हर hand-off के बाद check के साथ steps लिखें।
- Data और environment की ज़रूरतें लिखें, और वे non-product कारण भी जिनसे test fail हो सकता है।
मॉडल उत्तर दिखाएँ
Journey: एक registered patient चुने हुए doctor के साथ एक free slot book करता है, 50.00 SAR fee pay करता है और confirmation SMS पाता है; इसके बाद वह slot किसी और को offer नहीं होता।
Steps: 1) Sign in करें, doctor और free slot चुनें। 2) Provider के test card से pay करें; check करें कि booking service ने booking को payment reference के साथ CONFIRMED save किया। 3) Check करें कि scheduling system में slot इस patient के लिए booked दिखता है। 4) Check करें कि SMS provider के test log में उसी booking number वाला confirmation है। 5) दूसरे test patient के रूप में check करें कि वह slot offer नहीं होता।
Data और environment: हर run में unique phone number वाला नया test patient, test के लिए बनाए गए free slots वाला doctor, और scheduling system व SMS test log तक तय की गई access। Test fail होने के non-product कारण: पिछले runs के कारण कोई free slot न बचना, wait limit से धीमा SMS, sandbox outage।
इस test में नहीं: phone number format का check (component या API level), और cancellation पर fee refund का rule (simulated payment provider के साथ booking service का system test)।
अक्सर पूछे जाने वाले सवाल
क्या end-to-end testing और UI test automation एक ही हैं?
नहीं। E2E test का scope बताता है: systems के पार एक पूरी journey। UI automation एक technique बताता है: किसी tool से user interface चलाना। कई automated E2E tests UI से चलते हैं, लेकिन E2E test manually भी चलाया जा सकता है, और कई UI tests E2E नहीं होते क्योंकि वे back end mock करके एक ही page cover करते हैं।
क्या E2E tests production में चलते हैं?
आम तौर पर ये production जैसे test environment में चलते हैं, क्योंकि ये orders, payments और messages बनाते हैं। कुछ teams deployment के बाद system को monitor करने के लिए production में कुछ सावधानी से design की गई journeys चलाती हैं, जिन्हें साफ़ तौर पर synthetic marked किया जाता है। इसके लिए product owner और operations की स्पष्ट सहमति चाहिए, और इसमें असली customer data या असली payments कभी इस्तेमाल नहीं होते।
किसी product को कितने E2E tests चाहिए?
कोई सही संख्या नहीं है। Critical journeys की list से शुरू करें, और हर journey को main path और सिर्फ़ सबसे अहम alternatives के test से cover करें। अगर E2E suite धीमा है या environment की वजह से बार-बार fail होता है, तो और E2E tests जोड़ने की बजाय checks को lower levels पर ले जाएँ।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- The Practical Test Pyramid (Ham Vocke)ऑटोमेटेड टेस्ट पोर्टफ़ोलियो में unit, integration, contract और UI टेस्ट का संतुलन कैसे रखें — व्यापक रूप से उद्धृत व्याख्या।
- Eradicating Non-Determinism in Tests (Martin Fowler)flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
Mutqan tools से अभ्यास करें
किसी user story से end-to-end टेस्ट सिनेरियो निकालें, वैकल्पिक और अपवाद flow सहित।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।
एक डिस्पोज़ेबल ईमेल पता बनाएँ और आने वाले संदेश उसी पेज पर पढ़ें। उपयोग बंद करते ही पता अपने आप छोड़ दिया जाता है।
और गहराई से
- एंड-टू-एंड प्रोडक्ट क्वालिटी एश्योरेंसटेस्ट डेटा और एनवायरनमेंट
- मैनुअल बनाम ऑटोमेटेड टेस्टिंगक्या ऑटोमेट करें यह तय करना: पिरामिड और एक सरल नियम
- CI/CD पाइपलाइन में टेस्टिंगPipeline के टेस्ट स्टेज और उनका क्रम क्यों मायने रखता है
- Flaky टेस्टऑटोमेटेड UI टेस्ट flaky क्यों होते हैं — timing, shared state, डेटा, environment, third parties — उनकी जाँच कैसे करें, और सही retry व quarantine नीति।
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।