From MobileBDD scenarios to executable Maestro flows
Annual estimate for 2025
Statista Market Insights (2026), converted to EUR using ECB 2025 average.
Smartphone sales in Germany, Apr–Jun 2025
Required for efficient application development.
Check the intended behaviour through the UI.
Same intent different selectors and interaction steps.
How can a shared language help verify application behaviour across both platforms?
Final thesis · Introduction, pp. 1–2; §3.1.2, pp. 18–19
Applies BDD to Android testing with manual step definitions.
Specify UI interactions and check artefact consistency.
Formalise BDD scenarios as models for test generation.
Approach for UI test generation from BDD-like scenarios, wireframes and mappings.
Gap: no reviewed approach covers specification through execution and evaluation on Android and iOS.
Final thesis · Introduction, pp. 1–2 · §2.2, BDD-based UI testing · §2.5, comparison of closely related approaches
Contribution of this work.
DSL for mobile
UI scenarios.
Abstract Interaction Model
providing the context for MobileBDD
Runs UI tests on Android and iOS.
Compiler pipeline stages.
The set of MobileBDD scenarios used for evaluation.
Final thesis · §§3.1–3.3, 4.3
S1 + S2
What compilation success rate does the proposed compiler achieve, when transforming the MobileBDD scenarios in ℰ into syntactically valid Maestro flows?
S3 · Android and iOS
What expected terminal-status conformity rate do the generated Maestro flows for ℰ achieve on Android and iOS?
S4 · Android and iOS
What differential raw-status consistency is observed between the generated flows for ℰ and corresponding manual comparator flows on Android and iOS?
Final thesis · RQ wording condensed from p. 2 · criteria: Table 4, p. 24
@SCN-F1-01-PScenario: Opening Getreidegasse displays its activity detailsGiven a visitor has opened the Salzburg activitiesWhen the visitor opens activity "Getreidegasse"Then activity details for "Getreidegasse" should be displayedto the context free grammar
Final thesis · §4.2 · Listing 5, p. 44 · line breaks adapted for display
Final thesis · §§3.1–3.5, pp. 17–28 · §4.2 · §5.1, pp. 50–52
Final thesis · §3.1.2, pp. 18–19 · representative SUT screens
| Protocol | Purpose | Composition |
|---|---|---|
| ℰ | All reported RQ measures | 32 variants 16 paths 8 interaction categories |
| 10 runs | Same ℰ in every repetition, per platform |
RQ1:
320 shared compilation observations
RQ2–RQ3:
320 × 2 OS × (1 manual + 1 generated)
Total:
1,280 logical flow executions
|
| Retry policy | Interaction or infrastructure failure |
At most one retry Recovery = flaky pass |
Android + iOSOne emulator and one simulator; fixed configuration.
Final thesis · §§3.1–3.5, pp. 17–28 (retry policy: §3.5.2, p. 27) · Table 11, p. 51
Shared compilation observations
100%
32 known variants × 10 repetitions
Final retained outcomes
Android · 99.375%
iOS · 100%
Final retained outcomes
Android · 99.375%
iOS · 100%
8/10 complete run bundles passed.
Final thesis · §§5.1–5.5 · Tables 14–16, pp. 53–55
Transfer to unseen scenarios and applications remains untested.
Shared interpretation can inflate status consistency.
Repetitions describe this setup; they cannot rank platforms.
Final thesis · §6.3, pp. 59–61; §7.2, p. 63
.mbdd files, defined by ANTLR .g4 grammarsGenerated flows run on Android and iOS.
Linked reports separate compilation, runtime conformity and status consistency.
Final thesis · §§4.1–4.2, pp. 28–37; §6.2, pp. 57–59; §7.1, p. 62
Independent validation Review assertions and traces
Failure reproduction Vary state, execution order and devices
Transfer & reuse Other apps via AIM · another backend
Effort comparison Authoring and maintenance vs. direct Maestro
Final thesis · §7.3, pp. 63–65
MobileBDD to MaestroAn implemented compiler workflow with separately measured compilation, runtime conformity and status consistency.