ابزارهای تست

انتخاب ابزار تست موبایل؛ PoC از Device و Driver تا CI و TCO

انتشار در تاریخ توسط محمد عسکری

یک تیم سه نامزد ابزار تست موبایل را مقایسه کرد. نامزد Cloud با ۳۲ قابلیت روی کاغذ برنده بود؛ اما تست Release build آن ضعیف بود، اجرای آفلاین نداشت، پروژه و شواهد کامل را Export نمی‌کرد و دسترسی پایدار از ایران نیز ثابت نشد. اگر Feature count معیار تصمیم بود، تیم دقیقاً گران‌ترین ریسک را انتخاب می‌کرد.

انتخاب ابزار تست موبایل، انتخاب یک Logo یا Recorder نیست. تصمیم واقعی درباره یک Stack است: Framework/Runner، Driver، APIهای Android/iOS، Build و Signing، Device/Simulator، Test data، Backend، CI، Artifact و نگهداری. هر حلقه می‌تواند Journey را سبز، Flaky یا غیرقابل‌تشخیص کند.

این راهنما یک روش خریدارمحور و Buyer-operated ارائه می‌دهد: Problem brief→App/Platform map→Hard gates→Representative PoC→Change/Failure exercise→Evidence score→TCO/Exit. مثال‌ها برای تیم‌های ایرانی و اپ‌های Native، React Native، Flutter و Hybrid طراحی شده‌اند.

پاسخ کوتاه: ابزار تست موبایل را چگونه انتخاب کنیم؟

ابتدا Critical journeyها، پلتفرم/معماری، تعامل‌های OS و Device matrix را Freeze کنید. سپس هر Candidate stack را روی همان App، Release-like artifact، Dataset و Deviceها اجرا کنید. قابلیت‌های Must-have را به Hard gate تبدیل کنید؛ Flake، repair effort، diagnosis، CI throughput، امنیت داده، دسترسی ایران، TCO و Export را با Evidence امتیاز دهید. Demo فروشنده یا تعداد Feature برای تصمیم کافی نیست.

Business risk + critical journeys
  -> app/platform/OS interaction map
  -> candidate stack and exact versions
  -> hard gates
  -> buyer-operated PoC
  -> deliberate app/OS/device changes
  -> first-attempt reliability + repair + evidence
  -> TCO + Iran continuity + exit rehearsal
  -> adopt / complement / reject

مرز این مقاله با راهنماهای نزدیک

راهنمای تست اپلیکیشن موبایل مالک استراتژی عمومی Android/iOS، انواع تست، lifecycle و چک‌لیست است. مقاله حاضر فقط انتخاب و صلاحیت‌سنجی Stack اتوماسیون موبایل را مالک است.

راهنمای Browser و Device Matrix قرارداد پشتیبانی و انتخاب OS/Device/Locale را عمیق می‌کند. اینجا Matrix ورودی PoC و اجرای CI است، نه موضوع اصلی.

برای انتخاب عمومی ابزارهای Web/API/Mobile به راهنمای انتخاب ابزار تست اتوماسیون مراجعه کنید. ۱۲۳۵ تفاوت Driver، OS automation، Release artifact، Device lab و تعامل‌های خاص موبایل را تخصصی می‌کند.

واحد تصمیم «Stack» است، نه Tool

لایه نمونه ریسک انتخاب
Test API/DSL Kotlin/Swift/JS/Dart/Java/Python خوانایی، Type، Skill، Debug
Runner JUnit/XCTest/Jest/Flutter test Filter، shard، retry، report
Automation framework Espresso/Compose/XCUIAutomation/Detox Synchronization و App insight
Protocol/server Appium/WebDriver Latency، command mapping، compatibility
Platform driver UiAutomator2/XCUITest driver نسخه OS/SDK و capability
App harness test build/DI/launch args Fidelity و testability
Device layer Emulator/Simulator/real/cloud Availability، hardware، state
Build/signing APK/AAB/IPA/xctestrun/provisioning Release parity و secrets
CI/orchestration macOS/Linux runners/device farm Queue، parallelism، cost
Evidence logcat/xcresult/video/screenshot Diagnosis، privacy، retention

ممکن است Appium server ثابت بماند ولی Driver، Client library، Xcode، Android SDK، WebView/Chromedriver یا OS image تغییر کند و نتیجه عوض شود. Decision record باید کل Stack را نسخه‌دار کند.

Problem brief قابل‌اندازه‌گیری بنویسید

«بهترین ابزار موبایل می‌خواهیم» مسئله نیست. قالب کوتاه:

product: Iranian marketplace app
architecture: Kotlin Android + Swift iOS + shared HTTP backend
critical journeys: login/OTP, search, cart, PSP deep link, order status
release cadence: 3 releases/week
support contract: Android API ...; iOS ...; fa-IR/RTL
current pain: 140 min manual regression; payment escapes; flaky UI suite
target: PR signal <15 min; nightly critical matrix <90 min
hard risks: duplicate payment, cross-user state, permission/deep-link failure
data/security: synthetic only; source/binary upload restrictions
operations: Iran network; offline fallback; macOS capacity
owner/budget/horizon: named team; 3-year TCO
decision date/review triggers: OS/framework/device/vendor change

Outcome را از Feature جدا کنید

  • «Video recording دارد» Feature است؛ «شکست Permission را زیر پنج دقیقه تشخیص می‌دهیم» Outcome است.
  • «Parallel execution دارد» Feature است؛ «۲۰ Test روی چهار Device بدون Port/Data collision تمام می‌شود» Evidence است.
  • «Cross-platform است» Claim است؛ «هشت Journey با چه درصد کد/Adapter مشترک و چه repair effort اجرا شد» سنجه است.
  • «AI self-healing دارد» Feature است؛ «هیچ False Pass پس از تغییر Locator/Label ایجاد نکرد» شرط تصمیم است.

App map را پیش از Candidate list بسازید

معماری سطح‌های تست سؤال تخصصی
Native Android Unit/Compose or View/Instrumentation/System UI Espresso/Compose/UI Automator کجا؟
Native iOS Unit/Integration/XCUIAutomation Target، signing، simulator/real device؟
React Native JS/component/native module/E2E Gray-box compatibility و RN version؟
Flutter Unit/widget/integration/native surface Platform UI چگونه کنترل می‌شود؟
Hybrid/WebView Native shell + web context + backend Context switching و WebView driver؟
Mobile web Browser engine/responsive/real device آیا واقعاً App automation لازم است؟

اگر محصول Mobile web است، Stack مرورگر شاید مناسب‌تر از Appium باشد. اگر Native app با تست‌پذیری خوب دارید، ابزار پلتفرمی ممکن است سریع‌ترین Feedback را بدهد. اگر تیم Black-box مشترک Android/iOS می‌خواهد، Driver stack می‌تواند ارزشمند باشد؛ هیچ پاسخ از پیش برنده نیست.

Critical journey و سطح Fidelity را Freeze کنید

PoC باید کار واقعی را اجرا کند، نه Login demo. Dataset نمونه:

  1. نصب پاک، اولین اجرا، Locale فارسی و Permission اولیه؛
  2. ورود با OTP مصنوعی و انقضا/ارسال مجدد؛
  3. جست‌وجو، Scroll، Keyboard فارسی و افزودن کالا؛
  4. Checkout با نمایش تومان و مبلغ Canonical ریال؛
  5. خروج به PSP simulator و بازگشت Deep link؛
  6. Background/foreground، process death و ادامه State؛
  7. Push notification مصنوعی و navigation درست؛
  8. Network کند/قطع/برگشت و Retry بدون اثر تکراری؛
  9. Logout و نبود State/Token حساس؛
  10. Update از نسخه قبلی با data migration.

هر Candidate همان Artifact، Data، Backend، Device و Failureها را ببیند. اگر یکی Debug APK و دیگری Release-like IPA اجرا کند، مقایسه معتبر نیست.

Hard gateها قبل از Score

یک Candidate با امتیاز میانگین بالا نباید نقص حیاتی را جبران کند. Hard gateهای نمونه:

  • اجرای Journeyهای Critical روی Android و iOS هدف؛
  • Release-like build با signing/obfuscation/config واقعی؛
  • Permission، Deep link، notification و process lifecycle لازم؛
  • CLI headless، deterministic exit code و CI artifact؛
  • Deviceهای واقعی/مجازی موردنیاز و نسخه OS هدف؛
  • Source/Binary/Test data/Secret policy قابل‌قبول؛
  • First-attempt result و Retry شفاف؛
  • اجرای آفلاین یا fallback موردنیاز؛
  • تداوم فنی/تجاری/شبکه‌ای ایران با Evidence تاریخ‌دار؛
  • Export کامل Test، Config، Raw result و Evidence؛
  • بدون False Pass در Mutationهای کسب‌وکار؛
  • Owner و مسیر Debug برای تیم دوم.

Offering map نسخه‌دار بسازید

candidate: exact product/project
edition/license: community/team/enterprise or OSS license
framework/server: name + version + digest
drivers/plugins: exact packages + versions
client/runner: language + library + runner
host: OS/CPU/JDK/Node/Xcode/Android SDK
target: Android/iOS versions + app architecture
devices: model/OS/real-virtual/provider/region
build: debug/release-like/signing/entitlements
cloud: tier/concurrency/retention/data region
integrations: CI/TMS/issue/report API versions
support: channel/SLA/coverage hours
access evidence: account/payment/download/license/network/date
export/exit: formats/API/raw artifacts/rebuild proof

Appium ۳ را یک Package یکپارچه با همه Driverها فرض نکنید. مستندات نصب Appium ۳ صریح می‌گوید نصب Server هیچ Driverی را همراه نمی‌آورد؛ Driver هدف باید جدا نصب و نسخه‌دار شود.

Native platform stack چه زمانی مناسب‌تر است؟

Android: Espresso، Compose و UI Automator

مستندات رسمی Android UI testing تست‌های UI را Instrumented integration tests می‌داند که از Component کوچک تا Navigation بزرگ گسترده‌اند. Framework باید با معماری View/Compose، Dependency injection و API levelهای واقعی شما سنجیده شود.

  • Espresso برای Viewهای داخل App و synchronization پلتفرمی مفید است؛
  • Compose testing بر Semantics tree و Clock/idle کنترل‌شده تکیه می‌کند؛
  • UI Automator برای تعامل cross-app/system UI مناسب‌تر است؛
  • ترکیب آن‌ها ممکن است لازم باشد؛ یک API همه سطح‌ها را کامل نمی‌پوشاند.

راهنمای رسمی Compose testing Semantics، synchronization و interoperability با View را جزء مفاهیم اصلی می‌داند. در PoC بررسی کنید Componentهای سفارشی Semantics مفید و یکتا تولید می‌کنند؛ Tag مخفی بدون Accessibility معنا ممکن است نگهداری را بهتر نکند.

iOS: XCTest و XCUIAutomation

مستندات XCTest اپل برای UI Test همچنان XCTest همراه XCUIAutomation را معرفی می‌کند؛ Swift Testing جدید برای Unit Test به‌معنای جایگزینی UI automation نیست. PoC باید Test target، launch arguments، accessibility identifiers، Simulator/real device، signing و Result bundle را شامل شود.

مزیت و هزینه Native

  • مزیت: نزدیکی به API/diagnostics پلتفرم، synchronization و Developer workflow.
  • هزینه: دو Codebase/Skill/CI path برای Android و iOS.
  • ریسک: اشتراک کمتر Test code، اما Adapter کمتر و Debug مستقیم‌تر.
  • تصمیم: هزینه کد تکراری را با repair/diagnosis واقعی مقایسه کنید، نه با LOC خام.

Appium را به‌عنوان Driver stack ارزیابی کنید

Appium یک Server/extension ecosystem است. همان Command می‌تواند در Driverهای مختلف با فناوری زیرین متفاوت پیاده شود؛ بنابراین «پشتیبانی از Android و iOS» به‌تنهایی parity رفتاری را اثبات نمی‌کند.

راهنمای معماری Driverهای Appium توضیح می‌دهد UiAutomator2 driver علاوه بر فناوری Android از ADB/SDK و helper app استفاده می‌کند، درحالی‌که XCUITest driver بخش Device-side مبتنی بر XCTest دارد. Bug triage باید Server، Client، Driver، OS harness، Device و App را تفکیک کند.

PoC مخصوص Driver stack

  • Server/driver/client compatibility و Upgrade rehearsal؛
  • Session creation time و failure classification؛
  • Native/WebView context switching و WebView/Chromedriver match؛
  • Parallel session port/device isolation؛
  • App install/update/reset/activate/terminate semantics؛
  • Gesture، keyboard، picker، scroll، alert و system UI؛
  • Android logcat و iOS/WDA/Xcode diagnostic artifacts؛
  • Driver-specific command/Capability و portability cost؛
  • real-device signing/provisioning/USB/tunnel behavior؛
  • Offline installation of Server/Driver/Chromedriver dependencies.

مستندات XCUITest driver مسیر Command را از Client به Appium، Driver، WebDriverAgent و XCTest نشان می‌دهد و Target/Contextهای پشتیبانی‌شده را نسخه‌دار می‌کند. نام مشترک WebDriver نباید تفاوت WebView، Real device و ابزارهای Apple را پنهان کند.

