कम्पैटिबिलिटी टेस्टिंग

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

Compatibility defects systems के बीच रहते हैं, इसलिए कोई एक team उनकी मालिक नहीं होती। हर side अपने tests pass करती है: app valid JSON भेजती है, partner उसे accept करता है, और सिर्फ़ दोनों के साथ चलने पर order गलत date के साथ पहुँचता है। ये release के दिन इकट्ठे भी होते हैं, जब नया server हज़ारों ऐसे devices से मिलता है जो अभी भी पिछले महीने की app चला रहे हैं, पुराने shape के data से भरे accounts से, और ऐसे partners से जिन्होंने कुछ नहीं बदला।

Tester के लिए ख़तरा झूठी coverage है: fresh installation पर, mocks (नकली partner systems) के सामने, सबसे नए platform पर चलने वाला regression suite पूरा green हो सकता है जबकि असली users fail हो रहे हों। Product के compatibility relationships का नाम लेना, usage data से तय करना कि किन्हें test करें, और जो छोड़ा उसे लिखना, "यहाँ चलता है" को ऐसे statement में बदल देता है जिस पर team भरोसा कर सके।

ISO/IEC 25010 में compatibility

ISO/IEC 25010:2023 compatibility को इस degree के रूप में describe करता है कि product दूसरे products के साथ information exchange कर सके, या उनके साथ common environment और resources share करते हुए अपने functions कर सके, या दोनों। ISTQB Foundation syllabus compatibility को उन characteristics में गिनता है जिन्हें non-functional testing evaluate करती है। इसकी दो sub-characteristics, वह characteristic जिसमें platform support आता है, और versions के बीच का रिश्ता, हर एक अलग तरह के test की ओर ले जाता है:

• Interoperability: systems information exchange करते हैं और exchange की गई information इस्तेमाल कर पाते हैं। File पहुँच जाना काफ़ी नहीं; receiver को amounts, dates और codes उसी अर्थ में पढ़ने चाहिए जो sender का था।
• Co-existence: product दूसरे products के साथ environment और resources share करते हुए, उन्हें नुक़सान पहुँचाए बिना, अपने functions करता है। उसे अपने पड़ोसियों के बीच टिकना है और उन्हें तोड़ना नहीं है।
• Flexibility: adaptability दूसरे operating systems, browsers और devices पर चलना cover करती है; installability और replaceability product को install करना और नए version का पुराने की जगह लेना cover करती हैं, और upgrade testing यहीं आती है।
• Backward और forward compatibility: एक ही product के versions के बीच compatibility के लिए standard में अलग term नहीं है। Practice में यह versions के बीच interoperability है, जैसे पुरानी app का नए server से बात करना, साथ में replaceability।

Interoperability: सिर्फ़ sender नहीं, exchange test करें

Interoperability tests data को एक boundary के पार follow करते हैं और दोनों sides जाँचते हैं: क्या भेजा गया, क्या पहुँचा, और receiver ने उसके साथ क्या किया। पहले architecture diagram, integration settings और product के पास मौजूद keys से हर connected system की list बनाएँ; भूले हुए integrations ही बिना test रह जाते हैं। फिर चार तरह के exchange cover करें:

• Connected systems: अपने product में record बनाएँ और दूसरे system में field-by-field confirm करें: currency और decimals के साथ amounts, time zone के साथ dates, receiver के codes से map हुए status codes, सही-सलामत Arabic names। फिर unhappy paths: partner धीमा है, record reject करता है या उसे दो बार पाता है।
• Import और export formats: अपने exports उन programs में खोलें जो customers सच में इस्तेमाल करते हैं, और उन programs की बनाई files import करें। Encoding बदलें (byte order mark के साथ और बिना UTF-8), separator बदलें (RFC 4180 comma-separated CSV describe करता है, लेकिन decimal comma वाले regions में spreadsheet programs अक्सर semicolons लिखते हैं), date और number formats, quoted fields के अंदर line breaks, और एक खाली file।
• API और schema versions: पुराना और नया contract compare करें, जैसे OpenAPI description (API के endpoints और fields की machine-readable list) या response का JSON Schema (वे rules जो उसके fields को मानने हैं)। Optional field जोड़ना आम तौर पर safe है; field हटाना या rename करना, उसका type बदलना, optional request field को required बनाना या enumeration में नई value जोड़ना पहले से released clients को तोड़ सकता है। पिछले client की requests बिना बदले replay करें।
• Third-party integrations: payment, maps, sign-in और SMS providers अपने schedule पर बदलते हैं। Provider के sandbox (उसका test environment) में उस API version पर test करें जिसे आपका product pin करता है, उसका change log और deprecation notices पढ़ें, और जाँचें कि provider down होने पर आपका product क्या करता है।

