На главную

Выгода и опасности ИИ, мутационное тестирование, имитаторы и хитрый дебаг, новый курс про автоматизацию тестов для REST API при помощи Postman: самые интересные новости тестирования за май-октябрь 2026

2026-10-08T09:04:57Z

Опубликован выпуск рассылки за май-октябрь.

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

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Как мы приручили JMX-файл на 50 000 строк: декомпозиция JMeter-тестов для нормального code review

2026-10-06T20:00:00Z

Автор: Макарий Петров

Работая в Сбере, я столкнулся с тем, что общепринятым инструментом для функционального тестирования в моем трайбе был JMeter. Нравится ли мне это? Вопрос второстепенный. Приходилось работать с тем, что есть. По мере того как разрастались наши компоненты и их функциональность - разрастались и JMeter-тесты. Если кто не сталкивался - вся логика JMeter-тестов описана в файле с расширением .jmx. По сути это XML-файл, содержащий в себе всю логику тестов: вызовы endpoints, проверки JSON и прочая логика. И если подойти к этому вопросу без знания, то можно столкнуться с такой же проблемой, как у нас: файл разросся до 50 000+ строк и вносить/ревьюить/поддерживать его стало крайне сложно. Я нашёл способ уменьшить размер файла в 10 раз. Давайте же вместе распилим этот монолит)

Полностью обновленный курс Автоматизация тестов для REST API при помощи Postman Ольги Назиной

2026-10-05T12:48:20Z

Курс Автоматизация тестов для REST API при помощи Postman полностью перезаписан — обновлены все лекции, скорректированы домашние задания, добавлена новая тема автоматизации с помощью ИИ.

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

Несмотря на то, что ИИ поможет вам непосредственно в написании кода тестов, базовые знания «как писать такие автотесты» всё равно необходимы, они помогут:

правильно сформулировать задачу для автоматизации;
проверить, что именно ИИ написал (а он может сделать неправильно, но, чтобы это понять, нужна база, которую дает курс)

Подробнее об обновлениях можно прочитать в блоге Ольги Назиной.

Синдромы больших языковых моделей

2026-10-04T20:00:00Z

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Мы с Джеймсом Бахом разработали предварительный набор эвристик-ориентиров для «синдромов» нежелательного поведения больших языковых моделей — устойчивых паттернов проблем, которые мы наблюдали и за которыми теперь можно системно следить.

Это не взаимоисключающие категории; они могут пересекаться или взаимодействовать друг с другом.

Примечание: наши названия для этих категорий могут показаться антропоморфными. Мы на самом деле не считаем корректным приписывать человеческие свойства машинам, которые генерируют вывод стохастически. Но если поклонники ИИ утверждают, что их большие языковые модели ведут себя «прямо как люди!», наш ответ в том, что это поведение часто похоже на поведение крайне дисфункциональных, некомпетентных и ненадёжных людей.

Автогенерация тестов в IDE: как RAG + LLM превращают ручные сценарии в код

2026-09-29T20:00:00Z

Автор: Александр Поляков, Управление развития платформенных сервисов кибербезопасности, Департамент „Сервисы“ и безопасности

Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.

Где мы сейчас: ИИ уже в разработке, но почти не в автотестах

По данным недавнего опроса StackOverflow, 84% разработчиков постоянно используют ИИ‑ассистенты в своей работе. Для них это такой же привычный инструмент, как IDE или Git.

Как обычно работает подобный ИИ‑помощник в IDE:

анализирует открытые файлы;
дополнительно смотрит на соседние файлы в проекте;
учитывает локальный контекст: какие вопросы вы задавали и какой код меняли.

А вот автотестировщики часто оказываются как будто «на обочине» этой ИИ‑революции.

Эксперимент по генерации «рандомных» тестовых данных

2026-09-27T20:00:00Z

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Как можно использовать GPT в тестировании? Некоторые предлагают использовать его для генерации тестовых данных. Случайные тестовые данные могут помочь предвзятости меньше влиять на тестирование.

Можно предположить, что заставить бота генерировать случайные данные по простому промпту — это легко. Поэтому я провёл небольшой разовый эксперимент «первого барьера» 24 июля 2025 года, используя Google Gemini 2.5. Здесь отмечу случаи, соответствующие пунктам из нашего списка синдромов больших языковых моделей — шаблонов неправильного поведения, которые мы с Джеймсом Бахом наблюдали у LLM.