React Native و Detox

Detox یک Framework Gray-box E2E برای React Native است که synchronization را با مشاهده internals App هدف می‌گیرد. این مزیت باید روی Architecture و Version واقعی سنجیده شود، نه اینکه «Zero flakiness» را نتیجه قطعی هر پروژه بدانیم.

Hard questions برای Detox

  • نسخه دقیق React Native/New Architecture در compatibility window است؟
  • Expo/Native module/custom renderer/platform view چه محدودیتی دارد؟
  • Resourceهای async سفارشی Idle می‌شوند یا نیاز به synchronization adapter دارند؟
  • Debug و Release configuration هر دو قابل Build/Run هستند؟
  • Permission/System UI/notification/deep link روی Android و iOS چگونه پوشش می‌گیرند؟
  • TestID به عنصر Native درست propagate می‌شود؟
  • Migration RN/Jest/Detox چه Repair effortی دارد؟

مستندات فعلی Detox دامنه و compatibility مشخصی اعلام می‌کند و Expo integration را community-driven می‌داند. این قیدها باید در Offering map ثبت و روی پروژه شما آزمایش شوند.

Flutter integration_test و مرز Platform UI

راهنمای رسمی تست Flutter Unit، Widget و Integration را تفکیک و integration_test را در SDK معرفی می‌کند. همان مستندات هشدار می‌دهد این Package با بعضی UIهای Native مانند Permission dialog، Notification یا Platform view تعامل مستقیم ندارد؛ برای App شما ممکن است complement پلتفرمی یا Framework دیگری لازم باشد.

PoC مخصوص Flutter

  • Widget key/semantics و localization؛
  • Platform channels و plugin failure؛
  • Permission dialog و system picker؛
  • Deep/universal/app links و notification؛
  • Native payment/map/camera WebView/Platform view؛
  • Physical/emulator execution و Test Lab packaging؛
  • Debug/profile/release-like تفاوت؛
  • Android/iOS adapter و repair effort.

Cross-platform یعنی اشتراک Intent، نه لزوماً Script واحد

Journey «پرداخت سفارش» می‌تواند مشترک باشد، اما Locator، System dialog، Permission، Keyboard، Back navigation، Deep link، WebView و Evidence در Android/iOS متفاوت‌اند. معماری سالم معمولاً Intent و Domain oracle مشترک، ولی Adapter پلتفرمی صریح دارد.

CheckoutJourney
  - createSyntheticCart()
  - app.searchAndAdd(product)
  - app.checkout()
  - os.openPaymentRedirect()
  - psp.approveOnce()
  - os.returnViaDeepLink()
  - oracle.assertOnePaidOrder()

AndroidAppAdapter: Compose/View/UIAutomator details
iOSAppAdapter: XCUIElement/springboard details
DomainOracle: API/Ledger/Order evidence

Reuse را چگونه اندازه بگیریم؟

  • درصد Journey intent مشترک؛
  • درصد Driver/platform adapter code؛
  • تعداد conditional branch بر OS؛
  • تغییر یک UI pattern و files/tests touched؛
  • repair minutes برای Android و iOS؛
  • False Pass/Fail ناشی از abstraction؛
  • زمان diagnosis برای مهندس پلتفرم.

یک File مشترک با ده‌ها if (platform) ممکن است LOC کمتر اما TCO و Blast radius بیشتر داشته باشد.

Locator contract: TestID تنها پاسخ نیست

Locator باید معنای پایدار، uniqueness و diagnosability داشته باشد. اولویت عملی بسته به Framework:

  1. Accessibility/semantic role، label و state مناسب؛
  2. Test ID قراردادی برای کنترل مبهم/بدون متن؛
  3. متن فقط وقتی localization خودِ Contract است؛
  4. ساختار scoped و relationship؛
  5. Coordinate/image/XPath عمیق فقط با Risk و Evidence.

Mutationهای Locator

  • Label فارسی «پرداخت» به «پرداخت ۱۲۵٬۰۰۰ تومان» تغییر کند؛
  • دو Button با متن یکسان ظاهر شود؛
  • View به Compose یا UIKit به SwiftUI مهاجرت کند؛
  • Accessibility ID اشتباه تکرار شود؛
  • List virtualized/recycled شود؛
  • RTL ترتیب Visual را عوض کند؛
  • WebView context دیر Load شود؛
  • Permission dialog متعلق به OS باشد.

نامزد باید شکست ambiguous را واضح Fail کند، نه اینکه اولین Match را لمس و False Pass بسازد. اگر Codeless/Self-healing مطرح است، راهنمای ارزیابی اتوماسیون بدون کد Mutation و False-pass gate را عمیق می‌کند.

Synchronization را بر Condition بسنجید

Mobile UI ترکیبی از Animation، main thread، network، database، JS bridge، background task و system transition است. Sleep ثابت ابزار را ساده نشان می‌دهد ولی Suite را Flaky و کند می‌کند.

منبع Async شرط معتبر ضدالگو
Network UI state/domain response مشخص sleep 5s
Animation idle/disabled animation/visibility tap پشت سر هم
Background sync event/state probe wait arbitrary
WebView context + DOM readiness فقط page source
Permission OS dialog/state فرض Allow قبلی
Deep link foreground route + domain state وجود toast

Synchronization PoC

Latency را ۵۰/۵۰۰/2000ms، animation scale را معمول/کاهش‌یافته، CPU را Busy و response order را متغیر کنید. First-attempt pass rate، duration distribution و timeout diagnosis را ثبت کنید. Auto-wait Claim بدون این آزمون Evidence نیست.

Lifecycle و OS interaction را در PoC اجباری کنید

  • Install، clean launch، warm launch و upgrade؛
  • Background/foreground و task switch؛
  • Process death و state restoration؛
  • Permission grant/deny/don’t ask/revoke از Settings؛
  • Deep link/App Link/Universal Link valid/invalid؛
  • Notification foreground/background/tap؛
  • Keyboard فارسی، paste، return، hide/show؛
  • Rotation، split/fold/tablet در صورت Support؛
  • Low storage/memory/network transitions تا حد مجاز؛
  • Camera/file/contact/location picker با داده مصنوعی؛
  • Biometric success/failure/cancel در Profile مجاز؛
  • Clock/locale/timezone change و expiry.

همه Appها همه موارد را نمی‌خواهند. App map تعیین می‌کند کدام تعامل Hard gate است. Toolی که فقط App-owned UI را خوب می‌بیند می‌تواند کنار یک System-UI lane مکمل مناسب باشد.

Real Device و Virtual Device را نقش‌بندی کنید

Virtual ارزان‌تر/دردسترس‌تر و برای Feedback گسترده مناسب است؛ Real device برای Hardware/driver/vendor/thermal/camera/biometric/network و بعضی Release رفتارها ضروری‌تر است. هیچ‌کدام به‌تنهایی «واقعیت کاربر» کامل نیستند.

Firebase Test Lab در مستندات فعلی Android و iOS، Deviceهای میزبانی‌شده، Matrix، CLI/CI و Artifactها را ارائه می‌کند و صریحاً می‌گوید برای Load testing Backend ساخته نشده است. دسترسی و Data flow این SaaS باید جدا از قابلیت فنی ارزیابی شود.

Matrix نقش‌محور

Lane Device هدف
Developer local emulator/simulator + one device debug سریع
PR small virtual tier critical deterministic feedback
Nightly expanded virtual + selected real OS/device/locale coverage
Pre-release risk-selected real devices hardware/release/upgrade
Field production telemetry/beta escaped configuration learning

Release-like artifact یک Hard gate است

Debug build ممکن است minification، obfuscation، signing، entitlement، ATS/Network config، logging، feature flag، WebView debug، anti-tamper، push environment و Backend endpoint متفاوت داشته باشد. PoC باید Artifactهای زیر را تفکیک کند:

  • Developer debug برای سرعت و diagnosis؛
  • Testable release-like با Seamهای محدود و امن؛
  • Store candidate نهایی برای تعداد کم Smoke/critical tests؛
  • Production build بدون test-only backdoor.

اگر Tool فقط با Debuggable WebView یا Test framework embedded کار می‌کند، Coverage gap و Store/security constraint را ثبت کنید؛ مخفی‌کردن تفاوت Debug/Release خطرناک‌تر از رد Candidate است.

Testability contract را همراه ابزار بسنجید

Tool نمی‌تواند App غیرقابل‌کنترل را جادویی پایدار کند. App باید Semantic/Accessibility identifier، launch argument، Fake/Simulator محدود، Clock/ID کنترل‌شده، state reset، synthetic account و safe evidence ارائه کند.

risk: duplicate PSP callback changes order twice
control: simulator sends same signed callback twice
observe: UI state + Order API + ledger + audit
oracle: one Paid transition; one debit; one notification
identity: run/tenant/order/authority/trace IDs
reset: namespaced account + simulator reset + TTL
artifact: release-like digest + config
safety: synthetic data; no production PSP
budget: PR 90s; nightly 4-device matrix
owner: mobile QA + payments team

راهنمای انتخاب فریم‌ورک اتوماسیون معماری Runner/Driver/Data/Oracle/Report را عمیق می‌کند. در Mobile PoC، Design for Testability باید بخشی از Candidate cost باشد، نه کار رایگان و نامرئی تیم محصول.

Oracle را از UI Toast فراتر ببرید

لایه Oracle مثال False Pass پنهان‌شده
UI semantics Paid state visible/accessible Spinner روی دکمه
Navigation route/back stack/deep link target صفحه درست با stack غلط
API/domain Order status/amount/currency Toast موفق، Order pending
Side effect one debit/event/notification پرداخت تکراری
Absence no second order/token/PII اثر ممنوع نامرئی
Platform permission/notification/link state App state fake
Persistence state after relaunch/upgrade فقط memory state

ابزار باید API/fixture/helper و Evidence بیرونی را قابل‌اتصال کند. یک Suite UI که فقط Screenshot یا Text را Assert می‌کند برای Risk مالی کافی نیست.

Data، Identity و Reset در Deviceهای موازی

هر Test execution باید Namespace یکتا داشته باشد؛ Device reset به‌تنهایی Backend، Push، PSP simulator یا Cache را پاک نمی‌کند.

  • Run ID→Actor/Tenant/Cart/Order/Phone/Email مصنوعی؛
  • setup/teardown idempotent و TTL؛
  • Device state clean/upgrade/retained صریح؛
  • OTP/Push/Deep-link inbox مخصوص Run؛
  • PSP Authority و callback namespace؛
  • Clock و timezone کنترل‌شده؛
  • Parallel worker و Device lease در Evidence؛
  • پاک‌سازی backend/device/cloud artifacts و verification.

«noReset=true» یا حفظ App data یک بهینه‌سازی نیست مگر Precondition دقیق داشته باشد. State leakage باعث order dependency و Pass/Fail کاذب می‌شود.

Parallelism را واقعاً Qualification کنید

Capability «parallel execution» با Throughput واقعی فرق دارد. Bottleneck می‌تواند Build، signing، Simulator boot، Device queue، App install، Session/WDA، Test data یا Backend باشد.

آزمایش پله‌ای

  1. یک Worker/یک Device، warm و cold baseline؛
  2. ۲/۴/۸ Worker با Dataset و Device مستقل؛
  3. Measure queue/setup/install/session/test/teardown/upload؛
  4. port/UDID/simulator/cache/keychain/data collision injection؛
  5. یک Device offline/crashed/quarantined؛
  6. Retry تنها Failed test روی Device تازه؛
  7. Device replacement و Result reconciliation؛
  8. Cost per valid critical journey.

AndroidJUnitRunner filtering و sharding را پشتیبانی می‌کند و Android Test Orchestrator می‌تواند هر Test را در invocation جدا اجرا کند. این امکانات هزینه setup و state semantics دارند؛ روی Suite واقعی اندازه بگیرید.

Run health و failure taxonomy

هر شکست «App defect» نیست. Taxonomy عملی:

  • Product: رفتار/Oracle کسب‌وکار شکست؛
  • Test: Locator/Data/Assertion/cleanup غلط؛
  • Framework/Driver: command/session/synchronization defect؛
  • Device/OS: boot/offline/storage/system state؛
  • Environment: backend/build/signing/network unavailable؛
  • Evidence: artifact ناقص یا corrupt؛
  • Inconclusive: رفتار قابل‌تعیین نیست؛
  • Invalid: Precondition/Artifact/Device/Profile غلط یا unsafe.

Candidate باید این طبقه‌بندی را آسان کند. اگر هر شکست فقط «element not found» است، Score گزارش‌دهی بالا نباید بگیرد.

Evidence bundle موبایل

  • Run/Test/Attempt/Worker/Device lease ID؛
  • App digest/version/build type/signature؛
  • Framework/Driver/Client/Runner/Host/SDK versions؛
  • Device model/OS/ABI/locale/timezone/orientation/real-virtual؛
  • Network profile/backend/config/feature flags؛
  • step timeline، first-attempt و retry outcome؛
  • Screenshot/video فقط در نقاط مفید؛
  • UI hierarchy/semantics snapshot redacted؛
  • logcat/xcresult/WDA/server/app logs؛
  • API/domain/side-effect evidence و Correlation IDs؛
  • crash/ANR/hang artifacts؛
  • cleanup status و retention policy.

Evidence زیاد بدون Correlation فقط هزینه Storage است. Tool باید به‌ازای Fail Artifact کافی نگه دارد و در Pass، Capture را کمینه کند؛ Token، OTP، شماره موبایل، آدرس، کارت و KYC مصنوعی نیز باید Redact شوند.

Change exercise مهم‌تر از Demo اولیه است

بعد از سبزشدن PoC، تغییرهای کنترل‌شده اعمال کنید:

  • Button layout و Label فارسی تغییر کند؛
  • View→Compose یا UIKit→SwiftUI یک Component مهاجرت کند؛
  • Android/iOS نسخه جدید به Matrix اضافه شود؛
  • React Native/Flutter/SDK/Driver minor upgrade؛
  • WebView/browser engine به‌روزرسانی؛
  • Permission flow یا Deep link route تغییر کند؛
  • Backend latency و Error shape تغییر کند؛
  • CI worker/Device provider unavailable شود؛
  • Test owner دوم شکست را Debug و Fix کند.

زمان review، failures، files touched، repair minutes، false pass/fail و rollback را ثبت کنید. Ease of use باید با تغییر و شکست سنجیده شود، نه ساخت اولین Test.

امنیت، Privacy و Supply chain

  • Source/Binary/Test data/Video/UI tree/log کجا Upload می‌شود؟
  • Region، retention، encryption، access، deletion و subprocessor چیست؟
  • Cloud tunnel به شبکه خصوصی چه Scope و auditی دارد؟
  • Signing key/provisioning profile/keystore چگونه مدیریت می‌شود؟
  • Driver/plugin/npm/Gradle/CocoaPods packageها pin و verify می‌شوند؟
  • Test framework یا debug endpoint وارد Store artifact نمی‌شود؟
  • Remote device session پس از Run reset می‌شود؟ Evidence چیست؟
  • Screen recording و log PII/Secret را حذف می‌کنند؟

برای کنترل‌های فنی موبایل و Release artifact به راهنمای تست امنیت اپلیکیشن موبایل مراجعه کنید. ابزار اتوماسیون عمومی جای Mobile security test یا RoE را نمی‌گیرد.

Performance را از UI Functional Automation جدا کنید

Duration یک UI Test معیار Startup/Jank/Battery نیست؛ Runner، wait، capture، network و device queue آن را آلوده می‌کنند. Candidate می‌تواند Journey functional را اجرا کند، ولی Performance evidence باید stopwatch/trace/metric تعریف‌شده داشته باشد.

راهنمای تست عملکرد اپلیکیشن موبایل Android/iOS startup، frame، memory، energy و native tracing را تفکیک می‌کند. در Scorecard، «Performance test support» را فقط با یک آزمایش معتبر امتیاز دهید.

CI/CD و Pipeline lanes

Lane Artifact/Device Suite Gate
Commit host/local unit/widget/component fast deterministic
PR debug/testable + small virtual critical slice valid first-attempt
Post-merge release-like + virtual broader regression/failure risk threshold
Nightly expanded virtual+real matrix/lifecycle/race trend/quarantine
Pre-release store candidate + selected real critical/upgrade/deep link release decision
Post-release beta/field telemetry safe smoke/learning rollback/monitor

Gate نمونه

  • تمام Runهای اجباری Valid؛
  • Critical journey روی Tier-۱ Android/iOS پاس؛
  • هیچ False Pass mutation؛
  • First-attempt reliability بالاتر از threshold محلی؛
  • Quarantine بدون Owner/expiry وجود ندارد؛
  • Release-like artifact و Device profile درست؛
  • Evidence/redaction/cleanup کامل؛
  • Coverage gap و exception تاریخ‌دار.

دسترسی ایران و unavailable scenario

برای هر Offering/Tier/تاریخ جدا بررسی کنید: Signup، payment، license activation، Package/image download، Device region، Queue، Support، IP range، VPN policy و data transfer. وضعیت یک Vendor یا یک روز را به همه تعمیم ندهید.

  • آیا Server/Driver/SDK/Device image و وابستگی‌ها Mirror می‌شوند؟
  • آیا macOS/iOS runner داخلی یا جایگزین قراردادی دارید؟
  • Cloud Device lab بدون کارت/Account خارجی فعال می‌ماند؟
  • اگر SaaS قطع شد، Critical PR/Release lane کجا اجرا می‌شود؟
  • Binary/source/evidence اجازه خروج دارد؟
  • Queue/region/deviceهای موردنیاز واقعاً از ایران قابل‌استفاده‌اند؟
  • License expiry/offline grace و emergency renewal چیست؟
  • Export و replay محلی آخرین Run ممکن است؟

Unavailable drill را در PoC اجرا کنید: Network SaaS را قطع کنید، package cache را تازه/خالی آزمایش کنید و زمان بازیابی Critical suite روی fallback را اندازه بگیرید.

TCO سه‌ساله Stack موبایل

TCO = license/subscription + cloud device minutes + macOS/device lab
    + build/signing/storage/network + framework/driver upgrades
    + test authoring + app testability seams + data/backend simulators
    + flake triage + repair after app/OS changes + on-call/support
    + security/legal/procurement + training/hiring
    + migration/export/rebuild + outage/queue cost

هزینه را با Workload واقعی محاسبه کنید

  • Test count و average/p95 duration؛
  • Android/iOS/device tier multiplier؛
  • PR/merge/nightly/release frequency؛
  • retry/invalid/flake rate؛
  • concurrency و queue wait؛
  • artifact storage/retention/egress؛
  • monthly repair/upgrade/triage hours؛
  • optimistic/base/pessimistic scenarios.

Open source به‌معنای هزینه صفر و Commercial به‌معنای پشتیبانی/سهولت تضمین‌شده نیست. راهنمای ابزار تست متن‌باز یا تجاری License، SBOM، support، TCO، Fork و Exit را عمیق‌تر می‌کند.

Scorecard شواهد، نه نظر

معیار وزن نمونه Evidence
Critical journey coverage ۱۶٪ same dataset run
OS interaction ۱۳٪ permission/link/notification/lifecycle
Release-build fidelity ۱۲٪ signed artifact run
First-attempt reliability ۱۴٪ repeated matrix
Change/repair effort ۱۱٪ deliberate change exercise
Evidence/diagnosis ۱۰٪ second-person debug
CI/device operations ۱۰٪ parallel/failure drill
Cross-platform leverage ۶٪ shared intent/adapters/branches
TCO ۸٪ measured workload

امتیاز صفر تا پنج را با سطح Evidence تعریف کنید: Unknown، ادعا، Demo، Pilot، failure/change proven، production over cycles. Hard gateهای Security، Release build، Access و Export را خارج میانگین نگه دارید.

آزمایش قطعی انتخاب Stack

یک برنامه مستقل Node.js ۲۴.۱۸.۰ سه Stack کاملاً ساختگی را مقایسه کرد. Feature count انتخاب ساده را ساخت؛ سپس Hard gate و Scorecard وزن‌دار اعمال شد.

naive_feature_winner=ShabnamCloudStudio features=32
ArioNative score=4.43/5 gates=pass
BamdadDriverStack score=4.34/5 gates=pass
ShabnamCloudStudio score=4.26/5 gates=fail(offline_execution,complete_export,iran_access_continuity,release_build)
decision=ArioNative
decision_note=validate_platform_specific_gaps_before_adoption

تفسیر نتیجه

Shabnam با ۳۲ Feature برنده ساده بود، اما اجرای آفلاین، Export کامل، تداوم دسترسی ایران و Release build را رد کرد؛ Score ۴٫۲۶ نتوانست Hard gateها را جبران کند. ArioNative با ۴٫۴۳ جلو افتاد و Bamdad با ۴٫۳۴ نزدیک بود. نتیجه «Native همیشه بهتر است» نیست؛ فقط در این Requirements و Weightهای ساختگی برنده شد و شکاف‌های هر پلتفرم باید پیش از Adoption آزموده شوند.

محدودیت‌ها: نامزدها و اعداد ساختگی‌اند؛ Feature، TCO و Reliability واقعی Benchmark نشده؛ uncertainty و sensitivity کامل مدل نشده؛ و Candidate واقعی ممکن است با Architecture، نسخه یا Tier دیگر نتیجه متفاوتی بدهد. این یک Demonstration تصمیم است، نه رتبه‌بندی Vendor/Framework.

PoC دوهفته‌ای که واقعاً قدرت تصمیم دارد

PoC نباید نمایش خوش‌رنگ یک Login ساده باشد. یک Sprint کوتاه با Scope ثابت بسازید که همان Journey، داده، Build و Device Matrix را برای همه نامزدها اجرا کند. پیش از شروع، Gate، Weight، Budget و معیار توقف را امضا کنید تا بعداً نتیجه با علاقه تیم یا Demo فروشنده جابه‌جا نشود.

روز صفر: قرارداد آزمایش

  • یک Critical journey و دو Failure path با ارزش کسب‌وکار انتخاب کنید؛
  • نسخه اپ، Backend، Test account، داده و Network profile را Freeze کنید؛
  • دو Android tier و دو iOS tier، شامل حداقل یک Real device، تعیین کنید؛
  • Hard gate، Scorecard، Evidence level و روش محاسبه TCO را ثبت کنید؛
  • زمان آموزش، Authoring، CI setup، Debug و Repair را جدا Log کنید؛
  • مالک هر نامزد و Reviewer مشترک را مشخص کنید.

روزهای ۱ تا ۳: Thin slice انتها‌به‌انتها

اولین Test باید از Repository تا CI و Artifact قابل‌ردیابی عبور کند: Provision data، نصب Build، اجرای Journey، Assertion، Evidence، Cleanup و انتشار نتیجه. اگر سه روز فقط صرف نوشتن Selector شد، مشکل را به‌عنوان هزینه یادگیری یا Testability ثبت کنید؛ آن را پنهان نکنید.

PoC run contract
input: commit, app_build_sha, backend_env, dataset_id, device_profile
output: verdict, assertion_evidence, logs, screenshots/video, timing
required: cleanup_status, retry_history, framework/driver/device versions
forbidden: manual state repair, silent retry, shared mutable account

روزهای ۴ تا ۶: تکرار و Failure injection

هر نامزد را چند دور روی Matrix ثابت اجرا کنید؛ فقط Pass rate نگیرید. Airplane mode، پاسخ ۵۰۰، latency، Kill/restore، permission denial، expired session و duplicate callback را وارد کنید. هدف این است که Test هم شکست محصول را ببیند و هم شکست زیرساخت خود را درست طبقه‌بندی کند.

روزهای ۷ تا ۸: تغییر عمدی و Repair

یک تغییر واقعی مانند جابه‌جایی Component، تغییر Localization، Migration یک Screen، عوض‌شدن API field و Permission flow جدید اعمال کنید. تعداد فایل‌های شکسته، زمان تشخیص، زمان تعمیر، مقدار platform branching و نیاز به متخصص را اندازه بگیرید. Maintainability با اسلاید یا تعداد Page Object ثابت نمی‌شود.

روز ۹: اختلال سرویس و خروج

دسترسی Cloud یا Package registry را قطع کنید، یک دستگاه را از Pool خارج کنید و Credential را Rotate کنید. سپس Test critical را روی مسیر جایگزین اجرا و تمام Script، Config، Result و Evidence را Export کنید. اگر خروج فقط با تماس فروشنده ممکن است، همان را به‌عنوان Risk و Cost بنویسید.

روز ۱۰: Blind review و تصمیم مشروط

Reviewer دوم باید بدون کمک نویسنده، یک Failure را از Artifact تشخیص دهد و یک تغییر کوچک را اعمال کند. سپس Evidenceها امتیازدهی شوند. خروجی PoC بهتر است «Adopt with conditions»، «Extend PoC» یا «Reject» باشد؛ نه یک برنده بی‌قید.

سناریوی نمونه ایرانی: پرداخت و بازگشت از درگاه

فرض کنید اپ فروش بلیت روی Android و iOS کار می‌کند. کاربر مسیر تهران–شیراز را انتخاب می‌کند، کد تخفیف می‌زند، با Deep Link از درگاه برمی‌گردد و بلیت باید دقیقاً یک‌بار صادر شود. این Journey برای Qualification مناسب است، چون UI، Backend، Lifecycle، Browser/Bank boundary، Network و Idempotency را هم‌زمان درگیر می‌کند.

پیش‌شرط و Oracle

  • رزرو ساختگی با TTL معلوم و Account اختصاصی Run ساخته شود؛
  • مبلغ قبل و بعد تخفیف از API مرجع خوانده شود؛
  • Callback موفق، ناموفق، تکراری و دیررس شبیه‌سازی شود؛
  • پس از بازگشت، UI وضعیت درست، Backend یک Order و Ledger یک Charge داشته باشد؛
  • Push یا Inbox رسید به Correlation ID همان Run متصل باشد؛
  • اطلاعات کارت، Token و PII در Log/Video Mask شوند.

Variantهای اجباری

  1. بازگشت موفق با App در Foreground؛
  2. بازگشت موفق پس از Kill و Restore؛
  3. قطع Network بعد از پرداخت و پیش از نمایش رسید؛
  4. Callback تکراری بدون صدور بلیت دوم؛
  5. لغو کاربر و آزادشدن Seat؛
  6. Expired reservation و پیام قابل‌اقدام؛
  7. فونت بزرگ، RTL و Keyboard در فرم؛
  8. اجرا روی Release-like signed build.

ابزاری که فقط Tapها را اجرا کند ولی نتواند Deep Link، Lifecycle، Backend Oracle یا Evidence امن را مدیریت کند، Coverage این Journey را ندارد؛ حتی اگر همه گام‌های UI سبز دیده شوند.

Operating model؛ چه کسی مالک چه چیزی است؟

دارایی مالک پاسخ‌گو تعهد عملیاتی
Framework و shared libraries Test platform/enablement نسخه، الگو، Upgrade و پشتیبانی
Screen contract و test IDs تیم Feature موبایل Testability همراه Definition of Done
Journey و Oracle QA/SDET همان Domain Risk coverage، Assertion و نگه‌داری
Backend fixtures Service team Seed، reset، simulator و schema
Device lab و signing Platform/DevOps Pool health، identity، secret و capacity
Quarantine Test owner با Product visibility Owner، علت، expiry و coverage exception
Security/privacy Security و Data owner Redaction، retention، access و vendor review

یک Guild می‌تواند استاندارد و Library مشترک بسازد، اما مالکیت Failure باید نزدیک Domain بماند. اگر همه شکست‌ها به یک تیم مرکزی صف شوند، Feedback کند و Context گم می‌شود؛ اگر هر تیم Stack جدا بسازد، هزینه و Evidence پراکنده می‌شود.

Runbook شکست را قبل از Scale بنویسید

هر Failure باید حداقل به Product، Test، Environment/Data، Device/OS، Framework/Driver، CI/Infra یا Unknown طبقه‌بندی شود. Runbook بگوید چه Artifactی دیده شود، چه کسی Page شود، Retry چه زمانی مجاز است و چه زمانی Release متوقف می‌شود.

if assertion proves wrong business state => product_failure
else if test contract/selector/oracle is wrong => test_failure
else if dataset or backend health is invalid => environment_failure
else if device/driver/runner is unhealthy => infrastructure_failure
else => unknown_and_block_until_triaged

Unknown را با Retry سبز نکنید. یک Retry تشخیصی می‌تواند Evidence اضافه تولید کند، اما First-attempt verdict و retry history باید حفظ شوند.

معیارهای سلامت پس از Adoption

هدف محلی تعیین کنید و Trend را بر اساس Journey، پلتفرم، Device tier و Failure class ببینید. عدد جهانی جادویی وجود ندارد؛ Baseline خودتان مهم‌تر است.

  • First-attempt reliability: سهم Runهای معتبر که بدون Retry verdict پایدار می‌دهند؛
  • Invalid run rate: Runهایی که به‌دلیل زیرساخت/داده قابل قضاوت نیستند؛
  • False-pass escapes: نقص‌هایی که Suite باید می‌گرفت ولی نگرفت؛
  • Median و p95 feedback time: شامل Queue، Provision و Artifact upload؛
  • Time to diagnose: از Failure تا طبقه‌بندی قابل‌اعتماد؛
  • Repair effort: ساعت نگه‌داری به‌ازای تغییر App/OS/Driver؛
  • Quarantine age و coverage debt: نه فقط تعداد Test قرنطینه؛
  • Device availability: ظرفیت سالم برای Matrix لازم؛
  • Cost per valid signal: کل هزینه Run تقسیم بر verdictهای معتبر؛
  • Adoption latency: زمان افزودن Journey جدید توسط تیم غیرمتخصص.

داشبوردی که Retry آن را زیبا نکند

Pass-after-retry را Pass ساده نمایش ندهید. First attempt، final attempt، invalid، quarantined و not-run را جدا کنید. Denominator باید روشن باشد؛ حذف Testهای سخت از Suite نباید Reliability را مصنوعی بالا ببرد.

تمرین خروج؛ قابلیت مهاجرت را اثبات کنید

Exit فقط بندی در قرارداد نیست. یک Journey، Fixture، Config و Evidence را بدون دسترسی Vendor به محیط دوم منتقل کنید. زمان، کد قابل‌استفاده مجدد، فرمت‌های اختصاصی، Dependencyهای مخفی و از‌دست‌رفتن History را ثبت کنید.

  • Repository و Test logic واقعاً در مالکیت شماست؟
  • Runner و Report با فرمت مستند روی CI دیگر اجرا می‌شوند؟
  • Device profile و secret mapping قابل بازسازی‌اند؟
  • Result، attachment، audit history و metadata Export کامل دارند؟
  • Test IDها و Traceability پس از مهاجرت حفظ می‌شوند؟
  • تعهد حذف داده از SaaS قابل‌اثبات است؟

اگر ۸۰ درصد Script قابل‌انتقال باشد اما Oracle، Device orchestration و Evidence pipeline از نو ساخته شوند، آن ۸۰ درصد معیار گمراه‌کننده‌ای است. Exit cost را در سطح Stack حساب کنید.

۱۵ ضدالگوی انتخاب ابزار تست موبایل

  1. برنده‌کردن Feature list: تعداد قابلیت، Hard gate یا کیفیت Signal را نشان نمی‌دهد.
  2. Demo روی Login: Lifecycle، Deep Link، Backend و Failure path پنهان می‌ماند.
  3. مقایسه روی Scope متفاوت: یک نامزد Debug build و دیگری Release build را اجرا می‌کند.
  4. «یک Script برای همه» به‌عنوان هدف: تفاوت معنادار Android/iOS به Branch پنهان و Assertion ضعیف تبدیل می‌شود.
  5. وابستگی به Sleep: Flake به‌جای Synchronization طراحی‌شده وارد Suite می‌شود.
  6. اتکا به XPath شکننده: تغییر Layout هزینه تعمیر غیرضروری می‌سازد.
  7. فقط Emulator/Simulator: Driver، سخت‌افزار، Performance و رفتار Real device پوشش نمی‌گیرد.
  8. فقط Real device در PR: Queue و Cost، Feedback را بی‌دلیل کند می‌کند.
  9. Shared test account: Parallel runها داده هم را خراب و Verdict را نامعتبر می‌کنند.
  10. Retry نامرئی: Suite سبز می‌شود اما First-attempt reliability سقوط می‌کند.
  11. خرید پیش از PoC: Marketing claim جای Evidence محیط خودتان را می‌گیرد.
  12. نادیده‌گرفتن Testability: هزینه واقعی به تیم محصول منتقل و از TCO حذف می‌شود.
  13. نسخه بدون سیاست Upgrade: تغییر OS، SDK، Driver یا Xcode ناگهان Release lane را می‌شکند.
  14. فرض دائمی‌بودن دسترسی SaaS: پرداخت، Region، Queue یا Account continuity آزمایش نمی‌شود.
  15. نداشتن Exit rehearsal: Vendor lock-in فقط هنگام بحران آشکار می‌شود.

