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

Привет, Хабр. Сегодня поговорим о новой версии Allure Report — Allure 3, а именно о её модульной архитектуре. В ней можно настроить сколько угодно отображений тестовой иерархии в разных форматах; я покажу это на простом примере. В какой ситуации может это быть полезно?

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

Мы сделаем так, чтобы при каждом запуске тестов Allure генерировал два отчёта, каждый со своим отображением тестов.

Бесплатные адвенты, «практика в реальных условиях», «с нуля до PRO», тысячи отзывов и наград. Разбираю типовую модель, по которой в 2026 году продают иллюзию входа в QA — и почему она редко приводит к реальной работе.

Когда я впервые увидел .gitlab-ci.yml, мне показалось, что это какой-то древний магический свиток. Сплошные stages, artifacts, непонятные правила... Но на самом деле всё гораздо проще — это просто рецепт: что, в каком порядке и как делать с твоим кодом.

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

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

Привет, Хабр! Я написал эту статью для тех, кто с System Design особо не сталкивался. Никаких предварительных знаний не нужно — всё объясню с нуля. Если вы уже знаете, что такое load balancer — местами будет скучно, но, может, в секции про очереди или мониторинг найдёте что-то новое.

Меня зовут Лилия Урмазова, более 20 лет назад я начала работать классическим QA-инженером.

А последние пару лет специализируюсь на тестировании AI-приложений. В настоящее время — Senior Staff AI-QA Engineer/ML Evaluation Engineer в крупной международной IT-компании.

Для тех тестировщиков, кто хочет как минимум быть “в курсе” тестирования AI, я с коллегами подготовила небольшой бесплатный практический курс.

В мире тестирования программного обеспечения часто царит культ «хард скиллов». Selenium, SQL, Postman, Charles, написание автотестов — все это визитная карточка технического специалиста. Безусловно, эти навыки критически важны. Но есть загвоздка: самый совершенный скрипт не найдет баг, который требует человеческого любопытства, и не донесет критичную проблему до разработчика, который вас не слышит.

Пора признать: ключевое отличие тестировщика-исполнителя от тестировщика-аналитика и мыслителя заключается в развитых soft skills.

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

Всем привет, меня зовут Настя, и мне НЕ нравится, когда наши компании требуют от нас повсеместное внедрение искусственного интеллекта во все процессы.

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

Как превратить ChatGPT в ассистента, который берёт эту рутину на себя? В статье — 15 промптов, которые уже помогли командам ускорить процессы и освободить время для реального тестирования.

Статья будет полезна manual/automation QA, лидам и аналитикам, которые хотят систематизировать процессы и сократить рутину с помощью ИИ.

Хорошая новость: рекламы “тестирование - это легкий вход в айти” от крупных онлайн-платформ больше нет, экономика вместе с IT-наймом упали и курсы по тестированию начали закрываться.

Плохая новость: первыми закрываются курсы с уровнем трудоустройств студентов 50%.
А не те, после которых офферы в IT получают 5%.
Значит, инфоцыган пропорционально становится только больше.

Поговорим о блоксхемах.

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

Когда тестов становится больше сотни, любая «красивая обертка» превращается в тыкву, если за ней нет архитектуры. Именно поэтому BDR - это не просто "красивая обертка".

Я никогда не был фанатом Cucumber. Да им даже толком не пользовался. Мне хватило просто посмотреть со стороны, сколько сил уходит у людей на поддержку всей этой магии с регулярками и текстовыми файлами. Это дорого. И технически, и по времени.

BDR (Business-Driven Reporting) — это не попытка «сделать как в Cucumber, только на TS». Это попытка выжить и не превратить 1000 тестов в ад поддержки. Сегодня разберем «железо»: слои, композицию и то, почему это работает без костылей.

1. Когда «просто оберток» мало

Скептики правы, если просто оборачивать каждый клик в BDR.step, вы получите тот же мусор, только в профиль. Масштабируемость — это про разделение ответственности.

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

Мы сравнили OpenLiteSpeed и классический LEMP для WordPress на реальных серверах. RPS, latency, TTFB, потребление CPU и RAM, поведение под нагрузкой до 500 пользователей. И вот какие итоги у нас получились.

В прошлой статье "Ваш отчет никто не читает: Как мы научили разработчиков понимать падения тестов за 30 секунд?" мы разбирали, как слой Flows и декораторы позволяют разрабам не тратить время на дебаг отчетов. Статья вызвала большой отклик, и сегодня я хочу раскрыть «фундамент», на котором строится этот подход.

Многие годы нам продают BDD (Behavior-Driven Development) как "серебряную пулю" для коммуникации...

Давайте честно, это чушь. Никогда не понимал, зачем мы кормим этого монстра по имени Cucumber. Тратим до 50% времени на поддержку регулярок («клея»), возимся с хрупкими .feature файлами и боимся переименовать шаг, потому что все развалится. При этом ни один менеджер в здравом уме не заходит в ваш репозиторий читать эти файлы. Они все смотрят только отчеты.

Так зачем нам Gherkin на этапе написания кода? Представляю вам новую методологию BDR (Business-Driven Reporting).

Почему классический BDD (Gherkin) — это ошибка?

Gherkin заставляет инженера работать внутри IDE, как в текстовом блокноте. Это абсурд.

Привет! Меня зовут Оля, и я AQA в Отелло. В тестировании с 2018 года, а технические собеседования на все QA грейды — от trainee до lead — я провожу с 2021. Когда-то давно, ещё будучи студенткой вуза, я попала в IT-компанию через стажировку. Тогда на одно место в компании претендовали 700 человек, и в итоге работу получили только четверо — я была одной из них. Поэтому я знаю не понаслышке, сколько времени и сил нужно вложить начинающему тестировщику, чтобы получить первую работу. 

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

• Как выбрать свою первую компанию.

• Красные флаги работодателя на собеседованиях.

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

• Как подготовиться к собеседованию с помощью AI.

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

Утро, кофе, открываешь GitLab, а CI красный. Классика. Лезешь в отчёт, а там портянка на 5 экранов и TimeoutError где-то в недрах клика по кнопке. Селектор нормальный, data-testid="checkout-submit". Чтобы понять, что именно сломалось (может отвалилась база или фронт не отрисовал кнопку, возможно, юзер тупит), нужно лезть в код теста и дебажить глазами.

Бесит нереально. Ты или твой коллега тратите время не на фикс багов, а на расследование.

Классический POM: Как мы жили раньше?

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

Я люблю и практикую ChatOps. Поэтому решение пришло само: пусть агент мне пишет в телеге, когда я ему нужен.

На ранних этапах разработки аналитика часто оказывается в тени функциональных требований: фича работает — значит, задача выполнена. Корректность событий, логика их отправки и влияние на будущие отчеты нередко проверяют только после релиза — если вообще доходят до этой проверки. Но аналитика — это полноценный продуктовый инструмент. Именно на результатах аналитики строят гипотезы, запускают A/B-эксперименты и принимают бизнес-решения.

В этой статье Андрей Смирнов, инженер по тестированию Циан, раскроет, почему аналитика — это не «дополнение», а часть фичи, какую роль в ней играет тестировщик, а также как ревью аналитики повлияло на процессы и качество решений в нашей команде. Статья отражает опыт взаимодействия QA и аналитика внутри нашей продуктовой команды.

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

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

Новый проект, первый день. Тебя добавили в Slack, кинули ссылку на Jira и PM говорит: «Вот команда, начинай». И ты начинаешь… угадывать. Когда ретро? К кому идти, если упал стенд? Почему задача висит в Review неделю?

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

Проблема не в твоей компетентности, а в отсутствии системного онбординга. Исследования показывают: QA-специалист должен начать приносить пользу (находить баги) в течение 2-4 недель. Без правильных вопросов на старте этот срок растягивается на месяцы.

Этот гайд – ваша страховка от хаоса. Мы объединили критические вопросы тимлиду и расширенный чек-лист, который поможет профессионально влиться в работу за первые 48 часов.