मॉड्यूल 3 · Testing fundamentals

इंटीग्रेशन टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 17 मिनट · शुरुआती

Integration testing वह test level है जो components के बीच या systems के बीच interactions पर ध्यान देता है। हर हिस्सा अपने tests में पहले से pass हो सकता है; integration testing पूछती है कि क्या वे साथ मिलकर काम करते हैं: क्या एक हिस्सा जो data भेजता है वही है जिसकी दूसरा उम्मीद करता है, उसी format, units, क्रम और timing में। उदाहरण: checkout "amount": 150.00 भेजता है, यानी 150 रियाल, ऐसे payment gateway को जो amount हलालों में पढ़ता है, और customer से 1.50 SAR कटते हैं। Defect किसी एक component में नहीं, उनके बीच के interface में है।

ISTQB Foundation syllabus v4.0 integration के दो levels अलग करता है, component integration और system integration, जो नीचे समझाए गए हैं। दोनों component testing पर बनते हैं: अलग-अलग साबित हो चुके हिस्से अब जोड़े जाते हैं।

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

Interface वह जगह है जहाँ दो लोगों की assumptions मिलती हैं। जब agreement की उनकी समझ अलग हो (रियाल या हलाला, local time या UTC, गायब field या null), तो हर component test pass होता है और defect तभी दिखता है जब हिस्से साथ चलते हैं। Stub इसे शायद ही पकड़ता है, क्योंकि वह आम तौर पर उसी assumption से लिखा जाता है जिससे उसे call करने वाला code।

Product के लिए integration defects का मतलब है गलत charges, खोए orders और duplicate messages, जो अक्सर production में मिलते हैं क्योंकि external system को सिर्फ़ simulate किया गया था। Tester के लिए यहीं interface के दोनों पक्ष पढ़ने का फ़ायदा मिलता है।

Component integration और system integration

Integration tests interface पर ध्यान देते हैं: हिस्सों के बीच जाने वाले calls, messages और data, और दूसरा पक्ष fail हो तो क्या होता है, हर component के अंदर के logic पर नहीं। Test basis वह सब है जो interface को describe करता है: API specification जैसे OpenAPI document, message formats, sequence diagrams।

  • Component integration testing: एक system के components के बीच के interfaces, जैसे order service का inventory component को call करना। आम तौर पर developers इसे continuous integration pipeline में automate करते हैं।
  • System integration testing: दूसरे systems और external services के साथ interfaces, जैसे payment gateway या SMS provider। आम तौर पर testers इसे lead करते हैं; इसके लिए production जैसा environment, दूसरे पक्ष से sandbox, और ऐसी team के साथ coordination चाहिए जिस पर आपका नियंत्रण नहीं।

Big-bang या incremental: top-down, bottom-up, stubs और drivers

Big-bang integration में सारे components एक साथ जोड़े और साथ टेस्ट किए जाते हैं। किसी stand-in की ज़रूरत नहीं, लेकिन testing तभी शुरू होती है जब हर हिस्सा तैयार हो, और कोई test fail हो तो वजह किसी भी interface में हो सकती है। बहुत छोटे system में यह ठीक है; बड़े system में fail होने वाला interface ढूँढने में testing से ज़्यादा समय लग सकता है।

Incremental integration एक बार में एक या कुछ components जोड़ता है और अगले से पहले हर नया interface टेस्ट करता है, इसलिए fail होने पर पहला शक अभी जोड़े गए interface पर जाता है। गायब हिस्सों की जगह stand-ins लगते हैं, जिन्हें आप component testing में देख चुके हैं। Stub call किए जाने वाले component की जगह लेता है और पहले से तय जवाब लौटाता है। Driver call करने वाले component की जगह लेता है: एक test script या API client जो component under test को वैसे call करता है जैसे गायब caller करता।

  • Top-down: ऊपर से शुरू करें (API endpoint या user interface), नीचे के components की जगह stubs रखें, और उन्हें एक-एक करके बदलें। Main flow जल्दी दिखता है; calculations और data access सबसे बाद में टेस्ट होते हैं, और realistic data लौटाने वाले stubs जटिल हो सकते हैं।
  • Bottom-up: सबसे निचले components (calculations, data access, external services के clients) से शुरू करें, जिन्हें drivers call करते हैं, और ऊपर बढ़ें। Foundations जल्दी टेस्ट होते हैं और failure की जगह ढूँढना आसान है; पूरा flow सिर्फ़ आख़िर में दिखता है।
  • कई teams दोनों को मिलाकर बीच में मिलती हैं, जिसे sandwich या hybrid integration कहते हैं।
Big-bang checkout के सारे components एक साथ जोड़ता है, इसलिए fail हुआ test किसी भी interface की ओर इशारा कर सकता है; top-down ऊपर से stubs बदलता है, bottom-up नीचे से drivers, एक बार में एक interface। वैचारिक मॉडल

Big-bang

  1. 1हर component बना और अकेले टेस्ट हुआ
  2. 2सब एक ही step में जोड़े गएcheckout-api से payment-client तक
  3. 3एक test fail होता हैवजह किसी भी interface में हो सकती हैफ़ेल
ज़रूरी stand-ins:
कोई नहीं
Testing कब शुरू:
जब हर हिस्सा तैयार हो
Failure किस ओर इशारा करता है:
किसी भी interface की ओर
जल्दी दिखता है · बाद में टेस्ट होता है:
जल्दी कुछ नहीं; सब कुछ आख़िर में

Top-downincremental

  1. 1checkout-api से शुरुआतorder-service की जगह stub
  2. 2असली order-service अपने stub की जगह लेता हैउसके नीचे के components के लिए stubs
  3. 3असली निचले components आख़िरी stubs की जगह लेते हैं
ज़रूरी stand-ins:
Stubs, call किए जाने वाले components की जगह
Testing कब शुरू:
जैसे ही ऊपर की layer बने
Failure किस ओर इशारा करता है:
पहले अभी जोड़ा गया interface
जल्दी दिखता है · बाद में टेस्ट होता है:
जल्दी: main flow · बाद में: calculations और data access

Bottom-upincremental

  1. 1Drivers सबसे निचले components को call करते हैंprice-calculator, inventory, payment-client
  2. 2एक driver order-service को call करता हैअब असली निचले components के साथ
  3. 3checkout-api driver की जगह लेता है
ज़रूरी stand-ins:
Drivers, call करने वालों की जगह
Testing कब शुरू:
जैसे ही सबसे निचले components बनें
Failure किस ओर इशारा करता है:
पहले अभी जोड़ा गया interface
जल्दी दिखता है · बाद में टेस्ट होता है:
जल्दी: foundations · बाद में: पूरा flow

आज़माएँ: Mock API रिस्पॉन्स जनरेटर आज़माएँ: API रिक्वेस्ट बिल्डर

Interface defects: क्या ढूँढें

Interface defects दो ऐसे पक्षों से आते हैं जो आपस में सहमत नहीं, या ऐसे पक्ष से जो दूसरे के fail होने को संभाल नहीं पाता। पहली practical जाँच यह है कि हर पक्ष की असली requests और responses की तुलना agreed specification, जैसे OpenAPI document, से करें: कोई भी अंतर बताता है कि कौन-सा पक्ष agreement से हटता है। फिर हर interface से ये सवाल पूछें:

  • Format और encoding: 01/02/2026 1 फ़रवरी है या 2 जनवरी? क्या Arabic नाम सही-सलामत पहुँचते हैं?
  • Units और अर्थ: रियाल या हलाला, seconds या milliseconds, local time या UTC, VAT सहित या बिना VAT का price।
  • Structure: गायब, rename हुआ या extra field; null बनाम field का न होना; अलग enum values (CANCELLED, CANCELED); दोनों पक्षों पर अलग length limits।
  • क्रम और timing: गलत क्रम में calls, अपने record के save होने से पहले आने वाला callback, दूसरे पक्ष के सामान्य response time से छोटा timeout।
  • Failure handling: जब दूसरा पक्ष down हो, slow हो, 500 या अनपेक्षित error body लौटाए, या दो बार जवाब दे, तो क्या caller सुरक्षित तरीके से retry करता है, दो बार charge करने से बचता है और data consistent रखता है?

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

Worked example: checkout का integration

एक online shop के checkout में पाँच components हैं और वह एक external system को call करता है, जैसा नीचे के plan में है। Team bottom-up integrate करती है: checkout API सबसे बाद में लिखी जाती है, और gateway का sandbox account अभी तैयार हो रहा है, इसलिए steps 1 से 3 में gateway की जगह एक stub है।

यह stub payment client के अपने code से लिखा गया था, इसलिए वह कोई भी amount स्वीकार करता था, और steps 1 से 3 के सारे tests pass हुए। Step 4 वही tests असली sandbox पर चलाता है:

  • 150.00 SAR के order पर 1.50 SAR का charge बनता है: gateway पूरे हलालों में amount चाहता है, और JSON में 150.00 बस number 150 है। Defect report interface (payment-client से gateway), request और response बताती है।
  • Step 4 वह भी cover करता है जो सिर्फ़ असली system दिखाता है: उसके असली decline codes, timeouts और retries पर उसका व्यवहार (सिर्फ़ एक charge), और उसका callback कब पहुँचता है।
checkout-api               POST /checkout                          (top)
└── order-service          placeOrder(cart)
    ├── price-calculator   total(cart): SAR, 2 decimals
    ├── inventory          reserve(sku, qty), release(sku, qty)
    └── payment-client     charge(amount, currency)
            └──► payment gateway                        (external system)

Integration order: bottom-up
  1  drivers → price-calculator, inventory, payment-client   gateway: stub
  2  driver → order-service + the components from step 1    gateway: stub
  3  checkout-api replaces the driver                       gateway: stub
  4  the same tests, against the gateway sandbox            system integration

आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर

आम गलतियाँ

  • Interface की जगह हर component के business rules दोबारा टेस्ट करना, जबकि देखना यह है: भेजा गया data, calls का क्रम, failures की handling।
  • Agreed specification की जगह caller की अपनी assumptions से बने stub पर भरोसा करना, और असली system पर कभी टेस्ट न करना।
  • बड़े system को big-bang तरीके से integrate करना, फिर दिनों तक ढूँढना कि कौन-सा interface fail हुआ।
  • सिर्फ़ happy path टेस्ट करना: timeout, rejected request, error body या duplicate callback कभी नहीं।
  • External sandbox का access देर से माँगना, जिससे system integration release से पहले के आख़िरी दिनों में ठुँस जाती है।
  • यह मान लेना कि "integration test" का मतलब सबके लिए एक है। पूछें कि कौन-से हिस्से असली हैं और कौन-से replace किए गए।

QA का नज़रिया

Tester का integration काम तभी शुरू हो जाता है जब interfaces design होते हैं। Refinement के दौरान API specification और sequence diagrams पढ़ें, और दोनों पक्षों से वही सवाल पूछें: units और formats, ज़रूरी fields, error codes, timeouts, retries। तब सुलझा मतभेद कभी defect नहीं बनता।

Component integration tests आम तौर पर developers automate करते हैं; review करें कि वे कौन-से interfaces और error paths cover करते हैं। System integration आम तौर पर testers lead करते हैं: external पक्ष के साथ sandbox access और test data जल्दी तय करें, और पता करें कि sandbox production से कहाँ अलग है। जब कोई integration test fail हो, तो report में interface का नाम, exact request और response, और कौन-सा पक्ष specification से हटता है, यह लिखा हो।

अभ्यास

Appointment reminder के integration testing की योजना बनाएँ

आपका काम

एक clinic app हर appointment से 24 घंटे पहले SMS reminder भेजता है; उसके हिस्से नीचे दिए हैं। Booking API अभी लिखी जा रही है, और SMS provider का sandbox दो हफ़्ते बाद तैयार होगा। Integration testing की योजना बनाएँ।

सामग्री
booking-api                  POST /appointments                     (top)
└── appointment-service      book(patient, slot), cancel(id), sendDueReminders(now)
    ├── schedule-repository  save(appointment), findDue(now)
    └── sms-client           send(phone, text, sendAt)
            └──► SMS provider  POST /v1/messages           (external system)

Clinic data: phone numbers as typed by staff (e.g. 05XXXXXXXX),
             appointment times in Riyadh time (UTC+3)

send(phone, text, sendAt)
  phone    international format (E.164), e.g. +9665XXXXXXXX
  text     reminder text, Arabic or English
  sendAt   ISO 8601 date-time, UTC

SMS provider responses
  202 {"id": "msg-123", "status": "queued"}
  400 invalid number    429 too many requests    503 unavailable
चरण
  1. हर interface को component integration या system integration के रूप में चिह्नित करें।
  2. Integration order चुनें और उसके लिए ज़रूरी stubs और drivers की list बनाएँ।
  3. Reminder path के लिए पाँच integration test conditions लिखें, और हर एक में वह interface defect बताएँ जिसे वह target करती है।
  4. असली provider पर क्या जाँचना बाकी है, उसकी list बनाएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Component integration: booking-api → appointment-service, appointment-service → schedule-repository, appointment-service → sms-client। System integration: sms-client → SMS provider।

Bottom-up, क्योंकि ऊपर की layer तैयार नहीं: schedule-repository और sms-client integrate करें, फिर appointment-service। एक driver (test script या API client) book और cancel को call करता है जब तक booking-api उसकी जगह न ले ले, और sendDueReminders को अपनी चुनी हुई now value के साथ call करता है, जिससे time वाली conditions दोहराने लायक बनती हैं। SMS provider की भूमिका एक stub निभाता है, जो 202, 400, 429, 503 और एक slow जवाब लौटाता है।

Conditions: (1) Riyadh time में 10:00 का appointment पिछले दिन 07:00 UTC का sendAt देता है (time zone); (2) 05XXXXXXXX को +9665XXXXXXXX के रूप में भेजा जाता है, prefix कभी दो बार नहीं लगता (format); (3) Arabic reminder पढ़ने लायक पहुँचता है (encoding); (4) 503 या timeout पर appointment बना रहता है और बाद में retry होता है, सिर्फ़ एक SMS के साथ (failure handling); (5) sendAt से पहले cancel करने पर कोई reminder नहीं जाता (क्रम और timing)।

असली provider पर: क्या उसके responses वही हैं जो stub ने लौटाए (status codes और body fields), क्या वह sendAt को UTC में पढ़ता है, sender name, असली rate limit, Arabic text के लिए message length कैसे गिनी जाती है, और क्या sandbox errors वैसे ही लौटाता है जैसे production।

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

क्या integration testing और end-to-end testing एक ही हैं?

नहीं। Integration testing खास interfaces को target करती है: दो components, या आपका system और कोई दूसरा system। End-to-end test पूरे system में एक complete user journey का पीछा करता है और एक साथ कई interfaces पार करता है। वह integration defects दिखा सकता है, लेकिन धीमा है और fail होने वाला interface ढूँढना मुश्किल कर देता है। System testing और end-to-end testing अगले lessons में आते हैं।

Integration testing कौन करता है, developers या testers?

आम तौर पर developers component integration tests automate करते हैं, और testers system integration testing lead करते हैं, अक्सर external पक्ष के साथ मिलकर। Teams में यह अलग-अलग होता है, इसलिए इसे साफ़ तय करें; दोनों हालात में tester review करता है कि कौन-से interfaces cover हैं और क्या error paths टेस्ट हुए।

Developers असली database वाले test को integration test कहते हैं। क्या यह सही है?

कई teams इस term को इसी अर्थ में इस्तेमाल करती हैं: कोई भी automated test जो एक unit से आगे जाए, जैसे अपने असली database के साथ एक service, या एक असली HTTP call। यह broad definition, यानी हिस्सों के बीच interaction, में फिट बैठता है। जब कोई "integration test" कहे, तो पूछें कि कौन-से हिस्से असली हैं और कौन-से replace किए गए; इससे पता चलता है कि test क्या पकड़ सकता है और क्या नहीं।

Continuous integration का integration testing से क्या संबंध है?

Continuous integration एक development practice है: developers छोटे बदलाव अक्सर main line में merge करते हैं, और हर merge automatically build और टेस्ट होता है। इससे हर integration step छोटा रहता है, और integration tests आम तौर पर उसी pipeline में चलते हैं। लेकिन यह external systems के साथ system integration testing की जगह नहीं लेता, जिसे अपना environment चाहिए।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018ऑटोमेटेड टेस्ट पोर्टफ़ोलियो में unit, integration, contract और UI टेस्ट का संतुलन कैसे रखें — व्यापक रूप से उद्धृत व्याख्या।
  • Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
टूल्स

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

API स्टेटस कोड सिम्युलेटर

ऐसा सार्वजनिक endpoint पाएँ जो कोई भी HTTP स्टेटस कोड लौटाए, वैकल्पिक देरी और कस्टम JSON बॉडी के साथ, ताकि क्लाइंट की error हैंडलिंग टेस्ट हो सके।

API टेस्टिंग

API कॉन्ट्रैक्ट वैलिडेटर

जाँचें कि कोई API रिक्वेस्ट/रिस्पॉन्स जोड़ा अपने OpenAPI कॉन्ट्रैक्ट का पालन करता है या नहीं: path, method, पैरामीटर, बॉडी और रिस्पॉन्स स्कीमा।

वैलिडेशन

API रिक्वेस्ट बिल्डर

HTTP रिक्वेस्ट (method, URL, हेडर, auth, बॉडी) बनाएँ और भेजें, फिर रिस्पॉन्स जाँचें — आपके ब्राउज़र में हल्का-फुल्का Postman।

API टेस्टिंग

और गहराई से

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

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