Семь раз оттесть, один раз деплой
«Нам нужно сделать регрессионное, функциональное и интеграционное тестирование» — а ты автоматизатор и уже задумываешься о том, что попал куда‑то не туда. Или новичок решает пойти в тестировщики, смотрит вакансии и видит, что этих видов тестирования чуть ли не сотня. Как же понять, что от тебя требуют и куда идти? Попробуем разобраться.
За последние десять лет роль тестирования изменилась гораздо сильнее, чем за предыдущие двадцать. Если раньше QA воспринимался как последний рубеж перед релизом, то сегодня инженеры по качеству участвуют в проектировании требований, помогают команде выстраивать процесс поставки изменений и зачастую становятся теми, кто первым замечает, что система начинает терять устойчивость.
При этом вокруг технического долга до сих пор существует одна довольно устойчивая иллюзия. Стоит в команде заговорить о замедлении разработки, росте количества регрессий или усложнении релизов, как почти неизбежно звучит предложение: «Нужно усилить тестирование». Иногда под этим понимают автоматизацию, иногда — увеличение покрытия тестами, иногда — дополнительные проверки перед релизом. Формулировки могут отличаться, но логика остаётся одной и той же: если система становится сложнее, значит, её нужно лучше тестировать.
На первый взгляд такая логика выглядит вполне разумной: если система становится сложнее, значит, её нужно лучше тестировать. Проблема в том, что тестирование не устраняет причину этой сложности. Оно лишь позволяет раньше заметить её последствия.
Мы привыкли воспринимать технический долг как инженерскую проблему, которую можно постепенно уменьшить: провести рефакторинг, переписать несколько сервисов, улучшить покрытие тестами. Но тестирование вообще не находится в той точке жизненного цикла, где этот долг появляется. Оно сталкивается с ним значительно позже, когда архитектурные решения уже приняты, зависимости между компонентами сформированы, а сложность системы стала объективной характеристикой продукта.
В общем, базовая история с аудитом страниц — мы каждый месяц отправляли подрядчику несколько страниц на проверку. Отбирали несколько максимально разных. Если находились проблемы на одной, мы также правили и на однотипных. В месяц так проверяли 4–6 страниц. И тут, из очевидных минусов — оплата подрядчика и ожидание.
Учитывая, что по сути нужно проверять однотипные вещи, вроде title, description, H1 и, например, ошибки в консоли, то я подумал, почему бы не попробовать отдать это агенту. Да, в деталях все не так просто, но общая процедура каждый раз плюс‑минус одинаковая, а значит можно настроить сценарий.
Так появилась идея научить нашего AI‑ассистента делать аудит новых страниц самостоятельно. Не в стиле «посмотри сайт и скажи, что думаешь», а по нормальной процедуре, с фиксированным результатом. На выходе я хотел получать гугл‑таблицу с чек‑листом и PDF со скриншотами проблемных мест.
Сначала казалось, что это задача на пару дней. Берем несколько готовых навыков, подключаем технический аудит, показываем агенту шаблон отчета и просим его все аккуратно заполнить. На практике оказалось все сложнее.
Привет! Меня зовут Елена Поплоухина. Я отвечаю за развитие сообщества тестировщиков в ГК «Юзтех». В этой статье я хочу поделиться набором инструментов, которые полезны для ручного тестирования веб-приложений. Этот список собран на основе рекомендаций участников нашего сообщества.
Все ссылки и информация по инструментам актуальны на момент выхода статьи.
Примечание. В данной статье не рассматриваются возможности ИИ, инструменты для автоматизации тестирования, инструменты для тестирования мобильных приложений.
Почему отчётность, статистика и логирование в Go-автотестах превращаются в костыли — и как плагинная модель позволяет вынести инфраструктуру за пределы тестов.
Фикстуры в Playwright дают много возможностей, но за это приходится платить пониманием их жизненного цикла. В статье показываю на простых графиках, как фикстуры создаются и очищаются, как работает auto-режим, зависимости и скоупы.
Всем привет! В прошлой статье мы уже выяснили, что без README с описанием архитектуры фреймворка генерация автотестов на большом легаси-проекте превращается в бесконечный цикл ревью и правок. А сегодня хочу рассказать о том, как именно я генерировала автотесты и локаторы, сколько это заняло по времени, где модель всё равно ошибалась и стоит ли оно того.
Всех приветсвую! В данной статье я не буду пояснять какие-то сложные вещи касательно нагрузочного тестирования. Просто хочется поделится своей болью, пронесенную сквозь года в разных enterprise системах. Может я не один такой?
Итак, представьте, что вы инженер по нагрузке...
Современный ландшафт цифровых угроз демонстрирует очевидный тренд: веб-приложения и инфраструктура разработки давно превратились из второстепенной цели в ключевую мишень для атакующих. По нашим данным (за период с начала 2025 года по первый квартал 2026 года), на веб-ресурсы приходится каждая пятая успешная атака на организации в мире.
Цена компрометации веб-ресурсов выросла. Если раньше взлом сайта часто ограничивался банальным дефейсом или кражей маркетинговой базы данных, то сегодня веб-приложение — это полноценные ворота вглубь корпоративного периметра, способные остановить ключевые бизнес-процессы, парализовать цепочки поставок или полностью скомпрометировать процесс создания программного обеспечения.
В этой статье рассказываем про ключевые тренды и прогнозы, связанные с киберугрозами веб-приложений.
40-60% времени современных QA-команд тратится на диагностику сбоев в тестах. Эта проблема настолько серьёзна, что сейчас активно разрабатываются практики сокращения размеров тестовых сюит, Майкрософт рекомендует при триаже не разбирать каждое падение по отдельности, а кое-кто советует «стохастический подход» к разбору ошибок, при котором команды не тратят время на разбор каждого падения.
Если всё больше голосов говорят нам о том, что разбирать падения вручную становится слишком дорого, стоит задуматься об автоматизации. В этой статье я возьму тестовую сюиту средних размеров, попробую вначале пройти по результатам руками, а потом применю простейшее средство автоматизации: группировку результатов.
Всем привет!
Меня зовут Дмитрий Бутенко, я эксперт-разработчик банка Уралсиб.
Всё началось с рабочего созвона в первой половине февраля, на котором упомянули возможность применять модели ИИ прямо внутри инфраструктуры банка. Поначалу речь шла о работе через JetBrains AI Assistant — точечные запросы, ревью, вопросы по проекту. Вопросов, кстати, было много. Но довольно скоро случился переход на OpenCode, и это открыло принципиально другой уровень: не отдельные запросы к модели, а полноценные агенты, которые сами читают файлы, вносят изменения, итерируются по результату.
О том, какими были эти вопросы и задачи, и о том, что из этого вышло — речь пойдёт ниже.
На примере FastAPI-чата показываю, как выстроить автотесты для API с двумя транспортами: REST используется для подготовки состояния, WebSocket — для проверки событий. В статье разбираем архитектуру тестов на Python: клиенты, фикстуры, Pydantic-схемы, контрактные проверки, Allure и CI/CD.
Привет, Хабр! На связи Екатерина Серикова и Глеб Дмитриев, мы QA-инженеры в команде Авито Sales. В этой статье мы расскажем, как выстроили процесс обеспечения качества в Распродаже, где сроки нельзя сдвигать, а нагрузка на корчасть почти 2 млн RPM, а цена бага очень высока.
Это не история про «идеальный процесс». Она скорее про рабочую систему, которая помогает не сгореть команде и не терять качество, когда QA в проекте один, а разработчиков восемь.
Распродажа на Авито, где 120 млн пользователей, — это всегда высоконагруженные сценарии без права на ошибку. Поэтому в статье мы объясняем, почему важно подключать QA ещё на этапе идеи, а не тестирования. Перекладывание какой части задач на разработку только ускоряет общий процесс? Что можно скормить ИИ, а что следует выполнять самим? Для чего разделять Seller и Buyer контуры?
Здесь всё на личном опыте, по делу и понятно.
Flaky-тесты в Go — неизбежны, но наивные ретраи делают только хуже. Разбираем, почему retry — это не цикл и как правильно реализовать повторный запуск автотестов.
Всем привет! Меня зовут Алена, и я продолжаю свой цикл статей про применение ИИ в тестировании. Следующий этап в shift-left подходе — это автоматизация. А в нашем случае — генерация автотестов с помощью ИИ.
После успехов с требованиями и тестовой документацией мне казалось, что дальше всё будет ещё проще. Однако первый pull request оказался настолько «удачным», что его разбор занял почти две недели.
Меня зовут Даниил Никольский, я бэкенд-инженер команды Trisigma. В создании статьи участвовали Искандер Мирмахмадов, руководитель продуктового направления, и Александр Кузнецов, старший аналитик. В этой статье я расскажу про Switchback-эксперименты, рассмотрим как они устроены, почему для него не подходит обычный t-тест, и какая инфраструктура нужна, чтобы проводить такие эксперименты в промышленном масштабе.
Решение доступно всем желающим по ссылке, а тут можно познакомиться с подробной технической документацией.
Увы, в июне индекс активности IT-найма никаких особо хороших новостей не показывает. Число нанимающих компаний для роли Manual QA после роста в 2024 году и стабилизации в 2025 году падает уже 7-й месяц подряд. Для Automation и Senior QA продолжается постоянное небольшое снижение. Единственный рост, пусть и небольшой — у AI QA и ML Evaluation, но там рынок еще не сформирован.
Что с наймом в IT?
Есть множество способов узнать ответ на вопрос.
Субъективные – наблюдение за делами в своей компании, получение апдейтов от знакомых в других IT-компаниях или отслеживание новостей о сокращениях.
Объективные – анализ макроэкономических показателей или изучение статистики с числом вакансий на job-сайтах.
Обычно ориентируются именно на последний индикатор – на число открытых сейчас IT-вакансий. Но это относительный параметр (1000 открытых вакансий для конкретной IT-роли – это много или мало?), который не учитывает, что рост как числа IT-компаний, так и соискателей продолжается и во время кризиса (поэтому год назад 1000 открытых вакансий – это хорошо, а сейчас – плохо).
Год назад мы создали более точный индикатор активности найма.
Ежедневно AI-агенты сканируют напрямую тысячи источников: сайты компаний, ATS-системы и job-сайты. Миллионы накопленных записей о датах открытия и закрытия вакансий по каждой IT-роли в каждой из тысяч компаний позволяют видеть тренд роста или падения найма по конкретным IT-ролям.
При помощи этого индикатора можно узнать, когда (если) кризис закончится.
Не каждый сценарий, который можно покрыть автотестом, выгодно автоматизировать. Разбираю, какие тесты чаще всего не окупаются, почему длинные и хрупкие E2E быстро превращаются в источник затрат и как смотреть на автоматизацию с точки зрения бизнеса.
19 июля 2024 года в 04:09 UTC CrowdStrike выкатил обновление контентного файла для своего антивируса Falcon Sensor. За следующие 78 минут 8,5 миллиона Windows-машин по всему миру ушли в бесконечный BSOD-loop. Встали аэропорты (>5000 отменённых рейсов только в США), больницы, банки, биржи, 911-диспетчерские. Прямой ущерб корпоративных клиентов — около $5,4 млрд по оценке Parametrix; одна только Delta потеряла ~$500 млн.
Самое неприятное для нас, инженеров: баг был тривиальный. Не гонка потоков на проде под нагрузкой, не хитрый UB в компиляторе — а банальный выход за границу массива, который ловится unit-тестом за пять секунд. Ниже — как именно это произошло и почему ни один уровень защиты не сработал.