С некоторых пор в Яндекс.Деньгах все продукты состоят из множества микросервисов, для которых выходит до десятка обновлений в день. Кроме того, регулярно приходится проверять на прочность весь платежный сервис – насколько он выдерживает пиковые нагрузки, есть ли запас прочности.

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

В отделе есть еще специалисты по производительности, а также мобильному и интеграционному тестированию, но о них в другой раз.

Группа функционального тестирования проверяет работоспособность сервисов, над которыми вся продуктовая команда трудится в течение квартала. В основном проверки ручные – автотесты здесь пишут для часто повторяющихся сценариев. Кроме того, «функциональщики» выполняют обязанности техподдержки в сложных и непонятных случаях.

Что важнее: знать жизненный цикл разработки или как работает интернет

Просматривая сотни вакансий на профильных сайтах, можно подумать, что тестировщику нужно знать назубок методологию разработки, несколько языков программирования и иметь начальные навыки управления космическим шаттлом. В нашей парадигме принято ожидать, что тестировщик знает IT-алфавит и умеет составлять из него осмысленные «слова».

Можно воспринимать этот алфавит как фундамент пирамиды Маслоу, без которого по-настоящему понимать, как работает тот самый интернет, не получится.

У нас не принято назначать сверху «тестовый план» и даже нет выделенного тест-лида для распределения задач. Каждый тестировщик должен сам понимать, чем сейчас нужно заниматься, поэтому уровень личной ответственности достаточно высокий. Разумеется, общее понимание работы ключевых компонент компании тут здорово поможет, однако первое время все равно придется уточнять приоритеты в непонятных ситуациях у менеджеров проектов.

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

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

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

В первый месяц новички узнают больше про архитектуру приложения, REST API, JSON. Становятся ближе к Linux, знакомятся с языком запросов SQL и с гибкими методологиями разработки, автотестами. А также познают основы Java и Kotlin – последний показался нам удобным для автотестов благодаря более лаконичному и компактному итоговому коду.

Автотесты, к слову, у нас пишут все – если для тестировщика программирование выглядит чем-то с другой планеты, то накидывать в нужном порядке методы из нашего фреймворка он всё равно будет способен. А со временем и знания алгоритмов и языков подтянет.

Погружаться во фронтенд или бэкенд

Очень популярен среди начинающих тестировщиков подход «тестирование – это про то, чтобы прокликать все кнопки на сайте, можно быстро кликать UI и всегда быть востребованным», однако это не всегда упрощает поиск работы и дальнейший карьерный путь. К примеру, большинство сервисов Яндекс.Денег состоят из фронтенд- и бэкенд-частей, и у нас нет разделения тестировщиков по этим категориям.

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

К примеру, у нас есть внутренний инструмент для контакт-центра – веб-сервис с информацией обо всех пользовательских обращениях. В ходе очередного проекта инструмент получил новую сводную страницу, которая упрощает отслеживание состояний тикетов и соблюдения SLA.

Для новой версии нужно было сделать следующее:

• Проверить, что она поддерживает все, что было в старой версии.
• Проконтролировать соблюдение разработанных под проект User Story.
  Пример: Сотрудник мониторинга заходит на страницу мониторинга и смотрит на цвет очередей. Если есть красные – помечает, нажимает «назначить операторов», и из общего списка специалистов система автоматически выбирает всех подходящих и свободных.

Любой проект начинается с технического решения, после реализации которого к процессу подключается тестировщик.

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

На планировании проекта решение декомпозируется на задачи разработчиков, что позволяет тестировать их по мере выпуска. В такие моменты день тестировщика выглядит примерно так:

1. Утром формируешь себе список задач на день из текущего спринта ^[1]. Делается это с помощью канбан-доски в Jira, где приоритет отдается срочным вещам вроде багов. Остальные приоритеты распределяет руководитель проекта. Теперь главное – двигаться по списку и просто так его не перекраивать.

2. Проверяешь компоненты реализованных задач, обычно начиная с бэкенда, потому что он запускается в разработку раньше и фронт без бэка все равно не появится.

3. Чтобы что-то проверить, нужно знать, как все это работает в задумке. Поэтому у каждого проверяемого метода должно быть описание (что на вход, что на выход и т.п.). Но обычно информации не хватает (что понятно разработчику, не всегда понятно остальным), в этом случае сильно помогают Swagger и отзывчивые коллеги. Добытые знания полезно добавить в техническое решение, для пользы остальным и для истории.

У нас в инфраструктуре широко используется REST API, поэтому частый сценарий тестирования – запросы HTTP, отправляемые через Postman.

К слову об инструментах – в ежедневной работе наши тестировщики используют следующий набор:

• Postman или cURL – для отправки http-запросов.
• SoapUI.
• Командная строка Linux для просмотра логов и установки компонентов, в частности grep – лучший друг в просеивании информации. К слову, в начале карьеры достаточно совсем базовых навыков.
• Клиенты Oracle DB и PostgreSQL – для просмотра и управления данными в базах.
• Kibana для просмотра как «боевых», так и тестовых логов.
• Наконец, универсальный инструмент IntelliJ IDEA, отлично подходящий как для написания автотестов, так и для ручного тестирования: некоторые коллеги предпочитают для проверки API сразу накидать прототип теста вместо использования Postman.

Выбор конкретного инструмента зависит от личных предпочтений тестировщика и наличия инструмента на целевом хосте.

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

Обычно тестирование бэкенд-части заключается в отправке запроса с необходимыми входными данными, получении ответа и проверке, что результат соответстветствует документации. Эта простая цепочка часто спотыкается, например, о необходимость проверить запись результатов POST-запроса в БД. Для этого проще всего вручную зайти в БД через агента СУБД и проверить корректность данных.

Поэтому нужно локально зайти на сервер с базой (например, PostgreSQL) или через pgadmin и выполнить запрос на выборку интересующих данных. Язык SQL знать не обязательно, так как все можно сделать в графическом интерфейсе pgadmin. Однако совсем базовые конструкции SQL-запросов знать все же желательно (SELECT*, WHERE, ORDER BY).

Например, в БД может быть 10 000 записей, и искать данные через GUI может быть слишком долго. В общем, тестировщику хорошо бы уметь быстро написать в консоли запрос вида:

select * from {table_name} where {table_name.column_name}='condition' order by {column_name} desc;

Всё остальное – приятный бонус.

О балансе тестирования и межведомственном общении

Самостоятельность тестировщику нужна не только для выбора задач, но и для проведения серии тестов – нужно всегда искать баланс между «проверить все, что можно» и временем на это. Нет смысла проверять все возможные значения и сценарии в компоненте, если он уже получает данные из специальной формы с проверкой значений.

К примеру, есть метод, который принимает на вход только строковые переменные, и нужно проверить, что будет при передаче туда скриптов (к слову о безопасности) или переменных Integer. Даже составлять перечень таких данных очень долго, не успеешь выполнить другие задачи. В выборе разумного перечня тестов помогут уже готовые user stories. В сущности, фронтенд уже ограничивает ввод некоторых параметров, что резко сужает список проверок.

Некоторые задачи требуют проверки в условиях, приближенных к боевым, – например, на тестовой среде трудно полностью проверить платёж картой, проходящий через всех эквайеров и платежные системы. Поэтому проверка проходит на нашем preproduction – несколько фронтэнд-хостов, отключенных от балансировщика и доступных только из нашей сети по прямому URL.

По сравнению с тестовой средой, проверять сценарии в «боевых» условиях не так удобно из-за отсутствия некоторых доступов, да и настоящие деньги тратить не хочется. Поэтому на preprod-окружении мы проверяем только ограниченный приемочный набор тестов.

Интересно обстоят дела с проектами, где задействована не только наша компания, но и партнеры. Хороший пример – поддержка бонусной программы партнера, для которого Яндекс.Касса выступает как платежное решение. Кассе нужно уметь передавать ему информацию о бонусах и осуществлять, например, погашение ими части покупки – зависит от желания покупателя и возможностей бонусной программы.

Вся соль таких проектов – в «межведомственном взаимодействии», когда для успеха нужны определенные действия с той стороны.

Если помните прошлую статью о подборе тестировщика ^[2], то там важное значение имел навык общения – умение со всеми договариваться. И тут оно пригодится как нигде. При совместном проекте с любым партнером, с которым мы обмениваемся специфической информацией, необходимо получить рабочую тестовую среду и сами данные. Последнее может быть пулом партнерских карт, среди которых есть заблокированные, условно-неподдерживаемые бонусной программой и т.п.

Кроме тестовой среды и данных, нужен также канал коммуникации (обычно Telegram, который нравится партнерам и под который написано много ботов для собственных нужд) для оперативного общения технических специалистов. Когда подготовительные работы проведены, остается дождаться готовности проверяемого метода на стороне партнера.

Например, рассмотрим подробнее проверку метода типового платежа, которая состоит из следующей цепочки действий:

1. Установка сборки на тестовую среду. Теперь это можно делать с помощью Jenkins, о чем тоже скоро напишем, а пока вы можете почитать соседнюю статью про Jenkins в CI & CD процессе ^[3].
2. Так как все запросы выполняются с токеном карты, нужно получить уникальный токен под каждую цепочку платежа. Этапы цепочки: получение токена, запрос количества баллов для списания в рамках корзины (магазин передает в Яндекс.Деньги корзину с суммами товаров), совершение платежа с учетом партнерских бонусов.
3. Далее следует специфика конкретного партнера, которая обычно включает обмен информацией о бонусах с какими-то последующими действиями.
4. В ходе запросов из предыдущего пункта от партнера должен прийти ответ, в котором важно проверить его соответствие документации. Обычно ожидаем успешный статус-код (HTTP 200), тело ответа со статусом успешности операции, ID платежа, статус заказа, статус оплаты на стороне клиента. Проверяется как перечень полей, так и диапазон допустимых значений и совпадение ответов с произведенными действиями.
5. Если бонусная программа партнера предполагает отправку ему дополнительной информации по итогам транзакции, то также проверяем успешность доставки этих данных. Обычно просто смотрим логи на нашей стороне, проверяем, что в нашей системе сформирован заказ, платеж проведен и т.п.

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

Такая цепочка действий в дальнейшем автоматизируется для ускорения повторных тестов. Сами автотесты пишутся на Java или Kotlin.

Однажды на собеседовании после вопроса, что такое первичный ключ, меня в ответ спросили: «зачем вы это спрашиваете? Открываешь Хабр, там каждая вторая статья про блокчейн, нейро-сайенс и искусственный интеллект, а вы тут про первичные ключи». Эта статья – попытка объяснить, что знания тестировщика – это своеобразная пирамида Маслоу и без знания базовых вещей на следующие уровни не перепрыгнешь.

Базы данных, коды HTTP-ответов и консоль Linux – это своеобразный алфавит, который вам позволяет осмысленно говорить на языке IT-индустрии. Без них вы будете сидеть в китайской комнате ^[4], не особенно понимая, что вас спрашивают, но зная, какой ответ от вас ожидают.

Таким образом, мы ждем от нового человека не просто знания алфавита, а умения складывать из терминов предложения и способности понимать, что это значит на самом деле.

Автор: embriodead

Источник ^[5]