Quality Assurance (QA) is a filter between development and production

QA is an important part of any company's work. If you have developers in your team, you will need the testing specialists too. Team lead in BETBY Konstantin Melnik talks to us about the importance and basics of QA work.

Konstantin, how did you get in betting?

I’ve been connected to betting for a long time. When I was a student I liked making bets. I used to bet on big football events in Kyiv, for example when Dynamo played in the Champions League. Retail shops were popular back then more so than online bookmakers. I used to have fun with my mates betting on Dynamo, over and under goals, handicaps, that sort of thing.

As time went by I realized that the betting area really interested me, and I started to read some books about it. I wanted to understand both betting philosophy for gamblers and some of the business directions too. So this is how I got into this area. I like sports too of course. When you watch a game, it’s OK to bet a little money on something to increase the level of adrenaline I think.

Can you recollect a notable win or lose?

I tend to search for something which is high odds when I am looking to place a bet. I always try to set a new record. That is why I bet a little money on high odds. Once I managed to win with odds of 35 as a single bet. I made a live bet that Barcelona would advance to the next round of the Champions League. It was during the famous game in 2017 when the Catalan team were playing the second leg after a 1:6 defeat to PSG.

Things like this are what I like in betting. Step by step I started to like more general gambling such as in the casino or at a poker table. I used to play poker more than now because now I just don’t have the time.

Comparing gambling in a casino to sports betting, what is more interesting?

Betting seems more interesting to me. I believe that it’s more fair. I think that everything is programmed in casino games. A person can lose everything in a blink of an eye.

I never studied casino games deeply, although I tested some products of different providers. Poker is an intellectual game too. But still it’s not what I really like a lot. That’s why I choose betting.

Probably the main reason for this is because I like sports in general. I like watching football at the stadium, and also on TV. I like playing it as well, and I also play tennis. I guess that could help explain why betting is more interesting to me.

How should a person take betting?

One shouldn’t take betting too seriously. Otherwise you can start to make some stupid decisions that will affect your life. If you want to bet that is OK but you should do it as long as you are enjoying it. Also you need to have a bankroll to use that you won’t regret losing. For example maybe you ringfence 100 dollars per month, if you win, that’s great. If you lose you don’t spend more money than that. You need to have an inner switch to control it.

Do you place bets now?

I usually have to do it at work. If we talk about as a hobby, then yes I do for fun also. I keep placing bets on the Champions League or maybe some cool hockey games. If I see an interesting option and I feel I can win, then why not? I don’t do it that often though.

How did you start working at BETBY?

I worked for a gambling company. It was more of an integrational platform than a B2B business. It consisted of a lot of products besides the betting ones. Then an acquaintance of mine told me that I should have an interview at BETBY. So here I am in a QA position. I’ve been at BETBY since the very start of the company. I have seen all the stages of QA development.

Was QA your area right after you got in gambling industry?

Ever since I joined IT I’ve been always working in QA. As a junior I started with manual testing. I only knew some basic things and I was learning whilst completing tasks. You don’t need a technical education to work in QA. There are many people with different educational backgrounds, starting from lawyers…

Lawyers?!

Yes, sure. Lawyers can become great QAs. They are good at analyzing documentation, they’re accurate, careful with their work. This is the very base of success. These are the things that are intertwined between law and QA.

How can you evaluate work in BETBY? What is the main difference with the other experiences?

The difference is huge. The point is that we had betting as an implemented solution from a provider at my previous work. We would set a package to their frame and start testing the things we needed. There is a totally different area in BETBY, which is inner betting mechanics.

BETBY is a B2B platform that provides other companies with the product which is to be implemented. The difference is huge. This is a totally different approach to testing and a totally different area of testing.

You need to go deeper in some particular areas of different betting functions, some features need more inspection. For example, cash out, limits, margin, liability. These are not just terminology. There are certain drafts and checklists you need to follow behind it.

Before we start testing we need to follow a procedure of requirement analysis and understanding of what we do. Testing is just one of the last stages of what the QA team is supposed to do.

What does QA consist of?

QA is something more than just testing. It includes three stages which are verification, validation, and the testing itself.

What is verification? This is a process that includes requirements analysis, work with testing documentation and artefacts, use cases, checklists, and certain reports. This is the construction that serves as a preliminary stage to the testing itself. Verification can help us understand whether we are making a correct product or not.

Validation can also help us understand whether we are making a product correctly or not. This is a thin line. During this process we evaluate whether our implemented product and its features meet our client’s expectations.

At the first stage we collect requirements, then analyze and implement them. This is basically the preparation. At the second stage we evaluate the things we implemented. The testing starts only after these stages, following the requirements we have and those that we need to clarify.

Why do we need the first two stages? We need them to minimize the amount of mistakes at the later stage of product development. If we don’t do it, we will have two times more work to do in the future, twice as many bugs to iron out. Without the first two stages there will be just a raw product for testing. It makes the time we need to get features to a client longer and the product itself gets more expensive.

Should a QA keep a work plan in mind at the first stage or should it be designed?

A QA should realize what will be tested and how before the testing starts. A QA should analyze what tasks he or she should use to make a text document discussing this issue with developers, project managers, and business analysts. 

Let’s suppose we get a new cash out functionality which was created by someone and sent for QA. We don’t know how it works, what it is going to include. Perhaps, it’s an implementation of some new games. It’s impossible to test it without having analysis and a testing plan. That’s why the first verification stage exists.

A task may be described in different ways. For example, some particular parts may be omitted. Verification gives us the possibility to give advice on adding them.

For example, we have a task to make a system work with cash out. There is a formula that cash out follows. Then we need to discuss the task. We know the product and we know more or less how the feature works at our betting rivals. So we can make up some questions we need to ask. Should cash out work for all the types of bets? Cash out for combined bets are quite difficult. Do we need it in this particular case? Can we improve the cash out formula by adding a multiplier to help the risk management team regulate this issue? For example, in this case they could make the cash out amount higher or lower for particular clients.

We need to clarify these things. If development doesn’t take them into account, while a client expects it, then we will make a cash out feature which won't meet the client's expectations. 

Is it important to know a lot about betting for a QA?

Yes, it’s pretty important. It is about 50% of total work success.

What else is important?

Well, it’s important to understand the testing process itself and STLC (Software testing life cycle), which is knowing about a bug life cycle. To create a bug and give it to a developer is nothing. A bug is like a child: when it’s born you put it in a cradle, care for it, feed it with milk, in our case with features.

A developer fixes a bug, then returns it to a QA, who checks out everything, and makes a reverse testing. The QA should clarify that no other functionality was touched that can affect the process and create new bugs. It is a small cranky child that needs care.

The final stage of the STLC process is closing the bug when we are assure that it is fixed and everything’s alright. In this case we kind of bring a child into an adult life.

Is QA like a very caring mother and father, is it an observant person who can think logically?

Yes, it’s something like that.

I guess one needs to love the product and the work involved quite a lot?

Yes, that’s why I’d like to get back to the point that understanding the betting takes only 50%. It’s not even about love, it’s about knowing the product. It’s hard to talk about testing without knowing what you are dealing with. You don’t need a deep understanding for some of the abstract things like markup. Although understanding of how a bet slip works is a science itself which demands a careful approach.

It’s very hard to make a visual bet slip testing without understanding the product. It’s impossible to evaluate whether the product is made correctly and whether there are some bugs without understanding the product. You need to understand what kind of switchers should be included, what a quick bet, a single bet, a multiple bet are and so on. That’s why we hire people who have at least some understanding of betting or at least a little of gambling experience.

A bet slip is a small window on a website but it’s very important. What other parts of a betting website are critically important, too?

There is a part with the history of the user's bets with all the information about the bets, their statuses. Cash out functionality is presented there in most of the bookmakers if they are still pending. Some bookmakers implement different features there. For example, you can go to a banner from the bets history part or to use a referral link.

This is the functionality that allows bettors to view and understand their own bet history.

Where else can a cash out be implemented?

Some bookmakers put cash out directly onto a bet slip. When you make a bet you can see a cash out feature right away. You can do it in one click. It’s very convenient for live betting is the main reason for thisl.

How important is your department for the company? What could be the effect of the QA absence?

Well, the importance can be evaluated in comparison with some other departments. I think that QA is as important as development, management, analysis. We’re all equal I believe.

I have already mentioned the principles of QA work. Another important direction is so-called proactivity. This is implementation of different improvements.

Sometimes QA and business analysts analyze the practices that rivals have and look at the product we have created. You can always improve it if you want to. An improvements validity lies at the heart of QAs influence on the product.

Can QA work be evaluated in numbers?

There are particular QA efficiency metrics. They are measured in the amount of tests covered. However the main point of being efficient is to avoid or at least reduce the number of critical moments, bugs that may affect the financial situation of the company.

QA is a filter between development and production. It must validate the unpleasant moments that may influence the finances. You can’t allow critical bugs to happen. This is one of the first times that something may stop the bets acceptance process, break the product. God forbid it to be the financial part. For example, currency conversion. There are a lot of cases connected to it.

In the case of finances QA is a defensive line.

Is currency conversion your zone of responsibility, too?

Of course it’s a part of what we check, too. After all the currency conversion may be large. I won’t go deeper in this topic, but I’m gonna briefly explain it. First of all there are different types of currencies. There are the common ones, which can be divided by 100 like Euros, Dollars, Roubles or Hryvnias. Then there are specific ones in which there are not 100 pennies in 1 pound measures for example some African currencies.

You need to understand where you can get data on the exchange rate to convert currencies. There are different sources depending on the client. You should give the one that fits best in terms of profit.

There is one more type which is cryptocurrencies. It is essentially just another counting system with volatile currencies taken from different sources. We use a wide range of currencies. We have more than 100 both common ones and specific cryptocurrency mechanics like Bitcoin, Ether and others.

Can your work be automated?

Automatization plays a big role in the testing process. It saves you a lot of time. But still the balance between manual and automated testing is important.

In my subjective opinion you can’t work without manual testing. Automatization of everything is quite a utopia, because automatization of all the processes leads to a large workload in supporting what exists.

You need to find the balance between when it’s faster, better, and more efficient to do everything manually and when it’s better to create autotests and support them. The latter is more about reverse testing and the parts that are tested manually a lot of times like bets, cash outs, currency conversion, especially cryptocurrencies.

You can build in particular limitations that will make boundaries for cryptocurrencies with the help of autotests. If it breaks the boundary then there’s something wrong with the conversion. It’s possible to spend a large amount of the company’s resources on automatization, but it won’t be for the best outcome. 

What should be done manually?

The hard-to-reach parts of the code. QA does not always have access to developers’ resources or data bases where some things that you can see via the back office are kept. You can not go there and launch some tests, connect to a base and find something with the help of SQL. But you need to go through all those cases still. This is where manual testing issues matter.

How are automated technologies built in your company?

Our technology stack in QA is basically Java. We use REST assured libraries, assembly is made via Maven, the autotest library is JUnit.

We launch tests in GitLab containers with a scheduler, automatization goes to back end basically. In case of front end manual testing this is used in most cases because requirements for the front end are changed often and fast. Implementation of the new requirements to the autotests is quite a difficult process.

Do you create it on your own?

Yes, we use a particular framework. There are different patterns and approaches to testing automatization. For example, Page Object when particular elements are added to particular classes. Thanks to that the tests look more compact and attractive. All the mechanics serving the central test are put in the separate elements, components, and other things. For example bet slip class - is everything that is responsible for bet slip elements. These are the technical details of the realization.

Is there a B2B business in testing?

It’s the matter of necessity and adaptation to the processes built in a company. There are many products for testing like the ones of Google or specific QA products, for example, Apache Jmeter universal tool which is used for stress testing and common checking, too. It’s the matter of choosing stack technologies. QA is always oriented to the necessities already presented in a company. The libraries, assembly features, are collected according to them.

Is stress testing very different from the common one?

There are special QAs that do it. It’s a separate science actually. Experience and approaches applied in stress testing are slightly different in the common practice, one needs development knowledge more there.

It sounds simple but there are specific stages in stress testing, its own stress metrics that allow you to understand when you can give the maximum stress and when you can do it in a light manner. The main thing is to be able to make conclusions from the information received. It is not a solution to have a series of stress tests just to have it. You need to be able to deeply analyze the results you receive.

In our company, stress testing is not the thing that only QA is in charge for. Developers take part in it, too. They help us understand specifics of test realization or the use of particular utilities.

You know quite a lot. Have you read a lot or is it due to your education?

I self-studied QA plus attended special good courses, including those about stress testing. I was very glad with that. I studied testing theory in general, many practical moments, going deeper into SQL for example, the correct ways of writing search queries. I also studied basic things about Unix-like systems, working with logs, branding.

Are there courses of that kind in Riga or is it studied in universities abroad?

I can see a lot of advertising on QA forums, like in Facebook or LinkedIn. These are about programming courses in Latvia. I mean there a lot of them, at least five. However I can’t tell you whether they’re any good.

So, you can learn everything if you want, right?

You need to have a balance for yourself. If you can study on your own then some courses are gonna be a foundation, a base. But for some of the people I know some Internet sources are not enough, they need a lecturer to put the knowledge in their minds.

You also need to love the profession you’ve chosen. Many people perceive QA only as a stage between moving to IT either to development or to product management. Still some people take QA as a true purpose, they like only this process. I’m one of those people.