Pharmacy order response, v1 (read by every released app)
{ "id": "A-1042", "total": 149.5, "deliveryDate": "2026-10-04" }

Pharmacy order response, v2 (proposed)
{ "id": "A-1042", "total": "149.50", "currency": "SAR",
  "delivery": { "date": "2026-10-04", "slot": "AM" } }

Change                        Effect on released clients
"currency" added              usually safe if clients ignore unknown fields
"total" number -> string      breaking: arithmetic and validation fail
"deliveryDate" moved          breaking: the field old clients read is gone

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

Co-existence: environment share करना

Co-existence tests product को उन चीज़ों के बगल में चलाते हैं जो सच में उसका device, browser या server share करती हैं, और दोनों दिशाएँ जाँचते हैं: आपका product चलता रहे, और उसके पड़ोसी भी। ये failures requirements में शायद ही लिखी होती हैं, इसलिए पड़ोसियों की list support tickets, error logs और company के standard device setup से लें:

• Shared resources: camera, microphone या audio output जिसे कोई दूसरी app इस्तेमाल कर रही है; file, port या printer जिसे कोई दूसरा program पकड़े है; कम storage या memory; दूसरी services के साथ shared database या message queue। आपका product इंतज़ार करे, समझाए या recover करे, और जो लिया उसे छोड़ दे।
• दूसरा software: आपकी files scan करता antivirus, network बदलता VPN, screen reader, और payment के बीच आने वाली phone call।
• Browser extensions: ad blockers अपनी filter lists से match करने वाले elements छिपा सकते हैं, जैसे ad-banner जैसी class वाला banner; password managers और translators icons डालते हैं या text दोबारा लिखते हैं; dark-mode extensions pages का रंग बदलते हैं। Users जिन extensions की शिकायत करते हैं, उनके साथ critical journeys अलग browser profile में test करें।
• Side-by-side versions: एक computer पर install दो versions, एक phone पर store build के बगल में test build, या दो tabs जिनमें से एक deployment के बाद भी पुरानी web app चला रहा है। Shared settings, files और local storage जाँचें, और यह भी कि link कौन सा version खोलता है।

Support policy, backward और forward compatibility

Users कभी एक साथ update नहीं करते। Release के दिन नया server हर installed app version से, सबसे पुराने supported operating system वाले devices से और पुराने versions के लिखे data से मिलता है। एक लिखी हुई support policy तय करती है कि इनमें से क्या चलना चाहिए: minimum operating system versions, browsers, server अभी भी कितने app versions serve करता है (अक्सर current और previous, यानी N और N-1) और कब तक, और unsupported user क्या देखता है, जैसे silent error की जगह साफ़ update prompt।

Backward compatibility का मतलब है कि नया version पुराने versions के बनाए data के साथ और अभी भी इस्तेमाल हो रहे पुराने clients के साथ काम करे। Forward compatibility इसका उल्टा है: पुराना version नए version का data संभाल ले, आम तौर पर अनजान fields को ignore करके; rollback इसी पर टिका है। Upgrade paths पुरानी दुनिया से test करें, सिर्फ़ clean installation से नहीं:

• पुराना data, नया code: realistic accounts (orders, saved addresses, आधा भरा form) के साथ upgrade करें और पुराने exports और bookmarks खोलें। सब कुछ मौजूद, सही और इस्तेमाल लायक़ रहना चाहिए।
• पुराने clients, नया server: हर supported client version को बिना बदले नए server के साथ चलाएँ, और पहले unsupported version में update prompt जाँचें।
• Settings migration: language, notification और accessibility settings, saved sign-in और preferences upgrade के बाद बचे रहने चाहिए, कई versions एक साथ लाँघने पर भी, जैसे 3.8 से सीधे 4.2।
• नया data, पुराना code: नए version से data save करें, फिर rollback करें या उसे पिछले client में खोलें; पुराने version को अनजान चीज़ ignore करनी चाहिए, न crash होना चाहिए, न उसे overwrite करना चाहिए।

