Analysis of the arguments against migrating E2E tests to the platform engineering repos.
The only real benefit the plan offers over the status quo is: "Android engineers can write tests in Kotlin".
If the goal is for software engineers to contribute, a good README and an onboarding session on qa-core-mobile-automation has a lower cost than rewriting the entire framework.
Migrating Android from Python to Kotlin takes an estimated 4 weeks. Then comes the iOS plan, with no defined date. During that time the Quality team is split between maintaining what already works and building what does not work yet.
That is time not invested in coverage, new flows, or stability.
Today the Android and iOS jobs run from a single managed pipeline. With the plan, each platform would have its own independent pipeline:
With separate repos you lose the ability to orchestrate, prioritize, or reduce executions from a single control point. Any pipeline optimization must be implemented twice, with the risk that pipelines evolve out of sync.
With a single repo, the question "Where do I maintain this test? Is this test automated on both Android and iOS?" is answered by checking one repo, one pipeline, one execution.
With separate repos per platform, coverage starts living in silos and divergence becomes inevitable. If the tests for each platform are built by different people, each engineer will naturally build different tests with different assertions, different validation criteria, and different edge-case coverage. Over time, what is tested on Android and what is tested on iOS will drift apart — and the real cross-platform coverage will erode without anyone noticing until a production incident exposes the gap.
Moving the tests to another repo does not reduce LambdaTest execution time or eliminate flakiness — those are infrastructure and test stability problems, not a matter of where the code lives.
The migration does not solve those problems; it transfers them to a new framework with the additional risk of introducing regressions during the transition.
qa-core-mobile-automation solves today what the plan promises to solve in the future, with lower cost, lower risk, and without breaking the iOS coverage that already exists. The plan trades an architecture that works for a promise of developer enablement that has not been validated.
Furthermore, the goal of having software engineers contribute to automation can be achieved without migrating the framework. An Automation Adoption strategy can define a mandatory task in every User Story whose deliverable is a PR with execution evidence — regardless of the language or repo where the tests live.
This solves the cultural and process problem, which is the real problem, without touching the architecture that already works.
Quality Automation Strategy · Yuno Payments · 2026
Should we migrate qa-core-web-automation into the SDK Web repositories?
sdk-websdk-web-cardsdk-web-coresdk-3dssdk-webviewsdk-event-logA single card payment exercises 4–5 repos simultaneously. There is no natural “owner” repo for the test.
6 Playwright configs, 6 CI pipelines, 6 fixture sets. Maintenance cost multiplied, consistency lost.
A change in sdk-web-core can break sdk-web-card — but those tests won’t run.
Keep a single dedicated test repository and progressively migrate from Python + Selenium to Python + Playwright. This modernizes the test stack while preserving the existing team expertise.
e2e/ directory. Everything transfers verbatim, zero rework.Modernize to Python + Playwright in a single repo now. If a monorepo is built, the tests move in seamlessly. If not, the architecture already works. Either way, zero throwaway work.
Quality Automation Strategy · Yuno Payments · 2026
Embedding quality into every stage — a new status, a mandatory automation subtask, and a regression gate before every release.
| Scenario | Type | Notes |
|---|---|---|
| Valid payment | Happy Path | Confirm screen + status |
| Expired card | Negative | Proper error message |
| Amount = 0 | Edge Case | Min amount enforced |
| Existing flow | Regression | E2E suite for module |
Quality Automation Strategy · Yuno Payments · 2026
A set of internal skills — AI-assisted tools that accelerate the quality cycle, reduce manual effort, and let software engineers ship with confidence.
Given a User Story, acceptance criteria, or a Figma link, the skill produces a complete test plan: happy paths, negative cases, edge cases, and regression scope — ready to attach to the ticket during Technical & Quality Analysis.
Transforms a test case into a ready-to-run automated test following the qa-core-mobile-automation framework conventions — page objects, step definitions, and feature files included.
Analyzes recent pipeline runs, clusters failures by root cause (timing, selector, environment, real bug), and proposes a fix or quarantine action — turning noisy pipelines into actionable signals.
Maps existing automated tests against product modules and platforms, surfacing Android vs iOS divergence and uncovered flows. Answers "Is this already automated on both platforms?" in seconds.
Collects execution artifacts — screenshots, videos, logs, device info — and attaches a clean, auditable evidence bundle to the ticket automatically after a local or CI run.
These skills turn the Quality-First Development Cycle from a process everyone follows manually into a platform the whole engineering organization leverages. The work does not get skipped — it gets accelerated.
Starting with the Test Case Generator gives us the fastest payoff: it plugs directly into the new Technical & Quality Analysis status and removes the hardest part of adoption — knowing what to test.
Quality Automation Strategy · Yuno Payments · 2026
Data-driven quality improvement — the metrics that prove the process works, and the skills that will collect them automatically.
Percentage of tickets that enter development with a test plan defined during Technical & Quality Analysis. Measures whether the team is actually using the new status before writing code.
Percentage of tickets that have the mandatory automation subtask created before moving to testing. Tracks adoption of the new process step introduced in the Quality-First Cycle.
Number of production bugs that the quality process should have caught — bugs found in areas that had test plans defined or existing automation coverage.
Without metrics, the Quality-First Development Cycle is a set of good intentions. With metrics, it becomes a measurable, accountable process that the organization can track, improve, and trust.
Each metric maps directly to a step in the cycle. When the future skills are built, they will collect these metrics automatically — turning manual audits into real-time dashboards and proactive alerts.
Quality Automation Strategy · Yuno Payments · 2026