На главную

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

barancev@gmail.com (Administrator) — Tue, 25 Aug 2026 20:00:00 +0000

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

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

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

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

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

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

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

barancev@gmail.com (Administrator) — Sun, 23 Aug 2026 20:00:00 +0000

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

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

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

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

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

barancev@gmail.com (Administrator) — Tue, 18 Aug 2026 20:00:00 +0000

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

Предисловие

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

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

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

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

barancev@gmail.com (Administrator) — Sun, 16 Aug 2026 20:00:00 +0000

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

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

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

barancev@gmail.com (Administrator) — Thu, 13 Aug 2026 20:00:00 +0000

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

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

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

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

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

barancev@gmail.com (Administrator) — Tue, 11 Aug 2026 20:00:00 +0000

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

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

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

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

barancev@gmail.com (Administrator) — Tue, 04 Aug 2026 20:00:00 +0000

Автор: Олег Малышев, телеграмм-канал автора про 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

barancev@gmail.com (Administrator) — Sun, 02 Aug 2026 20:00:00 +0000

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

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

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

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

barancev@gmail.com (Administrator) — Wed, 29 Jul 2026 20:00:00 +0000

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

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

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

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

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

barancev@gmail.com (Administrator) — Sun, 26 Jul 2026 20:00:00 +0000

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

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

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

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

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

barancev@gmail.com (Administrator) — Tue, 21 Jul 2026 20:00:00 +0000

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

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

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

barancev@gmail.com (Administrator) — Sun, 19 Jul 2026 20:00:00 +0000

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

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

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

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

barancev@gmail.com (Administrator) — Tue, 14 Jul 2026 20:00:00 +0000

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

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

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

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

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

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

Начинаем работу с мутационным тестированием

barancev@gmail.com (Administrator) — Sun, 12 Jul 2026 20:00:00 +0000

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

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

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

5 промтов, которые сэкономили мне часы рутинной работы тестировщика

barancev@gmail.com (Administrator) — Wed, 08 Jul 2026 20:00:00 +0000

Автор: Екатерина Гаврилова (QA Tech Lead в MD Audit)

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

Заранее находим, что тестировать: модель ревью требований

barancev@gmail.com (Administrator) — Mon, 06 Jul 2026 20:00:00 +0000

Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование программного обеспечения — это не только поиск багов, но и их предотвращение. Случалось ли вам смотреть на требование и думать: «вроде всё нормально»? А затем, спустя несколько недель, наблюдать, как код по этому требованию превращается в баг-репорт, часы доработок или недовольство стейкхолдера? Это знакомо не только вам.

Именно поэтому была создана модель ревью требований (Requirements Review Model, RRM): чтобы дать тестировщикам и командам простой и единый подход к ревью. Это помогает повышать качество ещё до того, как написана хоть одна строка кода.

Модель была создана для сертификата Software Testing Essentials от Ministry of Testing (MoT), чтобы обучать тестировщиков-новичков ревью требований. В MoT решили, что будет полезно поделиться моделью со всеми, за пределами сертификата, и поддержать тестировщиков и их команды. Это соответствует их цели — развивать индустрию любыми позитивными способами. Поэтому и написана эта статья!

Как мы написали UI-тесты для ИИ-агента внутри JetBrains IDE

barancev@gmail.com (Administrator) — Tue, 30 Jun 2026 20:00:00 +0000

Оригинальная публикация
Автор: Nikolay Nedoseykin

Как проверить, что ИИ-агент в IDE работает, если на одинаковые запросы LLM отвечает по-разному? Ответы модели недетерминированы, а интерфейс и бизнес-логика вполне детерминированы, и их нужно тестировать отдельно.

Мы делаем ИИ-агента, встраиваемого в JetBrains IDE. В статье расскажу, как мы выстроили UI-автоматизацию плагина так, чтобы тесты ловили регрессии в интерфейсе, бизнес-логике и при этом не «моргали» из-за нестабильности LLM.