आज़माएँ: JSON डिफ़

Worked example: usage data से एक coverage matrix

एक pharmacy chain website और Android व iOS apps से बेचती है। Release 4.2 order API बदलती है और delivery slot जोड़ती है; interoperability section वाले contract comparison के बाद team ने total को number ही रखा और deliveryDate भी रखा, ताकि released apps response पढ़ सकें। अलग-अलग lists की जगह tester एक compatibility coverage matrix बनाता है, जिसकी हर row evidence से आती है: 90 दिन के analytics, API log में client-version header, app stores के version statistics, integration list और support tickets। हर row को depth मिलती है, जो छोड़ा गया वह लिखा जाता है, और row के अंदर बाक़ी parameters, जैसे language और payment method, pairwise testing वाले lesson की तरह pairwise selection से जोड़े जाते हैं, ताकि values की हर pair कम से कम एक test में आए। Numbers illustrative हैं।

Platform rows पुराने काम को दोहराती नहीं, दोबारा इस्तेमाल करती हैं: responsive testing का lesson viewport widths और breakpoints देता है, cross-browser testing का lesson engines और support tiers देता है (Tier 1 पर हर release में critical journeys और regression set चलते हैं, Tier 2 पर critical journeys का smoke set, Tier 3 पर सिर्फ़ best-effort checks), और आगे mobile module में device fragmentation का lesson बताता है कि phones कैसे चुनें। यह matrix वह जोड़ता है जो वे lessons cover नहीं करते: client versions, connected systems, formats, पड़ोसी और upgrades, ताकि एक page बता सके कि क्या test हुआ, किसके सामने, और क्या छोड़ा गया। Plan से तीन defects मिले:

• पुराना client, नया server: app 4.1, जिससे 31% orders आते हैं, अपनी order request में नया deliverySlot field नहीं भेजती (response slot को delivery.slot में लौटाता है)। API 4.2 इस field को required मानता है और default लगाने की जगह 400 Bad Request लौटाता है, ठीक वही request-side break जिसकी चेतावनी interoperability section देता है। यह release रोक देता है।
• Interoperability: stock system को जाने वाला नया export dates को 04/10/2026 लिखता है, day पहले, और stock system उसे 10 April पढ़ता है। दोनों systems ने अपने tests pass किए; सिर्फ़ field-by-field check ने इसे पकड़ा।
• Co-existence: एक लोकप्रिय password-manager extension अपना icon sign-in page के show-password button के ऊपर रख देता है। अकेले कोई product ग़लत नहीं; team button खिसका देती है।

Release 4.2 compatibility coverage matrix (illustrative numbers, last 90 days)

Area          Row                                     Evidence          Depth
Platforms     Tiers 1 and 2, cross-browser plan       analytics         per tier
              Android: oldest supported, current      store statistics  critical journeys
              iOS: previous and current               store statistics  critical journeys
Clients       app 4.2 (new)                           -                 full regression
              app 4.1 (31% of orders)                 API client log    critical journeys
              app 4.0 and older (2%, unsupported)     API client log    update prompt
Interop       payment provider, pinned API version    integration list  pay, fail, refund
              stock system export (CSV)               integration list  field by field
              SMS provider                            integration list  send, outage
Co-existence  password-manager extension              support tickets   sign-in journey
Upgrade       4.0 and 4.1 to 4.2, real accounts       -                 data, settings
Rollback      4.2 data opened in app 4.1              -                 forward check
Left out (recorded in the test plan): Firefox on Android (0.3%), tablets in landscape

आज़माएँ: पेयरवाइज़ टेस्टिंग जनरेटर आज़माएँ: User-Agent पार्सर

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

संदर्भ

• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• OpenAPI SpecificationOpenAPI InitiativeREST API के वर्णन का मानक: पाथ, ऑपरेशन, पैरामीटर, स्कीमा, रिस्पॉन्स और सिक्योरिटी स्कीम।
• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) FilesIETF · 2005CSV के आम नियम: कॉमा सेपरेटर, CRLF लाइन एंड, और कॉमा, कोट या लाइन ब्रेक वाले फ़ील्ड की क्वोटिंग।