Does your app delivery include ßeta-testing?
If so, you probably interact a lot with end-users, stakeholders or even just internal developers. And you know that testers spend a lot of time juggling with many versions of the same app: install, test, report, uninstall, repeat… A necessary job that can turn from a few minutes per day to several hours if end-users have multiple apps to screen.
Our recent work on the native app store should ease the process of installation for ßeta-testers.
Recurring insights from delivery teams converged towards the need of installing the right version, following its changelog. Some of you use changelog for classic description of bug fixes or new features brought into the version. Others use it as a custom field indicating the git branch or the user story number…
Anyway, your team needs the changelog to know which version they have to install and test.
Thus two screens were to be merged:
- the screen giving information about each version – changelog in particular (a)
- the screen with installation buttons for each version (b)
 |
 |
(a) (b)
Goal was to keep the information relevant to ßeta-testers : version/version.name, build/version.code, size of the binary, date of update, etc. and also display the “Install” button.
This way, end-users avoid losing time by switching between two screens to get the version that they target for their testing session.
Here’s what it looks like now:
 |
 |
We just started to think more about improving ßeta-testing workflows with our native apps.
Please reach out: had you any ideas about or feedback to make about this feature or larger ßeta-testing daily struggles?
Write to support@appalooosa-store.com!