Union54

Introduction

Union54 is a spinoff from Zazu, Africa’s challenger bank awarded Mastercard Principal Membership. Having witnessed African banks’ uncooperativeness and legacy processes, Zazu’s founders came up with a solution helping other fintechs speed up the card issuing process. With Union54, card production and issuance take three to nine days.

The Union54 APIs allow businesses to issue physical and virtual debit cards, fund cards in any currency, program them as per one’s preferences, use a card management platform for various digital banking activities, among other features.

Challenge

Cooperating with Union54 has been nothing but a pleasure: we were already familiar with their team, workflows, and quality standards through the Zazu project.

Here are some of the most important aspects we were required to comply with:

• Time Constraints. Since Union54 participated in the Y Combinator summer batch, they had about two months to deliver a fully functioning MVP before presenting it to a selected audience of investors and press on the demo day. From our end, we were responsible for timely testing of API endpoints as they were being built.
• Test Automation Stability. Fintech projects like Union54 cannot do without test automation. Such solutions require a twofold amount of testing effort, and manual testing alone won’t provide 100% test scenario coverage. Our task was to develop a stable test automation suite that is both comprehensive and easy to maintain and scale.
• Missing UI. Our client was looking for highly technical QA engineers capable of testing API endpoints without a user interface. This requirement was not a challenge for us as we have a team of experts skilled in API testing.

Fintech solutions like Union54 do not tolerate any oversights, so we shared the accountability for the project’s success from day one.

Solution

To ensure sufficient test coverage from early development stages and meet the deadlines, we decided to combine test automation with manual testing QA. Such an allocation of resources allowed us to automate about 90% of test scenarios concerning endpoints and most essential database triggers.

The manual tester, on the other hand, writes positive and negative test scenarios, which are further reviewed by the test automation engineer, and takes care of the rest of the functionality not yet automated or with no automation potential. The mission-critical test scenarios were checked both by a test automation engineer and a manual tester to achieve the utmost software quality.

Another aspect that lays the foundation for a successful test automation strategy is the right choice of testing frameworks. For manual testing, we relied on Postman as this tool is specifically designed for API testing and makes it easy to test apps with missing frontend – precisely what we were dealing with. Test automation scripts were written with Cypress, which is suitable for continuously growing test automation projects like Union54.

We tested API endpoints as they were being built, so our test plan included testing new features, integration, and regression testing.

Test Automation

Test automation stability is the primary challenge for any QA automation engineer. Why is it so important? Validating what tests failed because of bugs or changes to the code and what tests are the result of an unstable environment is the daily practice of a QA automation engineer. If automated tests are unstable, the number of false positives will continue to rise as the project grows. As a result, an enormous amount of time is wasted on filtering false positives from truly failed tests.

Before we started any work on the project, the Union54 team had already written a couple of tests with the Mocha framework, so we decided to give it a try. As new test scenarios became more elaborate and the test suites increased in size, we noticed significant stability issues and communicated our concerns to our client. To resolve this issue, we switched to a different framework, rewrote all the existing tests in Cypress, and placed them into a separate repository.

We agreed on Cypress because of the numerous benefits it offers. Cypress allows you to automatically retry failed tests and set a custom number of retry attempts, either for all tests or just for a specific one. This feature is super handy for reducing test flakiness and CI build failures caused by the temporary unavailability of third-party services or random network errors. Other Cypress advantages are logical and straightforward patterns, high readability of test scenarios, and scalable code; the already written patterns can be reused in future tests. Cypress is also a good match for running complex, multi-step test scenarios.

CI for the automated tests is implemented with the help of Bitbucket Pipeline. Every night at 2 a.m., the latest commits from the develop branch are pulled into the CI pipeline. Therefore, our tests cover all changes to the codebase even if developers work late into the night. Thanks to the Bitbucket integration with Slack, we are instantly notified of all commits, pull requests, and pipeline statuses, both successful and failed.

A complete test run including 1500 test scenarios in the CI pipeline takes about 1.5 hours, which is quite decent, considering the test scenario complexity and number. Having achieved the stability of automated tests, we see a clear picture every morning, spending minimum time on troubleshooting.

As new capabilities are being added to the Union54 website, we also cover the front-end part with automated functional tests.