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

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

Меня зовут Гайнутдинов Роман, я старший инженер по автоматизированному тестированию в компании «БКС Мир инвестиций». За плечами построение автоматизации с нуля, поддержка готовых решений и оптимизация уже раздутых регрессионных наборов.

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

Привет! Это снова Михаил Федоров. В предыдущей статье я рассказал об архитектуре 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.

Если вы уже имели опыт написания Ul-тестов для проверки страниц и форм, то, вероятно, задумывались: "Почему бы не протестировать весь сценарий целиком?" Так родилась идея делиться опытом, как мы внедрили подобный подход: начиная с первых шагов, объясняя, почему объединили UI, АРІ и SSH в единый интеграционный контур, и какие инструменты используем.

В первой части был заложен фундамент: локаторы, «умные» ассерты и хелсчеки. Это критически важные вещи, но на масштабе в 100+ тестов неизбежно возникает «второй слой» проблем — сложность диагностики и изоляция данных.

Неделю назад по сети пронеслась новость о том, что генеральный директор Y Combinator Гарри Тан с помощью ИИ Claude пишет десятки тысяч строк кода ежедневно и имеет виртуальную команду из 10+ ролей. Я решил проверить насколько это решение действительно рабочее и не является ли оно очередным хайпом. В этой статье мы разберемся, что за инструмент использует CEO Y Combinator и в чем его особенности. А также попрактикуемся в его использовании.