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

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

सिर्फ़ एक platform पर दिखने वाले defects शायद ही कभी उस business logic में होते हैं जो दोनों platforms साझा करते हैं। वे वहाँ दिखते हैं जहाँ app operating system से मिलता है: iOS पर deny की गई permission जिसे app बार-बार माँगता रहता है, Android का back press जो confirmation step छोड़ देता है, ऐसा build जो उस OS version पर अलग व्यवहार करता है जिसे team ने कभी install ही नहीं किया, या launch से एक दिन पहले store review में अटकी release।

Tester के लिए platform के नियम जानना अस्पष्ट scenarios को सटीक expected results में बदल देता है। "Permissions test करो" हर platform पर हर permission state के लिए एक ठोस case बन जाता है; "back navigation check करो" screens और gestures की ऐसी सूची बन जाता है जिसमें हर एक की expected destination लिखी है। यह आपको यह भी बताता है कि test device से आप क्या control कर सकते हैं और क्या सिर्फ़ platform तय करता है, ताकि आप defect सही जगह report करें।

टेस्टर की नज़र से Android और iOS

Android (Google) कई manufacturers के devices पर चलता है। System का core open source है, manufacturers अपनी layers जोड़ते हैं, और apps Google Play से, दूसरे stores से या सीधे APK file से install हो सकते हैं — इसीलिए testers को debug builds आम तौर पर files के रूप में मिलते हैं। Platform एक system-wide back action, runtime permission model, और OS versions व hardware का बहुत बड़ा फैलाव देता है।

iOS (Apple) सिर्फ़ iPhone पर चलता है, iPad पर iPadOS के साथ। Apple hardware, OS, build tools (Xcode, जिसके लिए Mac चाहिए) और मुख्य distribution channel, App Store, सबको control करता है (alternative app marketplaces सिर्फ़ कुछ regions में, जैसे EU में, allowed हैं)। Apps testers तक TestFlight या registered devices से जुड़े provisioning profiles के ज़रिए पहुँचते हैं। System back button नहीं है, camera या location जैसे protected resources के लिए घोषित purpose चाहिए, और नया iOS version सभी supported devices के लिए एक ही दिन release होता है।

जो एक जैसा रहता है वह सब कुछ जो आपने पहले सीखा: requirements, test design techniques, bug reports। जो बदलता है वह platform behaviour का oracle है। नीचे के चार differences ज़्यादातर platform-specific test cases cover करते हैं, और आख़िरी section आपको हर platform पर install, inspect और record करने के tools देता है; device sizes और device matrix अगले lesson का विषय हैं।

• Permissions: system कैसे और कितनी बार पूछता है, और deny के बाद क्या होता है।
• Back navigation: "back" का मालिक system है या app, और हर gesture का क्या मतलब है।
• Stores: build testers तक कैसे पहुँचता है, users तक कैसे, और store क्या जाँचता है।
• OS versions: एक साथ कितने version चलन में हैं, और उनके बीच व्यवहार क्या बदलता है।
• Toolkit: build device पर कैसे पहुँचता है, कौन सी developer settings मदद करती हैं, और logs व crash reports कहाँ हैं।

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

Permissions: एक dialog, नियमों के दो सेट

दोनों platforms पर protected resource (camera, location, microphone, contacts, photos, notifications) के लिए user की सहमति एक system dialog से चाहिए जिसे app न style कर सकता है न skip। अंतर sequence में है। Android पर permissions Android 6.0 से runtime पर माँगी जाती हैं; पहली deny के बाद app दोबारा पूछ सकता है, लेकिन Android 11 से दूसरी deny के बाद system dialog दिखाना बंद कर देता है, इसलिए app को Settings तक का रास्ता देना होता है। Android 11 ने location, microphone और camera के लिए "Only this time" grant भी जोड़ी, Android 12 ने approximate location जोड़ी, और Android 13 ने notifications post करने को runtime permission बना दिया। Android महीनों से इस्तेमाल न हुए app की permissions reset भी कर सकता है।

