Test Community Spotlight: Building Financial Products for Millions of Gamers

Placeholder

This post is our Test Community Spotlight Program, where we highlight personal experiences from testers and QA professionals around the world. To participate, apply here.

Introduction:

Kinguin is an aftermarket service for digital goods, selling mainly games. We have a challenging customer base of 7 million users with over $100 million USD annually. Kinguin thrives to serve each customer on a personal level, although having 7 million can be mind dazzling!

Our story

About a year ago, our IT leads consulted the business department about a great idea. This was around the time some of our software products were reaching the end of their 7 year average lifecycle.

Convert all of our legacy code into independent API Microservices.”

We can make them play together, and re-orchestrate everything to build the next generation marketplace, which will serve our ever-increasing number of customers.

Overall you might think, “This sounds like a great project, but it could bear some immense challenges to their respective development teams.” You would be right.  When re-thinking software, the biggest challenge arises from the business specifications and use cases, and then translating those towards actual functional specifications, which developers would be able to understand and work with.

Of course, building software at a massive scale has always been a challenge to software companies. However, we soon realized that it was no easy task to have proper communications set up between these individual microservices--each having request / response objects unified to fit a universal infrastructure. It needed to provide a look and feel that would represent the new platform to our customers.

Unit tests or Test Driven Development has been a buzz word in the industry for a long time. Can unit tests alone prevent any failure in our new distributed API services, with each single API service built using vastly different technologies?  How will our services work hand-in-hand with each other?

From Zero to Hero

I am the architect, project manager, team leader and intrapreneur behind a large set of new Kinguin Microservices. I am mainly involved in managing the customers’ financial assets within the wider Kinguin eco-system. My team and I have built Digital Wallets for our trade merchants, Micro Wallets for everyday customers, and Financial Based Risk Solutions, which prevent fraudsters from abusing our internal and external payment systems.  This, then, is the story of building Kinguin Wallet from Ground Zero.

As I mentioned above, it all started with this idea; The API-fication of our legacy code, and the transformation of IT infrastructure into a maintainable and scalable solution. A noble idea one might say, but a big pain others might argue!

I call it, simply a plan….

I have over 30 years in the tech industry.  Having worked for SMEs and Fortune 500 companies, successfully run and exited several startups, built almost anything starting from teller applications for a bank, to e-commerce solutions and online booking related travel solutions, trust me, I’ve seen everything!  I’ve worked, planned, and implemented code, so fairly nothing new can surprise me.

As with every project, we analysed the business requirements, and then translated them into user stories and functional specifications. The definitions of coding rules and prerequisites for pipelining code assets to development, staging and production servers were set as means of specifications, so was too the Test Driven Development.

Our solution was to comply to continuous integration and continuous delivery as a means of purpose. This would allow us to go to market early and continuously improve and advance our software. However, our company has multiple development teams spread across several locations. It is not enough just for one team to “try and not create blockers” for the other teams, and still keep development under control.

I thought:

Enough is enough, keep KISS in mind….

and I shall not be proven wrong!  Testing can, and should, not be only comprised of TDD in the classical sense.

Let’s think a bit of what TDD does for us. Tests, which are mainly comprised of unit testing methods within our code, ensures that our code functions well and that there is no unexpected behaviour of the code itself. In simple words, unit tests make sure each section of your code delivers the expected outcome, and that the code itself, is error free. Overall, error free code! However, APIs problems can start appearing even with error free code because what everyone needs to guarantee is something which I call:

The Contract of the API Interface.

In other words, having a non-changing response syntax of an API endpoint, which is independent of code changes at a much lower level. Think of several APIs communicating internally to build a service structure, while keeping the services at their lowest level independent of each other (microservices).

If one of these services changes its “contract”, or in simple words, its response syntax (or language), a whole sequence of other services will start failing. These other services relied upon on the exact response syntax that were in the previous requests.

Imagine what happens, a whole sequence of services starts failing and, perhaps, disastrously entire outages occur and SLAs are violated.

If one has ever built software which is simply not allowed to fail, that is "always on" , with a 100% uptime SLA , and most importantly, this software deals with customers’ money, then one will know how important proper and continuous functional testing is!

Having versioning of APIs as a master solution was out of question, simply because when relying on rapid development changes or bug fixes within the same version, this contract still needed to be guaranteed.

The Master Solution

What we needed was a software that would continually test the interfaces and guarantee all contracts were kept. When researching for functional testing software, I stumbled upon ReadyAPI. This tool looked promising when I tested it to see what it could do for us.

Shortly after taking the first trials, a colleague of mine, David(5) was trained in using ReadyAPI to create functional endpoint tests for all of our own projects. As a matter of fact, this extended quickly to cover all the endpoints exposed, in the context of APIs, that we, as a financial team, needed to consume.

What we realised then was a complete surprise to me:

TDD is slow, whereas functional automated testing with ReadyAPI is ultra fast

I am not arguing for or against the benefits of Test Driven Development. I am pointing out that, in terms of APIs, what really matters always at the end is the contract of your interfaces. What comes in, and then, what comes out of your API.

Due to the fact that these functional tests are always run before and after every code branch merge into master branches, we were able to lower the amount of code coverage to be unit tested to as little as 20%. What matters is Quality Assurance before merging code and during a release cycle.  One doesn’t need quality statements about the code on every single section of code.

As many companies have learned, their IT projects inherently become more complicated. With complication starting from the management level, all the way down to the complexity of code in the development cycle. I strongly believe in:

Optimizing the Development Cycle individually to the Project and the Team.

The staggering outcome for us, measured in Key Performance Indexes (KPI), was an increase in productivity within the teams by slightly more than 30%. This increase is mainly due to the fact of minimizing boring recommendations like unit tests, which none of the developers really enjoy!

ReadyAPI is now in used across teams. I surely can say, we started from “Zero and progressed to Hero” by leveraging all its unique capabilities.

Kinguin Wallet, a feature rich – multi-currency wallet, and other dependent services are now readily developed. It took my team a good 8 months to develop it along with accompanying helper services. In the meanwhile, of developing “The Wallet”, Kinguin also started to run our own ICO (Initial Currency Offering), whereas our own cryptocurrency was one of the changing objectives of the project. We are proud having built our software and being able to change and adopt to new challenges in a snap thanks to our fabulous partner in functional testing - SmartBear.

Kinguin has always invented new tech products from it’s start in late 2013, but test automation has always been challenging for development teams and business stakeholders alike. SmartBear’s ReadyAPI is the tool of choice to fully automate Kinguin's newly developed Restful API services. They connect internal as well as external stakeholders on the newly built generation of marketplaces that will serve millions of gamers.

Andreas Maier holds a Doctorate in Neural Network Technologies from the University of Cologne, Germany. He has worked in high ranking positions across a variety of different industries, serving as the CTO and CEO to a numerous amount of Startups and has always been a hands on leader. Holding technical positions that require architecturing complex IT solutions has always been a passion to him. One of the key beliefs of his, is the adoption of processes to the need of current challenges. Entrepreneurial thinking outside the box and innovation belong to his key dedication throughout his entire career.

 

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox

Sign Up Now

By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading