Представьте утро. Вы открываете ноутбук, заходите в Allure — и видите красное море.

Падает половина автотестов, часть — «временно», часть — «иногда». Почти каждый день начинается с одних и тех же починок, дебага и «вроде теперь стабильно».

Знакомо? Скорее всего да, иначе вы бы не открыли эту статью.

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

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

Каждый упавший тест — это не просто «флак» или «ошибка окружения». Это пропущенная проверка, потерянное доверие и часы бесполезных фиксов. Если таких тестов сотни, то со временем автотесты перестают быть инструментом качества — и превращаются в источник шума.

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

Автор:

Для сокращения усилий тестирования или полного прекращения тестирования какой-то области может быть множество причин.

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

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

Всем привет! Я один из лидеров стека тестирования в компании ТехВилл. Продолжаем разговор про то, как применять AI в работе так, чтобы он реально экономил время. В прошлой статье я рассказывал, как мы внедряем AI-ревью ручных тест-кейсов. А сегодня --ещё один не самый типичный кейс для Cursor: перенос тест-кейсов из Яндекс Трекера в Allure TestOps буквально одной командой.

Проблема: тест-кейсы живут в ЯТ, а должны жить в TestOps

Исторически так сложилось, что одна большая команда вела все свои тест-кейсы и чек-листы в Яндекс Трекере. А дальше случилось неизбежное: появилась потребность перевести всё в Allure TestOps, потому что:

• Это «правильно» (единая TMS),

• это «модно-молодёжно» (аналитика, связи, артефакты),

• можно нормально связать с автотестами и CI/CD,

• и главное — вся остальная компания уже живёт в TestOps, или почти вся.

Но был нюанс: старых кейсов и чек-листов накопилось много. Переносить руками — это очень много рутинной работы для QA, которую никак не хотелось заставлять их делать. Поэтому идея была такая: перенести всё быстро, без ручной копипасты, при помощи ИИ.

Автор:

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

Какое влияние эти инструменты окажут на качество работы разработчиков и создаваемых ими продуктов? Я решил исследовать этот вопрос, создав проект с использованием двух популярных ИИ-IDE для разработки — Cursor и Windsurf. Ниже – то, чему я научился, и мои наблюдения, как эти всё более популярные инструменты могут повлиять на нашу работу как инженеров по качеству.

Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.

И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте».

Автор:

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

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

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

Всем привет! Я один из лидеров стека тестирования в компании «ТехВилл» (в простонародье — Head QA). Моя цель простая: снимать рутину с QA-инженеров с помощью AI-инструментов.

В идеальном мире мы «скармливаем» модели, требования, ссылки на Figma, ветки в Git и прочие артефакты через MCP, а она помогает:

1) писать тест-кейсы по контексту,

2) а затем — генерировать автотесты на базе этих кейсов.

Про генерацию тест-кейсов из Swagger и автотестов на API по тест-кейсам через Cursor (на реальном проекте) я уже записывал большой гайд про «вайбкодинг/вайбтестинг». В этом гайде я в том числе показал свой подход вайбкодинга через вспомогательные файлы типа roadmap.md, progress.md, refactor.md, context.md и т. д. В таком подходе мне удалось завайбкодить два своих микропродукта на JS, у одного из которых более 60 000 weekly users (при том, что я ни разу не программист и JS «не знаю совсем»). 

Автор:

Введение в тестирование «shift-вниз»

Исследуя тестирование программного обеспечения, часто слышишь про два подхода: shift left (сдвиг тестирования на более ранние этапы разработки) и shift right (расширение тестирования до прода). Оба подхода полезны, как проверка дома во время строительства и после него. Однако существует ещё одно измерение, которое заслуживает внимания — сдвиг вниз, ближе к фундаменту кода.

Представьте, что вы строите дом. Разве вы начнёте украшать стены до того, как убедитесь, что фундамент прочен? Схожим образом в тестировании ПО (хоть мы зачастую сосредотачиваемся на проверке того, что видят конечные пользователи, на стенах и декоре) тщательное тестирование фундамента приносит огромную пользу. Здесь и приходит на помощь сдвиг тестирования вниз.

Всем привет! Меня зовут Катя и я QA Tech lead в MD Audit.

В прошлой статье я рассказала, какой подход помог мне сделать ИИ напарником по тестированию и поделилась формулой хорошего промпта для QA.

Но остаётся вполне логичный вопрос — А какая вообще разница? Ну попрошу я написать ИИ тесты без контекста. Что изменится в полученном результате?

Ведь где-то внутри всегда сидит ленивая версия нас и шепчет «И так сойдет».

В этой статье я покажу, почему, зная формулу «Роль → Задача → Контекст → Формат», нужно использовать именно её, как бы ни хотелось отправить ИИ что-то в духе: «Напиши тесты для логина, пожалуйста» и надеяться на лучшее.

Автор:

В этой статье я расскажу о первых впечатлениях и опыте использования инструмента low-code для автоматизации UI-тестов. Если вы незнакомы с термином «инструменты для автоматизации тестирования с низким порогом кода (low-code)», это визуальные инструменты, позволяющие пользователям автоматизировать тесты с минимальными или нулевыми знаниями программирования.

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

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

Привет, меня зовут Ирина, я тестировщик в продуктовой команде iSpring.

В этой статье я на реальном примере интеграции OpenSearch в LMS iSpring Learn расскажу, как протестировать полнотекстовый поиск, сохранив баланс между качеством и трудозатратами. Мы не только разберём базовые проверки, но и погрузимся в тестирование стемминга, релевантности, работы в распределённой системе и отказоустойчивости. Материал будет полезен тестировщикам и разработчикам, которые хотят понять, что скрывается за фразой «протестировать поиск».

Автор:

Как я начала тестировать приложения, созданные ИИ

Привет, я Рафаэла Азеведо! Уже 17 лет я работаю инженером по разработке и тестированию и специализируюсь на QA, тест-автоматизации, Web3, DevOps, мониторинге и предупреждениях.

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

Как тестировать ИИ-приложения: личный опыт

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

Когда ИИ-инструменты только появились, казалось, что это идеальное решение для эффективной разработки, способное производить качественный код с невероятной скоростью. Такие инструменты, как Lovable.dev, Replit, Manus, A0.dev и Firebase Studio, отлично подходят для быстрого прототипирования. Но код, который они создают, часто не выдерживает требований контекста, масштабируемости и интеграции с системой.

В феврале этого года я писал на Хабре про автоматизацию тестов для САПР. Мы делали систему с записью действий в JSON и воспроизведением через pyautogui. Работало. Но только для одного конкретного проекта.

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

Что изменилось? Убрал привязку к конкретному софту. Добавил умный поиск элементов вместо тупых координат. Сделал так, чтобы QA мог записать тест без единой строки кода. Прикрутил UI-ассерты, мониторинг системы, файловые проверки.

Короче, то что начиналось как решение для одной задачи, выросло в полноценный фреймворк. И оказалось полезным не только мне.

Автор:

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

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

И хотя сгенерированный код пока не является «черным ящиком», детали реализации имеют тенденцию размываться по мере роста количества строк кода.

Таким образом, ручное тестирование приложения по-прежнему кажется лучшим способом проверки результата.

Зачем вообще нужно нагрузочное тестирование

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

Автор:

Что общего у кулинарии и автоматизации тестирования?

Что общего у кулинарии и автоматизации тестирования, спросите вы? Можно провести красивые параллели между программированием и готовкой: автоматизаторы тестирования как шеф-повара, скрипты автоматизации как рецепты, фреймворки автоматизации как кастрюли и сковородки, а кулинарная книга — как эта статья! Эта статья посвящена всем тестировщикам, которые ищут новые рецепты аутентификации с использованием Playwright.

Статья предназначена для автоматизаторов тестирования, которые уже знакомы с Playwright или используют его в своей работе. Для демонстрации я буду использовать учебный магазин Book Cart, на который я наткнулась в статье Сары Дири на сайте Ministry of Testing.

Для этой «поваренной книги» я отобрала четыре рецепта аутентификации, варьирующиеся от базового до среднего уровня сложности. Эти рецепты используют сочетание методов аутентификации через UI и API, с объяснением реальных сценариев применения для каждого из них.

Пролог

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

О статье и общая проблематика

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

• это легаси проект с непрозрачной, плохо задокументированной и достаточно сложной логикой (назовем ее “серой логикой”). При этом члены команды, обладающие контекстом легаси не могут 100% гарантировать (или у вас есть сосмнения), что их воспоминания о фактическом поведении “серой логики” верны 

• на проекте присутствует БД, данные которой являются точкой применения вышеуказанной “серой логики”

• сам проект уже в production

• при этом ограничения, установленные на уровне БД не могут покрыть все необходимые ограничения, которые требует бизнес логика (само собой при наличии достаточно сложного функционала)

Согласитесь, не так, чтобы эти условия были какой-то редкостью).

Автор:

Недавно я посмотрела сериал AppleTV Silo. Шоу рассказывает о жизни 10 000 человек, обитающих в подземном бункере. Они знают, что их предки жили там сотни лет, но не знают, зачем, и почему выходить наружу опасно.

Бункер работает от генератора, который обслуживает команда Механиков. В третьем эпизоде показано, что генератор не работает правильно уже 30 лет и быстро приближается к критическому состоянию. Конечно, это сразу напомнило мне о техническом долге в программном обеспечении! В этой статье я рассмотрю восемь шагов, которые команда должна предпринять для работы с техническим долгом, с примерами из Silo и из проекта, над которым я работала несколько лет назад.

Меня зовут Катя и я ведущий инженер по тестированию в MD Audit.

Хочу поделиться как я внедрила ИИ в процессы тестирования, чтобы не тратить время на рутинные задачи и больше заниматься любимым делом (кидать мемы в рабочие чаты).

AI не заменит тестировщика. Но тестировщик, умеющий работать с AI, заменит десятерых.

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

Автор:

Таймауты — одна из ключевых частей end-to-end тестирования UI. При тестировании пользовательских интерфейсов мы часто сталкиваемся с различными формами случайности (или кажущейся случайности) в том, как элементы появляются и взаимодействуют.

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