iOS पर system हर permission का dialog एक ही बार दिखाता है। Deny के बाद app उसे कभी दोबारा नहीं दिखा सकता; user को Settings app में setting बदलनी होती है, और app को यह समझाना होता है। camera, microphone, location, photos और contacts जैसे resources के लिए app की configuration में purpose string चाहिए (जैसे NSCameraUsageDescription); वह न हो तो access fail होता है और app crash हो सकता है, और App Review build reject करता है। Location में "Allow Once" जुड़ता है, जो app का इस्तेमाल रुकते ही expire हो जाता है ताकि app बाद में फिर पूछ सके, और precise-location switch भी; photos को चुने हुए items तक सीमित किया जा सकता है, notifications के लिए हमेशा से permission चाहिए, और apps के पार tracking के लिए अलग App Tracking Transparency prompt चाहिए।

App background में हो और Settings में permission बदली जाए तो app process खत्म हो सकता है: Android permission revoke होने पर उसे खत्म करता है, और iOS camera जैसी कई privacy settings के किसी भी दिशा में बदलने पर। तब app पर लौटना एक cold start है (app नए process में फिर से launch होता है), जिसे user की जगह restore करनी होती है। Mobile app test scenarios की companion guide generic permission scenarios सूचीबद्ध करती है; ऊपर के platform नियम हर एक का expected result बताते हैं।

• Context में माँगें: dialog feature इस्तेमाल करते समय, छोटे explanation के बाद दिखे, पहले launch पर नहीं।
• Denied: feature साफ़ message और काम करने वाले "Open Settings" action के साथ gracefully degrade हो; dialogs का loop न बने।
• बाद में Settings से granted: लौटने पर feature reinstall के बिना काम करे।
• Store compliance: हर permission के लिए app जो कारण बताता है वह वही कहे जो feature करता है (iOS पर purpose string; Google Play पर background location जैसी sensitive permissions के लिए ज़रूरी declaration); दोनों stores के reviewers अस्पष्ट या missing explanation reject करते हैं।

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

Worked example: QR payment flow में camera permission

Requirement: "Pay screen पर user Scan tap करता है और camera को merchant के QR code की ओर करता है। Camera उपलब्ध न हो तो user merchant code manually दर्ज कर सकता है।" Team यही feature Android और iOS दोनों पर ship करती है। नीचे वह permission behaviour है जिसकी tester हर platform से उम्मीद करता है, और यही test cases का expected-result column बनता है।

• TC-1 (दोनों): fresh install, Scan tap करें: explanation sheet, फिर system dialog; grant करें: camera उसी flow में खुलता है।
• TC-2 (Android 11 और बाद): एक बार deny करें, Scan फिर tap करें: system dialog दोबारा दिखता है; फिर deny करें, तीसरी बार Scan tap करें: कोई dialog नहीं, app manual entry का विकल्प और "Open Settings" button दिखाता है जो app के permission page पर पहुँचाता है।
• TC-3 (iOS): एक बार deny करें, Scan फिर tap करें: कोई system dialog नहीं; app manual entry और "Open Settings" दिखाता है; Settings में grant करके लौटें: app restart हो चुका है और Scan camera खोलता है।
• TC-4 (Android 11 और बाद): "Only this time" चुनें, भुगतान करें, कुछ देर app से बाहर रहें, लौटकर Scan tap करें: silent failure के बजाय dialog दोबारा दिखता है।
• TC-5 (दोनों): Pay screen खुली रहते Settings में camera permission revoke करें, लौटें: app बिना crash के साफ़ restart होता है, और pending payment state या तो restore होती है या साफ़ तौर पर cancel।
• TC-6 (दोनों): permission denied रहते manual code entry से भुगतान पूरा होता है, यानी deny कभी business goal नहीं रोकती।

Camera permission for "Scan a QR code to pay"

Permission state               Android 11+                   iOS
--------------------------------------------------------------------------------------
Never asked                    system dialog on request      system dialog on request
Denied once, asked again       dialog shown again            no dialog: route to Settings
Denied twice, asked again      no dialog: route to Settings  no dialog: route to Settings
"Only this time" granted       expires soon after leaving    not offered for the camera
Revoked in Settings while open process ends, relaunch        process ends, relaunch
Purpose text                   explain before the dialog     NSCameraUsageDescription

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

Back navigation: system back बनाम app का अपना back

Android में system-wide back action है: three-button navigation में button, और Android 10 से gesture navigation में edge-swipe gesture। यह जो भी screen पर है उसे मिलता है, और app तय करता है इसका मतलब: dialog बंद करना, पिछली screen पर लौटना, WebView के अंदर एक page पीछे जाना, या app की पहली screen पर app छोड़ देना। Android Up (app bar का arrow, जो app की hierarchy में ऊपर जाता है) और Back (जो user के कदम उल्टे दोहराता है) में भी फ़र्क़ करता है; deep link (ऐसा link जो app के अंदर कोई ख़ास screen खोलता है) के बाद दोनों अलग जगह ले जा सकते हैं। जो apps इसे support करते हैं, उनके लिए नए Android versions gesture पूरा होने से पहले यह preview भी दिखा सकते हैं कि back कहाँ ले जाएगा (predictive back), जिससे गलत destination तुरंत दिख जाती है।

iOS में system back नहीं है। पीछे जाना app का काम है: navigation bar के ऊपर-बाएँ back button, navigation stack के अंदर बाएँ किनारे से interactive swipe (अरबी जैसी right-to-left भाषाओं में दोनों दाईं ओर चले जाते हैं), sheet को नीचे swipe करके dismiss करना, और tabs जिनमें हर एक अपनी history रखता है। App किसी दूसरे app से खुला हो तो status bar उस app पर "Back to" link देता है। ऐसा custom navigation bar जो चुपचाप edge swipe बंद कर देता है, या ऐसी sheet जो unsaved form data के साथ dismiss हो जाती है, iOS-only defects के typical उदाहरण हैं।

• हर screen के लिए लिखें कि हर platform पर back को क्या करना चाहिए, फिर करके देखें: destination, और unsaved data का क्या होता है।
• Root screen पर back: Android app छोड़ देता है (या "press back again to exit" दिखाता है); iOS पर इसका समकक्ष home gesture है, जो app को सिर्फ़ background में भेजता है।
• Request चलते समय back (Pay, Submit): action दो बार न भेजा जाए और result खोए नहीं।
• Rotation के बाद, permission dialog के बाद, background से लौटने के बाद और deep link के बाद back: stack अब भी ठीक रहे।
• Android पर WebView screens: back पहले page history में पीछे जाए, फिर WebView छोड़े।

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

Stores, releases और OS versions

Google Play app को Android App Bundle से publish करता है, और production से पहले internal, closed और open testing tracks, users के एक percentage तक staged rollout जिसे रोका जा सकता है, और pre-launch report देता है जो build को devices के एक set पर चलाकर crashes report करती है। Play के बाहर APK सीधे install हो सकता है, और कुछ devices Google services के बिना ही ship होते हैं। App Store Xcode से upload किया build लेता है; TestFlight उसे 100 internal और 10,000 external testers तक पहुँचाता है (builds 90 दिन में expire होते हैं, और external testers को भेजा गया पहला build beta review से गुज़रता है), App Review production build जाँचता है, और phased release update को सात दिनों में फैलाती है और pause हो सकती है। कोई भी store update कर चुके users को पिछले build पर वापस नहीं ले जाता: आप rollout रोकते या pause करते हैं और ऊँचे version number वाला fixed build ship करते हैं।

दोनों stores listing को app से मिलाते हैं: privacy declarations (Play का Data safety section, App Store के App Privacy labels), permissions के लिए बताए गए कारण, screenshots, और वे features जहाँ reviewer सच में पहुँच सकता है। Review rejection release defect है, इसलिए submission से पहले listing और app में reviewer का रास्ता test करें, उस test account समेत जो reviewer इस्तेमाल करेगा।

OS versions दोनों platforms पर अलग व्यवहार करते हैं। Android releases को API level से पहचानता है (Android 15 यानी API 35); updates manufacturers के ज़रिए devices तक पहुँचते हैं, इसलिए कई versions सालों तक चलन में रहते हैं। आपका app सबसे निचला version जिस पर वह install होगा (minSdkVersion) और वह version जिसके behaviour को वह अपनाता है (targetSdkVersion) घोषित करता है; Google Play हालिया target माँगता है, और उसे बढ़ाने से आपके app के लिए behaviour changes चालू हो जाते हैं — इसलिए target bump एक test event है। iOS एक version सभी supported devices को एक ही दिन भेजता है, बीच में कोई manufacturer नहीं होता, और हर गर्मियों में public beta आता है; apps deployment target घोषित करते हैं, और कुछ behaviour changes तभी लागू होते हैं जब app नए SDK से rebuild हो, इसलिए नया Xcode भी test event है।

• Install path: वह build test करें जो users को मिलेगा (store track या TestFlight), सिर्फ़ developer का debug build नहीं।
• Update path: पिछला production version install करें, इस्तेमाल करें, फिर update करें; data और sessions बचे रहने चाहिए।
• OS set: newest version और उसका beta, oldest supported version, और वे manufacturer layers जो आपके ज़्यादातर traffic ले जाती हैं; analytics, store consoles और crash reports बताते हैं कि असल में कौन से OS versions आते हैं, जबकि web traffic की User-Agent strings कम मदद करती हैं, क्योंकि Android पर Chrome और iOS 26 से Safari frozen OS version बताते हैं (अगला lesson इसे matrix बनाता है)।
• Forced update: back end जब पुराना version बंद करे, app यह बताए और store का link दे; Android in-app updates भी देता है।

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

हर platform पर टेस्टर की toolkit

Emulator, simulator या असली device: यह device-strategy का फ़ैसला है जिसे mobile testing guide cover करती है; यह section मानता है कि आपके पास build और हर platform के लिए कम से कम एक device या emulator है। Android पर toolkit adb है (Android Debug Bridge, SDK platform tools में), जो USB पर तब काम करता है जब Settings में build number सात बार tap करके Developer options चालू हों और USB debugging on हो। APK adb install से install होता है; Android App Bundle (AAB) सीधे install नहीं हो सकता, इसलिए universal APK माँगें, bundletool से bundle के device APKs बनाएँ, या उसे Play की internal app sharing पर upload करें जो install link देती है। Play के testing tracks ऐसे release candidates ले जाते हैं जो बिल्कुल production की तरह signed होते हैं।

iOS पर build असली device तक TestFlight (invitation या public link) से पहुँचता है, या development या ad hoc build के रूप में जिसके provisioning profile में device का UDID (unique device identifier) हो और जो Xcode की Devices and Simulators window से install होता है; iOS 16 से development-signed build चलाने के लिए Privacy & Security में Developer Mode चालू करना होता है। iOS Simulator को Mac से xcrun simctl चलाता है: app install करना, deep link खोलना, permission reset करना, screen record करना। दो तरह की developer settings हर test plan में जगह पाने लायक हैं। पहली है Android का "Don’t keep activities", जो हर screen को छोड़ते ही नष्ट कर देता है, जिससे खोई हुई form state और लौटने पर crash सामने आते हैं। दूसरी है network throttling: iOS का Network Link Conditioner (Settings > Developer, जो device को Xcode के साथ इस्तेमाल करने पर दिखता है) धीमे, packet खोने वाले या failing network की नक़ल करता है, Android emulator के network controls धीमा network type, कमज़ोर signal या बंद data connection set करते हैं, और हाल के Android versions असली device पर Developer options में network download rate limit भी देते हैं।

Logs आपका सबूत हैं। Android सब कुछ logcat में लिखता है: हर line में time, process id, V (verbose) से F (fatal) तक priority और एक tag होता है; adb logcat उसे stream करता है, --pid उसे आपके app तक सीमित करता है, और adb bugreport पूरे logs को ANR traces के साथ developer के लिए एक zip में पैक करता है। ANR (Application Not Responding) वह "isn’t responding" dialog है जो Android तब दिखाता है जब app का main thread (जो screen बनाता है और taps handle करता है) blocked रहता है, जैसे लगभग पाँच सेकंड तक input handle न करना। Play crash और ANR rates को Android vitals में track करता है, जहाँ user-perceived crash rate 1.09% से ऊपर या ANR rate 0.47% से ऊपर bad behaviour गिना जाता है और Google Play पर app की visibility घटा सकता है। iOS एक unified log रखता है जिसे आप device जोड़कर Mac पर Console app में live पढ़ते हैं, या Xcode के console में जब app Xcode से launch हुआ हो। Crash logs (.ips files) device पर Settings > Privacy & Security > Analytics & Improvements > Analytics Data में रहते हैं, और Xcode का Organizer उन TestFlight और App Store users के symbolicated crashes (memory addresses की जगह function names के साथ) इकट्ठा करता है जो उन्हें share करते हैं। iOS में ANR dialog नहीं है: watchdog उस app को terminate कर देता है जो main thread block करता है या बहुत धीरे launch होता है, और crash log में यह exception code 0x8badf00d के रूप में दिखता है।

• एक command में permission states: Android पर adb shell pm grant और pm revoke (revoke app process खत्म करता है, Settings की तरह), iOS Simulator पर simctl privacy grant, revoke या reset; simctl privacy में camera service नहीं है, इसलिए worked example जैसे camera cases के लिए असली iPhone चाहिए; असली device पर "never asked" का मतलब है uninstall और reinstall।
• Screen recording: Android पर adb shell screenrecord या Quick Settings का built-in recorder (Android 11 और बाद), Developer options में "Show taps" चालू करके ताकि हर tap दिखे; iOS पर Control Center का recorder, cable से Mac पर QuickTime, या Simulator पर simctl io recordVideo।
• हर platform bug के साथ जोड़ें: Android पर logcat का excerpt या bug report, iOS पर crash log या Console का excerpt, और gesture या dialog की recording। TestFlight testers beta app के अंदर से screenshot और comment भी भेज सकते हैं।
• Logcat की capture लंबी होती है, और उसकी lines में आपके package का नाम नहीं बल्कि process id होती है; ऐसा regular expression जो सिर्फ़ आपके app की process id और W, E, F priorities की lines रखे, उसे पढ़ने लायक attachment बना देता है।

# Android (adb from the SDK platform tools; USB debugging on)
adb devices                                  # the phone is listed as "device"
adb install -r app-debug.apk                 # install or update the build
adb shell pm grant com.example.pay android.permission.CAMERA
adb shell pm revoke com.example.pay android.permission.CAMERA
adb logcat --pid=$(adb shell pidof -s com.example.pay)   # your running app only
adb bugreport bugreport.zip                  # full logs and ANR traces
adb shell screenrecord /sdcard/scan.mp4      # Ctrl+C stops it; then:
adb pull /sdcard/scan.mp4

# iOS Simulator (xcrun simctl, from Xcode on a Mac)
xcrun simctl install booted Pay.app
xcrun simctl privacy booted reset location com.example.pay   # back to "never asked"
xcrun simctl openurl booted "pay://scan"
xcrun simctl io booted recordVideo scan.mp4

आज़माएँ: Regex टेस्टर

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

संदर्भ

• 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 टेस्ट, और बेहतरीन तरीके।
• Android vitalsAndroid Developers (Google)उपयोगकर्ताओं के डिवाइस से Google Play द्वारा जुटाए गए ऐप-गुणवत्ता मेट्रिक्स — core vitals में user-perceived crash और ANR rate — और वे bad-behavior thresholds जो ऐप की दृश्यता पर असर डालते हैं।