Preface

Mobile app versions must go through a single process for public release. This process is program-independent. Of course, the product owner can increase or decrease the proposed intervals and deadlines, depending on the amount of the changes and the importance of the program, but it is recommended that the process be performed seamlessly for all applications. Note that the prerequisite for performing these steps is that all the tasks of the desired version (both bugs and features) have been labeled ‍‍Done by the test team.

The suggested steps are as follows (in order):

General Test (Whole App Test)

After testing the bugs and features separately, the general test of the program is performed. How to do this step is specified in the test team and has nothing to do with this post. After the general test, the problems seen are categorized and at the discretion of the product owner, those with high priority are reported to the development team for fix. After the problems are fixed by the development team, those problems will be tested and if all of them are solved, the general test will be done again. If the high priority problem is seen again, This cycle will be repeated. The time to perform this step, depending on the type and nature of the program and also the amount and impact of changes compared to the previous version, can be more or less, but it is recommended to consider a period of 7 days (maximum 10 days).

Test Vital Features

This test can be performed separately from the general test and by the product owner. You can test features that are very important to your business and your end user, like: (1) software check version and (2) remote push notification. Other features can be added to this step at the discretion of the product owner. Given that if there was a problem in these cases, it will definitely be a high priority problem. If a problem is seen, they should be referred to the test team immediately to resolve it. This cycle will repeated until there will be no more problems with these features. The time to perform this step, depending on the type and nature of the program and also the amount and impact of changes compared to the previous version, can be more or less, but it is recommended to consider a period of 3 days.

Security Test

This test can also be parallel to the whole app test, but changes made to the overall test may have a side effect on the output of this test. As a result, it is suggested that the latest stable version of the whole app test output be given to the security team. How to do this step is also specified in the security team and has nothing to do with this post. After completing the security test, the reported high priority items (priority is determined by the security team) will be referred to the development team to resolve. Ultimately, this cycle goes so far that we do not have a high priority problems that have not been resolved. Depending on the amount and impact of the changes made at this stage, the product owner can decide whether to perform a general test or not. The time to perform this step, depending on the type and nature of the program and also the amount of changes compared to the previous version, can be more or less, but it is recommended to consider a period of 7 days.

Request Test

This test is performed to ensure that the infrastructure is not under pressure in the new version. Of course we can’t conclude this properly by just testing in our side but we can detect some programming problems from logs or by other tools. For example, instead of calling the request once on the hypothetical page X, it is called 10 times. As a result, if this version reaches users, it will put pressure on the server and infrastructure. Upon completion of this step, high priority items will be reported to the development team to resolve. Items are prioritized by the product owner. Eventually, this cycle goes through so much that we do not have a high unresolved priority. Depending on the amount and impact of the changes made at this stage, the product owner can decide whether to perform a general test or not. Also, due to the type of changes that are made at this stage, there is no need to retest the security unless a special issue specified. The time to perform this step, depending on the type and nature of the program and also the amount of changes compared to the previous version, can be more or less, but it is recommended to consider a period of 4 days.

Preparation of Release Note

In this step, the changes of the whole version compared to the previous version are listed and the items that are felt by the user are separated and inserted into the changelog. The time to do this is 1 day.

Preparation of Release Plan

In this step, the program of step-by-step release of the application is specified and presented by the product owner. The plan should be approved by stakeholders (operations and support, development, etc.). Finally, the final version must be published according to the schedule.

The Last Word

If the above steps are followed, it can be said with great confidence that the stable version will reach the end user. If, for any reason, a problem of high priority (priority in terms of repetition rate or in terms of business) is reported, that problem (or problems) should be created as a new issue on Jira. After debugging, the suggested cycle will be repeated again. Here, too, depending on the amount and impact of the changes and the importance of releasing a new update soon, the product owner may decide to skip some steps.

photo by Marvin Meyer