Статья пригодится, если вы QA-инженер или разработчик и вам интересны:
Выстраивание UI-автоматизации на примере IDE-плагина
Тестирование приложений с ИИ-функциями
Разделение ответственности между детерминированной и недетерминированной частями системы

Мутационное тестирование: не только юнит-тесты

barancev@gmail.com (Administrator) — Sun, 28 Jun 2026 20:00:00 +0000

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

Я уже несколько раз писал о мутационном тестировании в этом блоге, и даже частенько провожу воркшоп по мутационному тестированию.

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

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

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

Психология тестировщика: почему критическое мышление — это суперсила

barancev@gmail.com (Administrator) — Tue, 23 Jun 2026 20:00:00 +0000

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

Меня зовут Галина Коньшина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы не просто охотники за дефектами (хотя баги ловить умеем), мы те, кто ежедневно выходит на поле боя против самого изощрённого противника — нашего собственного мозга.

Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъярённых пользователей.

Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберём, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход и как нестандартное мышление спасает проекты (и иногда ночной сон).

Находим баги быстрее: умный способ дебага проблем интеграции

barancev@gmail.com (Administrator) — Sun, 21 Jun 2026 20:00:00 +0000

Автор: Арун Вишванатан (Arun Vishwanathan)
Оригинал статьи
Перевод: Ольга Алифанова

Проблема: отладка билдов в быстро меняющемся мире

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

Представим, что команда обнаружила баг в недавней версии продукта. Где-то по пути что-то пошло не так. Но как понять, когда именно всё начало ломаться?

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

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

Работа с нестабильными тестами в Allure 3

barancev@gmail.com (Administrator) — Thu, 18 Jun 2026 20:00:00 +0000

Михаил Ланкин, автор статей команды ТестОпс
Оригинальная публикация

Нестабильные (flaky) тесты создают постоянные трудности для тестировщиков. Такие тесты не отражают состояния тестируемой системы и подрывают доверие к тестовому набору.

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

Исследуем, как устроена история тестов
Разберёмся, как история позволяет определять нестабильные тесты
Настроим перезапуск тестов

Эту функциональность мы рассмотрим на примере PyTest, но все те же принципы работают и с другими фреймворками.

Ломаем автопилот: как я перестал тестировать механически

barancev@gmail.com (Administrator) — Tue, 16 Jun 2026 20:00:00 +0000

Автор: Ужвал Кумар Сингх (Ujjwal Kumar Singh)
Оригинал статьи
Перевод: Ольга Алифанова

Сигнал к пробуждению

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

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

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

Тогда ко мне пришло осознание: тестирование велось мной механически. Но программное обеспечение создаётся для людей.

Как начать тестировать внутренние покупки (In-App Purchases) на Android

barancev@gmail.com (Administrator) — Sun, 14 Jun 2026 20:00:00 +0000

Автор: Павлович Евгений

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

IAP - важный элемент монетизации мобильных приложений. К примеру, частый сценарий, предложение подписки через paywall. Корректная работа этого механизма критична как для бизнеса, так и для пользовательского опыта.

Руководство по имитаторам для тестировщиков

barancev@gmail.com (Administrator) — Tue, 09 Jun 2026 20:00:00 +0000

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

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

В этой статье описывается создание тестовых сценариев, которые могут поставить систему под угрозу в продакшене. Приходилось ли вам сталкиваться с дефектом, который сложно воспроизвести в тестовой среде? Если да, то, возможно, в этой статье вы найдёте идеи, которые помогут вам в этом.

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

Археология автотестирования: SUnit, прародитель JUnit

barancev@gmail.com (Administrator) — Sun, 07 Jun 2026 20:00:00 +0000

Михаил Ланкин, автор статей команды ТестОпс
Оригинальная публикация

Меня зовут Михаил, я технический автор, работаю с инструментами тестирования в команде ТестОпс. В какой-то момент мне стало интересно — а как получила распространение мысль о том, что разработчикам тоже надо писать тесты?

У меня было смутное представление о некотором тёмном «раньше», и условно-ограниченно-просвещённом «сейчас», когда мысль о том, что тестирование не должно жить отдельно от разработки, кажется, стала нормальной.

Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки.