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

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

В нашем арсенале более 2500 скриншотных тестов, поэтому многие выводы сделаны на основе длительного опыта эксплуатации.

Привет! Это снова Михаил Федоров. В первой статье я рассказал про архитектуру QA Assist — системы из 11 AI-агентов для автоматизации тестирования. Во второй — честно показал, как «4 часа подключения» превращаются в неделю корпоративной реальности.

Сегодня поговорим о штуке, которая на первый взгляд не имеет отношения к AI. О пирамиде тестирования. О том, почему классическая теория QA внезапно оказывается критически важной, когда вашим тест-дизайнером становится языковая модель с контекстным окном.

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

В Go нет фикстур, и в интеграционных тестах это быстро превращается в копипаст. Разбираем, как вынести инфраструктуру из автотестов и управлять жизненным циклом ресурсов.

Ранее в статье: Soft Skills для тестировщика: почему «мягкие» навыки важнее «жестких» скриптов я попытался рассказать почему для тестировщика важно развивать Soft Skills, а сейчас разберемся как это реализовать на практике.

Развитие мягких навыков — не разовая акция, а постоянный процесс. Поскольку я работаю QA‑инженером, то данный материал в большей степени будет полезен для QA, но и разработчики и менеджеры и другие участники команды могут найти для себя что-то полезное.  Ниже я привел конкретные, проверяемые методы для прокачки ключевых soft skills.

За последние пару лет AI начал постепенно проникать в инженерные процессы разработки. Сначала это были генераторы кода, затем инструменты анализа логов, а сейчас всё чаще появляются решения, которые помогают автоматизировать аналитическую работу.

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

Ваш тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но вот чего он не проверяет: реально ли записалась строка? Правильно ли записались позиции заказа? Уменьшился ли инвентарь? UI написал «подтверждено», но UI иногда врёт — проглоченная ошибка, откаченная транзакция, очередь, которая молча дропнула сообщение.

Классическое решение некрасиво: нужно подключить ORM или низкоуровневый драйвер базы данных внутри тестового харнеса, управлять отдельными учётными данными, писать SQL-ассерты вручную и надеяться, что схема не изменится. Работает. Но это накладные расходы на поддержку, которые вы платите за каждый тест.

Сейчас есть паттерн лучше. И в нём ноль SQL с вашей стороны.

Что если один AI-агент сможет делать обе половины — управлять браузером при оформлении заказа и затем переключиться в базу данных для проверки записи — используя два MCP-сервера?

Именно это разбирается в статье:

Всем привет! Меня зовут Артем. Я Android QA Engineer в команде Банки.ру.

Было ли у вас такое, что unit-тесты в проекте есть, но на практике ими почти никто не пользуется? Разработчики их пишут, но для QA это “что-то где-то в коде”: нельзя нормально посмотреть результаты, оценить покрытие или использовать в регрессе.

В статье рассказал, как мы решили эту проблему: сделали unit-тесты видимыми через Allure, связали их с тест-кейсами и встроили в реальный процесс тестирования.

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

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

На QA-митапе инженер из крупной продуктовой компании показал: AI-агент пишет тесты — все зелёные, но баги не находят. Моки подогнаны, ассерты подменены, архитектура деградирует. Стек при этом — near-SOTA: свежая модель, топовый open-source агент. Я был комментатором на том митапе и сначала списал проблемы на слабые инструменты. Но при подготовке статьи перепроверил — и вынужден поправиться. Инструменты в порядке. Проблема — в коде и процессе. В статье разбираю формулу из четырёх множителей (модель × агент × процесс × качество кодовой базы), показываю, как any-типы из соседней команды обнуляют LSP-интеграцию, которую OpenCode даёт бесплатно из коробки, и даю пошаговый Spec-Driven Development — процесс, который ломает reward hacking и работает даже на слабых моделях. Плюс чеклист, что внедрить завтра.

Привет, Хабр! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. В предыдущих статьях я рассказывал про QA Assist — AI-ассистента для тестирования. Сейчас идёт пилот на реальном проекте, копятся метрики и грабли — но писать об этом пока рано. Результаты будут, а пока давайте поговорим о чём-то другом.

Однажды друг в шутку спросил: «А тестировщики вообще могут верить в Бога? Это же не совместимо, нет?»

Вопрос оказался глубже, чем кажется. Не потому что я хочу обсудить религию на техническом ресурсе (спокойно, не буду). А потому что ответ на него выводит на кое-что полезное: неявные допущения, на которых стоит наша работа, и которые мы почти никогда не ставим под сомнение.

Эта статья — про границы знания в тестировании: что мы на самом деле знаем, что принимаем на веру, а что — на доверие. И почему разница между этими понятиями важнее, чем кажется.

Инжиниринг качества (Quality Engineering) — это современный подход к созданию надёжных и востребованных продуктов, основанный на проактивных методах, автоматизации и анализе метрик. Он помогает компаниям предотвращать ошибки на ранних этапах и обеспечивать высокий уровень качества на всём жизненном цикле разработки.

Сейчас TMS на рынке условно можно разделить на два подхода.

Первый — классический. Система работает как слой управления ручным тестированием: хранит тест-кейсы, формирует прогоны, фиксирует статусы и результаты. Вся логика выполнения при этом остается за пределами TMS.

Второй — с поддержкой автотестов. Здесь появляются интеграции с CI: система умеет связывать автотесты с тест-кейсами, подтягивать результаты запусков, отображать историю и статусы. Иногда добавляется возможность инициировать запуск, но фактическое выполнение и управление пайплайнами по-прежнему остаются в CI.

В новом релизе DoQA 4.0 как раз добавили сценарий с запуском автотестов прямо внутри TMS. Давайте разберем, как это ребята реализовали.

Playwright 1.59 — не очередное инкрементальное обновление. Это заявка на то, куда движется автоматизация тестирования, и это направление глубоко агентное. Если вы ждали, когда инструменты догонят AI-driven воркфлоу, о которых все говорят, этот релиз закрывает разрыв.

Разберём каждую крупную фичу и, что важнее, как каждую из них можно применить немедленно.

Как тестировать систему, если половина её компонентов — это «чёрные ящики» с уникальными протоколами, а стандартные API-mocks не справляются? С точки зрения готовых решений — тупик… 

Меня зовут Дмитрий, я AQA-инженер в ИнфоТеКС. Мы с командой столкнулись с этой проблемой и создали собственные API-mocks, которые не просто отвечают шаблонными сообщениями, а ведут себя как настоящие компоненты системы. В этой статье — наш путь от идеи до работающего решения, которое можно адаптировать под ваши задачи.

Привет, Habr.

Обычно найм представляют довольно просто: есть вакансия, есть кандидат, есть несколько этапов собеседования, после которых человек либо получает оффер, либо отказ. Такая картина хорошо смотрится в HR-отчётах и презентациях, но в реальности всё устроено заметно сложнее.

Если чуть дольше повариться в рынке, становится видно, что вокруг собеседований уже давно существует отдельная инфраструктура. Речь про слитые вопросы, базы по компаниям, закрытые чаты, документы и каналы, где собирают и передают друг другу реальные этапы найма. Причём это уже давно не история про редкие “утечки” или единичные случаи. Для части рынка это вполне рабочий инструмент подготовки.

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

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

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

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

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

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

Привет! Это снова Михаил Федоров. В предыдущей статье я рассказал об архитектуре QA Assist — системе из 11 AI-агентов, которая берёт на себя 80% рутины QA-инженера. Среди метрик была строчка: «Подключение тестирования на новый проект — ~4 часа настройки, первые баги уже в бэклоге».

Красиво, правда? Прямо слайд для презентации. Давайте проверим эту цифру на реальном проекте — и посмотрим, насколько я был честен с вами (спойлер: не совсем).

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

Мы разобрались с асинхронщиной, идемпотентностью и моками. Код выглядит хорошо. Тесты проходят. Но когда проект вырастает до тысячи тестов, начинают падать вещи которые падать не должны, и причина почти никогда не в логике теста.

Причина в архитектурных минах которые заложили месяц назад и забыли. В этой части разберём самые частые из них и настроим ESLint чтобы робот ловил их вместо лида на ревью.

Примеры кода намеренно упрощены для наглядности. Фокус на идее, не на архитектуре.