डिवाइस फ़्रैगमेंटेशन

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

Users app अपने devices पर चलाते हैं, आपके नहीं। छोटी screens पर कटने वाला layout, phone घुमाते ही खाली हो जाने वाला form, या किसी एक manufacturer की system layer पर ही होने वाला crash, उस device वाले हर user तक पहुँचता है, और store में ख़राब reviews और कुछ ख़ास models पर इकट्ठा होती crash reports के रूप में दिखता है।

कोई टीम हर model पर टेस्ट नहीं कर सकती, इसलिए ये defects या तो devices के सोचे-समझे चुनाव से मिलते हैं या users को। लिखे हुए कारणों वाला device matrix "हमने कुछ phones पर टेस्ट किया" को ऐसे coverage statement में बदल देता है जिसका release decision में बचाव किया जा सके: हर device कौन से risks कवर करता है, और टीम ने कौन से risks कवर न करने का फ़ैसला किया।

Fragmentation कहाँ से आता है

Android और iOS वाले lesson में OS versions और store builds आ चुके हैं। बाक़ी हर चीज़ में सबसे ज़्यादा फैलाव Android में है, क्योंकि कई manufacturers इसे budget से flagship तक के hardware पर ship करते हैं और अपनी system layer जोड़ते हैं। iOS कम models पर चलता है, पर कई iPhone sizes और, जहाँ app support करे, iPads एक साथ इस्तेमाल में रहते हैं।

• Screen: size, aspect ratio, pixel density, और camera cut-outs या गोल कोने जो layout की जगह घटाते हैं।
• Form factor: tablets, fold या unfold करने पर size बदलने वाले foldables, और split-screen windows जो app को screen का एक हिस्सा देती हैं।
• Hardware: memory, processor, camera और sensors। कम memory वाला device background apps को जल्दी बंद करता है, इसलिए app पर लौटने पर वह ज़्यादा बार restart होता है।
• Manufacturer layer (Android): बदले हुए system dialogs और keyboards, और battery optimisation जो background काम और notifications में देरी कर सकता है।
• User settings: font size, display size, dark mode, language और text direction।

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

Screen sizes: pixels, density और size classes

Apps का layout pixels में नहीं, density-independent units में बनता है: Android पर dp और iOS पर points। एक dp 160 dpi वाली screen पर एक physical pixel के बराबर है, इसलिए dp में width = pixels में width × 160 ÷ density। 420 dpi पर 1080 pixels चौड़ा phone लगभग 411 dp चौड़ा है; 320 dpi पर 720 pixels चौड़ा phone 360 dp का है। iPhones हर point को हर दिशा में दो या तीन pixels से बनाते हैं (@2x, @3x)। Screen पर कितना आएगा, यह resolution नहीं, dp या points में width तय करती है।

Adaptive layouts thresholds पर बदलते हैं। Width के लिए Android की window size classes हैं: compact (600 dp से कम: portrait में लगभग सभी phones), medium (600 से 839 dp: portrait में ज़्यादातर tablets और खुले बड़े foldables) और expanded (840 से 1199 dp: landscape में ज़्यादातर tablets); इससे चौड़ी windows की अपनी classes हैं। iOS पर हर axis compact या regular होता है: portrait में iPhone की width compact और height regular होती है, और full screen पर iPad app दोनों में regular होता है, पर तंग multitasking window में उसकी width compact हो जाती है। हर threshold एक boundary है, इसलिए boundary value analysis वाला lesson लागू करें: 599 और 600 dp, 839 और 840 dp टेस्ट करें।

Width अकेली सीमा नहीं है। Status और navigation bars, camera cut-outs और iPhone का home indicator जगह लेते हैं, और content को safe area के अंदर रहना चाहिए; Android 15 को target करने वाले apps default रूप से edge to edge दिखते हैं, इसलिए target SDK update किसी button को navigation bar के नीचे छिपा सकता है। User settings जगह और घटाती हैं: Android की display size setting dp में width बदल देती है, और 200% तक font scaling (Android 14 और उसके बाद) या iOS पर सबसे बड़े Dynamic Type sizes में बहुत कम text आता है।

• Matrix की सबसे छोटी और सबसे बड़ी width: कोई कटा text नहीं, कोई overlapping elements नहीं, कोई sideways scrolling नहीं।
• हर threshold के दोनों तरफ़: layout design के मुताबिक़ बदलता है, जैसे 840 dp से two panes।
• Safe area: system bar, cut-out या home indicator के नीचे कुछ भी tappable नहीं।
• सबसे बड़ा font और display size: text कटने के बजाय wrap होता है, और हर action scroll करके पहुँच में रहता है।

Width in dp = width in pixels × 160 ÷ density (dpi)

1080 px at 420 dpi  ->  ~411 dp   compact
1198 px at 320 dpi  ->   599 dp   compact  (just below the threshold)
1200 px at 320 dpi  ->   600 dp   medium   (first value of the class)

Android window size classes (width)
  compact    < 600 dp       almost all phones in portrait
  medium     600 - 839 dp   most tablets and unfolded foldables in portrait
  expanded   840 - 1199 dp  most tablets in landscape

On an Android emulator
  adb shell wm density 320
  adb shell wm size 1198x2000      # 599 dp, then 1200x2000 for 600 dp
  adb shell wm size reset && adb shell wm density reset

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

Orientation और दूसरे configuration changes

Android पर rotation एक configuration change है: default रूप से system मौजूदा screen (activity) को destroy करके फिर से बनाता है। App ने जो save नहीं किया वह खो जाता है: टाइप किया text, scroll position, चुना हुआ tab, खुला dialog, और चल रहा request दो बार जा सकता है या उसका result खो सकता है। Foldable को fold या unfold करना, split-screen window का size बदलना, और font size, dark mode या language बदलना, यही recreation चलाते हैं, इसलिए rotation उस state saving को टेस्ट करने का सबसे तेज़ तरीका है जिस पर events का यह पूरा परिवार निर्भर है।

iOS screen को बनाए रखता है और नए size के हिसाब से, और size classes बदलें तो नई size classes के हिसाब से, उसका layout दोबारा करता है, इसलिए iOS पर rotation defects ज़्यादातर layout defects होते हैं: छिपा हुआ button, या focused field को ढकता keyboard। Landscape में phone की height छोटी हो जाती है (Android की compact height class 480 dp से कम है), और keyboard खुला हो तो सिर्फ़ एक या दो fields दिख सकते हैं।

किसी screen को portrait पर lock करना product decision है जिसे record किया जाए, अनुमान नहीं। WCAG 2.2 का success criterion 1.3.4 Orientation (level AA) इसकी अनुमति तभी देता है जब कोई ख़ास orientation अनिवार्य हो। और Android 16 को target करने वाले apps के लिए system उन screens पर orientation और resizability restrictions को ignore करता है जिनकी smallest width 600 dp या उससे ज़्यादा है, games जैसे कुछ अपवादों के साथ, इसलिए portrait-only app भी tablets और खुले foldables पर landscape में दिखता है।

• Input वाली हर screen पर दो बार rotate करें: text, selections, scroll position, dialogs और मौजूदा step बने रहते हैं।
• Pay या Submit चलते समय rotate करें: action एक ही बार जाता है और उसका result दिखता है।
• Keyboard खुला रखकर landscape: focused field और submit action पहुँच में रहते हैं।
• जहाँ app phones पर orientation lock करता है, वहाँ lock बना रहता है; system में auto-rotate बंद हो तो app user की orientation बनाए रखता है।

Device matrix चुनना

Device matrix उन environments की लिखित सूची है जिन पर टीम टेस्ट करती है, हर एक कितनी गहराई से टेस्ट होता है, और वह वहाँ क्यों है। इसे किसी भी test design की तरह बनाएँ: पहले coverage items तय करें, यानी हर dimension की वे values जिन्हें कम से कम एक बार टेस्ट करना है, और उसके बाद ही वे devices चुनें जो उन्हें कवर करें।

• Data: analytics, store consoles और crash reports से OS version, model, manufacturer और screen class के हिसाब से active users। Mobile website के लिए server logs की User-Agent strings से browser और device type मिलते हैं, पर Android पर Chrome अब एक तय Android version और model भेजता है, इसलिए ये दोनों analytics से लें। नया app अपने target market से शुरू करता है।
• Coverage items: हर platform पर सबसे नया और सबसे पुराना supported OS, असल इस्तेमाल में सबसे छोटी width और हर बड़ी supported size class, कम memory वाला एक device, प्रमुख manufacturers, सबसे बड़ा font size और हर text direction।
• Devices: ऐसे devices को प्राथमिकता दें जो एक साथ कई items कवर करें, फिर सबसे ज़्यादा sessions वाले models और crashes के cluster वाला हर model जोड़ें।
• Tiers: Tier 1 के असली devices पर हर release में critical journeys और regression set चलता है; Tier 2 में emulators, simulators या device farm के devices पर हर release में smoke set चलता है; Tier 3 बड़ी releases से पहले चलता है।
• Settings: language, orientation, font size और theme को हर combination टेस्ट करने के बजाय pairwise selection से devices में बाँटें।
• Upkeep: हर device के होने का कारण लिखें, और हर quarter और हर नए OS version, नए minimum version या नए market के बाद matrix की समीक्षा करें।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: User-Agent पार्सर

Worked example: food delivery app

App Android 10 (API 29) और उसके बाद, और iOS 17 और उसके बाद support करता है, iOS पर सिर्फ़ iPhone पर चलता है (कोई iPad version नहीं), और Arabic व English में इस्तेमाल होता है। पिछले 90 दिनों का illustrative data: 55% sessions Android पर, जिनमें से तीन-चौथाई manufacturers A और B पर; Android के 18% sessions 4 GB या उससे कम memory वाले devices पर; इस्तेमाल में सबसे छोटी width Android पर 360 dp और iPhone पर 375 points; Android के 6% sessions foldables और tablets पर; 70% sessions Arabic में; और payment page से लौटते समय manufacturer B के phones पर crashes का एक cluster।

पाँच devices हर coverage item को कम से कम एक बार कवर करते हैं, जैसा figure दिखाता है। Budget phone D3 सबसे ज़्यादा काम करता है, और manufacturer B का phone होने के कारण "payment से लौटना" scenario सबसे पहले उसी पर चलता है। चौड़ी screens सिर्फ़ device farm के foldable से कवर होती हैं: Android के 6% sessions पर एक accepted risk, जो matrix में लिखा है। Settings के लिए, पाँच devices पर दो-दो values वाले चार parameters से 5 × 16 = 80 पूरे combinations बनते हैं; एक pairwise set values के हर pair को सिर्फ़ 10 runs में कवर कर सकता है।

• D1 और D2: हर platform पर सबसे नया OS और सबसे ज़्यादा sessions वाले models; D1 manufacturer A का भी है।
• D3: सबसे पुराना supported Android, कम memory, Android पर सबसे छोटी width और अपने crash cluster के साथ manufacturer B।
• D4: सबसे पुराना supported iOS और iPhone पर सबसे छोटी width।
• D5: सबसे नया Android, medium और expanded width, और app चलते समय size बदलने वाली window।

Device matrix: food delivery app (illustrative data, last 90 days)

ID  Device                         OS                   Runs on      Tier
D1  Android mid-range, maker A     newest Android       real device  1
D2  iPhone, standard size          newest iOS           real device  1
D3  Android budget, maker B, 3 GB  Android 10 (oldest)  real device  1
D4  iPhone, smallest (375 pt)      iOS 17 (oldest)      device farm  2
D5  Android foldable               newest Android       device farm  2

Tier 1: critical journeys + regression set, every release
Tier 2: smoke set of critical journeys, every release
Tier 3: other models above 1% of sessions, before major releases
Settings: language × orientation × font size × theme, pairwise across D1..D5

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

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

संदर्भ

• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019मोबाइल टेस्टिंग पर ISTQB का specialist पाठ्यक्रम: ऐप के प्रकार, डिवाइस व प्लेटफ़ॉर्म की चुनौतियाँ, टेस्ट प्रकार और टूल।
• Core app quality guidelinesAndroid Developers (Google)Android ऐप के लिए Google के बुनियादी गुणवत्ता मानदंड — विज़ुअल अनुभव, कार्यक्षमता, परफ़ॉर्मेंस, प्राइवेसी और सुरक्षा — उन्हें जाँचने वाले टेस्ट के साथ।
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।