Семь раз оттесть, один раз деплой
Что происходит, если вместо массовой раздачи AI-инструментов сначала изучить, как на самом деле работают команды?
Рассказываю, как мы начали AI Enablement в крупной финансовой организации: оценили 13 команд, визуализировали их delivery pipelines, обучили около 800 человек и построили программу вокруг реальных ботлнеков, а не вокруг модных AI-инструментов.
«Playwright сейчас модный, Selenium старый, Cypress удобный». Именно так чаще всего звучит выбор фреймворка на планировании — и именно поэтому команды потом полгода разгребают последствия решения, принятого за один созвон.
Я сам проходил этот выбор не один раз, и каждый раз он оказывался сложнее, чем «взять модное». Дальше — разбор архитектуры, реальных ограничений и того, во что выбор фреймворка выливается через год, когда тестов становится не 20, а 2000.
Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.
Искусственный интеллект заметно ускорил разработку, и очевидных выгод от этого много. Оборотная сторона — выросли издержки на поддержку кода, прежде всего на работу с багами. И ложатся они в первую очередь на тестирование.
В прошлой статье мы рассказали про то, как в команде ТестОпс написали и отлаживали агента по правке багов. Но чуть ли не важнее самого агента оказалось справиться с теми изменениями, которые он принёс в рабочие процессы. А для этого нужно было научиться измерять издержки работы агента.
В этой статье мы расскажем о том, как это оказалось непросто, какие инструменты мы создали, и что ещё планируем сделать, чтобы агент лучше интегрировался в команду.
Сразу скажу что именно чтобы тем кому надо знать только итог не тратили свое время на чтение. Сайт лежит в виде виртуальной машине убунта без морды на арендованном довольно шустром хосте с 64 Озу 12 ядер 500 ССД и канал 1G. Хост крутит тоже убунта без морды.
Ну и для сайта выделено было пару ядер и пару гигабайт памяти.
Что делает сам сайт — он подключен ко всем буквально источникам новостей об ИИ как к лидерам рынка, так к вендорам и агрегаторам. Суммарно 100 источников. Он собирает все новости что найдет и те что не на английском переводит на английский. Затем чистит от дубликатов. То что осталось раскладывает на рубрики, переводит на 15 языков и выкладывает себе в ленту, выкладывает в Канал в телеге на русском только и все новости на всех языках пихает в ленту RSS.
Чтобы все это делать он пользуется несколькими ИИ подключаясь к ним по API. То есть сайт чисто текстовый. Никаких вычислений тяжелых нет. Нет рендеров и нет картинок даже.
И вдруг выясняется что сайт на этой машине буквально еле ползает. Сайту неделя. Я там единственный пользователь. И чтобы ему нормально было работать оказалось что надо до 6G ему добавить память и выделить еще два ядра. Провел я расследование и вот что оказалось
Генерация тест-кейсов — один из первых сценариев, с которых компании внедряют ИИ в тестирование. Отдаёшь модели требования или код — через несколько секунд получаешь готовый список проверок. Кажется, что рутину тест-дизайна можно закрыть промптом, а ручных тестировщиков — сократить.
Но тест-кейс — не синоним тестирования. Модель работает только с тем контекстом, что ей передали: не знает незафиксированные правила и может принять баг в коде за норму. Кейсов становится больше, а контроля качества — нет.
Разбираем, что ИИ реально снимает с QA, где создаёт лишь видимость покрытия и почему сгенерированный набор всё равно приходится проектировать и проверять человеку.
Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже разобрали shift-left: контекст, тестирование требований, генерацию тестовой документации, автотесты и оптимизацию тестовой модели. Но даже когда кейсы написаны, а автотесты готовы, остаётся задача, на которую может уходить довольно много времени — это подготовка тестовых данных для ручного тестирования.
Привет всем заглянувшим!
В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим «секретным ингредиентом». Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга.
В чем «фишка» этого подхода?
Обычно Newman выдает довольно сухие отчеты. Мой скрипт выступает в роли умной прослойки: он обрабатывает результаты тестов на статус‑коды, собирает данные и упаковывает их в наглядный Allure‑отчет. Более того, здесь добавлена функция почтовых уведомлений, чтобы контролировать состояние системы, не заходя в Jenkins.
За последнюю пару лет появилось множество приложений на основе ИИ и ИИ‑функций. Чем больше появляется таких приложений, тем любопытнее мне становится изучить их внутреннюю работу. Надеюсь, мне удастся узнать что‑то новое; по крайней мере, почерпну какие‑нибудь знания о разработке десктопных приложений.
В то же время я заметил, что каждый месяц всё быстрее исчерпываю свои кредиты Copilot. Это заставило меня выбрать его в качестве главного кандидата для моих экспериментов. Я решил подробно исследовать VS Code и Copilot.
Добрый день, я хотел бы поднять крайне недооценённую среди PHP-разработчиков тему e2e-тестов, затронуть бизнес-важность таких тестов, техническую часть и почему их никто не пишет.
Файл llms.txt предлагают класть в корень сайта с 2024 года: считается, что языковые модели прочитают его вместо того, чтобы разбирать вёрстку. Я написал для него генератор и валидатор, проделал 64 теста для отладки — и параллельно посмотрел, сколько раз ИИ-боты вообще запрашивают этот файл. Значения получились неутешительные, но валидатор всё равно оказался полезным. Ниже — устройство разбора, схема оценки и код.
Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.
Что останется делать людям, когда код будут писать машины? Практика показывает — на удивление много, без работы никто не останется. В двух статьях мы опишем реальный опыт создания внутреннего агента для исправления багов в команде ТестОпс. Расскажем, сколько такой агент экономит, как его отлаживать, и чем автоматическая правка отличается от диалога с Claude Code.
В команде ТестОпс разработка поставила себе задачу: ноль багов в бэклоге. Эта амбициозная задача запустила большую работу по исследованиям и разработке, в результате которой родился агент, способный исправлять и проверять баги. Команда стихийно назвала его «Агент Смит».
Написать первую версию агента было делом двух-трёх дней. Гораздо сложнее оказалось внести в него экспертизу — то есть отладить его шаги и настроить помощников. Для этого потребовалось и набить шишек в реальной работе, и изучить много научной литературы. Возможно, самым сложным и важным было научиться оценивать издержки от внедрения агента. Об этом мы и поговорим — но вначале разберёмся, как устроен сам «Смит».
Это продолжение статьи Материалы по хакингу на русском.
Вкратце — я собираю автоматические переводы материалов по хакингу и выкладываю их на сайте библиотеки. В этой подборке — книги для тех, кто хочет разбираться в веб-приложениях, браузерах и сетях: от bug bounty и JavaScript/XSS до
Авторизация — это сложно… Хотя казалось бы — самая частая используемая фича в мире. Очень многие процесы завязаны на авторизации и аунтентификации. Начиная от ваших любимых соц сетей и заканчивая редакторами кода.
На днях внезапно обнаружил, что с домашнего компа мой сайт https://wenda.rip стал выдавать ответ 403.
Меня зовут Алексей Тиньков, я занимаюсь тестированием производительности уже 8 лет. В первой статье цикла хочу поделиться своим опытом организации процесса нагрузочного тестирования (НТ), рассказать о том, как правильно думать о тестировании производительности и чем оно принципиально отличается от привычного функционального тестирования.
После запуска хобби-проекта я заметил, что один робот за сутки открыл календарь 88 632 раза и добрался до 7273 года. Причиной оказалась обычная ссылка “следующий месяц”, которая создавала бесконечную цепочку корректных URL.
Рассказываю, как удалось обнаружить проблему с помощью собственной аналитики, почему сервер спокойно пережил неожиданный нагрузочный тест и во что в итоге превратилась страница несуществующих дат.
В статье я разберу, как писать тесты, используя Playwright. И покажу все на собственном примере.
Когда наш продукт стал сложным, мы столкнулись с тем, что релизы стали затаскивать на прод баги. Чтобы не “тестировать на пользователях” и минимизировать человеческий фактор, мы решили автоматизировать самые частые пользовательские сценарии, используя Playwright.
Давайте перейдем к сути и начнем писать тесты на Playwright.
Я делаю NotiBox — Pusher‑совместимый сервис realtime уведомлений. Под капотом я использую Sockudo — WebSocket сервер на Rust. Прежде чем показывать реальным пользователям, я решил проверить, на сколько Sockudo на самом деле «blazingly fast».
Я ожидал, что это будет лёгкая прогулка, типичное тестирование нагрузки. Даёшь мало ресурсов серверу, запускаешь бенчмарк, видишь что он захлёбывается запросами в какой‑то момент, и фиксируешь показатели.
Идеальный сценарий — полная загрузка процессора, памяти или сети, тогда ты реально нашёл предел ресурсов. Проверяешь масштабируемость и готово.
Другой сценарий — ничего не перегружено, но новые соединения/запросы не проходят, растёт задержка ответов. Это тоже ожидаемо и понятно как чинить: смотришь на TIME WAIT сокеты, max open files, и другие «предохранители».
А что делать, если там тоже всё по нулям? Вот тут начинается настоящее приключение.
Переход с Selenium на Playwright часто заканчивается теми же флаками, долгими прогонами и ручными ожиданиями.
Разбираем семь ошибок Java‑миграции и показываем, как перестроить тесты под возможности Playwright.
Последние годы стали серьёзным испытанием для тестирования.
Нейросети существенно ускорили разработку кода: интеграция ИИ-помощников в IDE позволила за минуты решать задачи, на которые раньше нужны были часы. Качество иногда страдает, но высвобожденное время в сумме даёт положительный эффект, и в итоге количество поставляемого кода резко растёт.
В то же время пропускная способность QA принципиально не изменилась. Тестировщики тоже пользуются нейросетевыми помощниками, но им для успешной работы обычно нужно больше контекста — а значит, больше инфраструктуры.
В этой статье я хочу привлечь внимание к тому, насколько большую роль подготовка данных играет для нейросетей в QA. Конкретно, речь пойдёт о группировке падений перед анализом их причин. Я буду анализировать запуски инструментом для автоматической отладки багов — playwright-ai/auto-debug.