Banking app audit: what is important for the successful release?

The difficulties in the development of mobile banking don’t always refer to code writing. They may happen as well while implementing the engineering practices that allow developers to work simultaneously over the project. Let’s view some important practices that may be helpful for the successful development of the project. We summed them up on the basis of various documents, manuals, and technical requirements that had faced during our work.

1. Code quality

There are several steps that have to be taken. First of all, the standards of the source code, best practices, and agreements. For example, SwiftLint to match Code Style in iOS development. With its help it’s possible to regulate the configuration parameters, such as the list of the rules that have to be included/excluded; subdirectories or files to be included/excluded, etc. You have to include the statistic code and style analyzers to check these standards. Besides, there should be an extended list of the rules or customized rules, providing the integration of the reports about the results of the analyzers in CI/CD, the tendency of their changes.

In case the analysis fails, the code delivery process should be canceled. You should add a local check before they commit via git hook.

It’s recommended to use the code quality metrics to check the code quality. They can be cyclomatic complexity, coupling, class hierarchy, code duplication, method cohesion.

2. Code review

According to a specially created checklist, you should accept the practice of the obligatory code review for Pull/Merge Request. You should check the standards and the correctness of business logic implementation.

While reviewing the source code it’s also necessary to check the availability and quality of unit testing. You should select the modules working with business logic and set the required level of test coverage. After that, it’s recommended to add a quality gate by matching the coverage with the target values.

3. Unit testing

It is obligatory if you want to release the project successfully. Read in our blog on how to implement and configure them in your code. In most cases, you should use the TDD approach (test-driven development). However, you may implement any useful tool that will help you to assess the test coverage and determine the parts that should be included in the coverage. For this purpose, you can use the plugin for the IDE.

One more recommendation is to use snapshot testing. It allows to save a snapshot of the data structure and compare new shots with the previous ones. It’s the key quality that allows spending fewer resources on regression testing. It prevents the UX from changing at some point suddenly.

4. Technical debt

Write your own rule for the static analyzer that will determine the number of to-do comments in the code. The tasks should be transferred to the general backlog of the project so that the project manager could see the number and status of tasks, tag them, assess, and determine how many of them should be considered for a new iteration.

5. Automation

The regression testing process should be automated in the sprint. Before every release, it’s important to track regression defects and create automated and manual test cases.

The test cases that are applied to the main code should be as well applied for the automated tests, including CI/CD process. If error, the tested branch cannot be merged with the original one. This approach prevents errors from getting into release.

A pyramid approach is used to test automation. If there is a shift towards one of the test types, you should think over strategies that would allow you to implement other tests.

6. Architecture

There is no doubt, that a high-quality project should involve a single architecture style with clear separation of the app layers, adhere to the principles of Clean Architecture. Besides, you should finish the code migration from legacy and get rid of this module and the linking code.

It affects the perception of the codebase in terms of defining the architectural approach and consistency.

Moreover, developers should be involved in the discussion of global architectural solutions affecting mobile banking apps.

The components of the interaction should be worked out before assessing and starting the project. The stages of technical solutions research that can form the basis of implementation should be included, as well as writing the ROS, scaling to the entire code base, and the planning stage. It includes creating a draft diagram of the interaction of the designed component with the system. After integration, the draft can become a ready-to-use diagram for the project documentation.

7. Process and role allocation

The core team should include various sprint roles in addition to the roles of Team Lead, Tech Lead, and developers. In particular, researcher, bug fixer, backlog, communicator, document creator, security champion. Each of them should have their own clearly formulated sprint task. It will allow you to calculate the KPI of each team member more accurately.

Besides, the bus factor should be calculated as well. It helps to determine the number of team members, who may leave their job and the project won’t be released by other employees. The lower the bus factor, the more specific knowledge these members possess.

To increase the bus factor you may:

- Reduce the project complexity

- Reorganize knowledge management

For that purpose, you may create a training program consisting of typical tasks, including fixing current bugs in the code, creating modules, and working with lists, CI, security, and source code review. This document will help new employees in the onboarding process.

8. Security

One of the most important aspects of the mobile banking audit. Read about it here.

Conclusion

Joy Dev team is an expert in mobile banking solutions. We always use and improve these engineering practices to create high-quality apps of high complexity. If you want to create a project with us, just send us a request!