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

इस कैटलॉग का इस्तेमाल कैसे करें

हर सिनेरियो एक स्थिति और एक observation है: ऐप को किसी स्थिति में रखें, मोबाइल-विशेष गड़बड़ी लागू करें, और देखें कि यूज़र क्या देखता है और उसके बाद डेटा कैसा है। जो लागू हों उन्हें preconditions, steps और expected results वाले test case में बदलें (test case लिखने वाली गाइड फ़ॉर्मेट कवर करती है)। जोखिम के आधार पर चुनें: बिना सेव इनपुट वाली स्क्रीन, नेटवर्क पर निर्भर फ़ीचर, permissions इस्तेमाल करने वाले या ऐप से बाहर जाने वाले flows (पेमेंट, दूसरे ऐप से साइन-इन), और लोकल डेटा स्टोर करने वाली हर चीज़।

ऐप के lifecycle को state machine के रूप में मॉडल किया जा सकता है, और कई मोबाइल defect ग़लत transitions हैं। टेस्टिंग के लिए पाँच states वाला एक सरल cross-platform मॉडल काफ़ी है: not running, foreground, background, suspended और killed। कोई भी प्लेटफ़ॉर्म ठीक यही सेट परिभाषित नहीं करता: suspended iOS की शब्दावली है, और killed का मतलब process death है — OS बैकग्राउंड में पड़े ऐप का process ख़त्म कर देता है, और यूज़र बाद में Recents से लौटकर अपनी पिछली स्थिति वापस मिलने की उम्मीद करता है। critical स्क्रीन को states और events (कॉल आना, ऐप का बैकग्राउंड में जाना, process kill होना, Recents से दोबारा खुलना) के रूप में मॉडल करने से transition table मिलती है और साफ़ सूची बनती है कि कौन से transition टेस्ट हुए और कौन से नहीं।

ID:        MOB-NET-04
Area:      Network — connection lost mid-request
Screen:    Checkout › Place order
Setup:     Signed-in customer, 2 items in cart, Wi-Fi on, mobile data off
Trigger:   Tap "Place order", then disable Wi-Fi within one second
Observe:   - A clear "no connection" state; no endless spinner
           - After reconnecting: exactly one order exists (order list and API)
           - Retrying does not charge the card twice
Devices:   Tier 1 Android and iOS

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

इंस्टॉल, अपडेट, अनइंस्टॉल और दोबारा इंस्टॉल

अपडेट वह जगह है जहाँ data migration के defect छिपते हैं: लोकल डेटाबेस का schema बदला, किसी preference key का नाम बदला, स्टोर किए token का फ़ॉर्मेट बदला, कोई cached फ़ाइल हट गई। हर उस पुराने वर्ज़न से अपडेट टेस्ट करें जिसे आप अब भी सपोर्ट करते हैं — पुराने builds को artefact के रूप में रखें ताकि उन्हें इंस्टॉल कर सकें — और यह डिवाइस पर असली जैसे डेटा के साथ करें, नए इंस्टॉल पर नहीं।

• सबसे पुराने और सबसे नए सपोर्टेड OS वर्ज़न पर साफ़ इंस्टॉल; बिना नेटवर्क के पहला लॉन्च।
• जिस डिवाइस पर लगभग कोई ख़ाली storage न बची हो, उस पर इंस्टॉल और पहला लॉन्च।
• पिछले वर्ज़न से और सबसे पुराने सपोर्टेड वर्ज़न से अपडेट, साइन-इन session, drafts, ऑफ़लाइन queue में रुकी actions, settings और डाउनलोड की गई फ़ाइलों के साथ — सब बचा रहे और यूज़र साइन-इन रहे।
• डाउनलोड या बैकग्राउंड sync चलते समय अपडेट।
• Forced update: न्यूनतम सपोर्टेड वर्ज़न से नीचे का वर्ज़न API कॉल फ़ेल होने के बजाय साफ़ update prompt दिखाए।
• अनइंस्टॉल और दोबारा इंस्टॉल: लोकल डेटा चला जाए, सर्वर डेटा लौट आए, backup और restore डिज़ाइन के अनुसार चलें। iOS पर कुछ Keychain डेटा ऐप हटने के बाद भी बचा रह सकता है, इसलिए तय करें और टेस्ट करें कि दोबारा इंस्टॉल को नया यूज़र माना जाए या नहीं।
• ऐप डेटा clear करें (Android) या ऐप offload करें (iOS, जो documents और डेटा रखता है) और फिर लॉन्च करें।

# Android (adb) — examples
adb install shop-3.8.0.apk                # old version; now sign in, create drafts, change settings
adb install -r shop-4.0.0.apk             # update, keeping app data
adb shell pm clear com.example.shop       # clear app data
adb uninstall com.example.shop

# iOS Simulator (xcrun simctl) — examples
xcrun simctl install booted Shop-3.8.app
xcrun simctl install booted Shop-4.0.app  # install the new build, then check what data survived
xcrun simctl uninstall booted com.example.shop

Runtime permissions: देना, मना करना, वापस लेना

Android ख़तरनाक permissions runtime पर माँगता है, और iOS तब पूछता है जब ऐप पहली बार किसी संरक्षित resource का इस्तेमाल करता है, ऐप का purpose text दिखाते हुए। दोनों प्लेटफ़ॉर्म पर यूज़र बाद में Settings से जवाब बदल सकता है, और नए वर्ज़न सिर्फ़ एक बार अनुमति देने या सटीक के बजाय अनुमानित लोकेशन साझा करने जैसे विकल्प जोड़ते हैं; Android ने notifications को भी runtime permission बना दिया है। ऐप को हर जवाब के साथ काम करना चाहिए — या साफ़ तरीक़े से सीमित होना चाहिए।

• पहले अनुरोध पर अनुमति: फ़ीचर ऐप को restart किए बिना तुरंत काम करे।
• इनकार: ऐप बताए कि क्या उपलब्ध नहीं है और दूसरा रास्ता दे (लोकेशन के बजाय पता टाइप करना)।
• दोबारा इनकार या "Don’t ask again": ऐप prompt को loop में न दोहराए; बताए कि Settings में permission कैसे चालू करें।
• Allow once / सिर्फ़ इस बार: अगला session फिर से पूछे, और फ़ीचर इसे सँभाले।
• अनुमानित लोकेशन या सीमित photo access: जिन फ़ीचर को ज़्यादा चाहिए वे चुपचाप फ़ेल होने के बजाय यह बताएँ।
• ऐप बैकग्राउंड में हो तब Settings से revoke करें। Android पर permission revoke होते ही ऐप का process kill हो जाता है; लौटने पर ऐप को किसी समझदार स्क्रीन पर साफ़ तरीक़े से restart होना चाहिए।
• Permission संदर्भ में माँगी जाए, जब फ़ीचर इस्तेमाल हो — पहले लॉन्च पर सब एक साथ नहीं — और purpose text सही हो।

# Android
adb shell pm grant  com.example.shop android.permission.CAMERA
adb shell pm revoke com.example.shop android.permission.CAMERA

# iOS Simulator
xcrun simctl privacy booted grant  photos com.example.shop
xcrun simctl privacy booted revoke photos com.example.shop
xcrun simctl privacy booted reset  all    com.example.shop

इंटरप्शन और ऐप lifecycle

इंटरप्शन वह सब है जो ऐप को foreground से हटाए या उसे ढक दे। सबसे ख़तरनाक वाला दिखता नहीं: ऐप बैकग्राउंड में हो तब OS मेमोरी वापस लेने के लिए उसका process kill कर सकता है, और यूज़र के लौटने पर ऐप को स्क्रीन दोबारा बनानी और टाइप किया हुआ वापस लाना होता है। Android पर developer option "Don’t keep activities" यूज़र के स्क्रीन छोड़ते ही उसे नष्ट कर देता है — state restoration की कमी पकड़ने का सस्ता तरीक़ा। rotation, भाषा, dark mode या font size जैसे configuration बदलाव भी Android पर डिफ़ॉल्ट रूप से स्क्रीन दोबारा बनाते हैं।

• फ़ॉर्म भरते, वीडियो चलते, रिकॉर्डिंग और पेमेंट के दौरान आने वाली कॉल — उठाई और काटी गई।
• दूसरे ऐप के notification; flow के बीच notification shade या Control Center खींचना।
• दूसरे ऐप पर जाएँ और कुछ सेकंड, कुछ मिनट और कई घंटे बाद लौटें (session expiry)।
• OTP का इंतज़ार करते या timer चलते समय स्क्रीन लॉक और अनलॉक करें।
• अलार्म बजे, या कम बैटरी की चेतावनी आए; battery saver या Low Power Mode चालू हो।
• ऑडियो चलते समय Bluetooth headphones डिस्कनेक्ट हों — playback रुकना चाहिए।
• Process death: ऐप को बैकग्राउंड में भेजें, process kill करें, Recents से दोबारा खोलें।
• दूसरे ऐप तक जाना और लौटना — बैंक ऐप, साइन-इन या 3-D Secure के लिए ब्राउज़र — सही स्क्रीन और सही स्थिति पर वापस लाए।
• Split screen, picture-in-picture, और flow के बीच foldable को मोड़ना या खोलना।

# Android — force the conditions
adb shell am kill com.example.shop          # kill the background process, then reopen from Recents
adb shell dumpsys battery unplug
adb shell dumpsys battery set level 5       # simulate a low battery
adb shell dumpsys battery reset
adb shell dumpsys deviceidle force-idle     # put the device into Doze
adb shell dumpsys deviceidle unforce

# Android emulator — incoming call and SMS
adb emu gsm call 5551234
adb emu sms send 5551234 "Your code is 482913"

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

नेटवर्क बदलाव, ऑफ़लाइन मोड और sync

मोबाइल पर नेटवर्क स्थिर नहीं, एक चर है। सिर्फ़ "online" और "offline" नहीं, बल्कि transitions और कनेक्शन की गुणवत्ता टेस्ट करें। ऑफ़लाइन काम करने वाले ऐप में sync सबसे बड़ा जोखिम है: queue में रुके बदलाव दो बार या ग़लत क्रम में भेजे जाना, डिवाइसों के बीच conflicts का चुपचाप सुलझ जाना, और ऐसे session में queue हुई actions जो इस बीच expire हो गया।

• Upload, download और streaming के दौरान Wi-Fi से cellular और वापस।
• Request के बीच airplane mode चालू और बंद।
• ऑफ़लाइन लॉन्च: साफ़ offline संकेत के साथ cached कंटेंट; actions queue में या कारण बताकर बंद।
• धीमा नेटवर्क (ज़्यादा latency, कम bandwidth): loading states, समझदार timeouts, और बेचैन टैप से दोहरा submission नहीं।
• रुक-रुक कर चलने वाला नेटवर्क (drops और packet loss): back-off के साथ retries, कोई duplicate record नहीं; ऑर्डर और पेमेंट request idempotent हों।
• Captive portal (होटल या एयरपोर्ट Wi-Fi): कनेक्टेड पर इंटरनेट नहीं — ऐप को JSON के बजाय HTML लॉगिन पेज मिलता है और उसे parsing error नहीं, नेटवर्क संदेश दिखाना चाहिए।
• ऑफ़लाइन conflict: डिवाइस A पर ऑफ़लाइन रिकॉर्ड बदलें, डिवाइस B पर वही रिकॉर्ड ऑनलाइन बदलें, A को दोबारा जोड़ें — तय conflict नियम लागू हो और दिखे।
• ऑफ़लाइन रहते session expire होने के बाद भेजी गई queued actions; ऑफ़लाइन रहते डिवाइस की घड़ी या timezone बदलना।
• Data saver या restricted background data चालू।

# Android
adb shell svc wifi disable     # and: enable
adb shell svc data disable     # and: enable

# Android emulator — start with a throttled network
emulator -avd Pixel_Test -netspeed edge -netdelay gprs

# iOS — Network Link Conditioner (device Developer settings, or Xcode additional tools for the Mac)

# Server side — point the app at an endpoint that answers slowly or with an error code

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

स्क्रीन, orientation, gestures और इनपुट

• इनपुट वाली हर स्क्रीन पर rotate करें: टाइप किया टेक्स्ट, चयन, scroll position और खुले डायलॉग बने रहें।
• ऐप खुले रहते dark mode बदलें; दोनों mode में contrast और इमेज जाँचें।
• सबसे बड़ा font size या Dynamic Type साइज़: कोई कटा या overlap होता टेक्स्ट नहीं, और लंबी स्क्रीन scroll हों।
• Android का display size बदलें; अपने मैट्रिक्स की सबसे छोटी और सबसे बड़ी स्क्रीन टेस्ट करें।
• कीबोर्ड: हर फ़ील्ड के लिए सही प्रकार (OTP और फ़ोन के लिए numeric, ईमेल के लिए email), focused फ़ील्ड और submit बटन दिखते रहें, "Next" focus आगे बढ़ाए, और जहाँ प्लेटफ़ॉर्म सपोर्ट करे वहाँ OTP autofill काम करे।
• Gestures: tap, double tap, long press, swipe, pinch, drag और pull-to-refresh; कस्टम edge swipe सिस्टम के back gesture से न टकराए।
• Submit बटन पर तेज़ बार-बार टैप से duplicates न बनें।
• Right-to-left: अरबी में layout mirror हो, swipe दिशाएँ और back तीर तर्कसंगत हों, मिला-जुला अरबी और लैटिन टेक्स्ट सही दिखे, और जहाँ ऐप अनुमति दे वहाँ इनपुट Arabic-Indic अंक स्वीकार करे।

# Android
adb shell settings put system font_scale 2.0     # large text (reset with 1.0)
adb shell wm size 1080x2400                      # emulate another screen (reset: wm size reset)
adb shell wm density 480                         # (reset: wm density reset)
adb shell cmd uimode night yes                   # dark mode on (no = off)

# iOS Simulator
xcrun simctl ui booted appearance dark
# larger text: raise the text size in the simulator’s Settings app

आज़माएँ: अरबी टेस्ट डेटा जनरेटर आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर आज़माएँ: फ़ेक फ़ोन नंबर जनरेटर

बैटरी, CPU, मेमोरी, storage और डेटा

Resource defect शायद ही कभी फ़ंक्शनल टेस्ट फ़ेल करते हैं। वे बाद में बैटरी की शिकायतों, "App not responding" डायलॉग, सुस्त scrolling और OS के ऐप kill करने के रूप में दिखते हैं। असली डिवाइस पर प्लेटफ़ॉर्म profilers (Android Studio के profilers, Xcode Instruments) से मापें, और हर रिलीज़ की तुलना किसी निरपेक्ष संख्या के बजाय पिछली रिलीज़ से करें।

• बैटरी: असली डिवाइस पर 30 मिनट का सामान्य session, पिछली रिलीज़ से तुलना; यूज़र के स्क्रीन छोड़ने पर location updates, sensors और wake locks रुकें; बैकग्राउंड काम Doze और Low Power Mode का सम्मान करे।
• CPU और rendering: सबसे कमज़ोर सपोर्टेड डिवाइस पर लंबी सूचियाँ smooth scroll हों; बिना वजह बैकग्राउंड में कुछ चलता न रहे।
• मेमोरी: मुख्य flow बीस बार दोहराएँ और जाँचें कि मेमोरी baseline पर लौटती है; बड़ी इमेज खोलें; कम RAM वाले डिवाइस पर टेस्ट करें।
• Storage: लगभग भरे डिवाइस पर writes शालीनता से फ़ेल हों; cache की सीमा हो और साफ़ हो; एक हफ़्ते इस्तेमाल के बाद ऐप का साइज़ उचित हो।
• डेटा: सामान्य session में खर्च हुआ cellular डेटा; स्क्रीन के हिसाब से साइज़ की गई इमेज; cellular पर बड़े डाउनलोड सिर्फ़ यूज़र की सहमति से।
• Start-up: सबसे कमज़ोर डिवाइस पर cold और warm start समय; कैमरा, वीडियो या मैप के लंबे session में गर्मी।

# Android — quick measurements
adb shell dumpsys meminfo com.example.shop
adb shell dumpsys gfxinfo com.example.shop       # frame rendering stats
adb shell dumpsys batterystats --reset
# ...run the session on battery...
adb shell dumpsys batterystats com.example.shop

आज़माएँ: रिस्पॉन्स साइज़ एनालाइज़र

Push notification

Push notification कई सिस्टम पार करता है: ऐप प्लेटफ़ॉर्म सेवा (Android पर Firebase Cloud Messaging, iOS पर APNs) के साथ रजिस्टर होता है, device token पाता है, उसे आपके बैक एंड को भेजता है, और बैक एंड प्लेटफ़ॉर्म सेवा के ज़रिए संदेश भेजता है। कहीं भी विफलता यूज़र को एक जैसी दिखती है — कुछ नहीं आता, या ग़लत चीज़ खुलती है — इसलिए chain और ऐप की स्थितियाँ अलग-अलग टेस्ट करें।

• Notification permission से इनकार: ऐप फिर भी काम करे और ऐप के अंदर विकल्प दे; ऐप की अपनी notification settings का सम्मान हो।
• ऐप foreground में (डिज़ाइन के अनुसार in-app banner या silent update), background में और killed स्थिति में डिलीवरी।
• टैप करने पर सही रिकॉर्ड के साथ सही स्क्रीन खुले — यूज़र साइन-आउट हो तब भी, और उस स्थिति में साइन-इन के बाद लक्ष्य खुले।
• साइन-आउट करें, फिर दूसरे यूज़र से साइन-इन करें: पहले यूज़र के notification अब न आएँ (token unregister या दोबारा assign हुआ)।
• दोबारा इंस्टॉल या restore: बैक एंड को नया token मिले और वह पुराने का इस्तेमाल बंद करे।
• कंटेंट: localized टेक्स्ट, right-to-left अरबी, लंबा टेक्स्ट, emoji और इमेज; लॉक स्क्रीन पर कोई संवेदनशील डेटा न दिखे।
• Badges साफ़ हों, notifications group हों, और Android notification channels की importance वही हो जो तय की गई।
• Scheduled notifications अलग-अलग timezones में सही लोकल समय पर पहुँचें।

# iOS Simulator — deliver a test notification without a server
xcrun simctl push booted com.example.shop order-shipped.apns

# order-shipped.apns
{
  "Simulator Target Bundle": "com.example.shop",
  "aps": { "alert": { "title": "تم شحن طلبك", "body": "Order A-1042 is on its way" }, "badge": 1 },
  "orderId": "A-1042"
}

आज़माएँ: अरबी टेस्ट डेटा जनरेटर

Defect के उदाहरण और मोबाइल बग रिपोर्ट में क्या लिखें

मोबाइल बग रिपोर्ट को वेब से ज़्यादा environment जानकारी चाहिए: डिवाइस मॉडल, OS वर्ज़न, ऐप वर्ज़न और build, नेटवर्क प्रकार, orientation, भाषा, font size, permission की स्थिति, और ऐप उस स्थिति तक कैसे पहुँचा (नया इंस्टॉल या किस वर्ज़न से अपडेट)। screen recording और डिवाइस log लगाएँ — Android पर logcat, iOS पर device console। बाक़ी फ़ॉर्मेट बग रिपोर्ट गाइड कवर करती है। नीचे के शीर्षक उन defects के उदाहरण मात्र हैं जिन्हें यह कैटलॉग पकड़ता है।

[Android, Pixel] Checkout crashes on resume after process death on the payment step
[iOS] Draft message lost when a phone call arrives while typing
Offline queue sends "Add to cart" twice after switching from Wi-Fi to 4G
Update 4.1 → 4.2: saved addresses missing (local database migration skipped)
"Order shipped" notification opens Home instead of order A-1042 when the app was killed
Location permanently denied: map screen shows an endless spinner and no link to Settings
Font size 200%: "Confirm" button off-screen on the OTP screen and not scrollable
Captive-portal Wi-Fi: app shows "Unexpected token <" instead of a network message

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

संदर्भ

• 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 टेस्ट, और बेहतरीन तरीके।
• XCTestAppleiOS और अन्य Apple प्लेटफ़ॉर्म पर Xcode प्रोजेक्ट के unit, performance और UI टेस्ट के लिए Apple का फ़्रेमवर्क।
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationमोबाइल ऐप के लिए OWASP की सुरक्षा आवश्यकताएँ, storage, cryptography, authentication, network और platform interaction जैसे नियंत्रण समूहों में।
• Test your app's accessibilityAndroid Developers (Google)Android ऐप की एक्सेसिबिलिटी को TalkBack जैसी सेवाओं से मैन्युअली और प्लेटफ़ॉर्म के टेस्टिंग टूल से ऑटोमेटेड तरीके से कैसे जाँचें।
• Accessibility — Human Interface GuidelinesAppleiOS और अन्य प्लेटफ़ॉर्म के लिए Apple की एक्सेसिबिलिटी डिज़ाइन गाइडेंस: VoiceOver, Dynamic Type, कंट्रास्ट, टच टारगेट और मोशन।