In our previous article Mobile app development timeline and stages, we covered the topic of development steps that take place in mobile app development. This time we’ll continue with release stage. We didn’t describe this part last time, but sometimes it seems that it takes even more efforts and skills than the development itself. So how to release your app?
When you passed through all the stages of mobile app development, are you sure the app is ready for release? Keep in mind that your first users might experience a mildly irritating minor bug if you wouldn’t be attentive. Or even worse, they might download an app that crashes constantly, provoking them to reach quickly for the “uninstall” button. Checking an app before releasing is crucial!
There are two common ways to test and release apps: manually, and continuous integration.
We will describe the manual way to release your app. Let’s start. There are several things you should keep in mind to release your bug-free and proper-working app.
- Test it!
Test your app and receive feedback before giving the project manager the green light. This part is the task for Q&A engineers. You can have your own in-house Q&A team, but many companies can not afford to have it. If you don’t have it the quality assurance can be provided with the help of the trusted outsource team.
Divide the various sections or features of the app to different engineers to be built and tested. This is tricky because developers know the app, they can not pretend real users and think what real users can think of facing the app for the first time. If you verbalize what you’re doing in the app and constantly question things, you might discover several new problems.
- Map out the flows
When you found a bug in one part of the application it will probably cause a bug in the other part. So you should have an understanding of all the pieces of the application and how they interact with each other.
Create a mind map for each feature that you changed, and which features, components or screens could be changed affected. If a change applied to component A alters component B, testing must cover both A and B.
- Test after test
When your developers have tested the app, another round of testing should come.
You should do unit testing for individual parts of the application. After that, the integration testing comes to combine the units and test them as a group. Use the mind map for it. And as the last one, the acceptance testing goes. This is the trial of the app before it’s published. The acceptance testing designed to replicate real-life use of the product to make sure what the user gets is fully functional and meets their expectations.
- Check the devices
For this task, an emulator is not a sufficient option as far as it wouldn’t cover all the nuances you’ll face on different devices. You should install the application on multiple real devices.
The worse thing happens when something doesn’t work. It means you have to head back to the engineer who built it with details of the issue. Once fixed, head back to QA and make your way through the stages once more.
- Rolling out
Consider rolling out the app in stages. You still might have some bags or errors slipped through all that testing. And the fewer users will face them before you’ll catch them the better. So think of releasing the app for 20%-30% of your user base first.
If everything is ok, you can expand the number of users. Congrats!
- What about updates?
For updates, make sure you dive back into those mind maps we talked before. Map out any potentially affected features and test again before updating.
That’s all! Seems hard, but in fact, all you need to do is to be attentive and do not miss the important details. Only when you are 100% sure, that the app is a bug-free and proper-working, only then you can release it. But not for all users (because nobody can be 100% sure).
Subscribe to our weekly newsletter to get all the updates to your mailbox!