Тестирование веб-сервисов *

В  Lamoda Tech мы работаем не только над e-comm платформой и приложениями, но и создаем продукты для внутренних пользователей. Например, системы для пунктов выдачи заказов, приложения для пеших курьеров и так далее.

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

В какой-то момент ситуация стала критической: в списке скопилось больше 100 задач. Для двух небольших команд это стоило бы пары лет разработки, если брать по 2 задачи в каждый спринт.

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

В Go 1.20 сделали возможность сбилдить приложение с флагом cover

go build -cover

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

Это, конечно, было сделано для интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но, вероятно, это можно попробовать использовать и по-другому:

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

Так можно найти недовыпиленный легаси-код, старые эндпоинты API, которые давно никому не нужны, малозначимые проверки if err != nil и прочее. Как минимум, на это интересно посмотреть, можно найти что-нибудь удивительное.

Disclaimer: разумеется, сбор статистики создает какой-то оверхед, поэтому подойдёт точно не всем. Как вариант, можно пустить туда небольшую часть трафика.

Сталкивались ли вы с проблемой возникновения багов из-за пересечения включенных фичей в приложении? Или, возможно, была необходимость одновременно проводить большое число A/B-экспериментов в одном компоненте? 

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

Меня зовут Денис Стасьев. В этой статье расскажу о том, как мы внедряли машину состояний в одном из компонентов главной страницы Mail.ru — блоке новостей, что получили на выходе и ещё подробнее о том, почему в итоге остановились на XState.

В последние годы в разработке Android наметился заметный сдвиг в сторону декларативных UI-фреймворков, и последним дополнением к этой экосистеме стал Jetpack Compose. Декларативные UI-фреймворки предлагают структуры контроля, с помощью которых можно менять способ отрисовки пользовательского интерфейса. Декларативно созданные пользовательские интерфейсы могут использовать эти структуры управления, что делает их более динамичными, чем императивные фреймворки, которые обычно используются для разработки под Android и IOS. 

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

В марте мы с ИТ-лидером системы Alfa ID и её архитекторами генерировали идеи по повышению стабильности и устойчивости системы, потому что в течение года планировался кратный рост нагрузки. Одной из мыслей, которая потом успешно воплотилась в реальность, была «А давай хаос инжиниринг попробуем? А то мало у нас проблем на проде как-то пока»

Автоматизированное тестирование стало настолько неотъемлемой частью обеспечения качества, что некоторые тестировщики задаются вопросом, не заменит ли оно полностью ручное.

Все мы привыкли к общепринятым инструментам для тестирования. Думаю, список есть у каждого и он постоянно пополняется. Лично мой: Postman, IntelliJ IDEA и DataGrip от JetBrains, ShareX для скриншотов и его величество DevTools. 

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

От коллег-тестировщиков я не раз слышал: «В ручном тестировании упёрся в потолок, хочется перейти в автоматизацию, но боюсь, что не потяну» или «…не знаю, с чего начать». Меня зовут Михаил, в тестировании 7 лет, из них около 4 занимаюсь автоматизацией. В последние пару лет мануальщики нужны всё реже, некоторые компании их уже не нанимают. Бизнесу интересны fullstack-специалисты, умеющие и вручную тестировать, и автоматизировать. Мой опыт подсказывает, что перейти из ручников в автотестеры по силам каждому. Так что я протёр клавиатуру и написал для вас эти мемуары. Заходите под кат, возможно, статья будет волшебным пенделем стимулом для тех, кто ещё сомневается и тянет с переходом. 

Не так давно (13 Сентября 2023) на Хабре опубликовали статью "Подборка выдающихся статей по тестированию". В приведенном списке есть и статья "Фетиш юнит-тестов" Мартина Сустрика.

Я считаю эту статью вредной, и постараюсь показать – чем именно. Кто-то из читателей согласен с утверждениями Мартина. Возможно, кто-то из них не смотрел с позиции QA на эти утверждения. Именно для них я изложил свою точку зрения.

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

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

Эту статью я хочу посвятить непростой работе QA-инженера, которую так легко обесценивает реклама курсов по «входу в IT». При этом все хотят работать только с профессионалами, но хорошего тестировщика днём с огнём не найдёшь. Потому что тестировщик — это командный игрок, который создаёт синергию для выпуска хорошего продукта. В слаженной команде QA-инженер становится T-shaped специалистом: умеет погружаться в код, может дать дизайнеру идеи  по UX и т. д. То есть социальные навыки у QA должны быть развиты не хуже технических. 

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

Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.

Привет! Меня зовут Лёша и я тестирую веб в 2ГИС. Расскажу, зачем мы выделили багам бюджет и наделили их весом, и как мы придумали систему исправления ошибок, из-за которой больше не приходится спорить.

Приветствую всех читателей, меня зовут Вадим, я — бэкенд-разработчик в компании Домклик. В этой статье я хотел бы поделиться своим интересным опытом мажорного повышения зависимостей в проекте, который свыше пяти лет находится в проде под ежедневной нагрузкой более 2000 RPS. Мне пришлось обновить наш основной фреймворк сразу на несколько мажорных версий. Приглашаю прочесть как именно и зачем я это делал!

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

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

Сейчас я курирую QA в нескольких командах в Спортмастер Лаб, и в том числе помогаю им выстраивать те самые хорошие процессы.

На одной из прошлых SQA days я сделала доклад на тему анализа дефектов в командах, и решила написать статью по его мотивам.

Будучи консультантом по тестированию, я за годы работы прочитал массу статей по QA. Большинство из них — это в какой-то степени полезные, но часто случайные материалы, которые не всегда стоят времени. Но иногда я натыкался на удивительно хорошие статьи, которые действительно могут помочь улучшить навыки написания тестов. Я отобрал эти статьи и написал к ним аннотации. Половина из них относится непосредственно к JavaScript / Node.js, вторая половина охватывает общие концепции тестирования, которые применимы в любом языке.

Тестирование API — это тестирование ПО, при котором API тестируются на уровне сообщений, например, веб-сервисы SOAP, REST API и т.д.  

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

Тестирование API особенно полезно при agile с ее короткими циклами разработки, что повышает необходимость автоматизировать тестирование.

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

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

Жизнеспособность плана зависит от того, знают ли все участники проекта, что они делают и как.