Почти 800 тестов, 10 минут на прогон, каждый пуш — ожидание на CI. Знакомо? Рассказываю, как довёл время до 101 секунды: снижение таймаутов, параллелизм ScalaTest, shared Testcontainers и защита от регрессий. Scala, SBT, PostgreSQL, GraalVM — конкретные шаги и подводные камни.
Когда я только начинал свой путь в автоматизации, мне отчаянно не хватало толкового и структурированного материала по паттернам проектирования именно для автотестов. Хороших статей про паттерны в целом — вагон, а вот с привязкой к тестированию — днём с огнём не сыщешь.
Паттерны — это та вещь, которая моментально выдает уровень культуры кода и понимание инженерных практик. Неудивительно, что на собеседованиях на позицию Automation QA любят покопаться в этой теме.
В этой статье я решил закрыть этот пробел. Вы найдете не только продуманную классификацию основных паттернов автоматизации, но и самый подробный, на мой взгляд, разбор каждого из них с примерами. А в конце поговорим про антипаттерны.
Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.
HTTP простыми словами. Часть 1 (Основы).
Статья для тех, кто хочет разобраться в основах протокола. Рассматриваются методы HTTP, форматы запросов и ответов, URI/URL, версии протокола, заголовки и коды состояния.
Материал содержит схемы и примеры, включая ручную сборку HTTP-запроса и отправку через PowerShell. Подойдёт начинающим разработчикам (фронтенд, бэкенд), тестировщикам и всем, кто работает с веб-технологиями.
Первая часть цикла – в следующих статьях будет разобран жизненный цикл HTTP-соединения.
Привет, Хабр! Это четвёртая статья из серии про QA собеседования. Уже разобрали тест-дизайн, API и Security и System Design. Теперь — SQL. На собеседованиях SQL задают чаще, чем многие ожидают. Не уровня DBA, но и не SELECT * FROM users. Обычно дают таблицу и просят написать запрос прямо на доске или в Google Docs. Если впадаете в ступор при слове JOIN — эта статья для вас.
Вы попросили ChatGPT добавить скидку 10% на заказы больше $100. Он выдал 40 строк кода. Скидка работает - проверили на заказе в $150, получили $135. Закоммитили.
Чего вы не заметили: модель переписала функцию расчёта цены целиком. Не потому что нужно было. Просто так получилось - LLM не "редактирует" код, он генерирует новый текст на основе вашего промпта и контекста. В процессе он изменил порядок вычисления налога. Заказы меньше $100 теперь считают налог дважды. Товар за $10 стоит $10.80 вместо $10.50. Вы узнаете об этом через три недели, когда клиент напишет в поддержку.
Хотите прокачать React и Kotlin, разобраться, как устроены саги и брокеры сообщений в распределённых системах, подтянуть Docker и Linux, а заодно понять, где в 2026-м заканчивается ажиотаж про хранилище данных (DWH) и начинается работающая практика? В этом дайджесте собрали 60 бесплатных уроков марта по ключевым направлениям: программирование, архитектура, инфраструктура, информационная безопасность, тестирование, машинное обучение и наука о данных, аналитика и управление.
Мехника прежняя: прикладные разборы от экспертов, инструменты и подходы из реальных проектов, возможность задать свои вопросы. Выбирайте тему, регистрируйтесь и приходите за конкретикой.
Браузер — основная рабочая среда QA-инженера, но стандартные DevTools не всегда удобны для повседневных проверок. В этой статье собраны 10 полезных расширений Chrome, которые помогают быстрее проверять верстку, отслеживать визуальные изменения, анализировать ссылки, работать с API и генерировать тестовые данные. Подборка ориентирована на практическое использование и подойдёт как manual-, так и automation-QA.
Задался вопросом, а чем, собственно, я занимаюсь, уже 1,5 года "допиливая" мои аранжированные песни через Suno? И не растворилось ли моё творчество в гомеопатической дозе в моих же ИИ-генерациях?
Чтобы разобраться, составил табличку с долями, привносимыми в песню от человека 🧑 и ИИ 🤖.. Так и нашёл конкретные ответы:
- не растворился;
- делегирую ИИ финальный чистовой production мной написанных песен;
- свой вклад субъективно оценил в 70%. А следовательно 30%🤖.
В статье предложил метод определения доли ИИ в песнях и способ их, песен, маркировки. Предварительно подробно описал, как я эти процентные доли получил. Навешал прикидочно эти маркировки/плашки/тэги на свои и чужие треки.
Также отыскал и классифицировал 11+ доступных способов создания треков в условиях современного инструментария ИИ-генераторов.
Более того, нашёл точки пересечения темы статьи с дискуссиями об ИИ на вот только отгремевшей конференции Colisium Baikal 2026 в Иркутске. Мне было интересно смотреть, поскольку некоторые факты и идеи конфы пересеклись с тезисами моей статьи, терзавшие меня ещё с этапа черновика!
Всем ИИ! 🤖+🧑
Если посчитать публичный API Ginkgo, получается внушительный список. Describe, Context, When, It, Specify, By, BeforeEach, AfterEach, BeforeAll, AfterAll, JustBeforeEach, JustAfterEach, BeforeSuite, AfterSuite, SynchronizedBeforeSuite, SynchronizedAfterSuite, DeferCleanup. Семнадцать функций, и это без F- и P-вариантов для focus и pending.
GoConvey проще, но и у него набирается не меньше: Convey, So, ShouldEqual, SkipConvey, FocusConvey, Reset и собственный DSL для assertion-ов.
Какой минимальный API нужен scoped-фреймворку для тестирования?
«На автотесты нет времени — релиз через неделю!» говорит зарубежная компания со штатом 500+ человек, зарплатами 5 000 €, баг-репортами по ISO. Разбираю, откуда берётся эта фраза, почему разработчики не могут объяснить бизнесу очевидное.
Всем привет! Меня зовут Ира Карачакова, я тестировщик в сервисе бронирования отелей Отелло.
В этой статье рассказываю, как у нас в команде выстроился процесс работы с нестабильными фронтовыми e2e-тестами: от простых перезапусков в CI до системы алертов, карантина и отслеживания стабильности.
Это не инструкция и не универсальный рецепт. Скорее история эволюции процессов в живом продукте: с какими проблемами мы сталкивались, какие решения пробовали и какие выводы сделали. Возможно, статья подкинет вам идеи и ориентиры: какие сигналы о flaky-тестах важно отслеживать, как не терять нестабильные тесты из виду и как со временем превратить борьбу с ними в управляемый процесс.
Когда-то давно, в те благословенные времена, когда программисты еще наивно полагали, что покрытие кода тестами — это показатель качества, я тоже разделял эту иллюзию. Восемьдесят процентов покрытия? Отлично! Девяносто? Великолепно! Сто? Да вы просто параноик, милейший, возвращайтесь в Скворечник, а то на ужин опоздаете.
А потом я написал библиотеку для мутационного тестирования. И понял, что все эти годы мы просто считали, сколько строк кода посещает тестовый раннер, гордясь собой, как малолетние дети, научившиеся считать до десяти.
Как вы считаете, что хуже – падение всего сервиса на сутки, или крошечный баг, слегка портящий пользовательский опыт месяцами?
В СМИ всегда попадают именно масштабные инциденты. Да и в поддержку пользователи пишут только тогда, когда что-то совсем не работает.
Раньше и я боялся больших инцидентов. Но как только мы сделали большой и сложный сервис, я понял, что бояться надо другого.
Привет! Я — Аля, старший продакт-менеджер выделенных серверов в Selectel. Представьте, вашей команде нужно разработать новый интерфейс для продукта. Вы ставите задачу на дизайнера, а он приносит статичные картинки экранов в Figma. На встрече команда смотрит на них и понимает, что половина сценариев не продумана. Возникают вопросы: «Что будет, если пользователь нажмет на кнопку или данные не загрузятся?» И вместо того, чтобы передать задачу в разработку, вам приходится выяснять детали в комментариях и чатах.
Нам это хорошо знакомо. Долгие циклы согласований, переделки после релиза, сложности с тестированием — все это было частью нашего процесса. Чтобы решить эти проблемы, мы решили попробовать AI-инструменты для прототипирования. В статье расскажу, как Figma Make и другие сервисы помогли нашей команде ускорить создание прототипов и сократить количество правок. Будет полезно тем, кто устал от цикла «получить макет → найти проблему → подождать правки → повторить».
Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.
И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте».
«Ты будешь единственным тестировщиком на проекте», — услышал я на знакомстве с командой. Ничего страшного, с кем не бывало? «У нас не было постоянного тестировщика, нужно выстраивать все процессы с нуля», — добавил мой будущий тимлид. А вот это уже интереснее.
Меня зовут Илья, я отвечаю за качество A/B‑платформы в Точка Банке. Сегодня я хочу рассказать, как тестировщику воспользоваться безграничной властью с пользой для всех (и немного для себя).
По мере роста продукта регрессионное тестирование быстро становится узким местом: количество сценариев растет, время проверки увеличивается, а цена ошибки перед релизом становится выше. В нашем случае переход к E2E-автотестам стал способом ускорить регресс и основой стабильных, предсказуемых релизов. В статье делимся тем, как мы выстроили покрытие регресса автотестами и встроили его в рабочие процессы команды.
Немного о проекте
Проект представляет собой распределенную систему, состоящую из двух web-порталов на React, порядка двадцати микросервисов на .NET и нескольких интеграций со сторонними системами. Все компоненты участвуют в одном сквозном бизнес-процессе, а релизы выходят регулярно — в среднем раз в две недели.
QA-инженер подключился к проекту уже после начала активной разработки. В этот момент мы осознанно отказались от наращивания объемной ручной тестовой документации и сделали ставку на E2E-автотесты.
Почему Е2Е?
Поддержание ручного регресса в актуальном состоянии задача важная для стабильного развития, но требует существенных затрат времени, вычитки и сверки с обновлениями. Часть кейсов теряют ценность, нужно время на их обнаружение. E2E-автотесты, напротив, становятся частью системы: они запускаются регулярно, отражают реальное состояние продукта и дают оперативный и понятный сигнал о готовности к релизу.
Для нас автотесты стали стратегическим инструментом. Они заменили собой классический ручной регресс и со временем начали выполнять роль индикатора качества — как для команды разработки, так и для менеджмента и заказчиков.
Параллельный запуск автотестов — это как ускоритель: экономит часы, но если не знать подводных камней, превращает прогон в хаос. Тесты зелёные локально, красные на CI? Падают без причины, а перезапуск «лечит»? Знакомая история. В этой статье делюсь реальными кейсами из боевых проектов: почему статические поля убивают стабильность; как «гонка данных» маскируется под рандомные падения и многое другое
Если вы пишете тесты на ZIO, то с моками, скорее всего, уже сталкивались. И почти наверняка — с ZIO Mock. Формально он решает задачу, но на практике ломает Arrange‑Act‑Assert, «краснит» в IDEA и иногда падает так, что вы видите только InvalidCallException: null. В Яндекс Вертикалях мы довольно долго жили с этой библиотекой — пока количество таких тестов не перевалило за пару сотен и они не расползлись по десятку команд.
Меня зовут Женя Веретенников, я тимлид в Яндекс Вертикалях и последние годы занимаюсь инструментами для Scala‑разработчиков и инфраструктурой бэкенд‑монорепозитория. Когда стало ясно, что ZIO Mock больше мешает, чем помогает, мы решили отказаться от него полностью — и подружить ZIO Test с классическим ScalaMock. Он даёт более предсказуемый синтаксис и понятные ошибки, но из коробки с ZIO не работает.
В этой статье я расскажу не о том, как пользоваться новой библиотекой, а о том, как мы её делали: какие ограничения ZIO‑стека пришлось учитывать, где пришлось лезть под капот ScalaMock и ZIO Test и во что в итоге превратилась эта инженерная затея. Это история про построение собственного test tooling в большой Scala‑кодовой базе — с честными компромиссами и практическими выводами.
Привет, Хабр. Сегодня поговорим о новой версии Allure Report — Allure 3, а именно о её модульной архитектуре. В ней можно настроить сколько угодно отображений тестовой иерархии в разных форматах; я покажу это на простом примере. В какой ситуации может это быть полезно?
Когда с тестами работает несколько команд, обычно удобно, чтобы у каждой был своя классификация тестов. Кто-то хочет, чтобы тесты были организованы по фичам, т. е. близко к требованиям. Кто-то предпочитает видеть организацию по сюитам — ближе к коду проверяемого приложения.
Мы сделаем так, чтобы при каждом запуске тестов Allure генерировал два отчёта, каждый со своим отображением тестов.
