Артем Сироткин

Старший специалист по тестированию в Usetech RTC

Дисклеймер: B первую очередь материал будет интересен тем, кто уже значительное время занимается тестированием пользовательского интерфейса и не знает, как подойти к тестированию backend части приложения. Я не претендую на истину: всё, что сказано ниже, является моим субъективным мнением и пережитым опытом.

Введение

Рынок IT специалистов начал стремительно развиваться в последние пару лет. Требования ко всем специальностям, которые задействованы в разработке программного обеспечения, растут со скоростью развития применяемых технологий. Требования выросли и к специалистам по тестированию. Например, если ещё в 2019 году для того, чтобы устроится тестировщиком в международную IT компанию достаточно было иметь год опыта тестирования чего-нибудь, прочитать «Тестирование dot com» Савина, уметь писать тест-кейсы, знать такие слова как «GIT», «SQL» и «Redmine», то в 2021 году ситуация стала радикально меняться. Осознание того факта, что пятилетний опыт ручного тестирования frontend части различных приложений недостаточен для конкурирования на рынке, привёл меня к выгоранию и побудил к решительным действиям. Я осознал, чтобы не остаться на обочине всей IT индустрии необходимо соответствовать современным критериям хорошего специалиста по тестированию. А именно, попытаться понять, как тестировать серверную часть приложений.

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

Отличие backend тестирования от frontend тестирования

Для начала расскажу, что такое backend тестирование (далее в тексте буду использовать сокращение БТ) и чем оно отличается от frontend тестирования (ФТ). 

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

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

Для БТ используются инструменты, позволяющие создавать тесты для API, которые предназначены для обработки запросов и в некоторых случаях их автоматизации. Позже приведу примеры таких инструментов. В общем, важнейшим отличием между этими двумя видами тестирования является то, что ФТ осуществляется на уровне пользовательского интерфейса, а БТ на уровне сервера. Важно понимать, что если мы тестируем backend, то это не значит, что мы не используем его фронтовую часть для проверок. 

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

Однако при переходе на backend есть ряд ключевых вещей, которые следует учитывать:

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

Какие инструменты могут понадобиться в работе с новым проектом:

• Graylog – Платформа с открытым исходным кодом для чтения логов

• Lens – Полноценная IDE для Kuberneties, в БТ чаще всего используется для чтения логов микросервисов. Про Kuberneties, кластеризацию, контейнеризацию и в целом про Linux также есть смысл отдельно почитать, информации достаточно, и лишним точно не будет.

• Notepad++ - Текстовый редактор с широкими возможностями, удобно читать логи, запросы и ответы. Есть плагины для xml и json, а также для декодирования Base64.

• JMS Active MQ – Брокер сообщений ориентированный на передачу сообщений на языке программирования Java.

• Offset explorer и Kafka UI – Графические интерфейсы для Apache Kafka распределенного хранилища событий и платформы потоковой обработки. 

• Redis – Резидентная СУБД. На разных проектах может использоваться по-разному, например как база данных или для реализации кэшей и брокеров сообщений.

• PostgreSQL, MySQL – Системы управления базами данных, в разных компаниях могут использоваться разные, главное знать SQL.

• DBeaver, SQL Developer, PgAdmin, Squirrel SQL – Клиенты для администрирования баз данных, бывают всякие, без SQL никуда.

• Elasticsearch – По сути документо-ориентированная база данных, используется в продуктах, для которых требуется реализация какого-нибудь поиска.

• Charles Proxy, Fiddler, Wireshark – Снифферы трафика, позволяют просматривать HTTP запросы и подменять ответы. В основном используются для ФТ, но уметь пользоваться крайне полезно.

• GIT (GIT LAB, GIT bash, GIT Extensions, Tortoise GIT) – Всё, что связано с распределенными системами управления версиями и их вспомогательными инструментами, тоже важно знать. Это упростит вхождение в сложные проекты.

• Отдельно выделю, надеюсь, всем известные инструменты разработчика: DevTools и чат-боты kuberneties в телеграм. Если ничего об этом не слышали, то срочно читайте.

Тестирование способов взаимодействия одной компьютерной программы с другими или тестирование API (Application Programming Interface), является существенной частью БТ. Тестировщик должен знать, какими инструментами тестирования API они могут пользоваться, какие сценарии нужно проверять и какие типы ошибок можно ожидать при работе с ним. 

API играет ключевую роль в процессе обеспечения функциональности приложения и включает проверку правильности запросов и ответов, а также проверку соответствия контрактам сервисов. В тестировании backend используются различные протоколы, такие как HTTP, HTTPS, SOAP и другие. Понимание этих протоколов и стандартов поможет лучше понимать, как устроен backend, и какие тесты нужно создавать.

• Postman – Наверное, самый популярный инструмент c широким функционалом для тестирования REST API. Позволяет не только собирать коллекции запросов, но и автоматизировать тест-кейсы, а также перехватывать http трафик благодаря расширению на Google Chrome - Postman interceptor.

• SoapUi – Одно из старейших приложения для тестирования веб-сервисов c SOAP (Протокол обмена структурированными сообщениям в распределённой вычислительной среде), также начинен серьезным функционалом по тестированию REST API и нагрузочному тестированию.

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

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

• jMeter – Инструмент для проведения нагрузочного тестирования от Apache.

• Yandex Tank – Чуть менее популярный инструмент от Яндекса.

• Иногда компании разрабатывают свои внутренние приложения для нагрузочного тестирования, но принцип работы будет схож с другими.

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

Концептуальные подходы к пониманию проблем:

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

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

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

• Задавайте вопросы. Тут пригодятся все ваши soft skills. Если поиск в интернете и по своим записям ни к чему не привели, то самое время обратиться к всевышним. Обратитесь к старшим коллегам-тестировщикам: наверняка они уже с этим когда-то разбирались и обязательно вам помогут (помните, что когда-то они были на вашем месте). Не забывайте задавать вопросы напрямую разработчикам фичи, которую вы будете проверять. Это закрывает большую часть проблем. Если ничего из вышеперечисленного не помогает, то пишите вашему прямому руководителю, чем быстрее, тем лучше для всех.

Как повысить свои когнитивные способности:

• Выспаться. Постоянный недосып напрямую влияет на работу мозга, старайтесь спать не меньше 8 часов.

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

• Следить за питанием. Здоровый рацион сам по себе крайне важен в жизни, но в нашем случае будет достаточно не переедать во время работы и употреблять достаточное количество жидкости.

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

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

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

• Stack trace (рус. «стектрейс», трассировка стека) – Понятие объемное и не простое, но тестировщику достаточно знать что это кусок логов который нужно прислать разработчику если возникло исключение.

• Exception (рус. «экзепшн», исключение, исключительный случай) – Возникает, когда произошло что-то что не было учтено программой, какое-то не спрогнозированное поведение.

• HAR (рус. «хар лог», «хар файл») – Архив или лог сетевых запросов браузера. Иногда тоже может потребоваться такой лог, в котором собраны все отправленные запросы.

• Breakpoint (рус. «брейкопинт», точка остановки) – Преднамеренное прерывание хода выполнения программы. Понятие может потребоваться в процессе работы со снифферами трафика или с интегрированной средой разработки.

• Mocks (рус. «моки», «заглушки») – Сюда входят любые инструменты которые заменяют реальный объект в условиях теста. Обычно применяются во всех видах тестирования, но конкретно при работе с бэкэндом без них никуда.

• Core (рус. «кор», ядро) – Достаточно широкое понятие и может употребляться в разном контексте, например, для определения какой частью приложения занимается группа разработки и тестирования, если самой основной, то говорят «кор команда». Также если речь идет непосредственно о коде: «зашито в коре».

• Monolith (рус. «монолит», монолитное приложение) – Приложения, состоящие из одной большой кодовой базы, которая включает в себя код фронтенда, бэкэнда и конфигураций. Считается уходящей в прошлое архитектурой. Нередко употребляется в одном контексте с Legacy.

• Legacy (рус. «легаси код», наследие) – Буквально термин означает старый код, который был написан очень давно по старой монолитной архитектуре. Его достаточно сложно читать и поддерживать.

• Microservices (рус. микросервисы, микросервисная архитектура) – В отличие от монолита направленная на взаимодействие небольших, слабо связанных и легко изменяемых модулей – микросервисов.

• Enterprise (рус. «энтерпрайз») – Термин не относится напрямую к понятию бэкэнд команд, но обычно сложные бэкэнд проекты являются значимой частью энтерпрайз разработки, проще говоря этим словом подразумевается промышленная разработка крупных систем под требования конкретного заказчика, ну и вся инфраструктура организации.

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

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