0

I'm wondering if anyone could help me with a strategy to ensure correct coverage for upcoming releases. A little about our setup...

We have multiple iOS apps released across different European regions. These all share the same codebase but point to different urls, depending on the scheme selected, which handles localisation for that region. That's the only difference between them at the moment. We've released them all concurrently and each region has been tested and there have been no issues.

My worry is for upcoming releases. Say, for example, we see an issue in the Italian app (e.g. truncated text when Italian language is used). We only want to release the fix for the Italian scheme so we test that and release. Our codebase is updated with that fix, and therefore it's updated for all our other regions, but they haven't been tested (because they've not been released).

I can envisage problems with this strategy. Say, in 6 months, we want to release a fix for the French app. Well, in those 6 months, the codebase could have been updated with a number of regional releases to that point. Very hard to track, even harder to track down tests related to each release.

Can anyone suggest a strategy to deal with this issue? When releasing one region, should all regions be tested at that point, despite not all been released? Any strategy on tracking a complete list of changes (e.g. through branches or tags) so if I am beginning work on a new release, I can first run a regression on releases up to that point to make sure it's okay.

I have no automation just yet but will do in the next few months. Thanks everyone for reading, and hopefully someone can offer some insight.

  • What are the possibilities of creating a mock app for the core (shared) code, test it and focus only on the correct data integration for each regional app? This way you can cover the business logic using an isolated app and focus on the i11n check for the regional. – João Farias Aug 28 at 13:25
  • Hi @JoãoFarias, thanks for the response. It's something that we had considered. I'm just out of a brief meeting about it now and we have decided that we were thinking about it the wrong way. We were treating each app separately, when in fact they're not. When we work on the code, we're no working on the Spanish app (for example), we're working on the one codebase. If only Spanish apps should see the changes, this would come up in our planning session and we can decide then what other regional apps should be checked (if any). Following this approach makes things a bit easier I think. – JordiLaForge Aug 28 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.