> At this point, I think we need to step it up and I'm looking forward to formalising a testing strategy for our mobile team.

It makes sense and is a good opportunity to agree on the testing terminology and the test boundaries. I have seen often E2E, UI, Functional and acceptance testing terms used interchangeably. Each test category should clearly define which code will be exercised, from the architecture layers and what can and can not be mocked\
\
In mobile, there is no one solution that fits all, but a good place to start is to follow the mobile testing pyramid and tweak it according to your needs. Ideally, you will have a combination of Unit, integration and UI testing.

> I want to introduce **API contract tests** because our back-end API lacks documentation

This is good, but it might be beneficial to use the mocked Json in integration tests. That way you will exercise the whole UI, Domain and Network layer. In both cases, you have to manually maintain the JSON files. Ideally, they will start a single screen and you could mock the response to test multiple view states. I know this is hard in iOS due to the close nature of the platform.

Snapshot testing is good, and it might cover localisation tests, they are also beneficial when refactoring the UI or migrating to the new design system.

You are spot on to keep the UI tests to core flows only as they are expensive to run. It is good to generate some automated reporting nightly so the team can check the state of these tests.

Lastly, be cautious of your time spent on keeping these tests in a healthy state and the benefit you are getting out it. I would also track the number of times, the regression has been caught before release because of these tests - this information will help you to prioritise your time!

Software dev

HWalia

Concrete metrics cannot measure everything for platform projects, but many other factors must be considered. There is some level of understanding from the leadership about the platform team projects. That is why your org has a dedicated platform team - to solve pain points so that the delivery teams can move faster and deliver business impact.

Some of the things you should try doing is

- Share weekly updates about this project's migration progress. In this, you can explain any technical difficulty you overcame and the benefit of it in the future. You can also highlight pain points referencing some issues/errors. The key is to produce regular updates until the migration is finished.
- If you have your weekly meeting with the team, share the progress and any technical direction you have followed, and ask about the feedback. These projects often run longer, so you must push the project's visibility and remind its importance for the business.
- Run a survey with the target internal team before and after completing the project. The survey could ask about the pain points before and the pain point addressed; you could collect many meta-points in this survey and feedback about the project.
- You should also rely on your relationship with team members who are the customers of your project. Have informal chats with them and ask about their biggest issues, things holding them back, frustrations with using the API architecture, and trickiest and most frequent bugs. This gives you a lot of reference points to collect and compare post-migration.

Some other related questions I asked earlier you may find helpful.

- <https://www.jointaro.com/question/mvMQj8228kuUe38BvdT9/how-do-you-convey-impact-for-non-product-technical-efforts-like-adding-tests-and-fixing-crashes/>
- <https://www.jointaro.com/question/reItyrYxp8rMCyC03v2u/how-do-you-measure-the-impact-of-refactoring-your-codebase-to-use-a-new-pattern/>

Interested

Interesting To Implement

Interview Prep

https://link.jointaro.com/VvJeLsXmtPSFbZpd8

Read Data

Learning new tech

Must Later

Onboarding

Starting at a new team or company? Or maybe you're just picking up a new tech stack? Go through these resources to learn how to ramp up fast.