«QA — это фильтр между разработкой и продакшеном»

QA — важная часть работы продуктовой компании. Если в вашем штате есть разработчики, то без проверяющих и тестирующих специалистов тоже не обойтись. О важности и принципах работы QA рассказывает Константин Мельник — тимлид в компании BETBY.

Однажды поймал кэф 35.00

— Как оказались в беттинге, Константин? 

— Со сферой беттинга меня связывает давняя история — со студенческих лет увлекался как простой обыватель, игрок. Иногда ставил на крупные футбольные события в Киеве: на Лигу чемпионов, например, на «Динамо» Киев. Тогда ещё были ППС, а не онлайн-конторы. Мы с ребятами баловались этой темой, заряжали на победы «Динамо», на тоталы, форы.

Потом со временем как-то сфера мне стала более интересна, я начал читать и углубляться в неё. Хотел понимать как философию беттинга для игроков, так и какие существуют направления бизнеса.

Собственно говоря, так и пришёл к этой теме. Плюс я люблю спорт, и когда что-то смотришь, можно скромненько зарядить на что-то для поднятия уровня адреналина :)

— Помните какую-нибудь примечательную вашу победу или поражение?

— Когда я ставлю, меня интересуют выигрыши с точки зрения больших коэффициентов — я всё время пытаюсь установить новый рекорд. Поэтому играю маленькими суммами на большие кэфы. Однажды удалось поймать кэф на ординаре 35.00 — я поставил в лайве на проход «Барселоны» в знаменитом матче против ПСЖ в 2017-м, когда 6:1 было.

Именно такого рода интерес меня в беттинге и прельщает. Потом со временем мне понравился гемблинг в целом — и казиношная тема, и покерная. Раньше в покер играл, но сейчас особо времени нет. 

— Если сравнить две эти позиции: казиношные и ставки, что интереснее?

— Мне интереснее беттинг. Выскажу своё субъективное мнение: он честнее. Потому что в казино, мне кажется, всё запрограммировано, и в один прекрасный момент человек может всё спустить.

Наверное, это связано с тем, что я спорт в целом люблю. Футбол на стадионе, у телевизора, самому побегать — я в теннис играю. Это, наверное, накладывает отпечаток.

— Как нужно относиться к ставкам? 

— К ставкам нужно относиться без фанатичности. Чтобы не сорваться на непонятные, ненужные моменты, которые будут мешать личной жизни. Если и баловаться беттингом, то в своё удовольствие, имея банкролл, который ты можешь проиграть. Выделил себе там условно 100 долларов в месяц и если выиграл — хорошо, если проиграл, то больше не играй. Для этого нужно иметь внутренний тумблер.

— Продолжаете сейчас ставки делать?

— Чаще всего по работе. А так на Лигу чемпионов или классные хоккейные матчи, если я что-то вижу и есть чуйка, что зайдёт, то почему бы и нет? Но опять же — это не всегда и не везде.

Юристы — отличные QA

— Как оказались в BETBY?

— Я работал в одной гемблинговой компании — это был не В2В-бизнес, а больше интеграционная платформа, которая совмещала в себе различные продукты, не только беттинговые.

Затем один знакомый, с которым раньше вместе работали, предложил пройти собеседование — и я стал здесь QA. В компании BETBY я у истоков, с её образования. Поэтому все этапы становления тестирования проходили через меня.

— Вы сразу в QA попали, когда оказались в гемблинге?

— В IT-сфере я всегда в QA работал. Джуном сначала в мануальное тестирование пришёл, зная только основы определённые, а потом через задачи начал расти. Не обязательно нужно техническое образование — в QA приходят много людей с различным образованием, начиная от юристов…

— Юристов?!

— Да, конечно. Из юристов отличные QA получаются. Их умение анализировать документацию, педантичность, внимательность — это же основа успеха. Это те качества, которые тесно переплетаются между юриспруденцией и QA. 

— Как вы оцените работу в BETBY? В чём главное отличие по сравнению с предыдущим опытом?

— Отличие колоссальное. Дело в том, что на прошлой работе у нас беттинг был в виде готового внедренного решения от провайдера. Мы на их фрейм упаковочку ставили себе на сайт и тестили уже свои моменты: взаимоотношения с кассой и со всем остальным. Здесь же совершенно другое направление — это внутренняя механика беттинга.

Компания BETBY как B2B-платформа поставляет свой продукт другим компаниям, которые его у себя интегрируют. И разница огромная — совершенно другой подход в тестировании и направление тестирования совершенно другое.

Здесь приходится углубляться в конкретные и точечные моменты разных функциональностей беттинга, каких-то фич. Кэшаут, например, — в чём их механика и смысл, лимиты и всё, что с ними связано, маржа, лиабилитиАнгл. Liability — суммарная финансовая ответственность букмекера в случае, если ставки игроков выиграют. Это банкролл, которым букмекер в совокупности может покрыть риски выплат игрокам. . И это не просто терминология — за ней стоит ряд определённых эскизов, чек-листов, которые приходится проверять.

Но перед проверкой следует ещё процедура анализа требований и понимания того, что мы делаем. Тестирование — это лишь один из последних этапов того, что предстоит сделать QA-команде.

QA — это верификация, валидация и тестирование

— Из чего состоит QA? 

— На самом деле понятие QA намного шире понятия тестирования. Оно включает в себя, как говорят в науке, три этапа. Это верификация, валидация и само тестирование.

Что такое верификация? Это процесс, который включает в себя анализ требований, работу с тестовыми документацией и артефактами, use caseТестовый артефакт, описывает поведенческую модель пользователя в конкретном случае, то есть на примере или по шагам, с визуализацией. , чек-листами и определёнными репортами. Эта та конструкция, которая служит подготовительным этапом к самому тестированию. Верификация отвечает на вопрос, делаем ли мы правильный продукт.

А валидация отвечает, делаем ли мы продукт правильно, — это тонкая грань. На этом процессе мы оцениваем, насколько наш внедренный продукт и фичи соответствуют ожиданиям клиента.

Для чего нужны первые два этапа? Для того чтобы минимизировать количество ошибок на этапе разработки продукта. Если этого не делать, то на этапе тестирования, во-первых, на нас взваливается в два раза больше работы, в два раза больше багов. Без первых двух этапов в тестирование даётся сырой продукт. Это удлиняет время доставки нужных фичей клиенту, и продукт становится дороже.

— То есть на первом этапе QA должен иметь схему работы в голове или нарисовать её?

— Перед тем как начать тестирование, QA должен понимать, что он будет тестировать и как. Для этого ему нужно проанализировать вместе с разработчиками, проджект-менеджерами, бизнес-аналитиками, по каким задачам составлять текстовую документацию. 

Предположим, приходит какой-то функционал по кэшаутам, который просто кто-то запилил и отдал в тестирование. Не понятно, каким образом она работает, что учитывает и что нет — может быть, это внедрение каких-то новых игр. Без предварительного анализа и плана тестирования, в котором мы обнаруживаем артефакты, тестировать невозможно. Для этого и существует первичный этап верификации. 

Задача может быть описана по-разному, например, она может не учитывать определённых моментов, которые как раз верификация может подсказать.

Например, появляется задача о том, чтобы система умела работать с выкупом ставки. Есть определённая формула, по которой он работает. Далее идёт обсуждение этой задачи — зная продукт и имея представление о том, как функционирует данная фича у конкурентов в мире беттинга, у нас появляются вопросы: на все ли типы ставок должен быть кэшаут? Потому что, например, кэшауты для систем — это сложно. Нужно ли нам это в конкретном случае? Можем ли мы усовершенствовать формулу кэшаута, ввести какой-то дополнительный множитель, чтобы команда риск-менеджмента могла каким-то образом регулировать этот вопрос? Например, кому-то из клиентов давать более выгодные суммы при выкупе ставки, а кому-то — менее.

Вот эти все моменты точечно надо выяснить. Если разработка их не учтёт, а клиент этого ожидает, то мы доставим в продакшин реализацию кэшаутов, которая не совпадёт с явными ожиданиями клиента и определёнными моментами. 

— Для QA важны знания в беттинге и насколько? 

— Достаточно важны. Это занимает 50% совокупности успеха работы.

 — А что ещё? 

— Ну непосредственно самого понимания процесса тестирования и STLCSoftware testing life cycle — жизненный цикл тестирования ПО. , т.е. знание того, как проходит жизненный цикл бага, например. Просто завести баг и отдать его разработчику — это ни о чём. Баг, он как ребёнок: родился, положили его в колыбельку, дальше за ним ухаживаешь, кормишь молочком — т.е. разными фичами. 

Разработчик его фиксит, затем возвращает QA. Тот всё проверяет, смотрит на предмет реверсионного тестирования: не задета ли какая-то другая функциональность, которая гипотетически может влиять на процесс и породить новые баги. Т.е. это такой маленький капризный ребёнок, за которым нужен уход. 

Финальный этап STLC-процесса — закрытие бага, когда мы убеждаемся, что он исправлен и всё нормально. Здесь мы как бы провожаем ребёнка в совершеннолетие :)

— QA это человек наблюдательный, умеющий логически мыслить и очень заботливый, как мама и папа?

— Да, где-то так.

— Для этого нужно, наверное, действительно любить продукт и то, что ты делаешь? 

— Поэтому, возвращаясь к вопросу, почему 50% — это знание беттинга. Тут даже не любовь, сколько сами знания продукта. Без знаний трудно говорить о каком-то тестировании. Абстрактные вещи, такие, например, как вёрстка — тут особо углубленного понимания не нужно. И то — понимание того, как функционирует бетслип, т.е. купон ставки — это тоже целая наука, которая требует к себе внимания.

Без знания продукта очень сложно визуально протестить купон на предмет каких-то фронтовых моментов. Правильно ли он реализован, есть ли в нём баги? Нужно понимать, какие должны быть переключатели, что такое быстрая ставка, экспресс, система, ординары и так далее. Поэтому мы подбираем в команду людей, которые мало-мальски имеют если не игроцкий опыт, то хотя бы понимание гемблинга, желательно в беттинговой сфере. 

— Купон — это маленькое окошечко на сайте, но страшно важное. А какие ещё разделы беттингового сайта критично важны?

— Это раздел, который отвечает за историю ставок. Там содержится вся информация о ставках, статусы ставок. В большинстве контор именно там реализован функционал кэшаута. Есть конторы, которые внедряют туда разные фичи: например, из истории ставок можно перейти на какой-то баннерок либо по реферальной ссылке на какой-то продукт.

Это как раз та функциональность, которая даёт понимание игроку, что происходит с его историей.

 — А куда ещё можно внедрить кэшаут? 

— Некоторые конторы делают кэшаут прямо в купоне. Сделал ставку, ничего с купоном не делаешь, сразу же появляется фича со ставочкой, и в ней есть функция кэшаута. Можно в один клик делать её. Это в первую очередь удобно для ставок в лайве.

 — Насколько важное влияние оказывает ваш отдел на компанию? Как пострадает продукт без QA? 

— Влияние оценивается наравне с другими отделами, которые участвуют в процессе функционирования бизнеса. Я не могу сказать, что QA играет какую-то меньшую роль, чем сама разработка или менеджеры, анализ, маркетинг. Все в этом отношении равны, по моему мнению.

Чуть выше я объяснял принцип построения работы QA и на что оно влияет. Ещё одним важным направлением является так называемая проактивная деятельность. Это внедрение и предложение различных импрувментов ? Улучшений.. 

Иногда QA наравне с бизнес-аналитиками и менеджментом анализируют те практики, которые существуют у конкурентов, и вообще смотрят на продукт, который мы реализовали, — при желании его всегда можно улучшить. Поэтому влияние QA на продукт — это обоснованность импрувментов.

— Можно ли оценить работу QA в цифрах? 

— Существуют определённые метрики эффективности QA. Они измеряются в количестве покрытых тестов. Но самое главная эффективность работы заключается в недопущении или минимизации критических моментов, багов, которые могут сказаться на финансовой составляющей компании. 

QA — это фильтр между разработкой и продакшеном. Он должен валидировать те неприятные моменты, которые в целом могут сказаться на кошельке компании, то есть при определённых диплояхОт англ. software deployment — развёртывание ПО. Процесс доставки новой реализации задачи в продакшн.  нельзя допускать критических багов. Это один из первых моментов, который может застопорить процесс принятия ставок, положить продукт. Не дай бог, если это финансовая составляющая — например конвертация валют. Много кейсов с этим связано.

— Конвертация валют — это тоже ваша зона ответственности? 

— Конечно, это же часть проверки. Причём конверт валют может быть очень большим. Я не буду сейчас внедряться в саму глубокую механику, но на базовом уровне постараюсь объяснить. Во-первых, валюты бывают разные. Есть стандартные, которые делятся на 100: евро, доллар, рубль, гривна. А есть специфические, в которых, например, не 100 копеек в одном рубле, а 1000 — это, к примеру, африканские валюты.

Чтобы конвертировать, нужно понимать, где брать курсы валют. Источники разные: у одного клиента может быть один, у другого другой. И нужно дать максимально подходящий источник с точки зрения выгоды.

А есть ещё и третий вид — это касается криптовалют. Там вообще отдельная система исчисления, и волатильные валюты берутся из разных источников. У нас используется широкий спектр валют. Их больше 100 — как обычных, так и специфических криптовалютных механизмов: биткоин, эфир и всё остальное. 

Наш стэк технологий в QA — в основном Java

— Насколько ваша работа может быть автоматизирована? 

— Автоматизация играет большую роль в процессе тестирования — она спасает во многих моментах. Но важен баланс между мануальным тестированием и автоматизацией.

По моему субъективному мнению, без мануального тестирования не обойтись. Автоматизация всего и вся — это по большому счету утопия. Потому что автоматизация всех процессов, которые могут быть, влечёт за собой большую нагрузку на поддержку того, что есть.

Тут надо как раз распределить баланс: где быстрее, качественнее и эффективнее протестить что-то руками, а где стоит написать автотесты и следить за их поддержкой. Последнее в большей степени касается реверсионного тестирования и тех участков, которые руками проходят много раз: ставки, кэшауты, частично конвертация валют, особенно криптовалют — это те моменты, которые нужно автоматизировать.

С помощью автотестов можно сделать определённые коридоры, за границы которых криптовалюта не должна выходить. Если вышла, значит с конвертацией что-то не то. На автоматизацию всего может уйти огромное количество ресурсов компании, и в результате ни к чему хорошему это не приведёт. Поэтому нужен определённый баланс.

— А что не целесообразно автоматизировать?

— Если есть труднодоступные участки кода. Начнём с того, что у QA не всегда есть доступ к ресурсам разработчиков или базам данных, где хранятся определённые вещи, которые можно, например, увидеть через бэк-офис. Но залезть и запустить там тесты, приконнектиться к такой-то базе и с помощью SQL вытянуть что-то запросом не всегда возможно. А кейсы эти пройти нужно. Здесь как раз вступают в действие вопросы мануального тестирования.

— Как у вас устроены автоматизированные технологии?

— Стэк технологий QA нашей компании — это в основном Java. Мы используем библиотеки REST-assured, сборка проходит через Maven, библиотека автотеста — JUnit.

— Вы всё это пишите сами?

— Да, сами. Мы используем определённый фреймворк. 

Вообще к автоматизации тестирования есть разные подходы и паттерны. Например, PageObject, когда определённые элементы вносятся в определённые классы. Благодаря чему сами тесты выглядят более компактными и красивыми, а вся механика, которая обслуживает центральный тест, вынесена в отдельные элементы, компоненты, составляющие. Например, класс бетслип — всё, что отвечает за элементы купонов. Но это уже технические детали реализации.

— Есть B2B-бизнес в тестировании?

— На самом деле это вопрос вкуса, потребности и приспособления к тем процессам, которые построены в компании. Продуктов же для тестирования очень много — от гугловских, заканчивая специфическими QA-продуктами, например, универсальным инструментом Apache Jmeter, который используется для нагрузочного тестирования, хотя и для обычных проверок тоже. Тут вопрос выбора стэк-технологий. Тестирование всегда ориентировано на те потребности, которые есть в компании. Уже исходя из них, выбираются библиотеки, сборочные элементы и т.д.

— Нагрузочное тестирование сильно отличается от обычного? 

— Есть специализированные QA, которые занимаются этим. Это, по сути, вообще отдельная наука. Умения и подходы, которые применяются в нагрузочном тестировании, немного разнятся в стандартной практике — там больше нужны девелоперские знания.

Это легко звучит, но на самом деле в нагрузочном тестировании свои этапы, метрики нагрузки — когда можно давать максимальные нагрузки, когда просто лайтово проходить. И главное — из всего из этого уметь делать выводы. Провести серию нагрузочных тестов ради того, чтобы их просто провести — не решение. Нужно уметь грамотно проанализировать полученные результаты.

В нашей компании нагрузочное тестирование не ложится полностью на плечи QA. У нас разделение труда, и разработчики тоже участвуют. Они помогают понять специфику реализации теста или использования определённых утилит.

— У вас достаточно большая база знаний. Вы много читали или у вас образование профильное?

— В части QA, да, самообразование плюс курсы хорошие. Очень был ими доволен. Причём несколько их брал, в том числе по нагрузочному тестированию. Я изучал комплексные знания как о теории тестирования в целом, так и много практических моментов, углубляясь в SQL, например, умение писать запросы. Основы Unix-подобных систем, умения работать с логами, брендированием хотя бы на базовом уровне.

— В Риге есть такие курсы или в университетах учат разработчиков?

— Так как я на QA-форумах часто пасусь, мне приходит назойливая реклама, начиная от Facebook и заканчивая Linkedin, как раз по курсам программирования, тестирования в Латвии. Я хочу сказать, что их очень много — пять как минимум. Но качества их оценить не могу, к сожалению. 

— То есть при желании можно всё изучить?

— Тут нужно баланс для себя соблюсти. Если человек способен к самообучению, для него курсы нужны как каркас, основа, а дальше он сам развивается. Некоторым моим знакомым не достаточно сидеть на ресурсах типа Хабра — им нужен лектор, чтобы вкладывал знания в голову. 

Тут ещё нужна любовь к профессии, которую ты выбрал. На самом деле многие рассматривают этап QA как переходный в сфере IT — в разработку или продакты. А есть люди, которые рассматривают QA как призвание, и только этот процесс им и нравится. К данной категории я и отношусь :)

Беседовал: Сергей Шведов.

Читайте также: