मोबाइल टेस्टिंग: एक व्यावहारिक गाइड

Mutqan Soft की QA टीम द्वारा · अपडेट: 6 अक्टूबर 2026 · 17 मिनट पढ़ने का समय

मोबाइल टेस्टिंग उन ऐप्लिकेशन की टेस्टिंग है जो फ़ोन और टैबलेट पर चलते हैं — नेटिव ऐप, cross-platform और हाइब्रिड ऐप, मोबाइल वेबसाइट और progressive web app (PWA)। फ़ंक्शनल सवाल वही हैं जो कहीं और होते हैं; बदलता है उनके आसपास का सब कुछ: डिवाइस और OS के हज़ारों कॉम्बिनेशन, आता-जाता नेटवर्क, हर कुछ मिनट में बाधित होने वाला यूज़र, बैकग्राउंड में ऐप को बंद कर देने वाला ऑपरेटिंग सिस्टम, और ऐसी permissions जिन्हें यूज़र कभी भी वापस ले सकता है।

यह पिलर गाइड पूरे क्षेत्र का नक़्शा देती है: मोबाइल अलग क्यों है, डिवाइस कैसे चुनें, किन जोखिमों पर टेस्ट ज़रूरी है, बैक एंड, एक्सेसिबिलिटी और सुरक्षा ऐप पर कैसे लागू होते हैं, ऐप को किन प्लेटफ़ॉर्म गाइडलाइंस पर परखें, और ऑटोमेशन व रिलीज़ गेट कहाँ आते हैं। इसके नीचे दो गहरी गाइड हैं — मोबाइल ऐप टेस्ट सिनेरियो का कैटलॉग (lifecycle, permissions, इंटरप्शन, नेटवर्क, resources, push notification) और Appium, Espresso व XCUITest के साथ मोबाइल टेस्ट ऑटोमेशन की व्याख्या।

मोबाइल टेस्टिंग अलग क्यों है

वेब ऐप्लिकेशन उन ब्राउज़र में चलता है जिनकी सूची टीम बना सकती है, और ऐसे नेटवर्क पर जिसे टीम ज़्यादातर मानकर चल सकती है। मोबाइल ऐप ऐसे हार्डवेयर पर चलता है जिस पर टीम का नियंत्रण नहीं, और ऐसे ऑपरेटिंग सिस्टम के नीचे जो उसकी ज़िंदगी चलाता है: OS तय करता है कि ऐप कब pause होगा, मेमोरी खाली करने के लिए कब kill होगा, बैकग्राउंड में नेटवर्क कब इस्तेमाल कर सकता है और कौन सा डेटा पढ़ सकता है। ISTQB का Mobile Application Testing पाठ्यक्रम (CT-MAT) इन्हें मोबाइल की ख़ास चुनौतियों के रूप में देखता है: डिवाइस और प्लेटफ़ॉर्म की विविधता, कनेक्टिविटी, सीमित resources, और उस डिवाइस का इस्तेमाल जिसे लोग हर जगह साथ रखते हैं।

ISO/IEC 25010 की भाषा में, मोबाइल पर compatibility (दूसरे ऐप और OS के साथ सह-अस्तित्व), इंटरप्शन के बीच reliability, performance efficiency (बैटरी, मेमोरी, डेटा), interaction capability (छोटी स्क्रीन, टच, एक हाथ से इस्तेमाल) और security (खो सकने, साझा होने या root होने वाला डिवाइस) का वज़न बढ़ जाता है। मोबाइल टेस्ट स्ट्रैटेजी को बताना चाहिए कि इनमें से हर एक कैसे कवर होगा, न कि सिर्फ़ यह कि फ़ीचर काम करते हैं या नहीं।

संदर्भ लगातार बदलता है — नेटवर्क, लोकेशन, orientation, बैटरी लेवल, foreground या background।
Lifecycle OS के हाथ में है — ऐप को kill होने के बाद भी यूज़र की स्थिति वापस लानी चाहिए, सिर्फ़ pause के बाद नहीं।
यूज़र पुराने वर्ज़न चलाते हैं — वेबसाइट के उलट, आप सबको नए build पर मजबूर नहीं कर सकते, इसलिए बैक एंड एक साथ ऐप के कई वर्ज़न सर्व करता है।
वितरण पर गेट हैं — रिलीज़ स्टोर review और staged rollout से गुज़रती है, इसलिए प्रोडक्शन का defect ठीक करने में वेब से ज़्यादा समय लगता है।
इनपुट अलग है — टच, gestures, ऑन-स्क्रीन कीबोर्ड, वॉइस इनपुट, और TalkBack व VoiceOver जैसी सहायक तकनीकें।

नेटिव, cross-platform, हाइब्रिड, मोबाइल वेब और PWA

ऐप का प्रकार तय करता है कि कौन से जोखिम मौजूद हैं और कौन से टूल UI तक पहुँच सकते हैं। कुछ भी प्लान करने से पहले जानिए कि आप किस प्रकार को टेस्ट कर रहे हैं — और हाइब्रिड ऐप में कौन सी स्क्रीन नेटिव हैं और कौन सी वेब।

नेटिव ऐप — एक प्लेटफ़ॉर्म के लिए उसके अपने SDK से लिखे जाते हैं (Android पर Kotlin या Java, iOS पर Swift या Objective-C)। इन्हें डिवाइस फ़ीचर की पूरी पहुँच मिलती है और प्लेटफ़ॉर्म के टेस्ट फ़्रेमवर्क (Espresso, XCUITest) सीधे काम करते हैं। हर प्लेटफ़ॉर्म को ऐसा अलग प्रोडक्ट मानें जिसकी आवश्यकताएँ साझा हैं।
Cross-platform ऐप — एक codebase जो दोनों प्लेटफ़ॉर्म के लिए build होता है (जैसे React Native या Flutter से)। बिज़नेस लॉजिक साझा है, पर rendering, permissions, कीबोर्ड और प्लेटफ़ॉर्म इंटीग्रेशन अलग रहते हैं, इसलिए हर प्लेटफ़ॉर्म को अपना UI पास चाहिए।
हाइब्रिड ऐप — एक नेटिव shell जो WebView में वेब कंटेंट दिखाता है। जोड़ वाली जगह टेस्ट करें: नेटिव और वेब स्क्रीन के बीच नेविगेशन, session और cookie की साझेदारी, back बटन, वेब कंटेंट से फ़ाइल अपलोड और कैमरा एक्सेस, और वेब कंटेंट लोड न होने पर यूज़र क्या देखता है।
मोबाइल वेब — मोबाइल ब्राउज़र में इस्तेमाल होने वाली वेबसाइट। responsive layout, टच टारगेट, viewport और zoom, फ़ील्ड को ढकने वाला ऑन-स्क्रीन कीबोर्ड, और मोबाइल ब्राउज़र इंजनों के अंतर जाँचें। आपके analytics की user-agent strings बताती हैं कि असली यूज़र कौन से ब्राउज़र लाते हैं; पर कई ब्राउज़र अब इस string में OS वर्ज़न और डिवाइस मॉडल घटा देते या freeze कर देते हैं (जैसे Android पर Chrome), इसलिए OS वर्ज़न और डिवाइस मॉडल User-Agent Client Hints या अपने ऐप के analytics SDK से लें।
Progressive web app (PWA) — web app manifest और service worker वाले वेब ऐप, जिन्हें होम स्क्रीन पर इंस्टॉल किया जा सकता है और जो ऑफ़लाइन चल सकते हैं। installability, ऑफ़लाइन व्यवहार, cache अपडेट (क्या नई रिलीज़ cached वर्ज़न की जगह लेती है?) और push notification टेस्ट करें, जहाँ प्लेटफ़ॉर्म इंस्टॉल किए गए वेब ऐप के लिए web push सपोर्ट करता है।

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

