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

Всем привет! Меня зовут Найля, и я инженер по обеспечению качества в Т-Банке на одном из внутренних сервисов. Занимаюсь ручным и автоматизированным тестированием на проекте. Расскажу о том, как мы написали API-тесты с использованием фейков, что это такое и когда стоит отдать предпочтение им, а не мокам.

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

Всем привет! Недавно решил попробовать, что из себя представляет Flutter Web, подумал, может попробовать сделать бота для Telegram, и заодно настроить простейший CI/CD для отдельного фронтенд- и бэкенд-проектов. Однако в интернете я не нашёл простой и исчерпывающей инструкции или процесса.

Поэтому задача этой статьи — решить эту проблему! Сделать автоматическую сборку, тестирование и деплой на сервер, и всё это — без необходимости городить SSH-ключи, Github-токены и подключать сторонние решения. Всё на минималках, без лишней бюрократии.

Одной из самых раздражающих проблем, с которыми я сталкивался за последние 25 лет в индустрии, являются нестабильные тесты (flaky tests) — тесты, которые чаще всего проходят, но иногда необъяснимо завершаются ошибкой без явных на то причин. Вы отправляете код в репозиторий, а через двадцать минут получаете уведомление о том, что набор тестов завершился ошибкой. Вам приходится бросать всё, чем вы занимались, чтобы разобраться в причине сбоя. В итоге вы приходите к выводу, что причина явно не в ваших изменениях, и прибегаете к старому как мир трюку — запускаете тест повторно. На этот раз тест проходит успешно, и вы думаете: «Опять нестабильный тест… Ну ладно». И возвращаетесь к более важным задачам.

Как и многие, я, как мог, сопротивлялся Test-Driven Development. Я не понимал, почему тесты нужно писать перед реализацией. Почему мы должны выворачивать разработку наизнанку и переворачивать естественный, как мне тогда казалось, процесс, с ног на голову.

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

И об этом мы поговорим в статье ниже.

Мы разберём страхи, останавливающие разработчика перед тем, чтобы начать, наконец, писать тесты. Выявим очевидные преимущества. Обсудим основные правила разработки через тестирование. И подкрепим всё это реальными примерами.

Приветствую! Сегодня расскажем вам про то, как реализовать Mock-серверы в Postman.

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

JSON — один из самых распространённых форматов данных, используемых для передачи и получения данных в современных API. Важно глубоко понять его. 

В этой статье я даю краткий обзор: в основном это структура данных вида key: value, содержащая примитивные типы данных, такие как строка, логическое значение, числа, а также массивы. JSON очень похож на словарь в Python. 

Привет, меня зовут Александр (aka bytehope). Прежде чем прийти к багхантингу, я пять лет занимался коммерческой разработкой. Однако меня всегда больше интересовал поиск уязвимостей, поэтому сейчас свое свободное время я провожу на площадках багбаунти.

Эту статью я решил посвятить уязвимостям, связанным с недостатками контроля прав (Broken Access Control). Вы узнаете, что это очень распространенный баг, который может проявляться самыми разными способами. Конечно, особый акцент будет сделан на практике: я покажу, как отловить четыре разных вида этой уязвимости в лабах Web Security Academy. Начнем с самых простых примеров, поэтому статья подойдет для начинающих охотников. Смело заглядывайте под кат!

Однажды я задумался, почему одни QA-инженеры застревают в мидлах, а другие — дорастают до CTO. Я исследовал эту тему, проводил интервью и пришёл к определённым выводам, которыми готов поделиться. 

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

При создании этого чек-листа из 64 пунктов в качестве точки отсчёта использовался WCAG — Руководство по обеспечению доступности веб-контента (универсальный стандарт). Решение вопросов, указанных в этом чек-листе, поможет улучшить восприятие сайта для всех его пользователей.

Привет, Хабр! Меня зовут Василина Кузнецова, я работаю инженером по тестированию в Ozon Tech. Я часто смотрю отдельные видео докладов с конференций. Полезными для себя находила доклады про особенности Selenium и Playwright в тестах фронта, про правильный процесс код‑ревью, когда вводила его в своей команде, про опыт того, как настроить процесс распространения знаний по фичам с командой, про борьбу с флаки‑тестами и многие другие. Да и просто для развития в тестировании, чтобы быть в ногу со временем, особенно когда был период работать единственным тестировщиком на проекте.

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

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

Итак, давайте начнём со списка конференций на 2025 год:

Привет, Хабр! Меня зовут Марина, я Backend-инженер в компании Авито. Сегодня я хочу поделиться собственными рекомендациями, к которым удалось прийти при работе над качеством тестового покрытия сервисов нашей команды.

Меня зовут Ирина, и я специалист по качеству в продуктовой команде iSpring.

Шесть лет назад я ушла в декретный отпуск с должности экономиста банка. Год назад прошла все этапы найма и онбординга и стала тестировщиком. Вот только оказалось, что попасть на работу — это даже не половина дела. Дальше новичка ждёт онбординг, первые рабочие задачи, вливание в коллектив, взлёты и падения.

В статье я расскажу, какие этапы проходит стажёр в процессе найма и онбординга, с какими сложностями сталкивается, и как их можно решить. Цель моей статьи — вдохновить тех, кто собирается сменить профессию и перейти в IT, и добавить решимости в прохождении этого пути.

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

Привет, Хабр! Меня зовут Денис Савран. Я старший разработчик направления серверной разработки на интерпретируемых языках и работаю в компании «Криптонит». В этой статье я хочу поделиться опытом сборки проектов на Python с использованием самых современных инструментов.

Привет, Хабр! Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-подразделении Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA.

Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы.

А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете.

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

Сталкивались вы когда-нибудь с ошибкой при просмотре потокового видео на Netflix? Может — неожиданно останавливался или вовсе не запускался фильм, который вас заинтересовал? В первой части этой серии статей мы рассказали о методологии тестирования канареечных релизов, применяемой к показателям, которые представлены непрерывными потоками данных. Среди таких показателей — «задержка воспроизведения» (play‑delay). Вот комментарий одного из читателей:

«А что если выход нового релиза не связан с изменениями в функционале воспроизведения и потоковой передачи видео? Например — что если в новом релизе будет изменено что-то, ответственное за вход пользователя в систему? Тестируя такой релиз вы, как и в других случаях, так же будете наблюдать за метрикой «задержка воспроизведения»?»

Привет, Хабр! Из этой статьи вы узнаете про применение последовательного A/B‑тестирования в Netflix.

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

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

Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг репорт хорошим. Прошу простить за долгое вступление, давайте начнем.

Всем привет, меня зовут Александр Матюшенко, я инженер по автотестированию в одной из платформенных команд в Альфа-Онлайн. В статье хочу рассказать, как внедрить функционал скриншот-тестирования в проект E2E автотестов с использованием библиотеки aShot от Yandex. Возможно, в этой статье я добавил излишне много кода на Java, но хочется более подробно показать, как это работает.

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

Для решения этой проблемы создаются проектные зависимости.