چک‌لیست نهایی انتخاب و پذیرش

  1. Intent خرید و Riskهای کسب‌وکار نوشته شده‌اند.
  2. App map شامل Tech، OS، Native boundary و Release artifact کامل است.
  3. Critical journey و Failure pathهای نماینده انتخاب شده‌اند.
  4. لایه مناسب هر Test از Unit تا System مشخص است.
  5. Offering، Framework، Driver، Runner و Device service با هم قاطی نشده‌اند.
  6. Hard gateها پیش از Scorecard تصویب شده‌اند.
  7. نامزدها روی Build، داده، Journey و Matrix برابر اجرا شده‌اند.
  8. Native، React Native یا Flutter fit با محدودیت‌های رسمی بررسی شده است.
  9. Selector contract و Testability seams با تیم محصول توافق شده‌اند.
  10. Wait و Synchronization بدون Sleep دلخواه طراحی شده‌اند.
  11. Oracle فقط به Toast و HTTP status محدود نیست.
  12. داده هر Run مستقل، قابل Seed و قابل Cleanup است.
  13. Real device و Virtual device نقش مشخص و مکمل دارند.
  14. Release-like signed build در Gate اجرا شده است.
  15. Evidence برای Reviewer دوم کافی و از PII پاک است.
  16. Repeated run، Failure injection و Change exercise انجام شده‌اند.
  17. Queue، concurrency، shard، retry و quarantine سیاست روشن دارند.
  18. Unavailable drill و مسیر fallback ایران آزموده شده است.
  19. TCO سه‌ساله با workload و سناریوی بدبینانه محاسبه شده است.
  20. Adoption شرط‌دار، Owner، Review date و Exit rehearsal ثبت شده‌اند.

پیشنهاد تصمیم یک‌صفحه‌ای

Decision: Adopt / Adopt with conditions / Extend PoC / Reject
Scope: app, platforms, journeys, build, device tiers
Evidence: repeated runs, failures, change, CI, exit
Hard gates: pass/fail + artifact links
Weighted score: score + uncertainty + sensitivity
Economics: 3-year TCO scenarios
Risks: owner, mitigation, due date, trigger
Exceptions: coverage gap, expiry, approver
Review: OS/SDK/driver/vendor/app-change date

این سند کوتاه باید به Raw evidence پیوند داشته باشد. تصمیم را با تغییر عمده معماری اپ، نسخه OS/Xcode/SDK، Driver، قرارداد Vendor، Workload یا دسترسی منطقه‌ای بازبینی کنید؛ انتخاب ابزار یک رویداد یک‌باره نیست.

سؤالات متداول انتخاب ابزار تست موبایل

برای تست موبایل Appium بهتر است یا Espresso و XCUITest؟

برنده عمومی وجود ندارد. Appium می‌تواند یک Interface مشترک و Driverهای پلتفرمی بدهد؛ Espresso/Compose testing و XCUITest به قابلیت‌های Native نزدیک‌اند. App architecture، Journey، OS boundary، مهارت تیم، CI، Reliability و هزینه تعمیر را روی PoC مشترک بسنجید. ممکن است Stack ترکیبی بهترین پاسخ باشد.

آیا یک کد تست برای Android و iOS واقعاً شدنی است؟

بخشی از Intent، Domain helper و Scenario data می‌تواند مشترک باشد، اما UI، Permission، Lifecycle، Navigation و Accessibility tree همیشه یکسان نیست. درصد reuse را هدف اصلی نکنید؛ کیفیت Assertion، شفافیت Adapterها و هزینه تغییر مهم‌تر است.

Emulator و Simulator کافی‌اند یا Real Device لازم است؟

برای Feedback سریع و Matrix گسترده، Virtual device بسیار مفید است؛ اما Hardware، OEM behavior، Driver chain، Push، Camera/Biometric و برخی Performance/Network رفتارها به Real device نیاز دارند. Tierها را Risk-based ترکیب کنید: PR سریع، Nightly گسترده و Release gate روی دستگاه‌های بحرانی.

PoC انتخاب ابزار تست موبایل چند روز طول بکشد؟

برای یک Scope محدود، Sprint دوهفته‌ای نقطه شروع عملی است، نه قانون. PoC تا وقتی Decision evidence نساخته تمام نیست: Journey واقعی، repeated run، failure injection، change/repair، CI، Release build، access drill و Exit. اگر Scope پیچیده‌تر است، زمان را افزایش دهید اما معیارها را عوض نکنید.

ابزار متن‌باز برای تیم ایرانی بهتر است یا Cloud تجاری؟

نوع License به‌تنهایی پاسخ نمی‌دهد. متن‌باز ممکن است کنترل و اجرای محلی بدهد اما عملیات و تخصص بخواهد؛ Cloud ممکن است Device coverage و Scale بدهد اما دسترسی، هزینه، Privacy و Exit ریسک شوند. Offering مشخص را در تاریخ مشخص، با fallback محلی و TCO واقعی بررسی کنید.

جمع‌بندی؛ ابزار را به‌عنوان Stack عملیاتی انتخاب کنید

انتخاب ابزار تست موبایل مسابقه Appium، Espresso، XCUITest، Detox یا یک Device Cloud نیست. تصمیم خوب از Risk و Journey شروع می‌شود، لایه‌های Framework تا Device و CI را جدا می‌بیند، Hard gate را بیرون میانگین نگه می‌دارد و ادعاها را با PoC برابر آزمایش می‌کند.

اگر فقط یک کار انجام می‌دهید، یک Critical journey را روی Release-like build با Real/Virtual Matrix اجرا کنید؛ سپس Failure، تغییر عمدی، قطع سرویس و خروج را تمرین کنید. انتخابی که در این چهار وضعیت Evidence قابل‌اعتماد، زمان تشخیص مناسب و هزینه قابل‌پیش‌بینی می‌سازد، برای تیم شما ارزشمندتر از نام مشهور یا بلندترین Feature list است.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید