रेस्पॉन्सिव टेस्टिंग

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

जो layout सिर्फ़ design की widths पर चलता है, वह असली लोगों को निराश करता है: sticky footer के नीचे छिपा pay button, landscape में न खुलने वाला menu, आधी कटी price। जब user काम पूरा न कर सके, तो यह cosmetic नहीं, functional failure है।

W3C का accessibility standard WCAG 2.2 इसका एक हिस्सा testable बनाता है: 320 CSS pixels पर reflow (success criterion 1.4.10), 200% तक बड़ा हो सकने वाला text (1.4.4) और किसी एक orientation में बँधा न होना (1.3.4)।

Viewport और breakpoints: widths चुनना

Viewport वह जगह है जिसमें page का layout बनता है, और इसे CSS pixels में नापा जाता है। Mobile browsers इसका size <meta name="viewport" content="width=device-width, initial-scale=1"> से तय करते हैं; इस tag के बिना वे page को desktop जैसी width पर बनाकर छोटा कर देते हैं। Breakpoint वह width (कभी-कभी height) है जिस पर media query layout बदल देती है; media query ऐसे CSS rules हैं जो तभी लागू होते हैं जब min-width: 600px जैसी कोई शर्त सच हो। Breakpoints के बीच fluid layout viewport के साथ फैलता और सिकुड़ता है।

हर breakpoint दो layouts के बीच की boundary है, इसलिए एक layout की आख़िरी width और अगले layout की पहली width टेस्ट करें: एक pixel से गलत media query सिर्फ़ इन्हीं दो widths पर fail होती है। Boundary value analysis वाला lesson इस technique को विस्तार से समझाता है। Breakpoints को popular phones की list से नहीं, design system से या ख़ुद CSS से लें (उसमें @media खोजें; CSS Formatter minified stylesheet को पढ़ने लायक बना देता है), क्योंकि layout breakpoints पर ही बदलता है।

• सबसे छोटी supported width, आम तौर पर 320 CSS pixels।
• हर breakpoint के दोनों तरफ़: min-width: 600px के लिए 599 और 600, लेकिन max-width: 600px के लिए 600 और 601।
• हर range में धीरे-धीरे drag, क्योंकि fluid layouts breakpoints के बीच भी टूटते हैं, ज़्यादातर संकरे सिरे के पास।
• बहुत चौड़ी screen, जहाँ content को अपनी maximum width पर रुकना चाहिए, और कम heights, जैसे landscape में phone।

आज़माएँ: बाउंड्री वैल्यू जनरेटर आज़माएँ: CSS फ़ॉर्मेटर

Orientation, zoom और reflow

Phone घुमाने से viewport की width और height आपस में बदल जाती हैं: portrait में 360 CSS pixels की width landscape में 740 हो सकती है और काम के बीच में कोई breakpoint पार कर सकती है। WCAG का criterion 1.3.4 कहता है कि content एक orientation में बँधा न हो, जब तक कोई ख़ास orientation ज़रूरी न हो।

Computer पर browser zoom हर CSS pixel को बड़ा करता है, इसलिए viewport संकरा होता है: 1280 CSS pixels चौड़ी window 200% पर 640 और 400% पर 320 की होती है, और छोटी screen जैसी ही media queries चलती हैं। Criterion 1.4.4 कहता है कि text बिना content या function खोए 200% तक बड़ा हो सके; 1.4.10 कहता है कि 320 CSS pixels पर content दो दिशाओं में scroll किए बिना काम करे, सिवाय data tables और maps जैसे हिस्सों के। Phone पर pinch zoom page को दोबारा layout किए बिना सिर्फ़ बड़ा दिखाता है, इसलिए वह reflow टेस्ट नहीं करता।

• काम के बीच में screen घुमाएँ: typed text, filters, scroll position और खुले dialogs बचे रहने चाहिए।
• Browser की font-size setting से सिर्फ़ text बड़ा करें, ताकि labels काटने वाले fixed-height boxes सामने आएँ।
• Viewport tag में user-scalable=no, या 2 से कम maximum-scale जैसे maximum-scale=1, report करें: ये लोगों को page बड़ा करने से रोकने की कोशिश करते हैं, जिससे page criterion 1.4.4 में fail होता है।

Worked example: product list का test plan

एक shop की product list 600 CSS pixels से कम पर एक column और menu button, 600 से दो columns, 1024 से चार columns और पूरा menu bar दिखाती है, और content कभी 1200 से ज़्यादा चौड़ा नहीं होता। CSS mobile-first है, @media (min-width: 600px) और @media (min-width: 1024px), इसलिए 600 और 1024 हर नए layout की पहली widths हैं।

Tester नीचे वाला plan device toolbar में चलाता है, फिर add-to-basket flow एक real Android phone और एक real iPhone पर दोहराता है। दो defects मिलते हैं: 600 से 680 pixels तक "Add to basket" label कट जाता है, और phone घुमाने पर चुने हुए filters साफ़ हो जाते हैं। दूसरे defect की report plan के बाद है।

• 320 × 640: minimum और reflow width; एक column, कोई sideways scrolling नहीं।
• 599 और 600, 1023 और 1024: हर breakpoint के दोनों तरफ़, साथ में हर range में धीमा drag।
• 1920 × 1080: content 1200 pixels पर रुका हुआ, बीच में।
• Filter करते हुए 360 × 740 को घुमाकर 740 × 360: दो columns, filters और scroll position बचे हुए।
• 1280 pixels की window 200% और 400% पर: पहले दो columns, फिर एक, और हर function पहुँच में।

Title:    Product list: phone घुमाने के बाद चुने हुए filters साफ़ हो जाते हैं
Where:    /products, build 3.8.0, staging पर
Device:   real Android phone, Chrome; device toolbar में भी, 360 x 740 से 740 x 360
Steps:    1. Product list portrait में खोलें (viewport 360 x 740)
          2. Filters "Size 42" और "Colour: black" चुनें
          3. Phone को landscape में घुमाएँ (viewport 740 x 360)
Expected: 2-column layout, दोनों filters चुने हुए, list filtered
Actual:   2-column layout, filters साफ़, पूरी unfiltered list दिखती है
Notes:    Desktop window को 600 px के आर-पार resize करने पर भी होता है, इसलिए
          यह device से नहीं, breakpoint से जुड़ा है। Width 600 के एक ही तरफ़
          रहे तो कुछ नहीं खोता।

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

Device toolbar क्या बता सकता है और क्या नहीं

इस sweep के लिए device toolbar सही tool है: exact sizes लिखें या किसी range में drag करें, rotate करें, और Chrome में media queries को page के ऊपर bars के रूप में देखें। Device preset उस phone का user agent भी भेजता है, जिसे आप User-Agent Parser में पढ़ सकते हैं। फिर भी यह phone की नकल करता desktop browser ही है, इसलिए layout पर निर्भर flows real devices पर पक्के करें। यह reproduce नहीं करता:

• Phone का engine: Chrome में iPhone preset page को Safari के WebKit से render नहीं करता।
• छिपने और लौटने वाले mobile browser bars; 100vh उनके छिपे होने वाली height है, इसलिए full-height panel का निचला किनारा छिप सकता है।
• On-screen keyboard, जो focused field या fixed submit button छिपा सकता है।
• उँगली की कम सटीकता: WCAG 2.5.8 में fail होने वाले छोटे या पास-पास के targets (24 × 24 CSS pixels या पर्याप्त spacing) mouse से ठीक लगते हैं।
• Phone की text-size settings और उसकी असली performance: CPU और network throttling सिर्फ़ उसका अनुमान देते हैं। Toolbar का अपना zoom सिर्फ़ preview का size बदलता है, CSS viewport नहीं।

आज़माएँ: User-Agent पार्सर

आम responsive defects

• Horizontal scrolling: fixed width, बिना टूटा लंबा शब्द या URL, चौड़ी table या बिना maximum width की image।
• ढका या पहुँच से बाहर content: field या button के ऊपर sticky header या footer, या छोटे viewport से लंबा dialog जो scroll नहीं होता।
• गायब functions: mobile पर display: none से छिपा action जिस तक कोई और रास्ता नहीं, या landscape में न खुलने या scroll न होने वाला menu।
• कटा text और खोई state: लंबे translations या बड़े text से कटे labels; rotation के बाद typed input या filters reset, अक्सर इसलिए कि page breakpoint पर components बदल देता है।
• Queries के बीच gaps और overlaps: max-width: 767px के साथ min-width: 768px होने पर 767.5 जैसी fractional widths पर कोई rule लागू नहीं होता, जो कुछ high-density screens और zoom levels पर आती हैं; max-width: 768px के साथ min-width: 768px होने पर 768 पर दोनों लागू होते हैं।
• खिंची, कटी या धुंधली images, और right-to-left pages में गलत तरफ़ से खिसककर आने वाला mobile menu।

आज़माएँ: Lorem Ipsum जनरेटर आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर

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

संदर्भ

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)WCAG 2.2 की हर guideline और success criterion की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।
• Responsive web design — MDNMDN Web Docs (Mozilla)व्यवहार में responsive design: flexbox और grid से लचीले layout, media queries और viewport meta tag, ताकि एक ही पेज हर स्क्रीन साइज़ पर चले।
• Responsive web design basicsGoogle (web.dev)responsive design की बुनियादी बातें: viewport सेट करना, content को उसमें फ़िट करना, और ऐसे breakpoints वाली media queries जिन्हें डिवाइस नहीं बल्कि content तय करे।