Семь раз оттесть, один раз деплой
Playwright 1.59 — не очередное инкрементальное обновление. Это заявка на то, куда движется автоматизация тестирования, и это направление глубоко агентное. Если вы ждали, когда инструменты догонят AI-driven воркфлоу, о которых все говорят, этот релиз закрывает разрыв.
Разберём каждую крупную фичу и, что важнее, как каждую из них можно применить немедленно.
Как тестировать систему, если половина её компонентов — это «чёрные ящики» с уникальными протоколами, а стандартные API-mocks не справляются? С точки зрения готовых решений — тупик…
Меня зовут Дмитрий, я AQA-инженер в ИнфоТеКС. Мы с командой столкнулись с этой проблемой и создали собственные API-mocks, которые не просто отвечают шаблонными сообщениями, а ведут себя как настоящие компоненты системы. В этой статье — наш путь от идеи до работающего решения, которое можно адаптировать под ваши задачи.
Привет, Habr.
Обычно найм представляют довольно просто: есть вакансия, есть кандидат, есть несколько этапов собеседования, после которых человек либо получает оффер, либо отказ. Такая картина хорошо смотрится в HR-отчётах и презентациях, но в реальности всё устроено заметно сложнее.
Если чуть дольше повариться в рынке, становится видно, что вокруг собеседований уже давно существует отдельная инфраструктура. Речь про слитые вопросы, базы по компаниям, закрытые чаты, документы и каналы, где собирают и передают друг другу реальные этапы найма. Причём это уже давно не история про редкие “утечки” или единичные случаи. Для части рынка это вполне рабочий инструмент подготовки.
Сразу уточню важный момент. Эта статья не про мораль, не про публичные разоблачения и не про попытку назначить кого-то злодеем.
Мне интереснее разобрать само явление: почему рынок слитых собеседований вообще появился, как он работает и почему стандартные процессы найма сами неплохо помогают ему жить.
Потому что проблема тут не только в кандидатах, которые хотят пройти собес по короткому пути. Проблема ещё и в том, что многие компании годами проводят одни и те же интервью почти в одном и том же виде, а значит рано или поздно этот процесс начинает жить своей отдельной жизнью.
Самый дорогой регрессионный набор не тот, который долго выполняется, а тот, которому команда перестала верить. Когда команда внедряет автоматизацию, она быстро приходит к соблазнительной идее: если автотесты ускоряют проверки и исключают человеческий фактор, значит автоматизировать нужно всё, до чего можно дотянуться. Но здесь и начинается ошибка. Автоматизировать всё, что можно, и автоматизировать то, что действительно нужно, не одно и то же.
Меня зовут Гайнутдинов Роман, я старший инженер по автоматизированному тестированию в компании «БКС Мир инвестиций». За плечами построение автоматизации с нуля, поддержка готовых решений и оптимизация уже раздутых регрессионных наборов.
В этой статье разберём логику приоритизации: что автоматизировать в первую очередь, что не стоит тащить в обязательный регресс совсем, и как выбрать уровень проверки. Если вам ближе автоматизация с расчётом на пользу и стоимость, а не всё подряд, сначала стоит разобраться, почему автоматизация без стратегии почти неизбежно превращается в набор дорогостоящих и малополезных проверок. Этот материал будет полезен тестировщикам, разработчикам, менеджерам и всем, кто связан или только знакомится с автоматизацией тестирования.
Привет! Это снова Михаил Федоров. В предыдущей статье я рассказал об архитектуре QA Assist — системе из 11 AI-агентов, которая берёт на себя 80% рутины QA-инженера. Среди метрик была строчка: «Подключение тестирования на новый проект — ~4 часа настройки, первые баги уже в бэклоге».
Красиво, правда? Прямо слайд для презентации. Давайте проверим эту цифру на реальном проекте — и посмотрим, насколько я был честен с вами (спойлер: не совсем).
Часто дело не в отсутствии вариантов, а в неопределенности: куда двигаться дальше и хватает ли текущей базы для следующего шага. Решение об обучении обычно принимают взвешенно, но без четкого понимания своего уровня легко ошибиться с выбором. В этом дайджесте — 14 направлений с вступительными тестами: они помогают трезво оценить подготовку перед стартом и понять, насколько обучение сейчас будет полезным.
Мы разобрались с асинхронщиной, идемпотентностью и моками. Код выглядит хорошо. Тесты проходят. Но когда проект вырастает до тысячи тестов, начинают падать вещи которые падать не должны, и причина почти никогда не в логике теста.
Причина в архитектурных минах которые заложили месяц назад и забыли. В этой части разберём самые частые из них и настроим ESLint чтобы робот ловил их вместо лида на ревью.
Примеры кода намеренно упрощены для наглядности. Фокус на идее, не на архитектуре.
Всем привет! Меня зовут Юля Трусова и я тестировщик. А ещё я лидирую под ключ одно из самых крупных и древних комьюнити в Авито — QA Community. В этой статье я расскажу про свой подход к теме, поделюсь важными вехами в становлении комьюнити и с удовольствием почитаю про ваш опыт в комментариях.
14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.
Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.
Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.
Даже с чистым кодом тесты могут падать с завидной нерегулярностью. Раз в десять прогонов, чаще в CI, чем локально. Не потому что CI какой-то особенный, а потому что там может быть меньше CPU, выше latency между сервисами и куча параллельных процессов. Асинхронные проблемы никуда не деваются и локально, но более мощная машина и быстрая сеть их маскируют. Стоит условиям стать чуть хуже, и тайминги разъезжаются: фронтенд уже отрисовал результат, бэкенд ещё обрабатывает запрос, а транзакция в базу ещё не закоммичена. Тест идёт проверять и не находит там того, что ожидает.
Три темы, которые дают стабильность на больших числах:
В дашборде было 83 успешных engagement’а. В аналитике X — 16 настоящих ответов. Пять к одному. Неделю я этого не замечал.
Контекст: у меня автономный AI-агент, который пишет комментарии в X (Twitter) от имени клиентов. Находит релевантные треды, генерирует ответ, публикует через браузер. Без моего участия. Ну, предполагается что без моего участия.
Матрица трассируемости (RTM) — инструмент, который помогает QA видеть реальное покрытие требований и не тестировать «вслепую».
В статье разберём:
• что такое RTM и зачем она нужна
• какие бывают типы трассируемости
• как выглядит матрица на практике
• типичные ошибки при работе с RTM
примеры таблиц, схемы и чек-лист для QA
Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.
«Кроилово ведёт к попадалову» — знает каждый русскоязычный, поляк бы сказал — «Tanie mięso psy jedzą», в британских колониях прозвучит — «Penny wise, pound foolish»...
Это история о том, к чему приводит экономия на SMM персонале и незнание банального
«Quis custodiet ipsos custodes?»
Postman используют миллионы разработчиков — и не зря. Удобный интерфейс, коллекции, окружения, командный доступ. О чём еще мечтать?
Но если вы большую часть дня проводите в IDE, у этого подхода есть один постоянный friction point: нужно переключаться. Открыть Postman, вспомнить, где нужный запрос, скопировать токен из консоли, вставить руками. Потом вернуться обратно. И так по кругу.
В этой статье разберем альтернативный HTTP-клиент, который встроен прямо в IDE и его возможности для тестирования API.
В статье разобраны основные группы мероприятий, из которых состоит процесс тестирования. Вы узнаете:
▪️ чем отличаются тестовые условия от тест-кейсов,
▪️ зачем нужны таблицы решений и попарное тестирование,
▪️ как мониторинг и контроль помогают в общем процессе,
▪️ почему ретроспектива тестирования так же важна, как и планирование.
Материал будет полезен тестировщикам, разработчикам, тимлидам и всем, кто хочет выстроить процесс тестирования.
Привет всем, я Надежда Дудник, главный инженер по тестированию в Сбере, ментор по тестированию ПО и автор канала по тестированию @protestinginfo.
Хочу вам рассказать о важности написания хорошо структурированных тестовых сценариев на примере стратегии их составления для бэкенда.
Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.
Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.
Здесь мы рассматриваем фабрики в тестировании. На очень элементарных примерах, с использованием языка python и инструментов Django, pytest, factory_boy.
JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.