डिवाइस fragmentation, OS वर्ज़न और स्क्रीन

Fragmentation उन अलग-अलग environments की संख्या है जिनमें आपके ऐप को चलना है। Android पर यह कई निर्माताओं से आता है, जिनमें हर एक की अपनी customised सिस्टम लेयर है, एक साथ इस्तेमाल हो रहे कई OS वर्ज़न से, और स्क्रीन साइज़, density और हार्डवेयर की बड़ी रेंज से। iOS पर डिवाइस रेंज संकरी है, पर कई iOS वर्ज़न और स्क्रीन साइज़ एक साथ चलन में रहते हैं, साथ में split-screen multitasking वाले iPad भी। Foldable और टैबलेट ऐसी स्क्रीन जोड़ते हैं जिनका साइज़ ऐप चलते-चलते बदल जाता है।

OS वर्ज़न के अंतर इसलिए मायने रखते हैं क्योंकि प्लेटफ़ॉर्म रिलीज़ के बीच व्यवहार बदलते हैं: permission मॉडल, बैकग्राउंड execution की सीमाएँ, notification के नियम और प्राइवेसी फ़ीचर। पिछले साल के OS पर सही ऐप इस साल के OS पर अपने कोड की एक भी लाइन बदले बिना फ़ेल हो सकता है। हर नए OS वर्ज़न के behaviour-change नोट्स पढ़ें और आपके ऐप को छूने वाले हर बिंदु को टेस्ट में बदलें — और यूज़र तक पहुँचने से पहले OS beta पर अपना regression suite चलाएँ।

स्क्रीन साइज़ और aspect ratio — छोटे फ़ोन, लंबे फ़ोन, टैबलेट, मुड़े और खुले foldable, split-screen और multi-window।
Density — layout density-independent इकाइयों में होते हैं (Android पर dp, iOS पर points); कम और ज़्यादा density पर इमेज में धुंधलापन और टेक्स्ट में clipping जाँचें।
Cut-out और सिस्टम बार — status bar, कैमरा cut-out या home indicator के नीचे छिपा कंटेंट।
Orientation — portrait, landscape और rotation ख़ुद: क्या स्क्रीन अपनी स्थिति और यूज़र का इनपुट बनाए रखती है? WCAG 2.2 का success criterion 1.3.4 Orientation माँगता है कि कंटेंट एक ही orientation तक सीमित न हो, जब तक वह orientation अनिवार्य न हो।
Responsive व्यवहार — मोबाइल वेब और PWA में breakpoints, viewport, horizontal scrolling और zoom जाँचें; ऐप में देखें कि layout खिंचने के बजाय ढलता है।
निर्माता की लेयर — कुछ Android डिवाइस पर आक्रामक बैटरी optimisation, कस्टम permission स्क्रीन और बदले हुए सिस्टम डायलॉग।

डिवाइस स्ट्रैटेजी: emulator, असली डिवाइस और device farm

कोई भी टीम हर डिवाइस पर टेस्ट नहीं कर सकती, इसलिए डिवाइस स्ट्रैटेजी जोखिम का फ़ैसला है। यह तीन सवालों के जवाब देती है: कौन से environment मायने रखते हैं (डेटा से, राय से नहीं), हर टेस्ट को किस तरह का डिवाइस चाहिए, और हर कॉम्बिनेशन कितनी बार चलाया जाता है।

Android emulator और iOS simulator तेज़, मुफ़्त और scriptable हैं — development और CI के लिए आदर्श। पर वे सब कुछ नहीं दोहराते: असली परफ़ॉर्मेंस और thermal व्यवहार, बैटरी की खपत, कैमरा और sensors, biometric हार्डवेयर, cellular नेटवर्क, निर्माता के customisation और push notification के रास्ते के कुछ हिस्से। iOS simulator असल में emulator है ही नहीं: वह host कंप्यूटर के लिए build किया गया ऐप चलाता है, इसलिए असली डिवाइस हार्डवेयर से और भी दूर है। रिलीज़ से पहले परफ़ॉर्मेंस, बैटरी, कैमरा, Bluetooth, NFC, पेमेंट, biometrics और निर्माता लेयर को छूने वाली हर चीज़ के लिए असली डिवाइस ज़रूरी हैं। क्लाउड device farm दूर से असली डिवाइस (और emulator) किराए पर देते हैं, ऑटोमेटेड suite या मैन्युअल session के लिए — लैब ख़रीदे और सँभाले बिना चौड़ाई।

डिवाइस मैट्रिक्स अपने analytics से बनाएँ: OS वर्ज़न, डिवाइस मॉडल, स्क्रीन क्लास और मोबाइल वेब के लिए ब्राउज़र, सक्रिय यूज़र में उनके हिस्से के क्रम में। वे डिवाइस कवर करें जिन पर आपका ज़्यादातर ट्रैफ़िक है, सबसे पुराना OS वर्ज़न जिसे आप अभी सपोर्ट करते हैं, सबसे नया OS वर्ज़न (और उसका beta), एक छोटी और एक बड़ी स्क्रीन, और हर वह डिवाइस फ़ैमिली जिससे incident आए हों। फिर बाक़ी parameters — भाषा, orientation, नेटवर्क, फ़ॉन्ट साइज़ — को पूरे cross-product के बजाय pairwise चयन से मिलाएँ।

नीचे के उदाहरण (illustrative) में मैट्रिक्स तीन tiers में बँटा है। Tier 1 — हर रिलीज़ पर असली डिवाइस: सबसे ज़्यादा sessions वाले डिवाइस, और धीमे नेटवर्क पर budget डिवाइस में सबसे पुराना सपोर्टेड Android। Tier 2 — यह भी हर रिलीज़ पर, emulator/simulator या device farm में: 200% font scale के साथ RTL, सबसे बड़े Dynamic Type साइज़ के साथ छोटी स्क्रीन वाला iPhone, और Split View में iPad। Tier 3 — सिर्फ़ बड़ी रिलीज़ से पहले, device farm में: 1% से ज़्यादा sessions वाले बाक़ी मॉडल, एक foldable और एक tablet।

Example device matrix (illustrative; build yours from your analytics)

Tier 1 — every release, real devices
  Android latest   · Samsung mid-range · 6.4"  · ar-SA · 4G     (largest share of sessions)
  iOS latest       · iPhone standard   · 6.1"  · ar-SA · Wi-Fi
  Android oldest supported · budget device, 3 GB RAM · en-IN · slow 3G

Tier 2 — every release, emulators/simulators or device farm
  Android latest   · Pixel · font scale 200% · RTL
  iOS latest − 1   · small-screen iPhone · largest Dynamic Type size
  iPadOS latest    · Split View · landscape

Tier 3 — before major releases, device farm
  long tail: remaining models above 1% of sessions, one foldable, one tablet

Combination rule
  language × orientation × network × font size → pairwise set, not the full product

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

मोबाइल पर क्या टेस्ट करें: जोखिमों का नक़्शा

फ़ीचर की फ़ंक्शनल टेस्टिंग वही तकनीकें इस्तेमाल करती है जो कहीं और; test case लिखने वाली गाइड इन्हें कवर करती है। मोबाइल के लिए ख़ास है जोखिम क्षेत्रों का एक सेट जिसे हर ऐप को कवर करना चाहिए। हर एक के विस्तृत सिनेरियो मोबाइल ऐप टेस्ट सिनेरियो वाली साथी गाइड में हैं; यहाँ नक़्शा है।

इंस्टॉल, अपडेट और अनइंस्टॉल — साफ़ इंस्टॉल, हर सपोर्टेड पुराने वर्ज़न से डेटा migration के साथ अपडेट, अनइंस्टॉल के बाद दोबारा इंस्टॉल, ऐप डेटा clear करना, backup और restore।
Permissions — पहला अनुरोध, इनकार, स्थायी इनकार, ऐप चलते समय सिस्टम सेटिंग्स से revoke करना, और एक बार की अनुमति।
इंटरप्शन — आने वाली कॉल, notification, अलार्म, ऐप बदलना, स्क्रीन लॉक, कम बैटरी की चेतावनी, और OS का बैकग्राउंड में ऐप kill करना।
नेटवर्क — Wi-Fi से cellular और वापस, ऑफ़लाइन, airplane mode, धीमा और रुक-रुक कर चलने वाला कनेक्शन, captive portal, और ऑफ़लाइन बदलाव जिन्हें कनेक्शन लौटने पर sync होना है।
डिवाइस और डिस्प्ले — स्क्रीन साइज़, orientation, dark mode, font scaling, ऑन-स्क्रीन कीबोर्ड, gestures, foldable और multi-window।
Resources — बैटरी की खपत, CPU, मेमोरी (leak, low-memory kill), storage (भरी डिस्क, बढ़ता cache) और cellular पर डेटा खपत।
Push notification — foreground, background और killed स्थिति में डिलीवरी, टैप करने पर सही स्क्रीन, और notification बंद होने पर व्यवहार।
एक्सेसिबिलिटी, localization, सुरक्षा और स्टोर अनुपालन — नीचे और अपनी-अपनी गाइड में कवर हैं।

Typical mobile defects (illustrative bug titles)

- Address form loses entered data after rotating the device (Android)
- App crashes on resume after camera permission is revoked in Settings (iOS)
- Order submitted twice when the network drops during "Place order" and the user retries
- Update from 3.8 to 4.0 signs every user out (stored session not migrated)
- Tapping an order notification opens the home screen instead of the order
- "Pay" button hidden behind the keyboard on small screens
- Checkout total truncated at the largest system font size
- Offline edits silently overwritten after reconnecting

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

मोबाइल बैक एंड: API, वर्ज़न और error handling

यूज़र तक पहुँचने वाले कई मोबाइल defect UI में नहीं, बल्कि इसमें होते हैं कि ऐप अपने बैक एंड से कैसे बात करता है। API वह हिस्सा है जिसे आप सबसे तेज़ और सबसे सटीक टेस्ट कर सकते हैं: ऐप जो request भेजता है वही API client से भेजी जा सकती हैं, और डिवाइस पर मुश्किल से बनने वाली स्थितियाँ — 503, timeout, expired token, टूटा हुआ body — जानबूझकर पैदा की जा सकती हैं।

मोबाइल की दो ख़ास चिंताओं के लिए अलग टेस्ट चाहिए। पहली है version skew: यूज़र देर से अपडेट करते हैं, इसलिए बैक एंड को हर सपोर्टेड ऐप वर्ज़न सर्व करते रहना है, और हर API बदलाव को सबसे पुराने सपोर्टेड client के सामने जाँचना है। दूसरी है बेरहम नेटवर्क: request दोबारा भेजी जाती हैं, दोहराई जाती हैं और बीच में कट जाती हैं। ऑर्डर और पेमेंट endpoint idempotent होने चाहिए, और जब request का नतीजा अज्ञात हो तब ऐप को साफ़ स्थिति दिखानी चाहिए।

ऐप जिस हर endpoint को इस्तेमाल करता है उसे valid, invalid और missing फ़ील्ड के साथ कॉल करें, और response को schema से validate करें।
ऐप के सामने 401, 403, 404, 409, 429, 500 और 503 response और धीमे response लाएँ; स्क्रीन पर संदेश और recovery जाँचें।
ऐप बैकग्राउंड में हो तब access token expire होने दें, फिर ऐप खोलें: ऐप को चुपचाप token refresh करना चाहिए या यूज़र से साइन-इन माँगना चाहिए, कभी crash या loop नहीं।
Payload साइज़ जाँचें: बड़े response cellular नेटवर्क पर समय और डेटा दोनों खाते हैं।
हर बैक-एंड रिलीज़ से पहले ऐप का सबसे पुराना सपोर्टेड वर्ज़न उसके ख़िलाफ़ चलाएँ।

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

मोबाइल एक्सेसिबिलिटी

मोबाइल प्लेटफ़ॉर्म की अपनी सहायक तकनीकें हैं, और ऐप को उन्हीं से टेस्ट करना होता है: Android पर TalkBack और iOS पर VoiceOver (gesture से चलने वाले screen reader), switch access, magnification, और सिस्टम text scaling (Android पर font size, iOS पर Dynamic Type)। WCAG 2.2 वेब की तरह मोबाइल कंटेंट पर भी लागू होता है — 1.3.4 Orientation, 2.5.1 Pointer Gestures और 2.5.8 Target Size (Minimum) जैसे success criteria टच इंटरफ़ेस के लिए ख़ास तौर पर प्रासंगिक हैं — और Android व Apple की अपनी एक्सेसिबिलिटी गाइडेंस ठोस अपेक्षाएँ जोड़ती है।

एक्सेसिबिलिटी टेस्टिंग गाइड तरीक़े को गहराई से कवर करती है, जिसमें screen reader टेस्टिंग और visual accessibility शामिल हैं। मोबाइल पर इन जाँचों से शुरू करें:

हर interactive एलिमेंट का सार्थक बोला जाने वाला label, role और state हो; सिर्फ़ आइकन वाले बटन आम विफलता हैं।
TalkBack या VoiceOver का swipe क्रम दृश्य और तार्किक क्रम का पालन करे, right-to-left layout में भी।
टेक्स्ट सिस्टम सेटिंग के साथ बड़ा हो, बिना clipping, overlap या कटे बटन के; सबसे बड़े साइज़ पर टेस्ट करें।
टच टारगेट पर्याप्त बड़े और दूरी पर हों: Apple की Human Interface Guidelines iOS पर controls का default आकार 44×44 points (और न्यूनतम 28×28 points) बताती हैं, और Android कम से कम 48×48 dp की सलाह देता है।
कस्टम gesture का सरल विकल्प हो, जैसे बटन, और कोई फ़ंक्शन सिर्फ़ डिवाइस हिलाने या झुकाने पर निर्भर न हो।
Light और dark दोनों mode में contrast बना रहे।

मोबाइल सुरक्षा: MASVS और MASTG एक नज़र में

OWASP Mobile Application Security Verification Standard (MASVS) बताता है कि सुरक्षित मोबाइल ऐप को क्या करना चाहिए, और Mobile Application Security Testing Guide (MASTG) बताता है कि इसे कैसे verify करें। MASVS अपने controls को क्षेत्रों में बाँटता है: storage, cryptography, authentication, network communication, platform interaction, code quality, reverse engineering के ख़िलाफ़ resilience, और privacy। फ़ंक्शनल QA टीम विशेषज्ञ मोबाइल security assessment की जगह नहीं लेती, पर हर रिलीज़ पर बुनियादी बातें जाँच सकती है और पहचान सकती है कि कब विशेषज्ञ बुलाना है।

Storage — ऐप फ़ाइलों, preferences, logs या cached screenshots में कोई password, token या निजी डेटा plain text में न हो; secrets की जगह प्लेटफ़ॉर्म का Keystore या Keychain है। logout के बाद डिवाइस पर क्या बचा रहता है, जाँचें।
Network — सारा ट्रैफ़िक TLS पर, plain HTTP पर कोई fallback नहीं, और certificate errors को नज़रअंदाज़ करने के बजाय reject किया जाए।
Authentication और session — token expire होते हैं, और logout session को सर्वर पर ख़त्म करता है, सिर्फ़ डिवाइस पर नहीं; biometric unlock एक valid सर्वर session से जुड़ा हो।
Platform interaction — deep links और दूसरे ऐप के लिए खुले components अपने इनपुट validate करें; जहाँ जोखिम माँगे वहाँ संवेदनशील स्क्रीन app-switcher preview में छिपी हों।
Privacy — permissions सिर्फ़ ज़रूरत पर और संदर्भ में समझाकर माँगी जाएँ; इकट्ठा किया गया डेटा स्टोर की privacy disclosures से मेल खाए।

प्लेटफ़ॉर्म क्वालिटी गाइडलाइंस और स्टोर के लिए तैयारी

दोनों प्लेटफ़ॉर्म बताते हैं कि वे किसे क्वालिटी ऐप मानते हैं, और ये दस्तावेज़ अच्छी checklist बनते हैं। Android के लिए Google की Core app quality guidelines visual experience, functionality, performance और stability, तथा privacy और security के बुनियादी मानदंड तय करती हैं, साथ में उन्हें जाँचने वाले टेस्ट भी। Apple की Human Interface Guidelines iOS इंटरफ़ेस के अपेक्षित व्यवहार का वर्णन करती हैं — नेविगेशन, controls, layout, एक्सेसिबिलिटी — और App Store Review Guidelines बताती हैं कि स्वीकार होने के लिए ऐप को क्या पूरा करना है।

इन्हें उन सवालों के oracle की तरह इस्तेमाल करें जिनका जवाब requirement शायद ही देती है: क्या back gesture को यह sheet बंद करनी चाहिए? घंटों बाद लौटने पर यूज़र को क्या दिखना चाहिए? क्या permission संदर्भ में माँगी जाती है? इनसे हटना अपने-आप defect नहीं है, पर यह फ़ैसला होना चाहिए, संयोग नहीं।

Back नेविगेशन — Android का back बटन या gesture और iOS का swipe-back gesture हर स्क्रीन पर अनुमानित व्यवहार करें।
State restoration — बैकग्राउंड में जाने या kill होने के बाद ऐप वहीं लौटे जहाँ यूज़र था।
Stability — मुख्य flows में कोई crash नहीं और कोई "App not responding" (ANR) डायलॉग नहीं।
Start-up — आपके सबसे कमज़ोर सपोर्टेड डिवाइस पर cold start से इस्तेमाल लायक स्क्रीन तक का समय स्वीकार्य हो।
स्टोर लिस्टिंग — screenshots, privacy disclosures और permission के उद्देश्य वाले टेक्स्ट ऐप से मेल खाएँ।

ऑटोमेशन, CI और रिलीज़ गेट

मोबाइल ऑटोमेशन वही pyramid अपनाता है जो कोई भी प्रोडक्ट (manual vs automated testing गाइड देखें): बहुत सारे तेज़ unit टेस्ट, बैक एंड पर API टेस्ट की मज़बूत परत, और critical journeys के लिए UI टेस्ट का छोटा सेट। UI परत प्लेटफ़ॉर्म फ़्रेमवर्क इस्तेमाल करती है — Android के लिए Espresso, iOS के लिए XCUITest — या Appium, जो WebDriver प्रोटोकॉल से दोनों प्लेटफ़ॉर्म चलाता है। स्थिर UI टेस्ट locator के रूप में accessibility identifiers, fixed sleep के बजाय फ़्रेमवर्क के synchronisation, और नियंत्रित डिवाइस स्थिति पर निर्भर करते हैं। मोबाइल टेस्ट ऑटोमेशन वाली साथी गाइड फ़्रेमवर्क की तुलना करती है और flakiness के स्रोत बताती है।

CI में हर बदलाव पर unit टेस्ट और emulator या simulator पर smoke टेस्ट चलाएँ, और हर रात या रिलीज़ से पहले device farm में असली डिवाइस पर बड़ा suite; हर विफलता का वीडियो, screenshots और डिवाइस logs रखें। क्योंकि मोबाइल रिलीज़ तुरंत rollback नहीं हो सकती, टेस्टिंग की आख़िरी पंक्ति स्टोर के आसपास होती है: पहले internal और beta वितरण (iOS पर TestFlight, Google Play पर testing tracks), फिर staged या phased rollout जो सबसे पहले यूज़र के छोटे हिस्से तक पहुँचे, हर चरण पर crash, ANR और API error दर पर नज़र रखते हुए। टूटे फ़ीचर को बंद करने वाला remote switch अक्सर सबसे तेज़ उपलब्ध इलाज होता है।

गेट — तय soak अवधि में beta build में कोई नया crash cluster नहीं।
गेट — ऐप का सबसे पुराना सपोर्टेड वर्ज़न नए बैक एंड के ख़िलाफ़ अपने API smoke checks अब भी पास करे।
Rollout — अगर crash-free दर या किसी मुख्य flow की सफलता दर तय सीमा से नीचे जाए तो रोकें।

क्योंकि मोबाइल रिलीज़ तुरंत rollback नहीं हो सकती, टेस्टिंग की आख़िरी पंक्ति स्टोर के आसपास होती है: पहले beta, फिर staged rollout जिसे सबके पास पहुँचने से पहले रोका जा सकता है।

1हर बदलाव पर CIUnit टेस्ट और emulator या simulator पर smoke टेस्ट
2असली डिवाइसDevice farm में बड़ा suite, हर रात या रिलीज़ से पहले; हर विफलता का वीडियो, screenshots और डिवाइस logs
3Internal और betaiOS पर TestFlight, Google Play पर testing tracks
गेट: तय soak अवधि में beta build में कोई नया crash cluster नहीं
4Staged rolloutपहले यूज़र का छोटा हिस्सा; हर चरण पर crash, ANR और API error दर पर नज़र
शाखा: crash-free दर या किसी मुख्य flow की सफलता दर तय सीमा से नीचे जाए तो रोकें
5सभी यूज़र

Remote switchटूटे फ़ीचर को बंद करता है; अक्सर सबसे तेज़ उपलब्ध इलाज
बैक एंड रिलीज़: अलग गेटऐप का सबसे पुराना सपोर्टेड वर्ज़न नए बैक एंड के ख़िलाफ़ अपने API smoke checks अब भी पास करे

soak अवधि और सीमाएँ वही हैं जो आपकी टीम तय करे; यह चित्र किसी मान का संकेत नहीं देता।

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

मोबाइल ऐप टेस्टिंग और मोबाइल वेब टेस्टिंग में क्या अंतर है?

मोबाइल वेब टेस्टिंग मोबाइल ब्राउज़र में वेबसाइट जाँचती है: responsive layout, टच, viewport और ब्राउज़र के अंतर। मोबाइल ऐप टेस्टिंग उसमें वह सब जोड़ती है जो OS नियंत्रित करता है — इंस्टॉल और अपडेट, permissions, background और killed स्थिति, push notification और डिवाइस हार्डवेयर।

Emulator पर टेस्ट करें या असली डिवाइस पर?

दोनों पर। Emulator और simulator तेज़ और scriptable हैं, इसलिए development और CI में उनका इस्तेमाल करें। रिलीज़ से पहले परफ़ॉर्मेंस, बैटरी, कैमरा, sensors, biometrics, cellular नेटवर्क और निर्माता-विशेष व्यवहार के लिए असली डिवाइस इस्तेमाल करें।

मुझे कितने डिवाइस पर टेस्ट करना चाहिए?

जितने आपका जोखिम माँगे, analytics से चुने हुए: जिन डिवाइस पर ज़्यादातर ट्रैफ़िक है, सबसे पुराना और सबसे नया सपोर्टेड OS वर्ज़न, एक छोटी और एक बड़ी स्क्रीन, और जाने-माने समस्या वाले डिवाइस। बाक़ी parameters pairwise चयन से मिलाएँ।

डिवाइस fragmentation क्या है?

उन environments की विविधता जिनमें ऐप को चलना है — निर्माता, OS वर्ज़न, स्क्रीन साइज़, density और हार्डवेयर। यह Android पर सबसे ज़्यादा है, पर iOS पर भी कई OS वर्ज़न और स्क्रीन साइज़ एक साथ चलन में रहते हैं।

क्या Android और iOS के लिए एक ही ऑटोमेटेड टेस्ट इस्तेमाल हो सकते हैं?

आंशिक रूप से। अगर दोनों ऐप के flows और accessibility identifiers एक जैसे हों तो Appium एक test codebase से दोनों प्लेटफ़ॉर्म चला सकता है, पर स्क्रीन और प्लेटफ़ॉर्म व्यवहार फिर भी अलग रहते हैं। प्लेटफ़ॉर्म फ़्रेमवर्क (Espresso, XCUITest) को हर प्लेटफ़ॉर्म के लिए अलग suite चाहिए, पर वे आम तौर पर तेज़ और ज़्यादा स्थिर होते हैं।

OWASP MASVS क्या है?

OWASP Mobile Application Security Verification Standard: मोबाइल ऐप की सुरक्षा आवश्यकताओं का सेट, जो storage, cryptography, authentication, network, platform interaction, code, resilience और privacy जैसे क्षेत्रों में बँटा है। MASTG बताता है कि इन्हें कैसे टेस्ट करें।

क्या WCAG मोबाइल ऐप पर लागू होता है?

WCAG वेब कंटेंट के लिए लिखा गया था, पर उसके सिद्धांत और ज़्यादातर success criteria नेटिव मोबाइल ऐप पर भी लागू किए जाते हैं, और कुछ — orientation, pointer gestures, target size — टच स्क्रीन पर सबसे अहम हैं। Android और Apple भी अपनी एक्सेसिबिलिटी गाइडेंस प्रकाशित करते हैं।

संदर्भ

Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019मोबाइल टेस्टिंग पर ISTQB का specialist पाठ्यक्रम: ऐप के प्रकार, डिवाइस व प्लेटफ़ॉर्म की चुनौतियाँ, टेस्ट प्रकार और टूल।
Core app quality guidelinesAndroid Developers (Google)Android ऐप के लिए Google के बुनियादी गुणवत्ता मानदंड — विज़ुअल अनुभव, कार्यक्षमता, परफ़ॉर्मेंस, प्राइवेसी और सुरक्षा — उन्हें जाँचने वाले टेस्ट के साथ।
Test apps on AndroidAndroid Developers (Google)Android की आधिकारिक टेस्टिंग गाइडेंस: टेस्ट के प्रकार और दायरा, local बनाम instrumented टेस्ट, और बेहतरीन तरीके।
OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationमोबाइल ऐप के लिए OWASP की सुरक्षा आवश्यकताएँ, storage, cryptography, authentication, network और platform interaction जैसे नियंत्रण समूहों में।
OWASP Mobile Application Security Testing Guide (MASTG)OWASP FoundationMASVS के साथ चलने वाला टेस्टिंग मैनुअल: मोबाइल ऐप सुरक्षा जाँचने की तकनीकें और टेस्ट केस।
Accessibility — Human Interface GuidelinesAppleiOS और अन्य प्लेटफ़ॉर्म के लिए Apple की एक्सेसिबिलिटी डिज़ाइन गाइडेंस: VoiceOver, Dynamic Type, कंट्रास्ट, टच टारगेट और मोशन।
Appium DocumentationAppium (OpenJS Foundation)iOS और Android पर नेटिव, हाइब्रिड और मोबाइल-वेब ऐप के ऑटोमेशन का आधिकारिक दस्तावेज़।
Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।

अभ्यास

ऐप रिलीज़ की मोबाइल टेस्टिंग प्लान करें

आपका काम

आप Android और iOS के लिए एक clinic booking ऐप (काल्पनिक) के टेस्टर हैं। Release 5.2 तीन बदलाव लाती है: appointment के साथ लगाई जाने वाली prescription की फ़ोटो, push notification से appointment reminders, और payment provider के वेब पेज पर ऐप के अंदर दिया जाने वाला booking deposit। नीचे के material में बदलाव, ऐप के पिछले 30 दिन के analytics, दो पुराने incidents, टीम के डिवाइस और रिलीज़ की प्रक्रिया है।

गाइड को साथ रखकर काग़ज़ पर 5.2 के लिए एक पेज का मोबाइल टेस्ट approach लिखें: ऐप का प्रकार, डिवाइस मैट्रिक्स, जोखिमों का नक़्शा, बैक-एंड जाँचें और रिलीज़ गेट। हर फ़ैसले का कारण लिखें ताकि टीम उस पर सवाल उठा सके। गाइड के टूल्स में से पेयरवाइज़ टेस्टिंग जनरेटर और एज केस जनरेटर (उसके file और concurrency cases) दो steps में मदद करते हैं। इसके लिए 40–45 मिनट रखें।

सामग्री

Clinic booking ऐप (काल्पनिक) - Android और iOS के लिए release 5.2
दोनों प्लेटफ़ॉर्म के लिए एक Flutter codebase। Deposit, payment provider के hosted
वेब पेज पर दिया जाता है, जो ऐप के अंदर WebView में दिखता है।

5.2 क्या बदलती है
  C1  Appointment के साथ prescription की फ़ोटो लगाना, कैमरा या gallery से।
      Upload: POST /v2/appointments/{id}/attachments
  C2  Appointment से 2 घंटे पहले reminder push notification; उस पर टैप करने से
      वही appointment खुलता है।
  C3  Hosted payment पेज पर 50.00 SAR का booking deposit देना।
      POST /v2/appointments/{id}/deposit (header Idempotency-Key) payment पेज का
      address लौटाता है।
  बैक एंड 5.2, 18 अक्टूबर 2026 को live होता है; ऐप एक हफ़्ते बाद staged rollout
  से आते हैं। सपोर्टेड ऐप वर्ज़न: 4.9 से 5.2।

Analytics, पिछले 30 दिन (सक्रिय यूज़र में हिस्सा)
  Android: 64%
    Samsung mid-range, 6.5-inch स्क्रीन: 19%
    Samsung budget, 3 GB RAM: 11%
    Xiaomi budget: 9%
    Pixel: 4%
    बाक़ी मॉडल, हर एक 1% से कम: 21%
    OS वर्ज़न: latest (N): 12%, N-1: 27%, N-2: 16%, पुराने: 8%,
    Android 10 (सबसे पुराना सपोर्टेड): 1%
  iOS: 36%
    iPhone standard, 6.1-inch स्क्रीन: 17%
    iPhone large, 6.7-inch स्क्रीन: 8%
    iPhone small, 4.7-inch स्क्रीन: 6%
    iPad: 2%
    बाक़ी मॉडल, हर एक 1% से कम: 3%
    OS वर्ज़न: latest (N): 27%, N-1: 7%, N-2 (सबसे पुराना सपोर्टेड): 2%
  भाषा: Arabic 71%, English 29%। सबसे बड़ा सिस्टम font size: 3% यूज़र।

Incidents
  INC-41 (release 5.0)  ऐप को recent apps से swipe करके हटाने के बाद Xiaomi
                        डिवाइस पर booking confirmations (push) नहीं पहुँचे;
                        कारण: निर्माता का battery saver।
  INC-44 (release 5.1)  Samsung budget डिवाइस: profile फ़ोटो लेने के बाद ऐप
                        home स्क्रीन पर दोबारा खुला और फ़ोटो खो गई।

मिलाने के लिए बाक़ी parameters
  भाषा: ar, en | orientation: portrait, landscape
  नेटवर्क: Wi-Fi, 4G, slow 3G | font size: default, largest

टीम का सेटअप
  लैब (असली डिवाइस): Samsung mid-range (Android N-1), iPhone standard (iOS N)
  Device farm: ऊपर के मॉडल के असली डिवाइस और emulator, हर session के लिए बुक
  CI: हर merge पर Android emulator और iOS simulator पर smoke टेस्ट
  Beta: TestFlight और Google Play का closed testing track (clinic स्टाफ़)
  Remote switches: C1 हाँ, C2 नहीं, C3 हाँ

चरण

ऐप का प्रकार बताएँ और लिखें कि प्लान के लिए इसका क्या मतलब है: साझा Flutter codebase क्या बचाता है, क्या नहीं, और WebView वाला payment पेज क्या जोड़ता है।
डिवाइस मैट्रिक्स तीन tiers में बनाएँ — हर रिलीज़ पर असली डिवाइस; हर रिलीज़ पर emulator, simulator या device farm; बड़ी रिलीज़ से पहले device farm — हर entry के लिए material से एक कारण के साथ। जिन टेस्ट को असली डिवाइस चाहिए, उन्हें चिह्नित करें। फिर बाक़ी parameters को pairwise मिलाएँ: पूरे cross-product की जगह कितने runs?
C1, C2 और C3 के लिए गाइड का जोखिमों का नक़्शा देखें: हर बदलाव पर लागू होने वाले जोखिम क्षेत्र बताएँ और कम से कम तीन टेस्ट ideas लिखें, सबसे ज़रूरी पहले।
18 अक्टूबर 2026 को बैक एंड live होने से पहले API client से चलाई जाने वाली जाँचें लिखें: version skew, deposit, नया upload, और वे error responses जिन्हें ऐप को सँभालना है।
रिलीज़ गेट और rollout लिखें: हर चरण से पहले क्या पास होना चाहिए, staged rollout के दौरान आप क्या देखते हैं, उसे कब रोकते हैं, और C2 के लिए remote switch न होने का क्या मतलब है।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

ऐप का प्रकार। Flutter इसे cross-platform ऐप बनाता है: बिज़नेस लॉजिक साझा है, पर rendering, permission डायलॉग, कीबोर्ड, back नेविगेशन और push इंटीग्रेशन हर प्लेटफ़ॉर्म पर अलग रहते हैं, इसलिए C1, C2 और C3 में से हर एक को Android पर एक और iOS पर दूसरा UI पास चाहिए — एक प्लेटफ़ॉर्म पर पास होना दूसरे के बारे में कुछ नहीं बताता। साझा कोड जो बचाता है, वह बिज़नेस लॉजिक है: उसके unit टेस्ट एक बार लिखे जाते हैं। Payment पेज ऐप को एक जगह पर हाइब्रिड बनाता है, इसलिए जोड़ वाली जगह टेस्ट करें: पेज उसी payment session के साथ खुलता है या नहीं जो deposit call ने लौटाया — यही appointment, 50.00 SAR; payment के बीच Android का back बटन और iOS का swipe-back; पेज लोड न होने पर (ऑफ़लाइन, 503) यूज़र क्या देखता है; और पेज से लौटने पर ऐप क्या दिखाता है (भुगतान हुआ, नहीं हुआ, cancel हुआ)। Payment step की ऑटोमेटेड coverage का वादा करने से पहले जाँच लें कि आपका UI ऑटोमेशन WebView के अंदर के कंटेंट तक पहुँच सकता है।

डिवाइस मैट्रिक्स, Tier 1 — हर रिलीज़ पर असली डिवाइस। (1) Samsung mid-range, Android N-1, Arabic, 4G: सबसे ज़्यादा इस्तेमाल होने वाला मॉडल (19%), सबसे ज़्यादा इस्तेमाल होने वाले Android वर्ज़न (27%) पर; यह लैब में है। (2) iPhone standard, iOS N, Arabic, Wi-Fi: सबसे ज़्यादा इस्तेमाल होने वाला iOS मॉडल (17%), सबसे ज़्यादा इस्तेमाल होने वाले iOS वर्ज़न (27%) पर; यह भी लैब में है। (3) 3 GB RAM वाला Samsung budget, Android N-2 पर, device farm से: 11% यूज़र, दूसरे सबसे ज़्यादा इस्तेमाल होने वाले Android वर्ज़न (16%) पर, और INC-44 इस बात का आम लक्षण है कि कैमरा खुला रहते OS ने ऐप kill किया और ऐप अपनी स्थिति वापस नहीं ला सका — ठीक वही रास्ता जिससे C1 गुज़रता है। (4) Xiaomi budget, N-2 से पुराने किसी वर्ज़न पर (कुल 8%), device farm से: 9% यूज़र, और INC-41 दिखाता है कि निर्माता का battery saver push notifications रोकता है — ठीक वही रास्ता जिससे C2 गुज़रता है। डिवाइस 3 और 4 अपने incidents की वजह से Tier 1 में हैं, जो गाइड में अपने-आप में एक कारण है, सिर्फ़ अपने हिस्से की वजह से नहीं।

Tier 2 — हर रिलीज़ पर, emulator, simulator या device farm में: Android 10, सबसे पुराना सपोर्टेड वर्ज़न (1%), क्योंकि उसका permission मॉडल अलग है — notifications को runtime permission सिर्फ़ Android 13 से चाहिए, और कैमरे की एक बार की अनुमति ("Only this time") सिर्फ़ Android 11 से है, इसलिए वहाँ C1 और C2 दूसरे रास्तों से चलते हैं; Pixel emulator पर Android N (12%), और जब उपलब्ध हो तो अगले Android वर्ज़न का beta; iOS N-2 (सबसे पुराना सपोर्टेड iOS, 2%) पर, सबसे बड़े text size (3% यूज़र) के साथ 4.7-inch iPhone (6%), वह छोटी स्क्रीन जहाँ कीबोर्ड payment पेज के "Pay" बटन को ढक सकता है और रक़म कट सकती है; और बड़ी स्क्रीन के रूप में iOS N-1 (7%) पर 6.7-inch iPhone (8%)। Tier 3 — बड़ी रिलीज़ से पहले, device farm में: Split View और landscape में iPad (2%), और long tail का एक नमूना, क्योंकि कोई और मॉडल 1% यूज़र तक नहीं पहुँचता। असली डिवाइस ज़रूरी हैं: C1 में फ़ोटो लेने (कैमरा) के लिए, और C2 में background और killed स्थिति में तथा Xiaomi के battery saver के पीछे push डिलीवरी के लिए। Layout, right-to-left, font size, Android 10 के permission डायलॉग, और WebView की loading और error स्थितियों के लिए emulator और simulator काफ़ी हैं।

Pairwise। भाषा (2) × orientation (2) × नेटवर्क (3) × font size (2) पूरे cross-product में 24 runs देते हैं। Pairwise को कम से कम 6 runs चाहिए, क्योंकि सिर्फ़ नेटवर्क × भाषा के ही 3 × 2 = 6 pairs हैं और हर run उनमें से सिर्फ़ एक कवर करता है। एक valid सेट: Wi-Fi · ar · portrait · default; Wi-Fi · en · landscape · largest; 4G · ar · landscape · largest; 4G · en · portrait · default; slow 3G · ar · portrait · largest; slow 3G · en · landscape · default। Generator 6 या 7 rows दे सकता है; जाँचें कि हर pair मौजूद है। सभी छह rows हर डिवाइस पर चलाने के बजाय उन्हें Tier 1 और Tier 2 के डिवाइस में बाँट दें।

C1, prescription फ़ोटो — permissions, इंटरप्शन और resources, नेटवर्क, सुरक्षा और privacy, एक्सेसिबिलिटी। (1) कैमरा permission: पहला अनुरोध, इनकार, स्थायी इनकार (gallery फिर भी काम करे और ऐप बताए कि Settings में कैमरा कैसे allow करें), एक बार की अनुमति, और ऐप बैकग्राउंड में हो तब सिस्टम सेटिंग्स से revoke करना, फिर resume: कोई crash नहीं। (2) 3 GB वाले Samsung पर: किसी appointment से कैमरा खोलें, फ़ोटो लें और लौटें; appointment और फ़ोटो वहीं रहने चाहिए, भले ही इस बीच OS ने ऐप kill कर दिया हो (INC-44)। Android का developer option "Don’t keep activities" इसे दूसरे डिवाइस पर reproduce करने में मदद करता है। (3) Slow 3G पर और बीच में कनेक्शन टूटने पर upload: दिखाई देने वाली progress और upload फ़ेल होने पर साफ़ संदेश, duplicate attachment के बिना retry, और cellular डेटा पर ठीक-ठाक फ़ोटो साइज़। (4) Prescription health डेटा है: upload के बाद और logout के बाद ऐप की फ़ाइलों और cache में क्या बचता है, जाँचें, और देखें कि स्टोर की privacy disclosures में फ़ोटो का ज़िक्र है। (5) कैमरा बटन, जो अक्सर सिर्फ़ आइकन होता है, का TalkBack और VoiceOver में सार्थक बोला जाने वाला label हो।

C2, reminders — push notification, permissions, बैक एंड, privacy। (1) ऐप foreground, background और killed (swipe करके हटाया गया) स्थिति में हो तब डिलीवरी, battery saver वाले Xiaomi पर (INC-41) और iPhone पर। (2) Reminder पर टैप करने से वही appointment खुले, home स्क्रीन नहीं — तब भी जब ऐप बैकग्राउंड में रहते access token expire हो गया हो: ऐप चुपचाप token refresh करे या यूज़र से साइन-इन माँगे और फिर appointment खोले; कभी crash या loop नहीं। (3) Notifications से इनकार: iOS पर और Android 13 व उसके बाद यूज़र prompt पर मना कर सकता है; Android 10 से 12 पर वे default रूप से चालू रहती हैं, पर Settings में बंद की जा सकती हैं। दोनों हालात में ऐप बताए कि reminders बंद हैं, चुपचाप फ़ेल न हो। (4) Cancel किए गए या दूसरे समय पर खिसकाए गए appointment का पुराने समय वाला reminder न आए। (5) Product owner से पूछें कि lock स्क्रीन पर reminder क्या दिखा सकता है: clinic या specialty का नाम health जानकारी उजागर कर सकता है।

C3, deposit — हाइब्रिड जोड़, नेटवर्क, इंटरप्शन, डिस्प्ले, सुरक्षा। (1) जोड़ वाली जगह, जैसा ऐप के प्रकार में बताया गया। (2) यूज़र के payment confirm करते ही कनेक्शन टूटे और यूज़र दोबारा कोशिश करे: deposit एक ही बार कटे — दोहराई गई deposit call वही Idempotency-Key भेजती है — और ऐप दोबारा payment का विकल्प देने के बजाय बताए कि payment की स्थिति जाँची जा रही है। (3) इंटरप्शन: अगर payment पेज one-time code माँगे, तो यूज़र उसे पढ़ने के लिए messages ऐप में जाता है और लौटता है — पेज और टाइप किया गया डेटा बना रहे; आने वाली कॉल के बाद भी यही। (4) 4.7-inch iPhone पर कीबोर्ड "Pay" को न ढके, और सबसे बड़े font size पर रक़म न कटे। (5) पेज सिर्फ़ HTTPS पर लोड हो, और certificate errors नज़रअंदाज़ होने के बजाय reject हों; दूसरी बात जाँचने के लिए intercepting proxy चाहिए, इसलिए इसे security विशेषज्ञ के साथ प्लान करें (MASVS का network क्षेत्र)।

18 अक्टूबर से पहले बैक-एंड जाँचें, staging पर, API client और ऐप के पुराने builds से। (1) Version skew: बैक एंड ऐप से एक हफ़्ता पहले live होता है, इसलिए उस हफ़्ते हर यूज़र 4.9 से 5.1 तक के वर्ज़न बैक एंड 5.2 के साथ चलाता है। ऐप 4.9 (सबसे पुराना सपोर्टेड) और 5.1 उसके ख़िलाफ़ चलाएँ: साइन-इन, appointments की सूची, booking और cancel, booking confirmation push — उस appointment के साथ भी जिसमें फ़ोटो और paid deposit है, क्योंकि जब वही account दूसरे डिवाइस पर 5.2 इस्तेमाल करता है तो पुराना ऐप ऐसे appointment से मिलता है। इसका पास होना बैक-एंड रिलीज़ का गेट है। (2) Deposit: POST /v2/appointments/{id}/deposit एक ही Idempotency-Key के साथ दो बार भेजें; दूसरी call वही payment session लौटाए, नया नहीं। पहले से paid appointment के लिए नई key को API contract के अनुसार मना किया जाए, जैसे 409 Conflict के साथ। (3) Upload: valid फ़ोटो, ग़लत या नक़ली (spoofed) file type, ख़ाली फ़ाइल, missing फ़ील्ड और size limit से बड़ी फ़ाइल, हर response को schema से validate करते हुए; एज केस जनरेटर file और double-submission cases की सूची देता है। (4) दोनों नए endpoints पर और reminder से खुलने वाले appointment को लोड करते समय ऐप के सामने 401, 403, 404, 409, 429, 500, 503 और धीमा response लाएँ (API स्टेटस कोड सिम्युलेटर, Mock एरर रिस्पॉन्स जनरेटर), और स्क्रीन पर संदेश और recovery जाँचें। (5) Response और upload का साइज़ (रिस्पॉन्स साइज़ एनालाइज़र), जो cellular नेटवर्क पर समय और डेटा दोनों खाते हैं।

रिलीज़। CI में हर merge पर unit टेस्ट और emulator व simulator पर smoke टेस्ट चलते हैं; बड़ा suite हर रात और रिलीज़ से पहले device farm के असली डिवाइस पर चलता है, और हर विफलता का वीडियो, screenshots और डिवाइस logs रखे जाते हैं। गेट 1, 18 अक्टूबर से पहले: ऐप 4.9 बैक एंड 5.2 के ख़िलाफ़ अपने API smoke checks पास करे। गेट 2, beta: 4.9 से और 5.1 से 5.2 पर अपडेट करने के बाद यूज़र साइन-इन रहे और उसके appointments बने रहें, clinic स्टाफ़ TestFlight और closed testing track से 5.2 इस्तेमाल करे, और तय soak अवधि में कोई नया crash cluster न दिखे। फिर Google Play पर staged rollout और App Store पर phased release: हर चरण पर crash-free दर, Android पर ANR, API error दर और तीनों नए flows (फ़ोटो upload, reminder से appointment खोलना, deposit payment) की सफलता दर देखें, और इनमें से कोई तय सीमा से नीचे जाए तो rollout रोकें। C1 और C3 फ़ेल हों तो remote switch से बंद किए जा सकते हैं। C2 नहीं: ऐप के reminders सँभालने में कोई defect अपडेट करने वाले हर यूज़र तक पहुँचता है और सिर्फ़ नई रिलीज़ से ठीक होता है, जो स्टोर review से गुज़रती है। 5.2 जाने से पहले switch माँगें, या कम से कम सर्वर से reminders भेजना रोकने का तरीका; अगर टीम मना करे, तो इसे रिलीज़ risk के रूप में दर्ज करें और beta में C2 को असली डिवाइस पर सबसे ज़्यादा समय दें।

अगर आपका प्लान अलग है, तो सूचियों की नहीं, कारणों की तुलना करें। हर डिवाइस को material से एक कारण चाहिए: यूज़र में हिस्सा, सबसे पुराना या सबसे नया सपोर्टेड वर्ज़न, स्क्रीन साइज़ या कोई incident। सिर्फ़ emulator पर प्लान किया गया कैमरा या push टेस्ट, सबसे पुराने सपोर्टेड वर्ज़न के बिना मैट्रिक्स, या पुराने ऐप वर्ज़न चलाए बिना live किया गया बैक एंड — यही कमियाँ हैं जिन्हें ठीक करना है।

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

इस topic से पहले

अगले topics

टेस्टर के लिए Android और iOS

इस मॉड्यूल के दूसरे topics

टूल्स

Mutqan Soft

Mutqan Soft कैसे मदद कर सकता है

Mutqan Soft की एक सेवामैनुअल टेस्टिंगऐसे इंजीनियरों द्वारा फ़ंक्शनल, एक्सप्लोरेटरी और कम्पैटिबिलिटी टेस्टिंग जो टेस्ट केस और डिफ़ेक्ट रिपोर्ट खुद लिखते हैं।Mutqan Soft की एक सेवाटेस्ट ऑटोमेशनएक ऑटोमेटेड रिग्रेशन सूट — API, वेब और मोबाइल — जो हर बदलाव पर आपकी CI पाइपलाइन में चलता है।

मोबाइल टेस्टिंग: एक व्यावहारिक गाइड

मोबाइल टेस्टिंग अलग क्यों है

नेटिव, cross-platform, हाइब्रिड, मोबाइल वेब और PWA

डिवाइस fragmentation, OS वर्ज़न और स्क्रीन

डिवाइस स्ट्रैटेजी: emulator, असली डिवाइस और device farm

मोबाइल पर क्या टेस्ट करें: जोखिमों का नक़्शा

मोबाइल बैक एंड: API, वर्ज़न और error handling

मोबाइल एक्सेसिबिलिटी

मोबाइल सुरक्षा: MASVS और MASTG एक नज़र में

प्लेटफ़ॉर्म क्वालिटी गाइडलाइंस और स्टोर के लिए तैयारी

ऑटोमेशन, CI और रिलीज़ गेट

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

संदर्भ

अभ्यास

ऐप रिलीज़ की मोबाइल टेस्टिंग प्लान करें

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

इस गाइड में बताए गए टूल्स

पेयरवाइज़ टेस्टिंग जनरेटर

User-Agent पार्सर

REST API टेस्टर

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

Mock एरर रिस्पॉन्स जनरेटर

रिस्पॉन्स साइज़ एनालाइज़र

स्टेट ट्रांज़िशन जनरेटर

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

बहुभाषी टेस्ट डेटा जनरेटर

Mutqan Soft कैसे मदद कर सकता है

और गाइड

मोबाइल ऐप टेस्ट सिनेरियो

मोबाइल टेस्ट ऑटोमेशन की व्याख्या

एक्सेसिबिलिटी टेस्टिंग

API टेस्टिंग क्या है? REST API कैसे टेस्ट करें

एक्सप्लोरेटरी टेस्टिंग

टेस्ट केस कैसे लिखें

मोबाइल टेस्टिंग अलग क्यों है

नेटिव, cross-platform, हाइब्रिड, मोबाइल वेब और PWA

डिवाइस fragmentation, OS वर्ज़न और स्क्रीन

डिवाइस स्ट्रैटेजी: emulator, असली डिवाइस और device farm

मोबाइल पर क्या टेस्ट करें: जोखिमों का नक़्शा

मोबाइल बैक एंड: API, वर्ज़न और error handling

मोबाइल एक्सेसिबिलिटी

मोबाइल सुरक्षा: MASVS और MASTG एक नज़र में

प्लेटफ़ॉर्म क्वालिटी गाइडलाइंस और स्टोर के लिए तैयारी

ऑटोमेशन, CI और रिलीज़ गेट

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

संदर्भ

अभ्यास

ऐप रिलीज़ की मोबाइल टेस्टिंग प्लान करें

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

इस गाइड में बताए गए टूल्स

Mutqan Soft कैसे मदद कर सकता है

और गाइड

मोबाइल ऐप टेस्ट सिनेरियो

मोबाइल टेस्ट ऑटोमेशन की व्याख्या

एक्सेसिबिलिटी टेस्टिंग

API टेस्टिंग क्या है? REST API कैसे टेस्ट करें

एक्सप्लोरेटरी टेस्टिंग

टेस्ट केस कैसे लिखें