मॉड्यूल 12 · वेब एप्लिकेशन टेस्टिंग

क्रॉस-ब्राउज़र और क्रॉस-डिवाइस टेस्टिंग

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

Cross-browser testing जाँचती है कि web application उन browsers में सही काम करे जो उसके यूज़र्स असल में इस्तेमाल करते हैं। Cross-device testing यही जाँच devices तक ले जाती है: phones, tablets और computers, जिनके operating system, screen, input method और hardware अलग होते हैं। Windows laptop पर Chrome में ठीक चलने वाला checkout पुराने iPhone पर Safari में टूटा हुआ order summary दिखा सकता है, या fee की ऐसी explanation जिसे phone पर कोई खोल ही न सके।

कोई भी हर device पर हर browser टेस्ट नहीं कर सकता, इसलिए असली skill चुनने में है: browsers को engine के हिसाब से group करना, usage data को support matrix में बदलना, और तय करना कि हर टेस्ट कहाँ चलेगा।

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

Browsers एक ही web standards को अलग code से, अलग रफ़्तार से और अलग defaults के साथ implement करते हैं। जो CSS rule, form control या JavaScript API एक engine में चलता है, वह दूसरे में ग़ायब हो सकता है या अलग व्यवहार कर सकता है, और failure सिर्फ़ उसी browser के यूज़र्स तक पहुँचता है: ग्राहकों का पूरा group कोई काम पूरा नहीं कर पाता, जबकि office के हर browser में सब ठीक दिखता है।

कम टेस्टिंग सबसे ज़्यादा इस्तेमाल होने वाले phone browser को बिना जाँचे छोड़ देती है; हर जगह सब कुछ टेस्ट करना कम फ़ायदे में मेहनत कई गुना कर देता है। Data पर आधारित, documented चुनाव से tester साफ़ बता सकता है कि क्या टेस्ट हुआ, कहाँ हुआ और कौन-सा risk बाक़ी है।

Browsers और devices के बीच क्या बदलता है

Responsive testing वाले lesson ने पूछा था कि layout viewport के साइज़ के हिसाब से ढलता है या नहीं। यहाँ सवाल अलग है: क्या वही page दूसरे engine में, दूसरे operating system पर, दूसरे input method के साथ सही व्यवहार करता है? आप मौजूदा critical journeys, जैसे sign-in, search और checkout, हर environment में चलाते हैं और इन फ़र्कों पर नज़र रखते हैं:

  • Engine और version: HTML और CSS कैसे render होते हैं, और कौन-से CSS features और JavaScript APIs मौजूद हैं।
  • Operating system: installed fonts (Arabic और Devanagari के लिए अहम), native date pickers और select lists, file और permission dialogs।
  • Input: touch, mouse या keyboard। जो menu सिर्फ़ hover पर खुलता है, उसका touch screen पर कोई भरोसेमंद trigger नहीं।
  • Device और settings: आधा page ढकने वाला on-screen keyboard, दिखते-छिपते toolbars, धीमा budget phone, zoom, dark mode और blocked third-party cookies।

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

Browser engines: browser के नाम नहीं, engines गिनें

Browser engine browser का वह हिस्सा है जो HTML, CSS और JavaScript को आपको दिखने वाले page में बदलता है। ज़्यादातर यूज़र्स के browsers तीन engine families में आ जाते हैं: Blink, जो Chrome, Microsoft Edge, Opera, Samsung Internet और Chromium पर बने दूसरे browsers में है (Chromium वह open-source code base है जिस पर Chrome बना है); Gecko, जो Firefox में है; और WebKit, जो Safari में है। हर family का अपना JavaScript engine भी है: V8, SpiderMonkey और JavaScriptCore।

इससे coverage गिनने का तरीका बदलता है। Windows पर Chrome और Edge दोनों Blink इस्तेमाल करते हैं, इसलिए rendering defect आम तौर पर दोनों में दिखता है; दूसरा browser engine coverage में थोड़ा ही जोड़ता है, हालाँकि उसकी अपनी autofill और privacy settings होती हैं। iPhone और iPad पर Apple लंबे समय से browsers के लिए WebKit ज़रूरी करता आया है और दूसरे engines की इजाज़त सिर्फ़ कुछ regions में देता है, इसलिए iPhone पर Chrome आम तौर पर Safari जैसा व्यवहार करता है, Android वाले Chrome जैसा नहीं।

Versions भी मायने रखते हैं: iPhone पर Safari सिर्फ़ iOS के साथ update होता है, इसलिए जो iPhone latest iOS install नहीं कर सकता, वह पुराने Safari पर रहता है। Team किसी नए CSS या JavaScript feature पर निर्भर हो, उससे पहले उस feature के MDN page पर browser compatibility table देखें।

Bug report करने वाले का browser User-Agent request header से पढ़ा जा सकता है, पर सावधानी से: उदाहरण के लिए iOS पर Chrome ख़ुद को CriOS से पहचानता है, लेकिन page WebKit से render करता है।

आज़माएँ: User-Agent पार्सर आज़माएँ: रिक्वेस्ट हेडर इंस्पेक्टर

Support matrix: usage data से tiers तक

Support matrix browser, operating system और device के उन combinations की तय सूची है जिन्हें product support करता है, साथ में यह कि हर combination को कितनी गहराई से टेस्ट किया जाएगा। इसकी जगह test plan में है, और product, development और QA इसे मिलकर तय करते हैं, क्योंकि यह यूज़र्स से किया गया वादा भी है।

इसे evidence से बनाएँ, team के पास संयोग से जो devices हैं उनसे नहीं: ऐसे analytics जो sessions के साथ orders जैसे पूरे हुए काम भी गिनें, contract में लिखे browsers, और वे combinations जिनसे incidents हुए हों। फिर rows को tiers में बाँटें:

  • Tier 1: ज़्यादातर traffic या revenue। हर release पर critical journeys और regression set, असली devices पर।
  • Tier 2: छोटे पर अहम combinations। हर release पर critical journeys का smoke set।
  • Tier 3: best effort। बड़ी releases से पहले या किसी यूज़र की शिकायत पर जाँचे जाते हैं।
  • Engine rule: आपके यूज़र्स के हर engine को Tier 2 या उससे ऊपर कम से कम एक combination मिले, share कितना भी छोटा हो, क्योंकि वह ऐसे defects दिखा सकता है जो matrix का कोई दूसरा browser नहीं दिखा सकता।
  • Pairwise rule: language, account state, zoom और dark mode भी engine के साथ interact करते हैं। किसी tier के platforms तय रखें और बाक़ी parameters को pairwise selection से मिलाएँ, जैसा pairwise testing वाले lesson में है।
  • तय करें कि unsupported browser के यूज़र्स क्या देखेंगे, जैसे टूटे page की जगह साफ़ message, और matrix की नियमित समीक्षा करें, जैसे हर तिमाही।

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

टेस्ट कहाँ चलाएँ: local browsers, emulators और cloud device labs

Desktop browsers local install हो सकते हैं, कुछ सीमाओं के साथ: Safari सिर्फ़ Apple computers पर चलता है, और iOS Simulator के लिए Xcode वाला Mac चाहिए। DevTools का device toolbar viewport बदलता है, engine नहीं। Android emulators और iOS Simulator असली hardware के बिना mobile browsers चलाते हैं, इसलिए touch, on-screen keyboard, camera और budget phone की रफ़्तार के लिए असली devices चाहिए।

Cloud device labs, जिन्हें device farms भी कहते हैं, किसी provider के host किए असली phones, tablets और desktop browsers किराए पर देते हैं। आप इन्हें अपने browser से manual sessions के लिए खोलते हैं या इन पर automated suites चलाते हैं, और screenshots, videos और logs record होते हैं। ये devices ख़रीदे बिना बड़ी coverage देते हैं, पर इनकी सीमाओं के लिए पहले से योजना बनाएँ:

  • जो test environment public नहीं है, उसके लिए lab की secure tunnel चाहिए, यानी ऐसा connection जिससे lab के devices आपके private network तक पहुँच सकें, या lab के addresses की allow-list, environment की मालिक team से तय करके।
  • Devices shared होते हैं और sessions के बीच reset होते हैं: test accounts और synthetic data इस्तेमाल करें, असली customer data या personal accounts कभी नहीं।
  • Network, location और speed lab के होते हैं, आपके यूज़र्स के नहीं, इसलिए वहाँ performance पर फ़ैसला न करें।
  • Plans minutes और parallel sessions सीमित करते हैं: पूरे suites Tier 1 पर और smoke sets Tier 2 पर चलाएँ।

Worked example: एक online shop का support matrix

एक online shop सऊदी अरब में Arabic और English में ग्राहकों को सेवा देता है। Team पिछले 90 दिनों का analytics export करती है, हर row में engine जोड़ती है और अपना tier rule लगाती है: sessions या orders का 10% या ज़्यादा Tier 1, 2% या ज़्यादा लेकिन 10% से कम Tier 2, और 2% से कम Tier 3। Numbers illustrative हैं।

Safari · iOS, Chrome · Android और Chrome · Windows Tier 1 बनते हैं। Chrome · iOS, Safari के साथ WebKit share करने के बावजूद Tier 2 में रहता है, क्योंकि उसका toolbar और autofill अलग हैं। Firefox अकेला Gecko browser है और कहीं भी उसका हिस्सा 1% से ज़्यादा नहीं, इसलिए engine rule उसके सबसे बड़े combination, Firefox · Windows, को Tier 2 में उठा देता है। Tier 1 के लिए pairwise selection तीनों platforms को language (Arabic, English) और account (guest, signed in) से मिलाता है: हर value pair 12 की जगह 6 runs में।

एक shop का support matrix: तीन combinations Tier 1 में हैं, iOS पर हर browser WebKit से render करता है, और सबसे बड़ा Gecko combination होने के कारण Windows पर Firefox को Tier 2 में उठाया गया है।
BrowserOperating system
WindowsmacOSAndroidiOSहर browser: WebKit
ChromeBlink; iOS पर WebKitTier 1Blink · 12% · 14%Tier 3Blink · <1%Tier 1Blink · 27% · 22%Tier 2WebKit · 4% · 4%
SafariWebKitmatrix में नहीं: ऐसा browser नहीं या कोई sessions नहींTier 2WebKit · 3% · 4%matrix में नहीं: ऐसा browser नहीं या कोई sessions नहींTier 1WebKit · 38% · 41%
EdgeBlink; iOS पर WebKitTier 2Blink · 5% · 7%Tier 3Blink · <1%Tier 3Blink · <1%Tier 3WebKit · <1%
Samsung InternetBlinkmatrix में नहीं: ऐसा browser नहीं या कोई sessions नहींmatrix में नहीं: ऐसा browser नहीं या कोई sessions नहींTier 2Blink · 7% · 5%matrix में नहीं: ऐसा browser नहीं या कोई sessions नहीं
FirefoxGecko; iOS पर WebKitTier 2Gecko · 1% · 1%Tier 3Gecko · <1%Tier 3Gecko · <1%Tier 3WebKit · <1%
  • Tier 1: हर release पर असली devices पर critical journeys और regression set
  • Tier 2: हर release पर critical journeys का smoke set
  • Tier 3: best effort, बड़ी releases से पहले या यूज़र की शिकायत पर
  • Engine rule ने Tier 3 से उठाया: सबसे बड़ा Gecko combination
  • WebKit · 38% · 41%engine · sessions का हिस्सा · orders का हिस्सा

एक shop के पिछले 90 दिनों के analytics के illustrative numbers। अपना matrix अपने data से बनाएँ।

  • सिर्फ़ WebKit: जिन iPhones को पुराने iOS से आगे update नहीं किया जा सकता, उन पर order summary का layout बिगड़ जाता है, क्योंकि वह ऐसा CSS feature इस्तेमाल करता है जो पुराने Safari versions में नहीं है। उसी iPhone पर Chrome भी वैसे ही fail होता है: engine का एक defect, दो browsers के दो defects नहीं।
  • सिर्फ़ Edge: autofill district को street field में भर देता है, क्योंकि address fields में autocomplete attributes नहीं हैं। Chrome सही अंदाज़ा लगाता है; वजह form है, जिसे एक browser के feature ने उजागर किया।
  • हर touch device: delivery fee की explanation सिर्फ़ mouse hover पर खुलती है, इसलिए phone यूज़र्स उसे नहीं खोल पाते। कोई desktop run इसे नहीं पकड़ सकता था।
पाठ संस्करण
Online shop — last 90 days (illustrative numbers)

Browser · OS                  Engine   Sessions  Orders  Tier
Safari · iOS                  WebKit      38%      41%   1
Chrome · Android              Blink       27%      22%   1
Chrome · Windows              Blink       12%      14%   1
Samsung Internet · Android    Blink        7%       5%   2
Edge · Windows                Blink        5%       7%   2
Chrome · iOS                  WebKit       4%       4%   2
Safari · macOS                WebKit       3%       4%   2
Firefox · Windows             Gecko        1%       1%   2 (engine rule)
Other, each below 1%          mixed        3%       2%   3
  Chrome · macOS, Edge · macOS / Android / iOS,
  Firefox · macOS / Android / iOS

Tier rule: 10% or more of sessions or orders → 1; 2% up to 10% → 2; under 2% → 3

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

आम गलतियाँ

  • Engines की जगह browser के नाम गिनना: Windows पर Chrome, Edge और Opera तीन browsers हैं पर engine एक, और कोई WebKit browser टेस्ट ही नहीं हुआ।
  • DevTools device toolbar या संकरी desktop window में देखकर page को "iPhone पर टेस्टेड" कहना।
  • Matrix analytics की जगह team के अपने devices से बनाना, या उसकी कभी समीक्षा न करना।
  • Tiers और pairwise selection की जगह हर combination पर पूरा regression suite चलाना।
  • Browser, version, operating system और device लिखे बिना, और उसी engine वाला दूसरा browser आज़माए बिना "mobile पर नहीं चलता" report करना।
  • Shared cloud lab devices पर असली customer data या personal accounts इस्तेमाल करना।

QA का नज़रिया

Support matrix test planning के दौरान product owner, developers और analytics के मालिक के साथ तय होता है। जल्दी पूछें: contract किन browsers का वादा करता है? Unsupported browser के यूज़र को क्या दिखना चाहिए? क्या कोई planned feature नए CSS या JavaScript पर निर्भर है जिसके लिए compatibility check चाहिए?

Execution के दौरान हर feature Tier 1 से शुरू करें, फिर Tier 2 और 3 पर जाएँ। कुछ fail हो तो उसे उसी engine वाले दूसरे browser में और अलग engine वाले browser में reproduce करें, ताकि report कह सके "सिर्फ़ WebKit" या "हर touch device"। Bug report में browser और version, engine, operating system, device model, language और account लिखें, और test completion report में matrix का version।

अभ्यास

Clinic booking site के लिए browser coverage plan करें

आपका काम

एक clinic booking site guests और signed-in यूज़र्स को Arabic या English में clinic visit और video consultation book करने देती है। नीचे दिए analytics और worked example के tier rule से उसका support matrix बनाएँ, Tier 1 platforms को बाक़ी parameters से pairwise selection द्वारा मिलाएँ, और तय करें कि हर tier कहाँ चलेगा।

सामग्री
Clinic booking site — last 90 days (illustrative numbers)

Browser · OS                  Sessions   Bookings
Chrome · Android                 41%        36%
Safari · iOS                     30%        33%
Chrome · Windows                 14%        17%
Edge · Windows                    6%         7%
Samsung Internet · Android        5%         3%
Firefox · Windows                 1%         1%
Other, each below 1%              3%         3%
चरण
  1. हर row में engine जोड़ें।
  2. हर row को tier दें, फिर engine rule लगाएँ।
  3. Pairwise set बनाएँ: Tier 1 platform × language × account × booking type।
  4. तय करें कि हर tier कहाँ चलेगा, और product owner के लिए अपने सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Engines: Android पर Chrome, Windows पर Chrome, Edge और Samsung Internet Blink इस्तेमाल करते हैं; iOS पर Safari WebKit; Firefox Gecko। Tier 1: Chrome · Android, Safari · iOS, Chrome · Windows। Tier 2: Edge · Windows, Samsung Internet · Android, और Firefox · Windows, जिसे engine rule ने ऊपर उठाया क्योंकि Firefox अकेला Gecko browser है। बाक़ी Tier 3 में रहते हैं।

Pairwise set, 24 की जगह 6 runs: (1) Chrome · Android, Arabic, guest, clinic; (2) Chrome · Android, English, signed in, video; (3) Safari · iOS, Arabic, signed in, video; (4) Safari · iOS, English, guest, clinic; (5) Chrome · Windows, Arabic, guest, video; (6) Chrome · Windows, English, signed in, clinic। Generator इसी साइज़ का कोई दूसरा set भी दे सकता है।

कहाँ: Tier 1 असली devices पर, क्योंकि video consultation को असली camera, microphone और permission prompts चाहिए। Tier 2: Windows computer पर Edge और Firefox, और Samsung Internet असली phone पर या test accounts के साथ cloud device lab में। Tier 3 बड़ी releases से पहले।

सवाल: Clinic किन browsers और iOS व Android के किन सबसे पुराने versions को support करने का वादा करती है? Unsupported browser पर मरीज़ क्या देखेगा? क्या video consultation हर Tier 2 browser में चलना ज़रूरी है?

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

क्या cross-browser testing और compatibility testing एक ही हैं?

कई teams दोनों शब्द एक ही अर्थ में इस्तेमाल करती हैं। लेकिन ISO/IEC 25010:2023 में compatibility का मतलब दूसरे systems के साथ co-existence और interoperability है, जबकि अलग hardware और software environments में सही चलना adaptability के तहत आता है, जो flexibility का हिस्सा है (2011 edition में इसे portability कहा जाता था)। नाम कुछ भी हो, टेस्ट वही है: वही journeys, उन environments में जाँची गईं जो आपके यूज़र्स के पास हैं।

क्या पुराने browser versions टेस्ट करने ज़रूरी हैं?

वे versions टेस्ट करें जिन्हें आपका matrix support करता है। Chrome, Edge और Firefox हर कुछ हफ़्तों में ख़ुद update होते हैं, इसलिए current version उनके ज़्यादातर यूज़र्स को cover करता है; managed company computers जैसे अपवादों के लिए analytics देखें। iPhone पर Safari का version iOS के version के साथ चलता है, इसलिए support होने वाला सबसे पुराना iOS version शामिल करें। कुछ teams यूज़र्स से पहले problems पकड़ने के लिए browsers के beta versions भी चलाती हैं।

Bug report करने वाले ने कौन-सा browser इस्तेमाल किया, यह कैसे पता करें?

पहले पूछें, फिर उसकी request का User-Agent header सावधानी से पढ़ें: लगभग हर browser इसे Mozilla/5.0 से शुरू करता है, Chromium browsers Safari भी लिखते हैं, iOS पर Chrome CriOS जोड़ता है, और operating system version अक्सर frozen या अस्पष्ट होता है: Android पर Chrome असली version और model कुछ भी हो, Android 10; K ही बताता है, और Windows 11 अब भी Windows 10 की तरह Windows NT 10.0 के रूप में दिखता है। User-Agent Parser string को browser, engine, operating system और device type में बाँट देता है।

क्या automation manual cross-browser checks की जगह ले सकता है?

आंशिक रूप से। Automated UI tests हर build पर Chromium, Firefox और WebKit में वही functional checks चला सकते हैं: Playwright तीनों engines के अपने builds चलाता है, और Selenium WebDriver installed browsers चलाता है। पर WebKit build ख़ुद Safari नहीं है, और test सिर्फ़ वही जाँचता है जो वह assert करता है; वह टेढ़ा layout या असुविधाजनक touch target नहीं पकड़ेगा। इसलिए Tier 1 और 2 पर छोटे manual या exploratory passes, और असली Safari पर कुछ runs रखें।

संदर्भ

  • 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सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • User-Agent header — MDNMDN Web Docs (Mozilla)User-Agent हेडर का फ़ॉर्मेट और प्रमुख ब्राउज़रों व क्रॉलरों द्वारा भेजी जाने वाली स्ट्रिंग।
  • Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
टूल्स

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

User-Agent पार्सर

User-Agent स्ट्रिंग से ब्राउज़र, वर्शन, इंजन, OS, डिवाइस टाइप और बॉट की पहचान करें।

वेब

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

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

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

और गहराई से

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

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