Сторонники ИИ часто делают чрезмерно громкие заявления о том, что GPT может делать что-то «как человек» — и нередко намекают, что GPT лучше людей, потому что быстрее и имеет мгновенный доступ к информации в интернете. Чтобы это было правдой, нужно на разумных основаниях ожидать, что GPT выполнит задачу так, как было запрошено, и учтёт возможные недопонимания по ходу дела. Это ожидание не оправдывается.

Параметризация Pytest: когда файловая коллекция становится тест-кейсами

2026-09-22T20:00:00Z

Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК InfoWatch. Мы разрабатываем DLP-систему для защиты контента и предотвращения утечек информации.

Специфика продуктов InfoWatch состоит в анализе самых разнообразных данных. Поэтому практически каждый автотест требует подхода с широким набором параметров. Для нашей команды хорошим решением стало вынести генерацию параметров pytest.mark.parametrize в отдельный компонент, который собирает данные из файловой коллекции проекта.

Существует множество способов параметризировать тестовые функции. Эта статья — пример изящной параметризации Pytest для сценариев, основанных на файловой коллекции проекта с большим количеством данных. Расскажем про наш опыт решения такой задачи.

Параметризация Pytest позволяет сделать из теста каркас, шаблон, который принимает данные для конфигураций, для assert и т.д.

За качество отвечают НЕ все

2026-09-20T20:00:00Z

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

В противовес моей идее о том, что тестирование программного обеспечения должно быть ролью, а не просто задачей, мне иногда говорят, что «настоящий Agile» этого не допускает. Почему? Потому что в Agile «качество — ответственность каждого». Это утверждение иногда подаётся так, будто это моральная истина, не подлежащая обсуждению, или же как моральное достижение, уникальное для аджайлистов, будто предыдущим поколениям разработчиков программного обеспечения никогда не приходило в голову помогать друг другу создавать хорошие вещи.

В любом случае, для меня это не имеет смысла.

Первая мысль, которая приходит в голову: «Я говорю о тестировании, а не о качестве. Почему сюда притягивается качество?» Тестировщики не обеспечивают качество. Тестировщики НЕ МОГУТ обеспечить качество. Тестировщики сейчас и никогда не «владели качеством» ни в каком смысле.

Но даже если отложить это в сторону, качество не должно считаться «ответственностью каждого». Вот почему меня беспокоит эта формулировка:

Что значит «отвечать за качество»?

2026-09-15T20:00:00Z

Автор: Пономарева Анастасия

Недавно знакомый PM попросил рассказать «Что значит отвечать за качество?» в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.

Начну немного издалека. Последние лет пять тема продуктовых команд очень популярна. Тестировщиков из «колодцев» и подчинения QA лидам и хэдам забирают в команды. Если сначала было матричное управление с функциональным руководством, то последние годы растет тренд на отказ от QA лидов с передачей функции лидам продуктовых команд.

Автоматизация нудной рутины с Goose и Playwright MCP

2026-09-13T20:00:00Z

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

И поскольку мне нравится автоматизировать свои проблемы, я решил упростить это с помощью инструментов, которые пробовал в последнее время. Покажу, как использовал Goose, Playwright MCP и их новое расширение Playwright MCP Bridge для Chrome, чтобы автоматизировать скучную задачу создания множества тикетов во внутренней системе отслеживания задач.

Зачем командам разработки и QA концепция DoR и DoD, и как не превратить ее в бюрократию

2026-09-01T20:00:00Z

На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».

Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок.

Вот несколько реальных примеров, когда описание к задаче похоже на квест:

Итак, вы «ускорили работу в десять раз»…

2026-08-30T20:00:00Z

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Существует множество способов «ускорить что-то в 10 раз».

Ехать со скоростью 300 миль в час по оживлённой городской улице.
Съесть 15 000 калорий за один приём пищи.
Завести десять собак.
Родить десять детей.
Завести сотни друзей.

У всех этих вещей есть вполне очевидные последствия и побочные эффекты. Даже простое наличие гораздо большего количества друзей заставит понимать дружбу гораздо поверхностнее, чем можно было бы себе позволить. Так почему же, когда фанаты ИИ говорят о «десятикратном» росте своей продуктивности, они никогда не упоминают о побочных эффектах?

Потому что они говорят и действуют безответственно.

Почему оркестр не играет без дирижёра, а команда — без QA и менеджера

2026-08-25T20:00:00Z

Оригинальная публикация

Это третья статья из серии. В первой я разобрал 5 техник тест-дизайна, во второй - API и Security Testing на собеседованиях. Сегодня тема другая - не техническая. Хочу поговорить про роли в команде.

Недавно я попал на концерт симфонического оркестра. Сижу в зале, 80 музыкантов на сцене, всё серьёзно - скрипки, виолончели, духовые. И тут дирижёр поднимает палочку, зал затихает, и у меня в голове:

«Подожди... а зачем он вообще нужен? Они же все профессионалы. Ноты перед глазами. Каждый знает свою партию. Ну начните играть, чего ждать-то?»

И тут меня накрыло. Я же слышу такое каждый месяц на работе:

«Зачем нам QA? Разработчики сами протестируют.»
«Зачем менеджер? Мы сами разберёмся, мы же взрослые.»

Одна и та же логика. И там, и тут. Давайте разберу, почему она не работает.

Тестирование 2FA с Playwright и Mailosaur

2026-08-23T20:00:00Z

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Когда вы пишете end-to-end тесты, аутентификация часто становится первым барьером. Невозможно протестировать реальную функциональность приложения, не пройдя сначала экран логина. Но современные методы аутентификации могут усложнять автоматизацию, используя несколько факторов, которые трудно автоматизировать (в этом и заключается смысл 2FA).

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

Так как же правильно работать с аутентификацией?

Почему индустриальный подход к качеству важнее Agile-ритуалов

2026-08-18T20:00:00Z

Артём Мотовилов
Оригинальная публикация

Предисловие

Эта статья — не критика Agile или Kanban как подходов и не попытка доказать, что в IT «всё делают неправильно». Я делюсь наблюдениями из собственного опыта работы с качеством в промышленности, энергетике, а затем — в IT‑продуктах.

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

Если у вас уже выстроена работа и всё стабильно — это отлично. Если нет — возможно, некоторые наблюдения покажутся полезными

Не разрешайте ИИ читать .env-файлы

2026-08-16T20:00:00Z

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

ИИ-ассистенты для написания кода - Claude Code, Cursor и GitHub Copilot, - становятся частью повседневного рабочего процесса. Они читают файлы, понимают кодовую базу и помогают писать код быстрее. Но есть проблема — они также могут читать .env-файлы. В последнее время в соцсетях ходит история об этом, и я сам столкнулся с этим на практике:

Методы убийства ИТ-продукта: мнение QA-инженера

2026-08-13T20:00:00Z

Автор: Воробьева Юлия

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

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

Все хотят успешный ИТ-продукт. Но создание успешного ИТ-продукта – это настоящее искусство, требующее от команды не только технических навыков и софт скилов, но и глубокого понимания потребностей пользователей. Правда убить продукт намного легче, чем сделать качественный. Далее расскажу, какие методы убийства я встречала чаще всего. В конце составила чек-лист, как спасти ИТ-продукту жизнь…

Пишем тесты с Claude Code, часть 1: первичные результаты

2026-08-11T20:00:00Z

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В недавней статье я писал о том, как использовал Claude Code для анализа кода RestAssured.Net и выполнения рефакторинга, используя написанные вручную тесты в качестве страховочной сетки. В той статье я упомянул, что не хочу, чтобы Claude трогал сами тесты, и объяснил, почему. Тем не менее, мне было любопытно самому выяснить, на что способен Claude с точки зрения написания тестов и насколько оправдано доверие, которое всё больше людей возлагают на тесты, созданные LLM.

В этой статье я поделюсь первыми шагами в этом направлении, а также своими мыслями и ходом рассуждений на этом пути. Вы увидите, как я создаю начальный набор тестов для небольшого API на Spring Boot, который я написал для использования в своих воркшопах, и как я оценивал результат. В следующей статье я покажу, как улучшил набор тестов на основе своих наблюдений, снова используя Claude Code.

Как мы научили AI разбирать упавшие автотесты и заводить баги в Трекере

2026-08-04T20:00:00Z

Автор: Олег Малышев, телеграмм-канал автора про QA,QA Auto, AI, Вайбкодинг лидер стека тестирования в компании «ТехВилл»

Всем привет, меня зовут Олег. В прошлой статье я рассказывал, как генерить автотесты из Swagger и тест-кейсов при помощи OpenAPI Generator + Cursor AI / Claude Code и как с этого всего автоматически снимать покрытие через Swagger Coverage.

В этой статье я хочу рассказать, как мы разбираем упавшие автотесты при помощи интеграции ТестОпс с Яндекс Трекером, MCP TestOps, MCP Яндекс Трекера и Cursor AI / Claude Code.

Но начнем не с AI. Сначала расскажу про сам процесс: зачем нам дефекты в TestOps, как мы руками разбираем запуск автотестов, почему без matcher-правил это быстро превращается в рутину и что именно мы потом автоматизировали.

10 советов по созданию тестов Playwright при помощи Cursor

2026-08-02T20:00:00Z

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы следите за сферой AI-ассистентов для программирования, то, скорее всего, заметили, насколько быстро всё развивается. Новые модели выходят каждый месяц, и все пытаются выявить «правильный способ» работы с этими инструментами. Я провёл последние пару месяцев, создавая тесты на Playwright с помощью Cursor, и, честно говоря, прошел через множество проб и ошибок. Некоторые вещи работали отлично, другие… не очень.

Я решил собрать всё, чему научился, в этом посте. Давайте разберёмся.

Как я сделала отчет о дифференциальном тестировании через Cursor

2026-07-29T20:00:00Z

Автор: Ольга Назина (Киселёва), автор курса Школа для начинающих тестировщиков

Я хочу рассказать, как я сделала отчет о дифференциальном тестировании (сравнение двух функций на одних данных) через ИИ. Знаю, что многие уже применяют ИИ и в хвост и в гриву, но также много тех, кто пока не умеет этого делать.

Картинка на заставку, конечно же, тоже сделала через ИИ (нанобанано)

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

Рефакторинг кода RestAssured.Net с Claude Code

2026-07-26T20:00:00Z

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

До недавнего времени я в основном избегал активного использования инструментов ИИ, за исключением ChatGPT, который помог мне составить персональный план тренировок на выносливость для велоспорта. Так было до тех пор, пока я не начал всё чаще слышать, как люди обсуждают Claude Code и насколько он хорош, особенно с новой моделью Opus 4.6. Это подтолкнуло меня проверить самому, действительно ли он полезен, и эта статья, вероятно, первая из цикла, где я буду делиться своими наблюдениями и выводами.

Конечно, можно было бы начать с создания чего-то с нуля (или «vibe coding», как сейчас модно говорить), но мне не кажется, что это хороший способ понять, что именно ИИ может дать для моей работы. В конце концов, я не занимаюсь созданием принципиально новых вещей, а помогаю людям выполнять уже существующие и важные задачи — в моём случае это тестирование и автоматизация — лучше и эффективнее.

Как мы превратили Swagger из документации в двигатель API-автотестов

2026-07-21T20:00:00Z

Мы продолжаем разговор о том, как применять ИИ в тестировании. В этой статье расскажу, как мы пишем API-автотесты с помощью OpenAPI Generator, Cursor/Claude Code и автоматически считаем покрытие по Swagger через swagger-coverage.

Раньше я уже записывал большое двухчасовое видео по Cursor, где показывал в том числе, как мы генерируем автотесты. Но с тех пор подход немного изменился: мы сильнее завязались на OpenAPI-контракт, добавили Swagger Coverage, JSON-отчёты для LLM и специальные skills для генерации недостающих тестов.

Как тестировщику участвовать в open-source проектах

2026-07-19T20:00:00Z

Автор: Има-Абаши Эффионг (Ima-Abasi Effiong)
Оригинал статьи
Перевод: Ольга Алифанова

Почему тестировщикам важно участвовать в проектах с открытым исходным кодом (OSS)

Участие в open source помогло мне приобрести множество навыков. Я научилась эффективно и уважительно общаться, что укрепило уверенность при взаимодействии с людьми. И хотя я не пишу код, я стала уверенно пользоваться GitHub и командной строкой в терминалах — навыком, который можно освоить только на практике. Open source предоставляет такую возможность.

Типы границ для классов эквивалентности

2026-07-14T20:00:00Z

Автор: Ольга Назина (Киселёва), автор курса Школа для начинающих тестировщиков

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? ...

Так можно вспомнить о проверке, про которую забыл или просто не подумал! Полезная штука.

Алексей дал нам тогда про такую типизацию границ:

Физическая — которую физически нельзя преодолеть.
Логическая — ограничение, накладываемое логикой, не программой.
Технологическая — ограничение, накладываемое используемой технологией.
Произвольная — ограничение, наложенное аналитиком или заказчиком.