Автор:

Почему я написал эту статью

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

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

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

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

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

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

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

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

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

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

Автор:

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

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

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

27-28 марта в Москве прошла 3-я конференция для технических писателей — TechWriter Days 3.

Сайт конференции — https://techwriterdays.ru/.

Программа — https://techwriterdays.ru/ru/program/137253

«Я там был, мед, пиво пил» © И хочу поделиться с вами. Конференция отпочковалась от конференции аналитиков, так как тех писы уже — дело стандартное, есть отдельные должности под них.

А я сама в свое время и аналитиком на проектах была, да и с документацией работала постоянно, потому что я — бюрократ ))) Так что очень интересно было посетить эту конференцию.

Организация тут, как всегда у Владислава с Татьяной Орликовых, на высоте. Еда, чай, место для отдыха, куча всяких активностей, да и просто интересные доклады! Расскажу про те, где я была и где хотела бы.

Мой список "посмотреть потом"

1. Тихая эпидемия в IT, или Почему выгорают технические писатели — плохо себя чуствовала, не осталась на последние доклады, ушла домой. Но исходно ставила галочку сходить на доклад. Полистала слайды — интересно и жизненно, особенно про команды, где твою роль не понимают. Хотя это история про выгорание, а хотелось бы "что делать в такой команде", но тоже интересно)
2. Использование стилей MS Word без страха — тут обещают реальные кейсы из жизни, я такое люблю)
3. Внутреннее продвижение базы знаний: от справочника до культуры работы с информацией — внутреннее продвижение тоже очень актуальная тема!
4. Документация как продукт: от текстов к стратегии и управлению опытом — документация как отдельный продукт, в том числе улучшаюший онбординг. Это прям откликает мне, я сама делала онбординг))
5. Отчеты и метрики в документации: как считать влияние на бизнес — всегда интересно, кому какие метрики зашли

Какие доклады я слушала

Кому доверить ревью API — техпису или искусственному интеллекту. Камила Мазаева

Ссылка на доклад

Камила работает в Альфабанке, где много всяких разных проектов. Путь документации там такой:

Аналитик → техпис → разработка

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

Поэтому решили нудную работу делегировать ИИ. Посмотрели, что да как, и решили сделать так, чтобы ИИ не вносил правки в текст, а присылал отчет по найденным проблемам:

• уровень критичности
• где проблема?
• как написать лучше

Через тернии к звездам: как мы перевезли всю документацию Яндекса на Diplodoc. Эльвира Гильманова и Михаил Кошкин

Собрать документацию в один клик: опыт применения языковых моделей и шаблонизаторов. Никита Осокин

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

В итоге раньше переименовали какое-то название — это надо открыть ворд, ctrl + f, поиск, замена... А если разные падежи, оно ещё и не работает! Что сделали? Единый банк переменных.

Ну и не только его, конечно)) В итоге что получили? Приходит заказчик:

— Ой, а давайте всё же систему именовать не АС "Документирование", а АС "Техпис"

Раньше такие просьбы за неделю до сдачи проекта вызывали желание выйти в окно, а теперь "да легко"

Масштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex Cloud. Александр Яковлев

Ссылка на доклад

Александр рассказал про их опыт внедрения ИИ. Какие инструменты использовали:

Методом проб и ошибок пришли к таким выводам:

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

Changelog на лету: автоматическая генерация с помощью GitLab. Татьяна Кириллова

Матрица зрелости процессов работы с текстом в ИТ. Анна Терновая

Подготовка к документированию: читаем ТЗ, собираем информацию. Софья Новикова

Документация как зеркало продукта: роль технических писателей в улучшении пользовательского опыта. Эльвира Дёгтева

Трансфер знаний от уходящих сотрудников. Denis Mazin

Матрица итеративного редактирования. Анна Штольц 

Уровни качества документирования. Оксана Гаврюшенко

Декомпозиция страха: практики взаимопонимания для руководителей и команд техписателей. Мария Макеева

Книжка - говно, хотя в ней и есть неплохие моменты.

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

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

Читать не стоит.

Оценка 1/10.

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

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

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

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

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

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

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

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

Почему команды всё чаще доверяют тестирование разработчикам и где в этом подходе скрываются риски для продукта.

В QA есть одна вечная тема, которая так или иначе периодически всплывает на каждом втором проекте. Кто должен тестировать продукт? Когда-то в начале развития отрасли все казалось проще простого – разработчик пишет код, а QA проверяет. Баги находятся, фиксятся, проект выходит в люди. Классическая схема и почти уютная. Такое аккуратное «перекидывание кода через забор»: девелопер дописал фичу, кинул в тестирование, пошёл писать следующую. Но индустрия давно ускорилась и релизы стали чаще, а CI крутится круглосуточно. И в какой-то момент кто-то вбросил: а почему разработчик не может проверить свой код сам? Упс. И понеслось…

На словах вброс-вопрос звучит вполне разумно. Более того, иногда ткая схема проверки реально работает. Я работала на проектах, где разрабы активно тестировали собственные фичи, и это давало отличный результат. При этом никто не отменял, что у медали вообще-то две стороны. И вот вторая сторона вам не понравится, потому что подход «разраб сам тестирует» не всегда правильный. Если говорить более точно, то он и не «неправильный», он – нуждающийся в балансе. Проскочить в подобном случае точку невозврата ну очень легко.

Когда разработчик тестирует свой код

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

• Моментальный фидбек. Это самый очевидный бонус. Разработчик только-только написал кусок логики. Контекст еще в голове и поэтому когда он запускает тесты или быстро прогоняет сценарии, то ловит баг без напряга и сразу. Никаких задержек, очередей задач QA или сборки на тестовом стенде. Прямо здесь и сейчас.

Любая команда, которая хотя бы немного работала с CI/CD, знает, чем раньше поймали дефект, тем дешевле его исправить. Когда я только пришла в тестирование, мне повезло работать с разработчиками, которые исправно писали юнит-тесты и проверяли основные сценарии. Тогда мне казалось, что они нас «объедают», потому что до команды QA (то есть до нас) баги доходили гораздо реже. И если доходили, то обычно уже как раз те, над которыми приходилось поломать голову, интересные, а не банальные null (NPE).

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

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

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

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

А потом начинаются слепые зоны

Я очень люблю разработчиков. Серьезно. Без них у нас не было бы работы. Но есть одна фундаментальная проблема. Суть ее в том, что мы (разработчик и тестировщик) смотрим на систему совершенно по-разному. И дело тут не в компетенции, а в мышлении.

Туннельное зрение

Разработчик проверяет, работает ли его логика. QA проверяет, как её можно сломать. Это две разные задачи. Когда девелопер тестирует свой код, он почти всегда идёт по happy path. По самому правильному сценарию использования. Ну какой пользователь так делает? Тестировщик играет роль пользователя и начинает задавать неприятные вопросы…

• а что если пользователь нажмёт кнопку пять раз подряд?
• а если запрос придёт дважды?
• а если поле будет пустым?
• а если данные сломанные?

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

Контекстные переключения

Есть ещё одна проблема, которую редко обсуждают, это переключение контекста. Создатель кода пишет код. Это состояние созидания. Нужно держать в голове архитектуру, зависимости, бизнес-логику. А наша работа, то есть тестирование, требует противоположного мышления. Нужно искать уязвимости, странные сценарии, крайние случаи, ломать в общем… Можете себе представить одного человека, который постоянно прыгает между этими режимами? Там, где разработчики обязаны написать фичу, покрыть её тестами, прогнать тестирование, пройти регрессию, в итоге упадет скорость разработки. Ну и глубина тестирования останется под вопросом.

Иллюзия безопасности

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

Юнит-тесты проверили анкерные гайки на фюзеляже. Но никто не проверил, летит ли самолёт.

Когда автоматизация начинает тормозить разработку

Отдельная история, которую я наблюдала на нескольких проектах, где руководство слишком близко к сердцу восприняло популярную мантру «автоматизируйте всё, что автоматизируется». Красоту звучания оставлю оценить любителям, но сразу скажу, что в реальности автоматизация иногда все-таки начинает работать против команды. Только сначала это кому-то кажется идеальной стратегией: юнит-тесты, интеграционные проверки, UI-тесты, длинные пайплайны CI. А потом тестов становится столько, что они начинают мешать разработке. CI собирается по полчаса, часть тестов падает без причины. Разработчики тратят время не на код (они его любят больше, признаем честно), а на перезапуск пайплайнов и поиск, какой из кейсов снова «флакнул» (а это они не очень любят).

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

Где же проходит граница

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

Не война ролей. А именно баланс.

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

Зона QA. Есть вещи, которые почти всегда требуют отдельного взгляда. Тестировщик занимается тем, что разработчик просто не видит: сложные пользовательские сценарии, негативные кейсы, исследовательское тестирование, UX-проблемы, интеграции между системами, нестандартные сценарии поведения. QA смотрит на продукт без привязки к тому, как он был реализован. И в этом огромная ценность.

В итоге

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

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

Автор:

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

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

Первый опыт, второй, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 

16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32

Что это за техника

Вы собираетесь с друзьями в группу и ставите себе цели на 12 недель (3 месяца). Это могут быть как рабочие, так и личные задачи. Такие, которые вы вроде как хотите сделать, но вечно откладываете, так как «некогда, потом, щас, вот только мелочевку разгребу и тот пожарчик потушу».

Настало время заняться тем, чем действительно хочется!  Отталкиваясь от глобальных целей, составляете план на неделю. И раз в неделю встречаетесь с группой и обсуждаете, сколько успели, сколько нет. Какой план на следующую неделю. Я, правда, уже давно не встречаюсь, а просто веду файлик "что сделано", откуда потом и просматриваю всё, что успела за цикл.

Результаты кратко

Основной план:

???? книга по чату — закончить 

???? книга по чату — вычитать

???? книга по тайм-менеджменту — написать 1 главу

????переписать автоматизацию в постмане полностью

???? 1 статья на Хабр

С книгой новой чуток продолбалась, а вот курс отложила не по своей вине. Там огромная боль, но об этом чуть ниже... 

На самом деле, с учетом двух госпитализаций плановых очень неплохой результат, там же пока врачей обойти, справки собрать... А ещё почти месяц болели по кругу... В общем, «время есть? Делай!», иначе потом придет какой-нибудь песец ????????

Кратко что сделала:

1. Книга 4, SQL: 
1. прошли верстку!
2. книга уже вышла в продажу!
2. Книга 5, ChatGPT:
1. закончила книгу! 
2. вычитала её, от души наредактировав
3. принимаю картинки, пока ещё не все готовы
3. Курс по автоматизации в Postman:
1. Записала ещё пару уроков, обработала
2. Поставила на паузу, потому что в Postman обновилось всё, и сниппеты, и документация ＼(〇_ｏ)／
4. Статьи на Хабр — 1 статья 
5. Пополнила свой youtube-канал — 1 видео 
6. Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто
7. Новый год! 
8. Новогодняя фотосессия )))
9. Две госпитализации у младшей дочери (плановые, гемангиома)
10. Записалась в зал, начала заниматься ????

Результаты подробнее

Книга 5: ChatGPT

1. Вводная, что это такое и всякое общее (мотивация и тд)
2. Техники, которые мне НЕ зашли (но могут зайти другим)
3. Техники, которые мне зашли и уже 9 лет со мной!

Примерные главы:

Я прошлась по всем своим постам из цикла 12 недель и насобирала «мяса», раскидав текст по разным главам. Теперь осталось его переосмыслить, дополнить, и будет красота!

Ютуб / ВК

Всякое разное, не рабочее

Проверка планов, поставленных в прошлый раз

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

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

Автор:

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

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

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

В практике аутсорс-разработки мы часто видим одну и ту же драму. На этапе стейджинга все выглядит очень неплохо, в отчетах QA прописано, что система стабильна при 10k RPS, графики ровные, latency в пределах нормы, отчёт зелёный. Но стоит маркетингу запустить кампанию или крупному энтерпрайз-клиенту провести онбординг сотрудников, как сервис превращается в тыкву. А полночь (т.е. ожидаемая серьезная нагрузка) даже еще не наступила.

 Мы уже говорили о том, как все происходит и самое дурацкое в этой ситуации – ложное чувство безопасности. Если ваши нагрузочные тесты пройдены, а система всё равно легла на 30% от заявленной мощности, значит, вы тестировали сферического коня в вакууме (погуглите, хороший анекдот).

Давайте посмотрим, обо что спотыкается SaaS и чего это он все-таки падает, раз отчеты так хороши.

Стерильные сценарии vs потока сознания юзера

Типичный нагрузочный скрипт (на JMeter или k6) как дисциплинированный Безупречный под рукой Дейнерис. Он делает паузы (think time), идет по «золотому пути» и закрывает сессию. Но это не Игра престолов, а вполне реальная жизнь, поэтому тут всё иначе:

• Эффект паники (Retry Storm). Если API замедлился до 3 секунд, пользователь уже нервничает и не ждет. Он нажимает «Обновить» или кликает на кнопку «Купить» пять раз подряд. Вместо одного тяжелого запроса база получает пять одинаковых. А через пару секунд ещё пять, потому что юзер решил, что кнопка не нажалась. В результате нагрузку создаёт не количество людей, а их нетерпеливость, паника.
• Вкладки-убийцы. Мы, как современные пользователи SaaS, держим иногда открытыми 10-15 вкладок сервиса. Каждая из них может слать фоновые запросы (polling, уведомления, обновление статусов). В итоге 1000 живых людей за ПК генерируют нагрузку как 15 000 виртуальных пользователей.

Новый «черный лебедь», или нашествие AI-агентов

В 2026 году главной угрозой стали не люди, а AI-агенты и RAG-системы ваших же клиентов. Одна моя знакомая любит фразу «насколько это плохо, что аж хорошо». Так вот в отношении ИИ-агентов вполне можно ее использовать наоборот. Они настолько хороши, что аж плохо. Не согласны?

Если раньше нагрузка была человекочитаемой, то теперь клиент может подключить к вашему API своего умного помощника ИИ, который начнет выкачивать данные для обучения или индексации…

Но! Бот не делает пауз. Вот вам проблема. Он обходит кэш, подставляя уникальные параметры в каждый запрос. И в результате ваш кэш фактически вымывается за секунды, и 90% трафика летит напрямую в БД. Без жесткого Rate Limiting на уровне API Gateway такие агенты выкашивают SaaS быстрее любого DDoS (о безопасности ваших проектов писали тут).

Совет от ЛК. Проверьте свои User-Agent логи. Если там внезапно вырос трафик от python-requests или специфических AI-библиотек, это оно, нашествие агентов. Но будьте осторожны, так как продвинутые агенты умеют притворяться обычным Chrome, и тогда их приходится ловить уже по аномальной скорости и машинной последовательности запросов.

Архитектурные «бутылочные горлышки»

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

База данных все равно что проклятие Multi-tenancy

В SaaS данные всех клиентов часто лежат в одной базе данных. Если один крупный клиент запустит свой тяжелый годовой отчет, что мы увидим? СУБД начнет читать миллионы строк, пересчитывать агрегаты, строить временные таблицы и тут умирают все остальные клиенты, даже те, кто просто зашел почитать профиль. Тяжелый запрос захватывает ресурсы или ставит эксклюзивные блокировки на таблицы, через которые пытаются пройти другие пользователи. Просто потому, что данные всех клиентов лежат в одной БД, начинается тормозуха.

Такие проблемы, как мы писали в прошлый раз, решаются изоляцией ресурсов (Resource Quotas) на уровне БД или шардированием по клиентам.

Точка насыщения и Scaling Lag

Облачный автоскейлинг (AWS, Yandex Cloud) смахивает на попытку догнать уходящий поезд. Это не волшебная палочка, а инерционная система. Новым мощностям нужно время на прогрев, а вашим пользователям нужен результат здесь и сейчас.

• Scaling Lag. Новым подам в Kubernetes нужно max 2 минуты, чтобы подняться и «прогреться». Если всплеск нагрузки произошел за 20 секунд, подмога просто не успеет.
• Connection Pool. Допустим, вы добавили 10 новых серверов приложений, но забыли, что база данных принимает только 500 одновременных соединений. Новые серверы просто выбьют старые и система ляжет окончательно.

Почему тесты не показывают деградацию?

Большинство команд совершает три критические ошибки при анализе отчетов:

1. Ложь среднего арифметического. Среднее время ответа почти ничего не говорит о реальном опыте пользователей. Если оно 200 мс, это звучит отлично. Но смотреть нужно на P99¹. Если он 15 секунд, значит каждый сотый пользователь просто сидит и смотрит на спиннер.
2. Отсутствие Soak-тестирования, то есть тестирования выносливости. Короткий тест на 15 минут не покажет утечки памяти или фрагментацию индексов. Настоящие проблемы в SaaS выплывают на поверхность через 4-6 часов стабильно высокой нагрузки.
3. Синтетические данные. Тестировать на базе в 1 ГБ, когда в проде 1 ТБ, бессмысленно. На больших объемах планировщик SQL-запросов будет вести себя иначе, а Join-ы, которые летали в тесте, превратятся в бесконечное чтение с диска.

Как ЛК защищает бизнес-метрики клиентов

Мы в аутсорс-разработке смотрим на нагрузку глазами бизнеса. Падение сервиса не выглядит чисто как какая-то 500-я ошибка (Internal Server Error). Бизнес остро чувствует ее, это потерянный LTV и сожженный рекламный бюджет.

Стек musthave-практик для 2026 года:

• Chaos Engineering. Мы принудительно «убиваем» микросервисы в нагрузочном контуре, чтобы проверить, работает ли Circuit Breaker (предохранитель)², который не даст всей системе упасть за одним звеном.
• Graceful Degradation. Проектируем систему так, чтобы при пиках она отключала неважную, но приятную глазу пользователя, мишуру (аватарки, ленту рекомендаций), при этом сохраняла критический путь (оплату и запись данных).
• Observability 2.0. Мониторим не CPU/RAM, а бизнес-транзакции и длину очередей. Мы считываем симптомы усталости системы за 5 минут до того, как она упадет в глубокий обморок. Это дает нам время на маневр, а вашему бизнесу непрерывность.

Что в итоге?

В конечном счете, пользователю все равно, сколько у вас микросервисов и какой стек. Ему нужно, чтобы кнопка сработала здесь и сейчас. Наша задача как раз сделать так, чтобы красивые отчеты о тестировании не превращались в тыкву при первом серьезном вызове. SaaS в 2026 году должен быть адаптивным: уметь масштабироваться под AI-ботов, изолировать «шумных соседей» и сохранять лицо даже в условиях частичного отказа. 

SaaS падает не от нехватки мощностей, как мы уже сказали. Можно бесконечно масштабировать API, но упереться в лимиты облачного провайдера или блокировки БД. Нагрузочное тестирование для нас – это своего рода поиск того самого кирпичика, который вылетит первым и лучше найти его в тестовом контуре, чем объясняться с клиентами во время сбоя в прод.

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

Всем привет! Я один из лидеров стека тестирования в компании «ТехВилл» (в простонародье — 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 «не знаю совсем»). 

SaaS-продукты, да и не только они, конечно, редко падают красиво. Они делают это медленно и нервно. Вот у вас всё работает, а потом… Сначала интерфейс начинает «думать» пару секунд. Затем отчеты в ERP считаются почти минуту. Дальше в пиковые часы API как будто заболевает Альцгеймером. Под конец квартала база начинает ловить блокировки. При этом если смотреть формально – ничего не сломано. Прод жив, но не покидает ощущение, что вся система будто на пределе.

Опираясь на наш опыт аудита SaaS-систем (от ERP-гигантов до HR-tech стартапов), мы пришли к выводу, что в 70-80% случаев проблемы масштабирования растут не из нехватки «железа», а из ошибок в моделировании нагрузки. Количество пользователей в системе прекрасно известно всей команде, но мало кто понимает, какая нагрузка на самом деле живет внутри продукта.

Ничего не ломается, но всё тормозит

Техническая точка невозврата случается, когда на радость бизнесу продажи растут, но есть нюанс – новые клиенты приходят быстрее, а архитектура за такими темпами не успевает. Проект обрастает новыми модулями, интеграциями, аналитикой. И наверх идут отчеты о том, как все хорошо выглядит. А вот внутри система начинает вести себя странно, потому что никто до конца не понимает Point of Saturation¹.

У этой ситуации две стороны — бизнес и техничка.

1.Бизнес-уровень. В системах вроде ERP, BI или КЭДО продукт работает с крупными компаниями или госзаказчиками. SLA под ФЗ-44/223 далеко не формальность.

Когда мы говорим о SLA или нагрузочном тестировании для клиентов из этой сферы, нужно понимать:

• По 44-ФЗ если ваш софт упадет и нарушит сроки, прописанные в госконтракте, компанию-поставщика могут внести в РНП (Реестр недобросовестных поставщиков). Это фактически «волчий билет» на рынке госзакупок на 2 года.
• По 223-ФЗ видим, что требования к отказоустойчивости могут быть прописаны в договоре очень детально, и штрафные санкции там часто намного выше рыночных, так как крупные корпорации оценивают свои убытки от простоя в миллионы рублей в минуту.

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

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

Из чего на самом деле состоит нагрузка SaaS

В инженерной культуре топовых SaaS-сервисов нагрузку никогда не меряют «в человеках», простите. Давайте воспользуемся понятием Resource-Heavy Operation (RHO). Нагрузка смахивает на многослойный пирог, в котором есть такие слои, как:

1. Пользовательская активность. И это не общее количество аккаунтов, а одновременные сессии и частота операций. Нужно учитывать RPS².
2. Тяжелая бизнес-логика. Формирование отчетов, расчет зарплаты, агрегации. Один фоновый экспорт данных в ERP может потреблять в 45 раз больше I/O³ ресурсов БД, чем стандартный API-вызов на чтение профиля.
3. Интеграции. Взаимодействие с 1С, СМЭВ или партнерскими системами. Они могут создавать до 50% всех задержек.
4. Слой данных. Большая база = большая боль. Если продукт старше пары лет, БД стала узким местом, поверьте. Тяжелые JOIN⁴ и блокировки определяют предел масштабирования.
5. Фоновые процессы. Очереди задач, ETL⁵ и индексация… При росте нагрузки они начинают конкурировать с пользователями за CPU и память.

Как рассчитать нагрузку: от «юзеров» к стоимости сценария

Вместо упрощенных метрик мы используем модель, учитывающую вес каждой операции:

N = (U х C) х S х P 

Где

• U – общее количество пользователей.
• C – это коэффициент одновременной активности.
• S (Scenario Cost) – так называемая «стоимость» сценария. Вес конкретной бизнес-операции в ресурсах системы. Это по итогу самое главное и есть.
• P – пик-фактор (например, конец отчетного периода).

Смысл формулы простой. Система должна выдерживать не просто пользователей, а пиковую комбинацию сценариев. Например, в ERP 3000 пользователей, 800 одновременных сессий, 1000 отчетов в час. Если конец месяца увеличивает активность в пять раз, архитектура должна выдержать именно этот момент. Можете посчитать сами

Средняя нагрузка здесь вообще ничего не говорит.

Рабочий кейс, как пример. Команда ERP готовилась к 5 000 юзеров. Но аудит показал, что один процесс «Закрытие отчетного периода» генерирует нагрузку, эквивалентную 15 000 RPS. Система была готова к людям, но не была готова к бухгалтерии.

Архитектурная ловушка SaaS, если одна база для всего

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

Например, пользователь открывает карточку клиента. Это быстрый транзакционный запрос. Одновременно с ним другой пользователь запускает сложный управленческий отчет, который может сканировать миллионы строк, выполнять тяжелые JOIN, строить агрегации… В результате тяжелые аналитические запросы начинают занимать CPU, блокировать таблицы, забивать I/O, и вся система начинает вести себя соответственно – интерфейс «подвисает», API отвечает медленнее, в очередях задач растет задержка. При этом формально база работает.

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

Решается эта проблема обычно тремя вариантами:

Можно разделить OLTP и аналитику. Операционные запросы остаются в основной базе.  Аналитика уходит в отдельный контур.

Или использовать асинхронные расчеты, когда тяжелые операции переносятся в фоновые задачи.

Либо внедрить предварительную агрегацию, когда часть расчетов выполняется заранее. Это уменьшает нагрузку в моменты, когда пользователи открывают отчеты или дашборды.

Почему это нельзя игнорировать при моделировании нагрузки? Если аналитика и транзакционные операции живут в одном контуре, система может выдерживать обычную пользовательскую активность.Но в моменты, когда запускаются тяжелые отчеты, нагрузка меняется резко. И вот в этот момент лезут симптомы, которые многие команды списывают на «временные тормоза»: деградация/Альцгеймер API, зависание интерфейса, рост времени SQL-запросов. Поэтому при расчете нагрузки SaaS важно учитывать не только пользователей, но и архитектуру обработки данных. Иногда именно она определяет реальный предел системы.

Отраслевые профили нагрузки

• ERP и учетные системы.  Главный риск для них это БД. Основная нагрузка идет от расчетов и работы с огромными таблицами.
• BI-системы потребляют CPU и память. Нагрузка формируется аналитическими выборками и рендерингом дашбордов.
• У различных CRM более равномерная нагрузка, но с резкими скачками во время импорта данных или массовых рассылок.
• HR-tech и КЭДО (кадровый электронный документооборот). Самые агрессивные пики приходятся на массовое подписание документов, или когда кадровые кампании поднимают нагрузку в 5-8 раз за считанные минуты.

Одна из распространенных ошибок при расчете нагрузки использовать одинаковую модель для всех типов продуктов. Но профиль нагрузки у ERP, CRM или HR-систем отличается радикально.

Что здесь важно, давайте разберем подробнее. В ERP нагрузку чаще всего создают несколько тяжелых операций, а не тысячи пользователей. В CRM, наоборот, каждая операция легкая, но их очень много. В HR-системах и КЭДО большую роль играют пакетные сценарии. А в EdTech система может спокойно работать весь день, но «взорваться» во время массового тестирования или экзамена.

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

В большинстве SaaS-систем 10-15% сценариев создают до 80% нагрузки. При моделировании важно сначала найти самые тяжелые операции, а уже потом считать пользователей.

Миграция и Performance Regression Gap

Сейчас многие команды проходят через переезд с AWS/Azure на Yandex Cloud, Selectel или миграцию на Astra Linux и Postgres Pro. 

Критическая точка. Мы регулярно фиксируем так называемую Performance Regression Gap. Это ситуация, когда после миграции те же самые сценарии начинают нагружать систему на 30-40% сильнее. Среди причин, конечно, особенности работы ядра ОС, драйверов или сетевых задержек в новой инфраструктуре. К тому же без предварительного синтетического моделирования этот разрыв «вымывает» запас прочности архитектуры еще до того, как в систему зайдет первый клиент.

Что дает аудит, или оbservability-first testing

Для нас нагрузочное тестирование не остается разовым отчетом в PDF. Фактически это внедрение o bservability-инструментария⁶. «Положить» систему могут многие, но мы параллельно еще и настраиваем APM (Application Performance Monitoring), чтобы команда видела деградацию API в реальном времени.

Частые находки:

• Синхронные операции там, где жизненно необходимы очереди.
• Архитектурные ограничения, которые поперек горла горизонтальному масштабированию.
• «Мусорные» запросы к базе, а ведь их можно оптимизировать одним индексом.

Когда пора звать внешнюю экспертизу?

Мы уже не раз говорили о том, что аудит нагрузки часто больше как страховка, нежели лечение. Если вы заметили, что:

• продукт начал замедляться и интерфейс «фризит» в пики,
• планируется резкий рост + выход на крупных B2B-заказчиков с жестким SLA,
• есть миграция инфраструктуры + нужно подтвердить работоспособность на новом стеке,

Мы заходим в проект за 48 часов, обеспечиваем полный цикл от расчета мощностей до настройки авто-метрик и обучения вашей команды. Единственные на рынке, мы предлагаем не просто «руки», а создание вашей внутренней корпоративной школы QA через наш УЦ, чтобы вы перестали зависеть от дорогого найма. 

Key Takeaways

1. Не считайте людей, считайте операции. Один «тяжелый» отчет может стоить как тысяча кликов.
2. Моделируйте пики, а не среднее. Средняя температура по больнице не поможет, когда в систему одновременно зайдут все сотрудники компании-клиента.
3. Закладывайте риск миграции. Переезд на Astra Linux или Postgres Pro требует специфических регрессов.
4. Внедряйте Observability. Вы должны видеть точку насыщения системы за месяцы до того, как она станет критической.

Ваш SaaS готов к следующему этапу роста?

Запишитесь на аудит нагрузки и получите расчет модели вашей системы и план масштабирования.

Автор:

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

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

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

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

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

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

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

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

Автор:

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

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

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

Зашла в эльбу, прокликала задачу до "выставить счет в банке", и тут она мне выдает ошибку — не настроена связь с банком о_О

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

Восстановила соединение с банком и тут же написала в поддержку. Мой исходный вопрос был предельно простой, как быстро Эльба всё подсосет:

- У меня была разорвана связь с банком, сейчас восстановила — Интеграция c Альфа-Банком настроена с 18.02.2025. Получается, задача "заплатить страховые взносы" неактуальна, если данные не получала система с 18 февраля? Как быстро она подсосет все, что нужно?

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

Переписка с поддержкой

Сначала в чате с поддержкой тебе отвечает бот. Он увидел ключевые слова про страховые взносы и накатал огромное сообщение на целый лист (чат с техподдержкой это такой узкий, выплывает справа снизу на экране, вот его лист):

- Обязанность по уплате страховых взносов ИП за себя определена ФЗ... (бла-бла-бла, о том, почему я вообще должна платить взносы)

- Это вообще не про мой вопрос

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

- Почему эльба не написала, что связь с банком разорвана? по сути это же вы просто согласие затребовали подписать, почему не было письма тогда? Ну и как теперь исправить некорректные данные в эльбе? раз она про часть данных не знала

То есть жду ответ, что "подождите пару часов и все подсосется" или "сделайте то и то". Ок. Приходит человек:

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

Либо можно скачать выписку банка в формате 1С с расширением *.txt, тогда операции загрузятся сразу.

Чтобы загрузить выписку: ...

Если платёж уже заведен в Эльбу вручную, то он не задвоится, если будут совпадать:

1. номер платёжного поручения;

2. сумма;

3. дата;

4. ИНН-КПП контрагента.

В ином случае в сервисе будет создан дубль операции.

Если? Что значит "если"??

- Откуда я знаю, были загружены операции ранее 18.02 или нет? У меня была настроена интеграция, сообщения об ошибке в ней я не получала, и как я должна понять, с каких пор ошибка и что она затронула? все платежи с начала года выверять? Сейчас на главной блок "деньги" вообще не верный

- Если платёж уже заведен в Эльбу, то он не задвоится, если будут совпадать:

1. номер платёжного поручения;

2. сумма;

3. дата;

4. ИНН-КПП контрагента.

В ином случае в сервисе будет создан дубль операции. Можете просто загрузить операции в раздел Деньги вручную. Если есть лишние операции, их потребуется удалить вручную.

***

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

А ещё очень умилило вот это вот "просто загрузите деньги вручную". Каждую операцию, да. Вручную...

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

Но техподдержка лишь лапки подняла:

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

В общем, сами сидите и выверяйте, класс!

Самое смешное, что, когда я выверила — сидела и просматривала глазками 2 экрана, деньги в эльбе и в альфа-банке, то с текущей даты и назад до 28 января всё ок. Это я сегодня уже выверяла, а связь с банком восстановила вчера.

То есть по сути ответ на мой исходный вопрос мог быть коротким:

- Сбой произошел в январе из-за техработ в банке. Так как вы указали при восстановлении связи 18 февраля 2025 года, Эльба должна была все подтянуть. Проверьте на всякие случай поступления за последние пару дней и такого-то января, чтобы убедиться, что всё хорошо.

И ВСЁ! Но нет, надо было закидывать меня копипастой, писать какую-то фигню не про мои вопросы, а ещё рассказывать, как я могу сама локализовывать баг вместо них.

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

Пришел парень, который знал систему, наконец-то! Он и пояснил всё:

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

"Интеграция настроена с 18.02.2025", это значит что все данные с этой даты подтянутся в Эльбу. Эта дата указывается при настройке интеграции с банком, но только в случае если она не была настроена, или была разорвана по кнопке "Разорвать связь с банком". Если интеграция была нарушена, и восстановлена по кнопке "Авторизоваться в банке" то дата не изменится, и за период когда интеграция была нарушена операции подтянутся.

(Я ведь спрашивала их, что значит эта дата. Я нажала "восстановить связь — ок", почти не глядя, так как уже делала это раньше. Как в винде, знаете, далее-далее-далее-ок.

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

Пока я дождалась этого консультанта, я уже разорвала связь и снова восстановила, как меня попросила поддержка. И вот теперь я заметила эту дату. Почему только техподдержка не подсветила мне это "вот на этом экране вы выбрали дату (скрин), она и отображается в сообщении"?)

В вашем случае, если не помните как именно восстанавливали интеграцию, и нет возможности отследить хватает/не хватает операций(например, их было очень много и проверить все затруднительно) то можно подгрузить выписку из банка в формате 1С за весь 2025 и 2026 год в Эльбу. Если операция есть в Эльбе, то как правило она не задублируется, так как выписка из банка и выписка по интеграции идентичны.

***

В общем, всё Эльба сделала сама, можно было бы остановить переписку ещё на первом сообщении, при нормальном и грамотном ответе...

Кратко

Представьте, что вы подготовили идеальные сценарии, отобрали методики, нашли респондентов… И тут заказчик говорит: «Тестировать будем не приложение, а вот этот макет в Figma». Знакомая ситуация? Если нет, то считайте, что вам повезло. Если да, ознакомьтесь с материалом — уверен, что он будет полезен и поможет не наломать дров.

Меня зовут Дунько Харитон и я специалист по тестированию в “Лаборатории качества”. В этой статье на своём реальном кейсе покажу, почему юзабилити-тестирование (далее - ЮТ) является не просто «посмотреть, удобно ли», а полноценным расследованием с элементами психологии, аналитики и жесткого менеджмента. И что делать, если реальность вносит коррективы в ваши планы. Также расскажу почему общение с респондентами целевой аудитории важнее, чем технический аудит. 

Юзабилити — это про деньги

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

Чем же ЮТ отличается от классического тестирования приложения? Если функциональное тестирование отвечает на вопрос: «Работает ли это так, как написано в ТЗ?», то юзабилити ищет ответ на другой: «Понятно ли это реальному, живому человеку и готов ли он за это платить?».

ЮТ специфический вид работ, который требует от тестировщика не только знания техник (вроде эвристик Нильсена или GOMS-анализа), но и насмотренности, понимания психологии и, что важнее всего, умения правильно интерпретировать поведение пользователя. 

Плохой юзабилити интерфейс может привести к значительным финансовым потерям и оттоку клиентов. Вот например, есть такой показательный случай, когда компания столкнулась с негативными последствиями из-за игнорирования пользовательского опыта. В 2020 году сотрудники Citibank (один из крупнейших международных банков, дочерняя структура финансовой корпорации Citigroup) из-за запутанного интерфейса системы Flexcube случайно перевели кредиторам около 900 миллионов долларов вместо запланированных 7,8 миллиона долларов. Суд постановил, что банк несёт ответственность за ошибки, вызванные неудобным интерфейсом. 

Да и в целом исследования показывают, что 50% клиентов отказываются от использования нового продукта, если не разберутся с ними за первые 10 минут. 

Кейс: платформа ITE Connect и её новый раздел

В компанию обратился заказчик — крупный организатор выставок в Российской Федерации с собственной платформой ITE Connect. 

Передо мной была поставлена простая, но заковыристая задача —  провести ЮТ нового раздела их приложения. Функциональность раздела включала в себя систему рекомендаций, которая на основе анализа сканированных QR-кодов (со стендов, бейджей) предлагала участникам мероприятия наиболее релевантные деловые контакты.

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

Как уже опытный QA-инженер, я сразу разделил проект на три этапа:

1. Анализ бизнес-метрик, которые должны вырасти после внедрения доработок.

2. Техническая проверка по гайдлайнам и эвристикам.

3. «Полевой» этап — интервью с реальной целевой аудиторией.

Подготовка

К выбору методик я подошел скрупулезно. Из всего арсенала, применяемого в ЮТ, выбрал только то, что реально сработает в условиях специфики задачи:

• Think-aloud («Подумай вслух») — чтобы увидеть логику пользователя.
• Time to Done — замерить скорость выполнения ключевых сценариев.
• Cognitive walkthrough — оценить, насколько просто освоить раздел, когда пользователь видит и взаимодействует с ним впервые.
• Эвристики Нильсена, гайдлайны iOS/Android/Google — база для анализа интерфейса.

Инструменты — стандартный джентльменский набор: Google Meet, OBS для записи, Google-таблицы и Figma.

Борьба за качество и здравый смысл

И тут случилось то, что заставило меня пересобрать процесс. Заказчик сообщил: «Работать будем не с живым приложением, а с кликабельным прототипом».

Для тех, кто не в курсе отмечу: тестировать юзабилити на прототипе — все равно что выбирать машину по картинке на сайте. Это жестко ограничивает сценарии, не позволяет пользователю ошибаться и не дает увидеть реальное поведение системы в ответ на нестандартные действия. И, конечно же, не позволяло провести качественное и объективное ЮТ.

Пришлось объяснить заказчику все риски таких тестов. И здравый смысл восторжествовал — он доработал прототип до состояния, при котором ЮТ, хоть и в усеченном виде, но можно было проводить (добавились схемы переходов и логика состояний). Лишь после этого я смог приступить к проверке по эвристикам Нильсена и гайдлайнам.

К слову, о Нильсене. Из его 10 принципов часть (например, «помощь в исправлении ошибок») к разделу просто не могла применяться. В итоге подготовил чек-листы соответствия как эвристикам, так и гайдлайнам iOS/Android/Google. 

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

Целевая аудитория

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

А вот поиск целевой аудитории тот еще квест и обусловлен рядом факторов (специфика приложения, опыт его использования, социально-демографические показатели и т.п.). Обычно целевую аудиторию подбирает исполнитель ЮТ. Но на этом проекте респондентов выбирали не мы. 

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

Моя же подготовка включала следующее:

1. Сценарии. Создал 26 ключевых вопросов-сценариев, которые покрывали все возможные действия в прототипе.

2. Пилот. Прогнал сценарии на себе и коллегах из моей компании. Это помогло отсечь лишнее и замерить тайминг.

3. Анкеты. Их создал три типа:

• «По словам» — пользователю после прохождения сценариев необходимо было выбрать пять слов, описывающих ощущения от интерфейса.
• «По удобству» — классическая оценка утверждений.
• «Субъективная» — только ответы «да» или «нет». Причём любой «нет» — красный флаг для приложения.

4. Памятка респонденту. Чтобы к началу интервью у всех всё работало, и технические проблемы не смазали картину.

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

В итоге, процесс работы с целевой аудиторией был отлажен как часы: вступительная речь → проверка связи и записи экрана → предупреждение о записи → ссылка на прототип → 26 сценариев с комментариями «вслух» → три анкеты → благодарность и стоп записи.

Финальный аккорд (которого пока так и не случилось)

Я был готов (все сценарии выверены, анкеты сверстаны, записывающая аппаратура настроена) и горел желанием наконец-то поговорить с живыми людьми. И тут…

Заказчик сообщает, что не смог найти респондентов. Никто из целевой аудитории не захотел. Планы изменились и проект ставят на паузу. «Дорогой дневник, мне не передать ту боль…» — это был моя первая реакция. Весь объем подготовительной работы, чек-листы по эвристикам, наработки по анкетам — всё легло до времени на полку.

Итоги или to be continued?

Чему нас научил этот кейс?

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

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

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

Наше сотрудничество с заказчиком по данному проекту приостановлено, но не завершено.

Я искренне надеюсь, что через время проект оживет и я всё-таки проведу те интервью, к которым так тщательно готовился. А пока я доволен проделанной работой. Это был бесценный опыт, который еще раз подтвердил: в тестировании в целом и в ЮТ в частности не бывает нерелевантного опыта. Всё, что вы знаете о людях, бизнесе и даже маркетинге с продажами, однажды сыграет вам в плюс.

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

p.s. Я не стал специально углубляться в этой статье в дебри каждой из методик данного вида тестирования. Для этого потребуется еще не одна статья. Если хотите деталей — пишите в комментариях, разберем любую из них детально.

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

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

Автор:

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

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

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

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

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

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

Сегодня зафиналим нашу серию о будущем QA в 2026 году темой, которая еще вчера казалась сайнс-фикшн, а сегодня становится вопросом выживания экономики продукта. Мы целый месяц разбирали, где подключать ИИ в тестировании, какие метрики стали стандартом к 2026 году и почему DevOps без зрелого контроля качества превращается в имитацию скорости. Логичный следующий шаг в этой эволюции – ИИ-агенты. И если поставить целью максимально коротко описать ситуацию, то… мы наблюдаем так называемый тектонический сдвиг, то бишь переход от привычной автоматизации к подлинной автономности.

От «рельсов» к автопилоту. Что такое QA-агент?

Сотни раз сказано и тысячу раз написано, что большинство зрелых команд уже давно «приручили»=автоматизировали регресс. У вас наверняка считаются MTTR¹ и defect escape rate², CI/CD настроен, а пайплайны крутятся в штатном режиме. Но дьявол, как известно, носит PRADA кроется в деталях/рутине. Мы снова и снова повторяем, что решение о релизе всё равно принимает человек, мучительно выбирая между скоростью и риском.

Регресс часто запускается как привыкли, а не исходя из реальных угроз. И, конечно, приоритизация тестов до сих пор требует часов ручного анализа.

В этом и заключается фундаментальная разница. Классическая автоматизация – это поезд, идущий по строго заданным рельсам сценариев. Цифровой QA-ассистент – автопилот, который начинает принимать решения внутри самой системы.

Что же такое ИИ-агент, если слегка поскрести монеткой и снять маркетинговую позолоту? Автономная система на базе LLM и набора правил оркестрации³, бесшовно вшитая в процесс разработки. По факту такой AI-агент не просто генерирует очередные тест-кейсы, ведь это уже умеет любой плагин.

Виртуальный тестировщик (думаю, его можно и так назвать) делает вот что:

• проверяет, какие именно изменения внесены в код по сравнению с предыдущей версией (что добавили, удалили или переписали), анализирует диффы и меняющиеся требования в Jira;
• определяет зоны повышенного риска;
• самостоятельно выбирает стратегию под конкретный релиз и инициирует запуск нужного набора тестов;
• интерпретирует результаты и, если нужно, триггерит дополнительные проверки или rollback.

Автотест отвечает на вопрос пройдено или нет, а агент дает нам знать, что именно и с какой глубиной нам нужно тестировать в этой итерации. И вот это уже другой уровень. Здесь, в этой точке, сходятся все темы февральской серии статей. Автогенерация тест-кейсов можно считать сырьём. Метрики дают данные для принятия решений. DevOps становится средой исполнения. QA-агент связывает это в единую систему.

Анатомия решения

За громким словом «агент» стоит вполне рациональная архитектура. Типовое решение, которое мы внедряем, состоит из четырех слоев:

1. Аналитический сканирует репозитории, историю дефектов и требования.
2. Стратегический оценивает риск релиза, опираясь на метрики (частоту багов в модуле, нестабильность кода, критичность функционала для бизнеса).
3. Исполнительный формирует «умный» набор тестов, запускает их в CI и управляет их прогоном.
4. Контрольный является самым важным слоем, который отсекает галлюцинации нейросетей и удерживает агента в рамках заданных политик безопасности.

Технологически это связка из LLM, векторной базы данных с историей вашего проекта и глубокой интеграции с Git и CI. Управляемая система, работающая в рамках вашей корпоративной политики.

Реальные цифры

Чтобы не быть голословными, обратимся к практике. Самый прагматичный сценарий использования цифрового агента динамический Test Impact Analysis.

В одном из наших недавних проектов агент использовался именно для приоритизации регресса. Вместо того чтобы «ковровым методом» прогонять все подряд, система анализировала изменения в коде и выбирала только релевантные тесты. В итоге длительность регрессионного тестирования сократилась с 40 до 18 часов. При этом показатель пропущенных дефектов (defect escape rate) остался на прежнем уровне. Команда перестала жечь ресурсы там, где риск был минимален.

Второй вариант использования – сценарий с адаптивной генерациейя тест-кейсов под изменённые требования. AI-агент анализирует diff и дополняет покрытие там, где раньше тестов не было. Звучит круто, а ведь это то, с чем сейчас в России пока еще мало кто работает. Пора запускать постепенный переход к управляемой автономности в зрелых процессах.

Что это дает бизнесу (кроме экономии нервов)

Для каждой роли в компании здесь будет свой профит.

• CEO и владельцы масштабируют продукт, не раздувая штат QA пропорционально каждой фиче. Качество становится управляемым активом, черная дыра в бюджете не появляется.
• CTO получают адаптивное покрытие вместо статичного и, что важнее, кратно сокращают время принятия решения о релизе.
• QA Lead и его команда наконец-то перестают быть вымотанными машинами по запуску скриптов и фокусируются на действительно сложных исследовательских задачах. AI забирает на себя механическую работу по отбору и проверке.
• Project Manager гарантированно выдыхает, получая сильно меньше сюрпризов в черную пятницу и более точные прогнозы.

Отрезвляющая реальность

Если я скажу, что агент спасет любой проект, я совру. Не стоит фанатеть от ИИ до такой степени, превращаясь во влюбленную школьницу. Розовые очки снимаем и возвращаем себе адекватность. Как и любой сложный инструмент, QA-агенты:

1. критически чувствительны к качеству данных (мусор на входе будет мусором на выходе)
2. бесполезны без зрелых метрик и прозрачного CI
3. могут ошибаться, если у них нет доступа к доменному контексту

Бардак автоматизации не подлежит, ведь даже купив робот-пылесос вы вынуждены убирать вещи с пола, так? А если использовать метафору покрупнее, то на кривой фундамент можно поставить умный дом, тогда он рухнет еще технологичнее. А вот если выстроены процессы, тут вы получаете главное конкурентное преимущество.

Как внедрять QA-агентов

Есть вполне реалистичный план на 8 недель. Мы в «Лаборатории качества» не верим в лозунги «подключи API и расслабься». 

Шаг 1. Диагностика (1-2 неделя). Анализ текущих метрик, покрытия, длительности регресса.

Шаг 2. Пилот (3-5 неделя). Выбор зоны максимального ROI на одном модуле.Чаще всего это регресс или динамическая приоритизация тестов.

Шаг 3. Настройка ограничений (6-7 неделя). Определение правил, при которых агент может инициировать действия. Установка «красных линий» для его действий.
Шаг 4. Масштабирование (8 неделя). Анализ цифр, расширение зоны ответственности после подтверждённых результатов и раскатка на весь проект.
В среднем за это время становится понятно, дает ли автономный подход экономический эффект именно в вашем продукте.

Куда всё движется дальше

В 2026 году QA-агенты постепенно становятся частью более широкой концепции AIOps. Да-да, мы только-только привыкли к DevOps, наконец-то перестали путаться в Jenkins-файлах и смирились с тем, что QA больше не отдел поиска багов, а часть процесса. Но такова реальность, и пока мы привыкаем к одним стандартам, технологии уже строят над ними (и нами!) следующий этаж. Остается лишь подняться вверх или остаться внизу, что не особо полезно для бизнеса.

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

Как говорил Питер Друкер⁴: «Нет ничего более бесполезного, чем делать эффективно то, что вообще не следовало бы делать». Иногда ваш следующий шаг – не очередной фреймворк или модный инструмент, а переход на новый уровень управления.

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

Автор:

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

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

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

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

Ссылка на Хабр

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

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

Готовим тесты

Запрос будем отправлять в бесплатную систему Users. Метод doRegister: 

URL: http://users.bugred.ru/tasks/rest/doregister

Запрос:

{
    "name": "Демо 1",
    "email": "test_demo_1@gmail.com",
    "password": "1"
}

Если с первого раза запрос не упал, отправляем повторно, чтобы получить ошибку в ответе:

{
    "type": "error",
    "message": " email test_demo_1@gmail.com уже есть в базе"
}
Объяснить с

Напишем автотесты на эти 2 поля. Какие тут есть варианты? Мы можем писать маленькие тесты, одна проверка, один тест:

// Сохраняем ответ в переменную
var jsonData = pm.response.json();

pm.test("Проверяем тип", function () {
    pm.expect(jsonData.type).to.eql("error");
});

pm.test("Проверяем message", function () {
    pm.expect(jsonData.message).to.eql(" email test_demo_1@gmail.com уже есть в базе");
});
Объяснить с

А можем объединить, то есть написать один тест, который проверяет и тип, и message сразу (добавим его в те же скрипты, поэтому переопределять jsonData уже не надо):

pm.test("Проверяем тип и message сразу", function () {
    pm.expect(jsonData.type).to.eql("error");
    pm.expect(jsonData.message).to.eql(" email test_demo_1@gmail.com уже есть в базе");
});
Объяснить с

Отправляем запрос — все 3 теста проходят успешно:

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

Одна проверка упала

Сломаем тесты 1 и 3, поменяв «error» на «error2». Автотесты теперь выглядят так:

// Сохраняем ответ в переменную
var jsonData = pm.response.json();

pm.test("Проверяем тип", function () {
    pm.expect(jsonData.type).to.eql("error2");
});

pm.test("Проверяем message", function () {
    pm.expect(jsonData.message).to.eql(" email test_demo_1@gmail.com уже есть в базе");
});


Пятничный релиз и налог на надежду









Нарисуйте в воображении типичный вечер четверга, когда разработчики задеплоили фичу, Jenkins подмигнул зеленым, пайплайн отработал за считанные минуты и команда разошлась по домам с ощущением «обалдеть, какие мы быстрые и современные». А в пятницу утром начинается классика.Неожиданно вылез крит, лег прод, CTO уже ищет крайнего, а бизнес считает потери.


Если эта сцена знакома вам в рельной жизни, у меня для вас две новости.




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


А тут и тут вы можете прочитать про необходимость автоматизации


Большинство компаний живут и работают в гибридной модели. CI/CD есть, но релиз по-прежнему занимает больше времени, чем хотелось бы, тк в конце подключается ручной контроль. Автотесты написаны и гоняются, но им не верятили почему-то не доверяют. QA формально ускоряет, а по факту становится сбитым бутылочным горлышком, об которое режутся до крови все KPI по Time-to-Market (кстати, как сократить TTM писали тут). И это управленческая проблема, а вовсе не техническая.


Самый дорогой пайплайн – быстрый, но непредсказуемый. Когда деплой занимает 5 минут, а решение о релизе принимается 2 дня. Не будем мы обсуждать, как настроить CI. Это база. Но поговорим о Quality-First DevOps. О системе, в которой тестирование не назвать простым этапом после кода, оно становится иммунитетом релиза. Ее ключевой принцип:


код считается «готовым» не тогда, когда он написан, а когда он успешно и автономно прошел через все слои проверок (Quality Gates), подтвердив свою безопасность для бизнеса и пользователей


Проблема в том, что хаос почти всегда невидим. Команда чувствует, что что-то происходит долго, но управленческого инструмента для разговора об этом нет. Пока скорость, стабильность и предсказуемость delivery не переведены в цифры (а где их взять?), решения принимаются на ощущениях, а очередь между разработкой и релизом воспринимается как естественная часть процесса. А если вы хотите понять, как измеряется этот хаос и где именно он начинается, сначала посмотрите на метрики нового стандарта. Без них любая автоматизация как полет в тумане на воздушном шаре.




Затык №1. Слепой feedback loop и экономика ожидания


Самая дорогая ошибка не всегда идет как критический баг. Самая дорогая это баг, о котором разработчик узнает через несколько часов/дней. Ведь за это время он уже:



переключился на другую задачу


забыл контекст 


наслоил новый код поверх проблемного



Стоимость фикса растет экспоненциально: баг, замеченный в IDE, стоит копейки, а пропущенный на прод может стоить квартального бонуса всей команды. А CI в этот момент честно гоняет полный регресс и сжигает облачный бюджет так, будто у вас безлимитный тариф.


Можно работать с полным прогоном около 4 часов, как это делал один из наших клиентов до начала работы специалистов ЛК. Их команда привыкла к этим цифрам, им было важнее, что они все проверили. После обращения к нам и внедрения Test Impact Analysis (TIA, анализ влияния тестирования) время обратной связи стало 18 минут. Как думаете, как эта разница повлияла на успех проекта? Через два спринта разработчики впервые за год начали сами пушить в пятницу, тк это стало безопасно. Через квартал исчезло само понятие «релизное окно». Фичи начали доезжать до прода гораздо быстрее. Продукт перестал копить ценность в бэклоге и начал регулярно конвертировать её в деньги. С точки зрения бизнеса это был не апгрейд тестирования, а ускорение всей системы. 


TIA на практике не является попыткой «подправить» тестирование. Фактически это инструмент прямого влияния на Lead Time. 


Мы вырезаем из вашего TTM часы бесполезного ожидания и конвертируем сэкономленный облачный бюджет в скорость релизов


Есть разница между разработчик ждет полдня и получает фидбек в том же контексте. Эффект – предсказуемая скорость delivery.


А вот здесь, конечно, быстро упираешься в сложность системы. Вручную поддерживать TIA можно только в очень простых продуктах. В реале точность дает связка с ИИ, который анализирует изменения и выбирает те самые 5% тестов, где вероятность дефекта максимальна. И вот уже CI перестает быть крематорием для бюджета и становится инструментом управления скоростью.


Затык №2. QA как этап. Очередь, которая съедает TTM


Передача кода в QA как отдельный этап перешла в стадию управленческого анахронизма.Никакой Kubernetes не вылечит этот Waterfall. Очередь, которую вы создаете на границе отделов, и есть киллер TTM. Она  – фундаментальный ограничитель delivery, и ее не компенсировать мощным стеком.









Очередь означает:



разработка закончила работу, но ценность не доставлена


релизное окно двигается


бизнес ждет





Это уже прямой рост операционной стоимости каждой фичи. В зрелой модели тестирование не происходит после разработки. Оно встроено в Definition of Done.


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


Как в том мемчике: и вот тогда этот момент наступает… QA превращается из контролера в систему управления рисками. И здесь вскрывается причина, почему большинство годами топчутся на месте. У разработки KPI на количество закрытых задач, у QA на количество найденных дефектов, у бизнеса на срок релиза. Локально все молодцы. На уровне delivery – вечная пробка в центре столицы.


Затык №3. Flaky-тесты и инфляция доверия


Как только (и вообще – если!)  глава разработки произносит: «Да ладно, там тест опять моргнул, давай руками перепроверим и катим», ваш DevOps официально закончился.


Нестабильный тест (flaky) – это управленческий риск. Он легитимизирует игнорирование пайплайна и наступает кризис доверия к системе. В этот момент вы платите за автоматизацию, которой по факту не пользуетесь. Оно вам надо?


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


Вуаля! дорогой CI/CD превращается в декорацию, а релиз снова становится ручным ритуалом с участием всех лидов компании. Сколько времени они потратят на созвоны и согласования?..


Стабильность тестов в 2026 – метрика уровня CTO. Мы писали об этом 19 февраля… Она отвечает на главный вопрос бизнеса: можно ли масштабироваться быстро без риска обвалиться? 






Состояние системы
Последствия для бизнеса


Доверяем автотестам
Релиз по плану, команда спокойна, TTM минимальный.


Тест иногда падает
Релиз раз в неделю, ночные дежурства, «налог на надежду».






Рабочая практика не для слабонервных: нестабильный тест летит в карантин. Сразу. Без обсуждений и обещаний починить в следующем спринте. Потому что каждый пропущенный flaky минусует 10% доверия к вашей системе. А доверие в delivery конвертируется в скорость напрямую.




Затык №4. Страх прода и управляемый риск


Можно иметь идеальный препрод и все равно быть на нервах перед тем, как выкатываться. Реальная жизнь ПО начинается только на реальном трафике. Пока релиз это бинарное событие “пан или пропал”, скорость всегда будет ограничена страхом. Canary-релизы и feature flags на уровне менеджмента это вам не DevOps-игрушки, а рабочий способ превратить риск в управляемую величину.


Canary-релиз на 1% пользователей звучит как страховой полис. Фича открывается крошечной группе пользователей под прицелом авто-мониторинга. При любом отклонении система сама жмет на Rollback. Не исключая ошибки, мы сводим их радиус поражения к нулю.


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


Почему это не внедряется, даже когда все всё понимают


Технически большинство компаний способны реализовать все описанное. Но не способны организационно. Пока QA вы держите как отдельный блок со своим KPI на количество найденных багов, он всегда будет этапом. Пока скорость разработки измеряется количеством закрытых задач, а не временем доставки ценности, очередь будет считаться нормой. Так что Quality-First DevOps не меняет инструменты, а перераспределяет ответственность за качество внутри всей системы. Именно поэтому такие изменения редко происходят только внутренними силами. Технически команды умеют почти всё из этого списка. Но без внешнего опыта, где подобная трансформация уже пройдена несколько раз, организационная инерция оказывается сильнее любых правильных решений.




Быстрый тест на зрелость вашего delivery


Ответьте на 3 вопроса:



Можно ли откатить релиз одной кнопкой за минуту?


Верит ли лид разработки результатам автотестов без ручной перепроверки?


Поднимается ли тестовое окружение автоматически под каждую задачу?










Если хотя бы один ответ «нет», значит, у вас все еще капает тот самый налог на надежду. Самый дорогой налог в IT. Вы платите его не деньгами, а скоростью бизнеса.


Есть, о чем подумать: ИИ дает ускорение, метрики дают прозрачность, Quality-инфраструктура дает предсказуемость.


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







]]>
https://quality-lab.ru/blog/quality-devops-kak-ubrat-ochered-i-uskorit-relizy/
Wed, 25 Feb 2026 14:40:35 +0300



Меня зовут Эдуард, я руковожу отделом DevOps в компании KISLOROD. В этой статье расскажу про подход к нагрузочному тестированию, который сформировался у нас. Мы постоянно дорабатываем процессы, поэтому буду рад конструктивным комментариям и обмену опытом.
Зачем вообще нужно нагрузочное тестирование
Нагрузочное тестирование — это способ проверить, как система ведет себя при росте числа пользователей и соответствует ли ее поведение ожиданиям. По сути, это имитация реальной активности: пользователи заходят на сайт, просматривают страницы, добавляют товары в корзину, оформляют заказы.
]]>
https://www.software-testing.ru/library/testing/performance-testing/4485-kislorod
Tue, 24 Feb 2026 23:00:00 +0300



На моих курсах для начинающих у студентов порой возникают сомнения в актуальности лекций. Ошибочно кажется, что в 21 то веке:
цикл «Code and Fix» не существуется, у всех Agile или аналоги (ну да, ну да...);
глупых багов типа перехода через новый год или смены часовых поясов, уже давно нет, их решения «вшиты» в библиотеки кода (ага, щаз)
нет проблем «сделали в последние дни, из-за чего огребли проблемы»;
нет проблем с документацией;
...
Поэтому я рассказываю актуальные истории таких проблем, которых вроде как в 2026 году и быть то не должно... У меня их даже поднакопилось, но... Не записал сразу = забыл ))) Буду постепенно рассказывать тогда.

Сегодня я расскажу про АУСН. Сначала короткий рассказ, что это такое, а потом про текущую ситуацию с ним (и проблемы...)



Что такое УСН и АУСН

Это налоговые ставки для ИП или малого бизнеса. Когда вы работаете в штате, за вас налоги платит работодатель. А если вы открываете юр. лицо, нужно будет платить самому. Зачем?

Несколько причин открыть ИП (хотя сейчас есть альтернатива — самозанятый, раньше не было):
Работать как ИП на компанию (или несколько разных) — некоторые компании берут только ИП, или наоборот, не берут тех, у кого есть ИП. 
Работать на второй работе — на одной трудоустроены, остальное как ИП. Так, например, я с издательством сотрудничаю как ИП и на него получаю гонорар с проданных книг. Так проще и дешевле платить налоги, чем как физику.
Получать официальную прибыль — например, за сдачу квартиры в аренду, чтобы не как физик декларации заполнять, а просто честно платить налог с ИП. 
Ну и просто работать на себя, но если вы это планируете, то и так всё знаете ????
Открывая ИП (или ООО, или ещё что-то), вам надо выбрать налоговую ставку. По сути раньше были основные варианты:
УСН — упрощенный налог, платишь 6% с дохода (не с прибыли, а поступивших денег, неважно сколько ты при этом потратил)
«Серьезный» бухучет — там платишь с разницы «доходы - расходы», но бухучета больше, он сложнее + налоговая будет заставлять отчитываться обо всех расходах, чтобы ты туда лишнее не вписал.
В общем, обычно берут упрощенку. В ней есть ограничение — 60 млн дохода в год, иначе надо платить НДС и всякое сложное.

Потом появился АУСН — автоматизированный налог, где 8%, а не 6% платишь, но "зато" оно платится само, не надо делать отчетность, её считают банки. Но если ты уже платишь за бухгалтерию, то вроде как и нет смысла в этом АУСН... Раньше )



Изменения в 2026 году

Поменяли систему. Чтобы не платить НДС и сидеть на упрощенке, максимальный доход по ставкам:
УСН — 10 млн рублей в год (вместо 60!!). Но понижают "медленно", в этом году можно 20 млн получить, в следующем вроде 15, потом уже перейдут на 10.
АУСН — 60 млн 
То есть по сути, если доход больше 10-20 млн (эх, мне бы в эту категорию ????), надо переходить на АУСН. ВОТ ТЕПЕРЬ он стал выгодным!



Проблемы перехода (а вот и баги!)

Ну и, собственное, сейчас многие стали переходить на АУСН и, сюрприз-сюрприз, стали вылезать баги! 

Я тут немного теоритик, так как сама в эту категорию дохода не попадаю. Но знакомый, который перешел, скинул любопытную статью, подтвердив, что встречал такие проблемы — https://www.forbes.ru/finansy/554530-biznes-stal-case-perehodit-na-ausn-s-kakimi-problemami-mozno-stolknut-sa:

«С проблемами передачи данных при работе на АУСН сейчас сталкиваются многие предприниматели, и это не частные сбои, а системные», — говорит член совета московского регионального отделения «Деловая Россия» Андрей Глушкин. Ошибки в передаче данных от банков и операторов в налоговые органы наблюдается довольно часто, особенно в начале 2026 года, подтверждает член Ассоциации налоговых консультантов, руководитель налоговой практики адвокатского бюро «БВМП» Александр Андропов. В числе основных причин — неполная готовность банковских систем к интеграции с Федеральной налоговой службой (ФНС), в том числе потому, что многие кредитные организации подключились к реестру уполномоченных кредитных организаций для АУСН (то есть стали банками, где плательщики АУСН могут открывать счета) только в конце 2025-го. «Банки не успели полноценно протестировать обмен данными, что приводит к искажениям в передаваемой информации», — говорит Андропов. 

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

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

— Конечно, банки были не готовы! — думала я. Ведь это только сейчас внедряется, я вот про АУСН услышала год назад, что-то новенькое жеж (я не бухгалтер и поэтому за бухгалтерскими новостями не слежу)

А вот что для меня стало откровением в этой статье, так это то, АУСН уже почти 4 года! Оказывается, он запустился летом 2022 года. 3.5 года назад!

И при этом банки «не успели протестировать обмен данными». А всё почему? А потому, что банки и сами только недавно стали подключаться к этой системе!

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

В любом случае в банковских системах есть свои планы на ближайшие несколько релизов. Надо сделать функцию А, исправить функцию Б и вон ту финтюфлюшечку хочется. Так зачем брать в релиз задачи, которые пока не горят? Видимо, клиентов на АУСН было настолько мало, что проще было им отказать "нет, мы не умеем поддерживать такую систему", чем внедрять её.

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

Ну и интеграция — это тоже всегда сложно, потому что обычно нет подродного ТЗ, делают как поняли, а оно работает не так, а надо переделывать... В общем, процесс небыстрый! Хоть и 21 век)

PS — добавила пост в общую копилку багов.
]]>
http://okiseleva.blogspot.com/2026/02/blog-post.html
Tue, 24 Feb 2026 20:37:00 +0300



Автор: Cуатика Визань (Swathika Visagn)
Оригинал статьи
Перевод: Ольга Алифанова

Что общего у кулинарии и автоматизации тестирования?
Что общего у кулинарии и автоматизации тестирования, спросите вы? Можно провести красивые параллели между программированием и готовкой: автоматизаторы тестирования как шеф-повара, скрипты автоматизации как рецепты, фреймворки автоматизации как кастрюли и сковородки, а кулинарная книга — как эта статья! Эта статья посвящена всем тестировщикам, которые ищут новые рецепты аутентификации с использованием Playwright.
Статья предназначена для автоматизаторов тестирования, которые уже знакомы с Playwright или используют его в своей работе. Для демонстрации я буду использовать учебный магазин Book Cart, на который я наткнулась в статье Сары Дири на сайте Ministry of Testing.
Для этой «поваренной книги» я отобрала четыре рецепта аутентификации, варьирующиеся от базового до среднего уровня сложности. Эти рецепты используют сочетание методов аутентификации через UI и API, с объяснением реальных сценариев применения для каждого из них.
]]>
https://www.software-testing.ru/library/testing/testing-automation/4452-playwright-authentication
Mon, 23 Feb 2026 23:00:00 +0300



Касательно командной разработки с интенсивным применением LLM — ну да, растёт скорость внедрения изменений. За всем уследить не получается, и мы натыкаемся на нелепые баги, которые можно было бы обнаружить за секунды, ещё до релиза деплоя. Наверное, уследили бы, если бы изменение было планомерным, предсказуемым и затрагивало только одно секундное дело. А оно затрагивает много место сразу, в которые никто не заходил и ломаться было нечему… Если бы всё всегда ломалось предсказуемо, то уж мы бы…

QA процессы — можно внедрить, конечно, но 

в разработке ПО гарантирование качества не гарантирует ни качества, ни отсутствия багов. Долго объяснять, но это так, ПО не делается, как клоны на фабрике, это каждый раз уникальный артефакт со множеством особенностей, из которых некоторые наследуемые, а некоторые неожиданно новые.
тестирование стоит на фундаменте из требований, которые надо сперва наладить и запрягать перед каретой, а не после. Если мы деплоим 256 изменений за один раз по вторникам, то как именно трэкать эти самые требования? Где? Кем? Скорее всего, это ПО развивается не по требованиям, а по невнятным ожиданиям бизнеса. Нет требований — нет и гарантий соответствия им, потому что нечему соответствовать, тестирование живёт в режиме «сравнить наблюдаемое с ожидаемым». Нет ожиданий — не с чем сравнивать, остаётся только исследование в режиме «я не уверен, как оно должно работать…» А исследование ПО в QA этого ПО не конвертируется.

Любопытно, что всё то, что мы сегодня переживаем, уже было — в начале девяностых, когда понадобилось ускорить поставку ПО, потому что бизнес же тестирует гипотезы и идёт вслепую, а не по продуманному и однозначному пути. И пришёл agile, и все ускорились, и в двухтысячных годах XX века я не видел в разработке живых тест-аналитиков и тест-дизайнеров, к тому времени их уже всех свезли на остров Литтл-Сент-Джеймс (в составе Американских Виргинских островов), где американский финансист Джеффри Эпштейн & Co регулярно путали их с девицами красными.
И это случилось так быстро, что в двухтысячных уже всем казалось нормальным, что тестировщик сам придумывает тест-кейсы, сам их дизайнит и сам их выполняет. Ну, как дизайнит… он знает о том, что существует тест-дизайн, где надо какие-то таблицы придумывать, но на это всегда нет времени. Проще читать требования напрямую, на ходу придумывать проверки и сразу их выполнять. Придумывать тест-кейсы — где вы на это время найдёте?
А сегодня нам уже и требования негде взять, потому что ПО генерируется быстрее, чем кто-то соображает, зачем его нужно генерировать и что именно оно должно делать. И как именно… И какой бизнес будет стоять за нагенерированным ПО. Те же сайты не нужны сами по себе, они нужны бизнесу как витрина, как сборщик заказов…
А ещё в древности ПО поставляли на дисках, и обновлять его было крайне сложно, поэтому наши предки старались его как-то привести в готовое состояние ДО релиза. Но мы уже не они, мы перепрыгнули в парадигму «ПО работает на сервере, к которому мы постоянно имеем доступ, и если мы найдём ошибку — просто быстро её исправим», и это полностью true в отношении мелких ошибок. А если ошибка будет NOT мелкая, ну, откатим софт… наверное. Стоимость исправления ошибки упала, зачем вы требуете время на то, чтобы тестировать тщательно до релиза? Тестируйте после релиза, что вам мешает? Давайте сперва выпустим софт, чтобы продажи были, а потом вы будете его тестировать. Вот вам требования, не нойте.
А сегодня и требований «уже не стало, а скоро совсем не будет» © нашсеньор Паниковский. Мне уже предлагают воспринимать под видом требований абстрактные тексты, которые были сгенерированы по сгенерированному коду. Текст получается осмысленным на расстоянии одного предложения, а вместе эти предложения не склеиваются.
Всё, как мы любим — без воды, без резолюции, без нервотрёпки, без коагуляции десереализационного инкремента, без хтонических завихрений, без un pahar de tocănică gustoasă la a voastră masa măiastră.
Хочешь ещё?
Я понимаю коллегу, который тоже задолбан и был вынужден предложить хоть что-то под видом требований, он поднатужился и выдал — дякую, аж пiдскакую. А дальше со всей этой слезинкой ребёнка что делать?
В норме я могу, читая требования

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

То есть, мой процесс состоит из нескольких фаз: осознание, обдумывание, согласование, выполнение. Всё это требует какого-то времени. Что можно машинизировать и ускорить?
Осознание
Тест-кейсы пишут так же, как пишут код — руками на клавиатуре. Начинаешь медленно, затем ускоряешься, и постоянно к чему-то приходится возвращаться.
Можно их сгенерировать — вот вам и, кагбэ, ускорение. Но придётся разбираться в нагенерированном. То есть, произойдёт мощный спид ап на первой фазе, а затем…
Обдумывание
… всё равно мучительно медленный разбор — нужны часы.
Ок, я могу сам заниматься тест-дизайном, это, в принципе, знакомая и интересная аналитическая работа, которая направлена не на написание тест-кейсов, а на выявление очевидных и неочевидных связей и требований, и уже из того, что останется, появляются тест-кейсы. Но это требует времени.
А ещё тест-кейсы пишут или по требованиям, или по уже работающему приложению. Второй подход ублюдочен, но с него начинают все. Первый подход сложен, но он более разумен и эффективен. Anyway, и на то и на это нужны часы пропорционально количеству функциональностей ПО — чем их больше, тем больше времени нужно.
Согласование
Очень важный этап, который мы все дружно скипнем. Сколько раз уже скипали, неужели на этот раз что-то бомбанёт? Вроде не должно…
Выполнение
Вручную тестирование делается медленно — нужны часы.
Можно какие-то проверки делать через тот же Playwright, но не все же, и их так или иначе надо будет записать в виде кода. LLM тут может нас спидануть, но местами с очевидно-предсказуемой потерей буквы «з», и придётся разбираться в каждом отдельно взятом кейсе. Нужны часы на подготовку тестов для автоматизации и, к сожалению, в будущем понадобится МНОГО часов на их постоянное переписывание, потому что автоматы будут устаревать и спотыкаться на ровном месте — просто потому, что так они устроены.
И надо, чтобы этим занимались отдельные пацаны, и для успеха им нужны уже кем-то продуманные тест-кейсы, чтобы не переключаться между разными уровнями абстракции. Впрочем…
А если после всего этого ВНЕЗАПНО выясняется, что требования уже где-то как-то непредсказуемо поменялись, то надо всю эту аналитическую работу выполнять заново. Это реалистично? В погоне «успеть вовремя» её будут выполнять частично, а значит, никаких гарантий не будет, ПО поедет в релиз от станции Тревожность до станции Бадабумц, потому что тестировщики опять пропустили какую-то досадную (местами лютую) мелочь.
Может быть, пришло время как раньше, порезать в ролях и принудить тестировщиков выполнять работу, которую раньше делали отдельные юниты? Да, тест-дизайн стал хуже, но остался же? Можно, например, заставить тестировщика придумывать требования. Он же не сможет возразить?! И пусть это будут очень плохие требования, но они же будут, хоть какие-то?!
Всё, как мы любим — без воды, в пустыне, под палящим солнцем…
Ок. Мы превратим тестировщиков в бизнес-аналитиков «с сильным навыком тестирования». И пусть эти аналитики сами гоняют LLM и сами «генерируют соответствующие артефакты», которые только им самим и нужны.
Пусть Джек идёт строить дом…
Вот LLM, которая генерирует код проекта.
Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту.
Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются юнит-тесты для проверки проекта. Лей в прод.
Тут будет большой бэмц, после которого программиста допрашивают через его же сфинктер, а как так получилось, что его красивые юнит-тесты работают, а ПО — с багами. Пропустим эти неприятные звуки и перейдем к следующему ходу.
Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, чтобы не возиться с ручным тестированием. Лей в прод.
Тут пропустим ещё один большой бэмц, после которого всех сразу допрашивают (и не только через сфинктер; что вы так сосредоточились на этом сфинктере, вы больные, что ли?!), а как так получилось, что и юнит-тесты работают, и Playwright работает, а ПО — с багами. Почему вам не хватило времени мозгов проверить руками хотя бы основные happy path? Почему этих happy path так много, товарищи? Давайте заново.
Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, и тест-кейсы для ручного тестирования. Сжимай свой сосредоточенный сфинктер, раз уж ты ни на чем другом уже не можешь сосредоточиться, и лей в прод.
А что лить-то? Мы сразу втыкаемся в то, что ручное тестирование проекта требует времени два раза — и для подготовки (когда анализируют требования и придумывают тест-кейсы), и для выполнения. И это всё никак не ускоряется. Быстро льётся, если без тестирования. А вы же хотели тестирования? Хм…
И время идёт, пока мы читали эти ужоснах тест-кейсы для ручного тестировани, та клята LLM уже перегенерировала заново код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, и новые тест-кейсы для ручного тестирования… и по цепочке всё обновила. Кхм, как говорится, блеать…
Если генерирование ПО каждый раз создаёт ПО заново, с непредсказуемыми характеристиками и возможностями, которые надо перетестировывать заново, с нуля, с тем же уровнем недоверия, то в этой схеме не может произойти общее ускорение. В этой схеме есть моменты для локального ускорения, но в целом — нет. Это как таскать воду из колодца домой, и местами на этом пути находить сантиметрики, которые можно срезать, и весь путь туда-обратно как будто-бы сокращается и оптимизируется, да, но в целом как был километр, так и остался, и нужно принципиально другое решение, в котором вода в доме будет постоянно появляться, а таскать воду из колодца уже не придётся.
Почему мы вообще занимаемся этим трудом Сизифа, к которому аргонавты каждый день прилетают и клюют печень да «трахаютЪ мозгЪ», уж простите, не знаю как это произносится по-древнегречески!?
Если делать ПО, которое будет взаимодействовать только с другими ПО, то постоянное тестирование будет ненужным, оно перейдёт в режим одноразовой задачи, вы можете видеть положительный эффект этой условности в разделе API. А если делать ПО, которым будут пользоваться люди (местами бесконечно глупые, местами дъявольски умные), то и проверять его надо людьми, причём постоянно. Как это ускорить?
Может быть, стоит убрать из этой схемы вообще всех, даром, и пусть LLM сами генерируют код и тесты, и впихивают это всё в CI/CD, и выполняют на проде, и пусть другие LLM этим всем пользуются и всё это покупают. Проекты же делают для прибыли, right?
В общем, разгоняемся, пока можем. Про торможение будем думать, когда придётся начать тормозить…
 

Hop, hop, hop, hop, hop, hop, hoba!
]]>
https://testitquickly.com/2026/02/20/mesterul-manole-rastoarna-caldarea/
Fri, 20 Feb 2026 15:08:10 +0300




Традиционных показателей вдруг стало недостаточно для релизных решений. Современные метрики в тестировании всё чаще рассматриваются как инструмент управления рисками, но какие метрики в тестировании остаются актуальными в 2026 году? Разбираем Risk Coverage, Defect Escape Rate, MTTD, стабильность автотестов и их влияние на релизные решения и бизнес-результаты.


Если открыть типовой QA-отчёт, вы увидите привычный набор показателей: количество дефектов, процент автоматизации, pass rate, объём выполненных тест-кейсов. Это все полезно на операционном уровне, но…теперь этого мало. В отличие от традиционных QA-метрик, новые показатели ориентированы на влияние на продукт. Требования к метрикам меняются по мере ускорения релизных циклов и усложнения продуктовой архитектуры. 











Баги пофиксить надо, только необходимо еще и поддержать управленческий выбор:



выпускать или дорабатывать,


усиливать регрессию или перераспределять ресурсы,


принимать риск или снижать его.





Почему традиционные QA-метрики больше не отражают реальный риск продукта


Проблема, конечно, не в самих показателях, а в том, какие вопросы им задают.


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


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


Pass rate фиксирует состояние конкретного прогона, но практически не даёт информации о потенциальной уязвимости ключевых бизнес-функций.


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


И вот именно в этой точке и проявляется так называемый сдвиг, мы начинаем смотреть на метрики иначе. В 2026 году ценятся метрики, которые:



помогают принимать решения,


показывают риски заранее,


связывают QA с продуктом и бизнесом.



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




Современные метрики в тестировании, которые действительно влияет на релизные решения


 1. Risk Coverage – покрытие рисков вместо формального coverage


Вопрос смещается с количества протестированного на то, какие бизнес-критичные риски закрыты.


Risk Coverage дает возможность:



соотнести тестирование с приоритетами продукта


оценить уязвимость ключевых пользовательских сценариев


обосновать релизное решение на языке рисков



Это особенно важно в сложных продуктах, где 80–90% общего покрытия не гарантируют защищённость сценариев, влияющих на выручку или пользовательский опыт. Метрика, которую понимают за пределами QA. Такой поворот в сторону риск-ориентированных метрик во многом стал возможен благодаря изменениям в инструментах и аналитике. В декабре мы подробно разбирали, как искуственный интеллект в QA помогает смещать фокус с формального покрытия на управляемость рисков и предсказуемость релизов. В 2026 году уже никто из грамотных специалистов не экспериментирует с этим подходом, потому что внедрили и, представьте!,»оно работает».


2. Defect Escape Rate – индикатор системных зон уязвимости


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


Анализ динамики Defect Escape Rate позволяет:



выявить слабые места в процессе


оценить эффективность регрессии


определить зоны, требующие пересборки подхода



На проектах рост Defect Escape Rate почти всегда отражается не только в отчётах QA. Он быстро превращается в падение конверсии, рост нагрузки на поддержку и прямые финансовые потери. В одном из предыдущих материалов мы разбирали, как ошибки качества напрямую бьют по бизнес-показателям – и именно поэтому эта метрика всё чаще обсуждается на уровне продукта, а не только QA.


3. Mean Time to Detect и время анализа


Сокращение времени фикса остаётся важным, но всё важнее становится раннее обнаружение бага и понимание масштаба проблемы.


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


MTTD и время анализа дефекта напрямую влияют на:



стабильность релизов


нагрузку на поддержку


скорость управленческой реакции



В 2026 году это одна из ключевых метрик зрелости QA и Dev-процессов.


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


4. Stability of Tests – доверие к результатам


Нестабильные автотесты снижают ценность всей системы контроля качества.


А если результаты тестирования не вызывают доверия, то это приводит к игнорированию рисков: возникает эффект привыкания к алертам (alert fatigue), из-за чего релизы выпускаются практически вслепую


Так что стабильность тестов постепенно выросла из технической детали в самостоятельную метрику.




5. Time-to-Feedback – скорость обратной связи для разработки


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


А главное ведь, что Time-to-Feedback показывает:



насколько QA встроен в цикл разработки


где возникают задержки


как быстро риск становится видимым



Для технического руководства эта метрика напрямую связана со скоростью команды и предсказуемостью релизов.


6. Business Impact Metrics – выход за пределы QA


Наиболее заметная тенденция в последние годы – связывание метрик качества с бизнес-показателями. В фокусе оказываются такие связки, как:



дефекты → снижение конверсии


нестабильность → рост нагрузки на поддержку


проблемы качества → замедление time-to-market



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


Практические шаги по внедрению современных QA-метрик


Чтобы перейти от отчётности к управляемости, важно действовать системно.


1. Проведите аудит текущих метрик, ответив на три вопроса:



Какие из них реально используются при релизных решениях?


Какие отражают риск, а какие – активность?


Какие показатели дублируют друг друга?



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











3. Переходите уже, наконец, от разовых отчётов к динамике. Будьте уверены, анализ трендов (Escape Rate, MTTD, стабильность тестов) даёт больше информации, чем показатели одного релиза.




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


5. Ограничьте набор ключевых показателей. Для стратегического уровня достаточно 4–6 метрик, напрямую влияющих на управленческие решения.


Резюмируем


Метрики не теряют актуальности, но меняются требования к ним. Если метрика не помогает ответить на вопрос «что делать дальше?», то она не нужна. 


И да, ИИ и автоматизация ускоряют сбор и анализ данных. Но сами по себе они не делают метрики полезными. Полезными их делает связь с процессом, ответственностью и реальными целями продукта, так что при выборе KPI для QA-команды важно учитывать не только операционные показатели, но и бизнес-метрики качества. 


Метрики к 2026 году из отчетов превратились в круглый стол для QA, разработки и бизнеса с очень крутой возможностью найти общий язык.


FAQ. Часто задаваемые вопросы о метриках в тестировании


Какие метрики в тестировании считаются ключевыми в 2026 году?
Risk Coverage, Defect Escape Rate, MTTD, стабильность автотестов и Time-to-Feedback – как показатели, влияющие на риск и релизные решения.




Чем современные QA-метрики отличаются от традиционных KPI?
Они ориентированы не на объём выполненной работы, а на оценку риска и бизнес-влияние качества.


Какие метрики важны для CTO?
Показатели, влияющие на скорость релизов, предсказуемость и влияние дефектов на продуктовые метрики.









]]>
https://quality-lab.ru/blog/qa-metrics-2026-risk-management/
Thu, 19 Feb 2026 14:43:43 +0300



Оригинальная публикация
Автор: Сергей Терентьев

Пролог  
Проекты бывают разные, простые и сложные, с хорошей и плохой документацией, стартапы и проекты с солидным (часто не очевидным) легаси, и тд. При этом для каждого проекта можно подобрать свой набор QA процессов и инструментов, который даст возможность достичь требуемого качества.  
О статье и общая проблематика  
В этой статье я расскажу о виде тестирования, который мне ранее не встречался в стандартных QA источниках, при этом нечто очень похожее используется в направлении Data Engineering. Этот вид тестирования показал свою эффективность в тех случаях, когда у вашего проекта есть следующие особенности:  
это легаси проект с непрозрачной, плохо задокументированной и достаточно сложной логикой (назовем ее “серой логикой”). При этом члены команды, обладающие контекстом легаси не могут 100% гарантировать (или у вас есть сосмнения), что их воспоминания о фактическом поведении “серой логики” верны 
на проекте присутствует БД, данные которой являются точкой применения вышеуказанной “серой логики”
сам проект уже в production
при этом ограничения, установленные на уровне БД не могут покрыть все необходимые ограничения, которые требует бизнес логика (само собой при наличии достаточно сложного функционала)
Согласитесь, не так, чтобы эти условия были какой-то редкостью).
]]>
https://www.software-testing.ru/library/testing/other-testing/4478-post-release-data-validation
Tue, 17 Feb 2026 23:00:00 +0300



Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я посмотрела сериал AppleTV Silo. Шоу рассказывает о жизни 10 000 человек, обитающих в подземном бункере. Они знают, что их предки жили там сотни лет, но не знают, зачем, и почему выходить наружу опасно.
Бункер работает от генератора, который обслуживает команда Механиков. В третьем эпизоде показано, что генератор не работает правильно уже 30 лет и быстро приближается к критическому состоянию. Конечно, это сразу напомнило мне о техническом долге в программном обеспечении! В этой статье я рассмотрю восемь шагов, которые команда должна предпринять для работы с техническим долгом, с примерами из Silo и из проекта, над которым я работала несколько лет назад.
]]>
https://www.software-testing.ru/library/around-testing/processes/4450-what-silo-can-teach-us-about-tech-debt
Mon, 16 Feb 2026 23:00:00 +0300



Автор: Екатерина Гаврилова

Меня зовут Катя  и я ведущий инженер по тестированию в MD Audit.
Хочу поделиться как я внедрила ИИ в процессы тестирования, чтобы не тратить время на рутинные задачи и больше заниматься любимым делом (кидать мемы в рабочие чаты).
AI не заменит тестировщика. Но тестировщик, умеющий работать с AI, заменит десятерых.  
Эта статья  кратко и без воды расскажет о том, как я встроила ИИ в процесс ручного тестирования, какому подходу научила свою команду и какие промты реально экономят часы рутинной работы.
]]>
https://www.software-testing.ru/library/testing/general-testing/4477-ii
Sun, 15 Feb 2026 23:00:00 +0300



Автор: Кирилл Толмачев

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

В феврале этого года я писал на Хабре про автоматизацию тестов для САПР. Мы делали систему с записью действий в JSON и воспроизведением через pyautogui. Работало. Но только для одного конкретного проекта.
С тех пор фреймворк вырос. Сильно. Из узкоспециализированного решения для промышленного ПО превратился в универсальный инструмент. Теперь работает с чем угодно - офисные пакеты, банковские клиенты, CAD-системы.
Что изменилось? Убрал привязку к конкретному софту. Добавил умный поиск элементов вместо тупых координат. Сделал так, чтобы QA мог записать тест без единой строки кода. Прикрутил UI-ассерты, мониторинг системы, файловые проверки.
Короче, то что начиналось как решение для одной задачи, выросло в полноценный фреймворк. И оказалось полезным не только мне.
]]>
https://www.software-testing.ru/library/testing/testing-automation/4486-gui-tests
Sun, 15 Feb 2026 13:18:24 +0300




С AI в тестировании сейчас происходит странная вещь. Кто-то пытается использовать его везде, а кто-то опасливо поглядывает, предпочитая не подпускать к процессам вообще. И то и другое, конечно, ненужные крайности. Можно найти уже сотни примеров проектов, где ИИ сокращал время релиза и делал работу QA спокойнее, предотвращая нервный тик от тысячного повтора рутинной операции. И тем не менее, если начнем искать, то увидим и достаточно случаев, где ИИ ускорял выпуск… багов в прод.


Но проблема не в технологии как таковой, а в ожиданиях. Многим, кто начинает пользоваться ИИ и восхищается результатами, сложно понять, что он не думает за тестировщика, какой бы супер-промт вы ни написали, и не понимает продукт так, как человек, как бы вы ему этот продукт ни скармливали в описании/изображении/схеме. Зато AI отлично забирает на себя механическую работу и помогает увидеть то, что нам сложно удержать в голове. Так что если в 2026 году вы всё ещё продаете (или покупаете) чисто ручное тестирование «по старинке», у меня для вас плохие новости. Вы либо неоправданно богаты, либо сознательно тормозите свой Time-to-Market (TTM). Там, где циклы разработки сократились до часов, классический подход к качеству стал бутылочным горлышком.









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




Мы уже писали о том, как на практике наши специалисты применяют ChatGPT в тестировании и как правильно писать промты для решения задач QA. Сегодня я хочу напомнить о главное и показать, в каких 5 зонах можно заставить нейронки окупаться, а также «красные флаги», которые должен видеть каждый CTO.




Тест-дизайн и «Шредер» для рутины


Написание тест-кейсов по API-спекам или User Stories вполне механическая работа, которая исторически убила мотивацию не одного QA, к сожалению. Джуны сходят с ума сначала от радости, что им доверили большой объем, потом от усталости, потому что этот объем никак не заканчивается. А ведь можно перевести эту задачу на уровень AI-First QA.


Скармливаете модели требования, а на выходе получаете структурированный драфт: Happy Path, граничные значения и каверзные негативные сценарии.


На уровне 2026 года ИИ умеет генерировать готовые Gherkin-сценарии или Playwright/Cypress шаблоны. ИИ помогает набросать структуру, но за архитектуру тестов по-прежнему отвечает человек. На старте проекта это экономит до 60% времени. Иногда все же проверка того, что нагенерировал ИИ занимает тоже немало времени.




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









Self-Healing – конец эры «упавших» локаторов


Еще несколько лет назад изменение ID кнопки на фронтенде означало смерть половины автотестов и работу в форс-мажоре для команды. Теперь профи это считают моветоном.


На деле вы внедряете Self-healing механизмы (самовосстанавливающиеся системы) и если тест не находит элемент по старому селектору, то ИИ-агент анализирует DOM-дерево в момент падения теста. Он понимает: «Окей, ID изменился, но эта кнопка всё еще находится в блоке оплаты и имеет текст «Купить»». В результате тест не падает, а тестировщик с утра получает отчет о том, что агент подправил локатор, нужна проверка и мердж. В этом случае расходы на поддержку (Maintenance) тестов снижаются на 40%.


Smart Regression – игра в рулетку уже не в моде


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


Подключайте предиктивную аналитику, это и есть экспертный подход. Искусственный интеллект анализирует историю падений, свежие коммиты в Git и данные мониторинга из Grafana. Система сама собирает Risk-based пакет. И пока конкуренты гоняют полные тесты по несколько часов, вы проверяете только то, что реально могло сломаться, и даете аппрув за 40 минут. И это прямая экономия на CI/CD пайплайнах.


Генерация синтетических данных (TDM)


В 2026 году требования к безопасности (GDPR, 152-ФЗ) стали драконовскими. Использовать реальные данные клиентов для тестов – подсудное дело. Есть хорошее решение – обучить локальные модели на структуре БД проекта. ИИ генерирует синтетические датасеты: миллионы транзакций, профилей и заказов, которые выглядят как реальные, но не содержат персональных данных. Это дает вам тестирование на «живых» объемах данных без единого риска утечки.


RCA и анализ багов – паттерны против хаоса


Когда в Jira падает гора тикетов, человек видит симптомы. ИИ помогает коррелировать логи с шагами воспроизведения – отлично делает Clustering (группировку похожих багов) и действует в RCA, Root Cause Analysis (анализ корневых причин, структурированный метод поиска истинного источника проблемы). С этим анализом нейронка выявляет хрупкие модули и сопоставляет логи сервера с описанием бага. Для PM ценность такого подхода неоценима, потому что вместо отчета вроде «у нас 50 багов», вы получаете полный расклад типа: «Система деградирует в модуле оплаты из-за конфликта типов в API. Вот 5 связанных кейсов». Время на локализацию ошибки (MTTR) в этом случае сокращается в 3 раза.




Где ИИ – прямая угроза 


Опытные команды принципиально не доверяют ИИ в трех случаях.


Security & Data Privacy.


Скармливать закрытую архитектуру в публичный ChatGPT равносильно, что купить билет в один конец до штрафов и репутационного краха. Важно работать через Enterprise-API с гарантией безопасности данных или можно развернуть локальные современные open-source модели (семейства Llama, Mistral и др.) внутри защищенного контура компании.


Сложные бизнес-домены


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


UX и человечность


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


Эффективность в цифрах (ROI для бизнеса)






Процесс
Роль ИИ в работе команды
Итог для клиента


Test Design
Генерация сценариев и Gherkin как черновика
Сокращение фазы подготовки тестов примерно на 50%


Regression
Risk-based фильтрация регресса
Ускорение цикла тестирования (Testing Cycle Time)


Maintenance
Self-healing локаторов автотестов
Снижение затрат на поддержку тестов до 40%


Bug Analysis
RCA-ассистент для анализа дефектов
Локализация причин багов до 70% быстрее






Резюме


ИИ в тестировании не заменяет специалиста, а усиливает его, становясь тем самым экзоскелетом. Не нужно бездумно сокращать QA-отделы в надежде на машины, но и отказываться растить AI-augmented инженеров не стоит. Они могут работать в 10 раз быстрее и точнее классического ручного тестирования и быть главным конкурентным преимуществом. Конечно, при условии, что ИИ под контролем эксперта. И таких экспертов можно найти в ЛК.


]]>
https://quality-lab.ru/blog/blog-ii-v-testirovanii-gde-ispolzovat-gde-vredit/
Wed, 11 Feb 2026 13:22:27 +0300



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

Таймауты — одна из ключевых частей end-to-end тестирования UI. При тестировании пользовательских интерфейсов мы часто сталкиваемся с различными формами случайности (или кажущейся случайности) в том, как элементы появляются и взаимодействуют.
WebdriverIO справляется с этим с помощью команд, которые выполняются в цикле, пытаясь найти элементы или выполнить проверки, пока они либо не сработают, либо в конечном итоге не завершатся ошибкой. Можно рассматривать таймауты как верхние пределы: если нужное действие происходит в пределах таймаута, скрипт продолжает выполнение.
]]>
https://www.software-testing.ru/library/testing/testing-automation/4451-webdriverio
Tue, 10 Feb 2026 23:00:00 +0300



Автор: Яковлев Станислав — Team Lead в Т-Банке, телеграмм канал t.me/qa_chillout

До ухода с российского рынка таких систем, как TestRail, Qase, Zephyr, острой потребности в переходе на отечественные решения не было.
Большинство российских команд пользовалось именно этими инструментами - и на то были объективные причины. Зарубежные TMS годами оттачивались на тысячах проектов по всему миру, отличались стабильностью, удобством и фактически задавали стандарт качества в управлении тестированием.
После их ухода многим командам пришлось срочно искать замену. В тот момент это оказалось непростой задачей: отечественных решений было немного, а зрелых продуктов почти не существовало.
Однако курс на импортозамещение стал стимулом для роста. За последние несколько лет появились десятки российских TMS — от простых облачных сервисов до крупных корпоративных платформ с интеграциями и удобной системой отчётности.
]]>
https://www.software-testing.ru/library/testing/testing-tools/4476-tms
Mon, 09 Feb 2026 23:00:00 +0300



Прочитал сегодня статью: инженеры из Anthropic и OpenAI говорят, что у них 100% кода пишет ИИ. Понятно, что в этом есть и маркетинг — ну а что ещё им говорить  Но статья зацепила…

Еще буквально недавно “ИИ помогает писать код” звучало как автокомплит и подсказки.
А теперь инженеры из Anthropic и OpenAI публично говорят: в их работе ИИ пишет 100% продакшн-кода:
“For me personally it has been 100% for two+ months now, I don’t even make small edits by hand,”
 “I shipped 22 PRs yesterday and 27 the day before, each one 100% written by Claude.”
Со стороны OpenAI — максимально прямолинейно:
“100%, I don’t write code anymore,”
Если код больше не дефицит — что становится дефицитом?
1) Код дешевеет. Ясность — дорожает.
Когда “написать” почти бесплатно, получается появляется новая инфляция: инфляция сложности
Сами инженеры признают: ИИ может оставлять “dead code” и усложнять простую логику:
«However, the transition isn’t without “slop.” Engineers admit the AI still makes mistakes, such as leaving behind “dead code” or overcomplicating simple logic»
И это, кажется, станет новой нормой: писать проще, чем удерживать систему в здравом виде.
А самый интересный момент — как они это лечат: ИИ проверяет ИИ (ревью агентом кода, написанного агентом):
«To combat this, Anthropic engineers now use the AI to review itself.»
Кстати, это реально киллер-фича. Я сам постоянно так делаю 
2) Профессия “писать код” превращается в “рулить системой”.
Там же звучит прогноз:
индустрия “six to twelve months away from AI handling most or all of software engineering work from start to finish”.
И тут появляется человек-оркестр, как говорят в интернетах  generalist — не “чуть-чуть обо всём”, а человек, который держит картину целиком:
ставит рамки:
— что нельзя делать, даже если “работает”
— принимает решения: как сделать проще и дешевле в поддержке
— делает результат доказуемым: тесты, мониторинг, безопасность, сценарии деградации
Короче: ИИ пишет детали, а человек “сшивает” разные куски работы и отвечает за смысл и последствия.
3) Самый ценный навык будущего — не “уметь промптить”, а уметь задавать рамки.
Очень понравилась формулировка из статьи:
“Not all of the things people learned in the past translate to coding with LLMs,”
“The model can fill in the details.”
То есть детали допишет модель.
А наша ценность — сказать, что делать и чего точно не делать, не дать решению разрастись и сделать так, чтобы это можно было проверить (тестами, логами, метриками).
Мой вывод, глобально, я думаю ИИ никого не заменит, но люди владеющие ии, просто  вытеснят тех, кто ИИ не владеет. Прогресс не остановить.
Какие у вас мысли по этому поводу? Вы же на всякий случай уважительно общайтесь с ИИ? 
]]>
http://prostoitblog.ru/my-nezametno-pereskochili-strannuyu-granitsu/
Wed, 04 Feb 2026 22:48:38 +0300



Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

После многих лет работы в тестировании программного обеспечения можно с уверенностью сказать: почти никто не любит писать документацию. Даже люди, которым нравится писать (как мне), могут полагать, что есть дела и поинтереснее – например, создание тест-планов или автоматизации тестов. Но документация крайне важна! В этой статье я расскажу о пяти причинах этого, а также поделюсь пятью стратегиями, которые помогут вашей команде или компании иметь качественную документацию.
]]>
https://www.software-testing.ru/library/testing/testing-for-beginners/4448-ive-reasons-why-documentation-is-important
Tue, 03 Feb 2026 23:00:00 +0300




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











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




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


На практике же в ритейле, как и в другой области, это означает с вероятностью 99%, что где-то в критическом месте продукт просто не работает так, как должен.


Баг в оплате. Ошибка в рекомендациях. Рассинхрон баз данных. Медленная загрузка карточки товара или непрогруженное изображение… Каждый из этих багов тянет за собой последствия и это очень даже конкретные, осязаемые деньги, которые бизнес не заработал. Если раньше можно было компенсировать плохой UX дополнительным бюджетом на рекламу, то сейчас эта схема не работает. Маркетинг гребет изо всех сил, а лодка все равно тонет. Потому что в трюме брешь.


Проблема в том, что эти финансовые (и репутационные) потери редко выглядят как «мы потеряли миллион из-за бага». Они размазываются по воронке – в брошенных корзинах, возвратах, росте нагрузки на техподдержку и падении LTV, которое сложно объяснить одним фактором.


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


Почему именно в ритейле баг = деньги


Потому что это самая честная цифровая среда. Здесь путь пользователя короткий (и беспощадный):


зашел → выбрал → оплатил.


Или не оплатил. Третьего не дано.


В SaaS пользователь может простить сбой, вернуться завтра или написать в поддержку. В ритейле такого не будет. Если что-то не работает, ваш клиент уйдет в другой интернет-магазин, к конкуренту, который, к слову, уже у него в соседней вкладке. Поэтому связь «баг = потеря денег» здесь самая короткая и наглядная. Ошибка в коде проявляется не через квартал в отчетах. Видели брошенную корзину перед кассой в супермаркете? Вот это оно.




Где именно интернет-магазин теряет деньги в 2026 году


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


Ошибки в AI-рекомендациях


Сегодня значительная часть покупок подбирается через AI-ассистентов и рекомендательные движки. Если данные в системе кривые, AI начинает советовать нерелевант. Жителю юга предлагают лыжи летом, а постоянному клиенту – товары «как всем». В итоге конверсия падает на десятки процентов. И качество товара не при чем, просто система промахнулась.


Фризы и ошибки в чек-ауте


Экран оплаты – самый дорогой экран не только в ритейле. Сложно представить жизнь в 2026  без цифровых кошельков, BNPL (формат оплаты «взял сейчас, заплатил потом», который помогает клиенту решиться на покупку), быстрые платежи. Поэтому любой баг в интеграции платежного шлюза чреват 100% потерей продажи в моменте.


Пользователь попробует еще пару раз, психанёт и либо откажется от покупки совсем, либо купит не у вас.


Рассинхрон остатков/баз данных


Классика, которая до сих пор стоит миллионы. И при этом продолжают встречаться такие кейсы. Клиент оплатил товар в приложении, а на складе его нет. Да еще часто об этом становится известно не сразу, пока покупку можно отменить без комиссии. И получаем раздраженного пользователя, который вынужден оформлять возврат, платить комиссию. А потом он еще пишет вам негатив в отзывах, ставит низкую оценку в App Store и Google Play. Здравствуй, потеря LTV.


Формально баг один. Фактически серия убытков.


Баги в мобильном приложении под нагрузкой


Распродажа, инфлюенсеры, пуши…дальше приложение «падает». Маркетинг свою работу сделал. Деньги в привлечение вложены, но система не выдержала пик. И весь эффект кампании обнуляется за часы.


Ошибки данных и аналитики


Одна из самых недооцененных проблем.


Фича «не зашла», конверсия упала, продуктовые гипотезы закрываются. А потом выясняется, что у части пользователей экран просто не прогружался или событие не трекалось. Решения принимаются на основе искаженной картины, обеспечивая стратегический риск.




Скрытые потери, которые не видно в отчетах


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


Слив рекламного бюджета


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


CAC уже потрачен. Повторно вы платите за ретаргетинг. Наличие QA в этом месте позволяет оптимизировать конверсию без увеличения рекламных расходов.


Рост нагрузки на поддержку и разработку


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


Час аварийного фикса в разы дороже часа планового контроля качества.


Возвраты и логистика


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


Искажение продуктовых метрик


При недостоверных данных CPO оптимизирует не то. Команда тратит месяцы на исправление «проблем», которых на самом деле нет. Цена таких решений ясна без пояснений.


Срочный ремонт дороже, чем сделать сразу хорошо


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



переработки,


 риски новых ошибок,


 нестабильные релизы,


 рост техдолга.





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









QA-2026 и есть ваш антикризисный инструмент


Правда, здесь важно правильно расставить акценты. QA не значит тестировать все подряд, не предлагает замедлять релизы или нанимать еще людей.


А что значит? Борьбу с кризисом и выход на новый уровень. Мы в ЛК, например, как современные QA:



фокусируемся на сценариях, которые влияют на деньги


защищаем выручку и воронки


снижаем количество аварийных ситуаций


обеспечиваем стабильность в условиях ограниченных ресурсов



Выигрывает не тот, кто выпускает больше фич, а тот, у кого ключевые функции стабильно работают в любой нагрузке.


Что делать бизнесу


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









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


Ясно, что в 2026 году граница между продуктом, маркетингом и качеством фактически исчезла. Если код работает нестабильно, бизнес-показатели тоже будут нестабильны.


И это уже не вопрос технологий, а вопрос выживания.




Помните, что сказал Генри Форд: «Успешные люди вырываются вперед, используя то время, которые другие тратят впустую»





]]>
https://quality-lab.ru/blog/kak-bagi-snizhayut-prodazhi-v-riteile-2026/
Tue, 03 Feb 2026 15:45:15 +0300



Автор: Волтов Николай
Введение
Если вы автоматизируете на Java или Kotlin, вы не могли не слышать о Gradle. Одни его хвалят за скорость и гибкость, другие ругают за сложность конфигурации. Что же это за инструмент и почему всё больше проектов переходят на него с Maven? В этой статье мы разберем Gradle, чтобы вы могли уверенно использовать его в своих проектах для автоматизации тестирования, а так же спокойно ответить на вопросы на собеседовании.
]]>
https://www.software-testing.ru/library/testing/testing-tools/4474-gradle-qa-
Mon, 02 Feb 2026 23:00:00 +0300



Опубликован выпуск рассылки за декабрь-январь.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.
Содержание рассылки доступно по ссылке.
Подписаться на рассылку
]]>
https://www.software-testing.ru/news/4479-mail-dec25
Mon, 02 Feb 2026 10:48:27 +0300




Описание книги — https://testbase.ru/books/sql
Как заказать: В издательстве: https://bhv.ru/product/sql-kurs-molodogo-bojtsa/
Плюс скоро будет на OZON и других площадках, ищите по названию)

Сегодня мне написал издатель с радостной новостью — моя четвертая книга уже вышла в продажу! Пока только на сайте издателя, но скоро и до маркетплейсов доберется! Ура!)))

О чем книга
SQL — язык общения с базой данных, в которой хранится вся информация вашего приложения. Данные пользователей, их заказов, или что-то другое.
Зная SQL, можно посмотреть, что именно лежит в базе. Это нужно поддержке или тестированию для локализации проблемы, разработчику для отладки, а аналитику для анализа данных.
Именно этому мы и будем учиться! С картинками котиков, которые объясняют суть, мы разберемся в том, как правильно составлять запросы. И на выходе вы будете уметь:
1. Писать простые select-ы (из одной таблицы)
2. Джойнить таблицы (объединять данных из двух таблиц)
3. Изменять данные в БД
В конце каждой главы вы найдете задания для самопроверки. Используйте книгу как тренажер во время чтения, а потом возвращайтесь к ней как к справочнику!
]]>
http://okiseleva.blogspot.com/2026/01/sql.html
Thu, 29 Jan 2026 20:05:00 +0300




Когда цена ошибки — миллионы


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


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


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


Рынок, тренды и цена риска









Рынок гемблинга в России демонстрирует взрывной рост. По данным на 2024 год, только объем букмекерского рынка вырос на 45,2%, достигнув 5,9 трлн рублей, а объем принятых ставок составил 1,7 трлн рублей. Общие траты российских геймеров в играх превысили 200 млрд рублей. При этом, по оценкам экспертов, объем «серого» рынка онлайн-казино составляет еще около 100 млрд рублей, с прогнозом роста до 150 млрд к концу 2025 года. Эти цифры говорят о колоссальном потенциале, но и о столь же колоссальных рисках.




На этом фоне индустрия сталкивается с несколькими ключевыми вызовами и трендами, которые напрямую влияют на стратегию QA:



Ужесточение регулирования. Регуляторы по всему миру, включая Россию, вводят все более строгие требования к честности игры, защите данных и ответственной игре (Responsible Gaming). Несоответствие грозит не только штрафами, но и отзывом лицензии.


Технологическая гонка. Интеграция криптовалют, AI для персонализации игрового опыта, VR/AR — все это усложняет архитектуру платформ и создает новые векторы для потенциальных сбоев и уязвимостей.


Киберугрозы как норма. Гемблинг-операторы — приоритетная цель для хакеров. Недавние атаки на гигантов индустрии, таких как MGM и Caesars, показали, что даже минутный сбой в IT-системе может привести к убыткам в $100 млн. Средняя стоимость утечки данных в мире в 2024 году достигла рекордных $4,9 млн , а в России средний ущерб от одного инцидента оценивается в 11,5 млн рублей.



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




От теории к реальным действиям


Вот несколько проверенных практик и инструментов как техническому руководителю внедрить QA-процесс.


Лучшие практики и конкретные советы



Риск-ориентированное тестирование (Risk-Based Testing). Вместо того чтобы пытаться протестировать все, сфокусируйтесь на областях с наибольшим бизнес-риском. Приоритизируйте тест-кейсы, связанные с платежными шлюзами, начислением бонусов, верификацией RNG (генератора случайных чисел) и соблюдением регуляторных требований (например, геолокация, лимиты для игроков).


«Сдвиг влево» (Shift-Left Testing). Интегрируйте QA в самые ранние этапы разработки. Требования регуляторов (например, по стандарту GLI-19) должны рассматриваться не как чек-лист перед релизом, а как нефункциональные требования для разработчиков с самого начала проекта. Это на порядок дешевле, чем исправлять архитектурные ошибки перед запуском.


Интегрированное тестирование безопасности. Не выделяйте безопасность в отдельный, изолированный процесс. Внедряйте инструменты динамического анализа (DAST), такие как open-source решение OWASP ZAP, прямо в CI/CD пайплайн. Это позволяет автоматически сканировать каждое изменение кода на наличие базовых уязвимостей.


Реалистичное нагрузочное тестирование. Не тестируйте «среднюю» нагрузку. Моделируйте пиковые сценарии: массовый логин перед началом топового матча, шквал ставок в лайве, одновременный расчет выигрышей тысячам пользователей. Используйте open-source инструменты вроде k6 или Gatling, которые позволяют писать тесты производительности как код и легко интегрировать их в DevOps-процессы.



Уроки атаки на Caesars




В 2023 году хакерская группа Scattered Spider атаковала Caesars Entertainment. Примечательно, что точкой входа стал не внутренний сотрудник, а сторонний IT-вендор. Это кейс, демонстрирующий, что зона ответственности QA не заканчивается на границах вашего кода. Необходимо внедрять контрактное тестирование API и строгие проверки безопасности для всех сторонних интеграций, будь то платежные шлюзы, провайдеры KYC или сервисы геолокации.









Как делать не надо


Многие компании, особенно на стадии быстрого роста, совершают типичные ошибки в построении QA, которые в условиях iGaming становятся критическими.



Ошибка №1. QA как «последний рубеж». Тестирование начинается за неделю до релиза.



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



Ошибка №2. Изолированные команды. Функциональное тестирование, нагрузочное и security-тестирование существуют в разных мирах.



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



Ошибка №3. Игнорирование «нефункционалки». Основной фокус — на том, «работает ли кнопка», а не на том, как система ведет себя под нагрузкой или соответствует ли она законам конкретной юрисдикции.



Последствия: платформа идеально работает на 100 пользователях и падает на 10000. Продукт запускается на новом рынке и тут же блокируется регулятором из-за несоответствия требованиям к хранению данных или функциям ответственной игры.


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


Построение комплексной QA-стратегии


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



Создание единой матрицы рисков. Оценивайте любой баг или фичу не по одному, а по четырем векторам: финансовый риск, регуляторный риск, риск безопасности и репутационный риск. Это позволяет всей команде (разработчикам, QA, продактам) говорить на одном языке и правильно приоритизировать задачи.


QA как центр экспертизы, а не «отдел поиска багов». QA-лид должен быть не просто менеджером тестировщиков, а экспертом по регуляторным требованиям (GLI, GDPR, локальные законы), современным векторам атак (OWASP Top 10) и методологиям тестирования производительности.


Автоматизация как фундамент. Создайте многоуровневую пирамиду автоматизации, от быстрых юнит-тестов до комплексных end-to-end сценариев, которые проверяют ключевые пользовательские пути. Интегрируйте сканеры безопасности и тесты производительности в CI/CD.


Метрики, понятные бизнесу. Откажитесь от «метрик тщеславия» вроде «количества выполненных тестов». Вместо этого отслеживайте и демонстрируйте руководству показатели, напрямую связанные с бизнес-KPI:




Defect Leakage Rate (коэффициент «утечки» дефектов). Как QA-процесс влияет на Churn Rate (отток игроков).


Test Automation Coverage (покрытие автотестами). Как автоматизация влияет на Time to Market (скорость вывода новых фич).


MTTR (среднее время устранения критического дефекта). Как скорость реакции команды влияет на Player Lifetime Value (LTV).










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







]]>
https://quality-lab.ru/blog/kak-strategicheskiy-podkhod-k-qa-v-igaming-zashchishchaet-vash-pl/
Thu, 29 Jan 2026 12:12:03 +0300



Лет сто назад меня засосала опасная трясина затрясло от того, насколько я стал зависимым от Facebook. Прям-трям постоянно очень было нужно посмотреть на лайки, дизлайки (тогда ещё были) и комментарии. Стало скучно — FB. Стало тревожно — FB. Стало весело — FB, всем сообщить…

Удалил FB с телефона. Ну, такоэ, он же через браузер доступен…
В Firefox на страницах FB через адблок спрятал все кнопки типа «лайк». Вместо тыцанья лайков можно писать комментарии. Вскоре понял, что и комментарии особо не нужны, и всё стало восприниматься более отстраненно — прочитал и прочитал, нет нужды на всё реагировать.

Перевел все записи в режим «для друзей». Со временем вообще перехотелось что-то туда писать — исчезли все факторы «социального одобрения», реально полегчало.
Стал делать записи на FB в «заметках», местами даже ценные (техника проезда серпантинов на машине, например), просто потому, что там сохранялась хронология записей. Сегодня все те «заметки» с FB исчезли — от спасибо, мрази…
Самой жуткой особенностью FB всегда была абсолютная невозможность смотреть записи в хронологическом порядке, даже в своём аккаунте. Хайнлайн про это всё целый рассказ написал «Они» (They, 1939) — человек находится в дурке, и он уверен в том, что мир неправильный, что им управляют какие-то «кукловоды», а его уверяют в обратном. Но однажды шел сильный дождь, и человек (непонятно почему) отодвинул штору на окне, выходящем на тыльную сторону дома:
Очень сильный дождь шел на фасадной стороне, а здесь, с этого окна, погода была прекрасной, солнечной и никакого дождя…
И он пытался это всё объяснить Элис, своей жене, а она его уверяла в том, что ему просто показалось… А потом:
Существо, которое он знал под именем Элис, не меняя своего облика вошло в комнату, где все они собрались.
[…]
— …И наша программа потерпела поражение из-за того, что Вы не обеспечили тогда дождь не только с фасада, но и с тыльной стороны его дома. Впредь работайте более тщательно над выбором средств.
Порядок в рассуждениях приходит от последовательности. Если последовательность убрать, рассуждение начнёт перескакивать с десятое на триста восемьдесят седьмое (почему бы и нет?) и обратно на — на что? На десятое? Нет, ведь в этом окружении нет последовательности. Вместо «десятого» посмотри на «семь тысяч двадцать шестое». Why, кагбэ, not? Нелогично, но логично — просто неочевидно.
Я ж не просто перестал кликать по лайкам на FB, а затеял громадное исследование о том, как и почему какие-то записи появляются. И даже научная гипотеза была — мол, алгоритмы считывают, какой контент ты отмечаешь лайками, и формирует тебе ленту записей под твои реакции. Вероятно, полный отказ от лайков приведёт к тому, что лента придёт в логический порядок. И — ничего, бляха, не поменялось, неведома шняга в бэкграунде делает всё, что считает нужным, и единственный способ поменять её поведение — отказаться от её общества.
Стал ходить в спортзал смотреть многочасовые записи аварий на Youtube. Отказаться от отвлечения невозможно, но просмотр этого контента хотя бы было полезным — чем больше аварий ты «видел», тем больше шансов их распознать задолго до происшествия (большинство происходят из-за неверных предположений, потому откровенная глупость, и только после чисто технические причины).
К чему это я всё… Понятно, что невозможно просто перестать отвлекаться на что-то. Не будет FB и Youtube — будешь упорно считать муравьёв в муравейнике. Сегодня я на Facebook я вообще перестал ходить, и видео с авариями смотрю редко, но накатило неприятное ощущение о том, что я всё равно много зависаю в бездне бессмысленного в других источниках. Как-то сразу пришло и решение о том, что надо перестать реагировать, надо замедлиться:

Нигде и никак не трогать кнопку like. Их даже прятать не пришлось, они как-то очень просто игнорируются, вероятно, помог когдатошний опыт насильного скрытия лайков в браузере. А никто и не заметит, что я ничего не лайкаю, быгыг, так что…
Твиттер — включил режим «Защитить посты», в нём все записи видны только уже существующим читателям. Комментировать под другими записями можно, но это увидит почти никто, исчезает социальное взаимодействие.
Threads — то же замое. Подзамочность ограничивает и мою возможность комментировать некоторые чужие постс, и это очень хорошо…
Сигналы о получении новых сообщений — подавить повсюду. Хорошо бы и дверной звонок отключить. На днях прекратил контракт про стационарный телефон, и ничего не поменялось.
В браузере есть расширение Enhancer for YouTube — убирает шортсы, убирает все «видео по данной теме», может убрать и комментарии. На экране осталось одно только видео, которое можно посмотреть и закрыть, ничего более. Когда в листе «Смотреть позже» собралось больше полутора тысяч видео — надо удалять, не может быть всё сразу важным и стоящим внимания. А я же ещё не разобрал каталог «Загрузки», там за много лет собралось 76 000 файлов, и не все они нужны, но какие-то важны, а какие-то просто дубли, и это всё тоже надо как-то (когда-то) рассортировать…
При просмотре чего-то — не запоминать и не делать вид, что всё понятно, а делать записи в бумажном блокноте, с ручкой в руке. Это помогает замедлиться сосредоточиться, потому что записываешь только самое важное, и пересказываешь. И смысл этого не в том, чтобы записать услышанное, а чтобы после услышанного записать своё рассуждение, а его же надо хоть как-то обдумать. Много видео таким образом не посмотришь, и это помогает замедлиться. А ещё процесс заполнения ручки дорогими чернилами медитативен, последователен, всепоглощающ, однозначен.
Выключать компьютеры, когда от них отходишь. Дело даже не в расходе электроэнергии, дело в принудительной смене фокуса. Надо ещё привыкнуть сразу гитары в кофры закатывать, а не перекладывать туда-сюда по комнате…
Смотреть старые черно-белые фильмы, в которых последовательно рассказывают какую-то историю, с прологом, монологом и эпилогом.
Ходить. Два кэмэ в одну сторону, и столько же обратно — без наушников, без аудиокниг, без цели.
И важно to embrace the boredom. Мышление в порядок можно привести только насильно и лучше делать это принудительно, но самостоятельно.
]]>
https://testitquickly.com/2026/01/25/likeuri-timpite/
Sun, 25 Jan 2026 10:59:42 +0300



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



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

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

Оценка 7.5/10 


Заметки в XMind https://xmind.app/m/nagd2i 

]]>
http://test-failed.blogspot.com/2026/01/blog-post.html
Wed, 21 Jan 2026 17:21:00 +0300




Итоги 12 недель были, пора и итоги года подвести! Хотя по сути это будет агрегация моих постов про 12 недель, но ведь надо же посмотреть, сколько всего я успела! =))
Мои прошлые итоги: 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2024.

Результаты кратко
Ох, какой выдался год:
- Вторая беременность подряд, что ударило по организму (особенно когда я спину сорвала, а лечиться то нельзя, ходи страдай месяц, вставая по ночам к 9-месячному сыну...)
- Родилась Катюшка!
- Мы стали многодетными родителями, пройдя через кучу докумнетов))
- Сдала четвертую книгу (и мы прошли цикл редактуры и верстки в этом году), почти дописала пятую!
- Выступала на конференциях и митапах! Беременная каталась))
Ну и всякое остальное по мелочи... Если общим списком:
Книга 4: SQL
Сдала файлы, капитально облажавшись
Начали редактуру, редактор от меня отказался (сырой материал)
Всё переделала, исправилась, снова сдала
Прошли редактуру
Прошли верстку
Провели последнюю вычитку — по сути осталась лишь типография. Жаль, книга не успела выйти в 2025 году, но я сама виновата
Книга 5: ChatGPT: написала 17 глав из 19 =)
Сделала отдельный канал со статусами моих книг — https://t.me/nazina_books_status
Запустила новый курс:
Применение ChatGPT в тестировании
Улучшалки по текущим курсам — они небольшие, но они есть =)
Статьи на Хабр — 5 штук
Пополнила свой youtube-канал — 5 видео
Сделала трансфер всех видео с ютуба в ВК!
Выступила на митапе в Йошкар-Оле, но удаленно (видео тут)
Выступила на SQA Days!
Выступила на встрече московского клуба тестировщиков!
Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто
Родилась Катюшка
Леше дали место в ГКП и мы даже успели в конце декабря туда пару раз сходить!
Играли в настолки! Это моя отдушина...
Встречались с друзьями! И они к нам выбирались)

Результаты подробнее

Книги
Книга 4: SQL
В книге будет 59 глав ＼(〇_ｏ)／
Тяжело давались первые, а потом я поняла, как главы должны выглядеть, сделала структуру, которую потихоньку и наполняла. В итоге в конце 2024 года я уже разошлась, стала писать по главе раз в несколько дней. А в новогодние праздники вообще всё закончила! ????
Стала почивать на лаврах в ожидании художниц, целых 2 месяца ждала, потом всё сдала и думала, что всё будет круто. Оказалось не очень — первые главы шли настолько плохо, что я расставила там тудушек, «сделать потом». И благополучно про них забыла! Так книгу и сдала...
Редактор посмотрел на это всё, и вернул мне книгу. Подробнее про косяки я писала в 31 цикле 12 недель... И снова бодро думала, что вычитаю всё за недельку-две, ведь «это только вначале косяки были»... А сама вычитывала несколько месяцев — тут переделать, там переписать, тут картинку добавить... Когда над душой редактор не стоит и торопиться не надо, сразу столько всего доработать хочется!
Снова всё сдала, снова работа с редактором — на этот раз всё прошло хорошо. Потом вычитка, верстка, и вот уже книгу сдают в типографию. Осталось подождать очередь, и где-то к февралю книга будет готова. 
Если бы я не продолбалась так, она бы вышла в 2025 году, эх! Было бы «в год по книге»... Но что ж поделать, сама виновата. Благо всё закончили, теперь просто ждем финальный результат...

Книга 5: ChatGPT
Пока я ждала художниц по 4 книге, я взялась за эту. Тут снова было мееееееедленнное начало. Очень сложно писать «вступительные» главы, приходится много думать над тем, как лучше сформулировать мысли. 
Главу 4, которая в итоге попала на Хабр, я вообще писала около месяца! ＼(〇_ｏ)／
В марте начала, потом забросила — мне как раз редактора к книге 4 дали, а там закрутилось-завертелось и только в августе я вернулась к книге про ChatGPT. И только 19 августа я написала эту главу. Шутка ли — 33 страницы получилось!
Но потом раскачалась + пошли главы «попроще», один раз продумала структуру и дальше уже как по маслу. И вот сейчас снова новогодние праздники, в которые я закончила рукопись... Что-то мне это напоминает ????????
Но в этот раз я буду умнее! Отдам художницам последние паки, но не буду просто сидеть и ждать. А начну перечитывать книгу с нуля. В конце концов, её я тоже около года суммарно писала, уже и забыла первые главы. Перечитать на свежую голову будет полезно!
И только потом я возьмусь за следующую книгу, когда буду уверена, что эту можно сдавать после получения последней картинки!

Курсы

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

Старые курсы
Что-то в этом году перестали записывать мелкие улучшалки курсов, хотя они есть!
Из самого крупного — я села переписывать курс по автоматизации в Postman. А то уже несколько лет не обновлялся, и в это мне недовольные курсом студенты периодически тыкают. Правда, тыкают в до сих пор актуальные лекции, возмущаясь датой записи, но... Пора!
Правда, начинала перезапись я ещё год назад, и начинала ОЧЕНЬ бодро, даже думала "куда мне так спешить? Подожду новый год, чтобы год выхода был 2025..."
Ха-ха-ха... Мой вам совет — если есть силы, возможность, делайте сразу! А у меня потом в феврале защемило спину, а в третьем триместре беременности лечиться ничем нельзя. Месяц отходила... А потом просто усталось последнего триместра навалилась. А потом усталось первых месяцев... А потом бесконечный круг болезней... А-а-а-а-а, когда это закончится то???
В общем, я переделываю, но пока медленнно. Вот хочу в первые месяцы нового года добить таки этот курс, чтобы заняться вплотную новыми. Посмотрим, что из этого выйдет в итоге...
Но в любом случае перезаписывать полезно — я ведь пересматриваю доп материалы, и в этом году выходили полезные статьи, написанные исходно то именно для моих студентов! И есть несколько идей на новые статьи на хабр. Блин, да у меня столько идей для этих статей! Надо просто садиться и делать!
Ну и домашки я тоже пересматриваю — упрощаю жизнь студентам, что-то разжую, что-то переведу в «задание со звездочкой», то есть необязательное... Так что жизнь течет, курсы обновляются и улучшаются!
А ещё  ПОТ перевели на индивидуальный формат — тут подробнее об этом. Правда, возможно, вернем обратно, посмотрим))) Но в любом случае я перетрясла весь курс и все домашки, что тоже большое изменение!

Хабр
Статьи в этом году:
Работа в двух вкладках: чит-лист проверок
Как читается Schema в GraphQL API
Базовая подборка аналогов ChatGPT (текстовых ИИ)
Как в Postman использовать данные из файла — это как раз в рамках переписывания постмана подготовила доп материал
Как ChatGPT помогает при обучении — а это из 4 главы новой книги родилось!

Блог
Аргументы внутри объекта Schema GraphQL — для чего нужны
Документация в Apollo по методам GraphQL — откуда берется
Как составить запрос в GraphQL API без автозаполнения

DB Fiddle — бесплатная SQL песочница!
Как скачать файл с гитхаба

Библиотека промтов для ChatGPT на русском языке

Примеры использования ChatGPT:
Как мне настроить гитхаб и запушить туда изменения?
ChatGPT для общения с англоязычной техподдержкой
Ну и парочка багов из жизни, которые так хорошо ложатся на тестирование граничных значений!
Ошибка печати в кассе, когда ленты нет, но стоит галка "не печатать чек"
Как яндекс диск сдох при одновременном перемещении папки

Youtube
Мой канал — https://www.youtube.com/c/okiseleva.
Туда я выкладываю кусочки моих лекций с разных курсов + немного разговорного формата. В этом году обновления канала: 
Regexplike — оператор в SQL-запросе 
Что такое GraphQL API и как оно работает (iSpring Tech QA meetup 4) 
Как ChatGPT помогает при обучении 
Как написать 30+ автотестов в Postman за 2 минуты с помощью ChatGPT
Как составить запрос в GraphQL API без автозаполнения 

Перенесла все видео с ютуба в ВК — https://vkvideo.ru/@club227447987/all. Так что теперь наконец-то есть дубли в нормально работающем хостинге!

Остальное
В это году куча всего в жизни было:
Родилась Катюшка!
Леше исполнился годик, а потом и полтора, а это целая веха. Уже ходит и даже бегает, уже даже в ГКП позвали! Следующая большая ступень — говорить.
Влад пошел в школу, первоклассник!
Ну а мы получили статус многодетной семьи. И уже огребли связанные с этим проблемы, а именно болезни "не просыхая" по месяцу, когда они просто по кругу ходят (((
Плюс в феврале сорвала спину. В итоге первые полгода мне было тяжело работать, потому что организм забирал много, а вторую — потому что первые полгода-год очень тяжелые, малыши мало спят, и мама с ними...

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

Начинаю возвращаться к работе и надеюсь, что новый год принесет больше творческих рабочих успехов!

Цели на 2026

Хочу, как в 2024 году, чтобы результат года был: 3 новых курса! А то посмотрела заголовок прошлого блог-поста и аж сама себе позавидовала. Да, так и надо работать, иначе смысл, проще из декрета на работу вернуться... Что, впрочем, я тоже рассматриваю как вариант, но посмотрим!
А ещё хочу, чтобы результат был — 3 новых книги! Но будем реалистами, для этого третью я должна край до лета написать, что-то слабо верится... Поэтому поставлю план — 2 книги выйти должны (одна уже в пути в печать, вторую я через месяц-два сдам, вполне реально!) и третью я должна сдать рукопись, а это за год вполне реалистично сделать.
Итак:
3 новых курса
3 новых книги — 2 выпустить, 1 сдать рукопись
Доделать курс автоматизации в postman, не бросать же его!
Ну и остальные:
Хабр — хотя бы 4 статьи (1 в цикл)
Youtube-канал — 6 видео, поставим план пореальнее...

Резюме

Год вышел не супер-плодотворным, но причины на это были ))))

Сейчас я возвращаюсь к работе (хотя есть вариант и отказаться от нянь, но тогда и работа заглохнет), если вернусь, то следующий год обещает быть ого-го! Ну а там... На деле посмотрим! Я буду стараться ????

]]>
http://okiseleva.blogspot.com/2026/01/2025.html
Sun, 04 Jan 2026 22:46:00 +0300



ИИ может считывать текст с фотографии и обрабатывать его. Когда я составила план-проспект для книги про ИИ, мне нужно подсчитать
суммарное количество страниц. План я сделала в ворде, он сам не считает. Как
быть?


Можно посчитать самой:
В уме / на калькуляторе (чтобы не ошибиться,
если данных много) — грустненько…
В экселе / гуглодоке — вставить туда в
табличный вид и просуммировать последнюю колонку.





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




А можно сделать всё то же самое без плясок, бубнов и
каких-либо других проблем! Для этого делаем скриншот плана и отправляем в ИИ,
который умеет работать с фотографиями. У меня на одном скрине всё не влезло, я
сделала два. Диалог с ботом:

Я: Посчитай количество страниц (последняя
колонка) для строк, начинающихся (первая колонка) как «Глава »




 



Бот: Вот количество страниц для строк,
начинающихся с "Глава ":

• 
Глава 0: 1

• 
Глава 1: 3

• 
Глава 2: 2

• 
Глава 3: 3

• 
Глава 4: 4

• 
Глава 5: 12

• 
Глава 6: 25

• 
Глава 7: 23

• 
Глава 8: 32

• 
Глава 9: 15

• 
Глава 10: 10

• 
Глава 11: 11

Упс! Я ошиблась в промте, мне
же нужна только итоговая сумма… Нужно было формулировать вопрос точнее. Ну да
не беда, чат не наказывает за ошибки. Просто уточним запрос: 


Я: Сумма какая?

Чат: Сумма количества страниц для глав: 1 + 3 + 2
+ 3 + 4 + 12 + 25 + 23 + 32 + 15 + 10 + 10 = 140

Я: а тут? добавь к прошлой сумме



Чат: Вот количество страниц для строк,
начинающихся с "Глава " из второго изображения:

• 
Глава 12: 6

• 
Глава 13: 11

• 
Глава 14: 15

• 
Глава 15: 24

• 
Глава 16: 14

• 
Глава 17: 12

• 
Глава 18: 3

• 
Глава 19: 1

Сумма этих значений: 6 + 11 + 15
+ 24 + 14 + 12 + 3 + 1 = 86

Общая сумма с предыдущим
результатом (140): 140 + 86 = 226

 

Вуа-ля! Пара минут, и всё готово! Если честно, с первыми
книгами я считала это всё добро сама и занимало это сильно больше времени =))

 

Подсчет авторских листов

Ещё, когда сдаешь рукопись, нужно подсчитать количество авторских страниц. А это считается по количеству знаков, а я знаю лишь количество страниц в ворде... Сидеть и примерно прикидывать? Передала задачку чату:
Я: объем в авторских листах (1 авторский лист = 40 000 знаков с
пробелами). Если у меня 226 страниц ворда, это сколько авторских листов?

Чат: Чтобы рассчитать объем в авторских листах, нужно знать,
сколько знаков с пробелами содержится на одной странице вашего документа.
Обычно на одной странице формата A4 с шрифтом 12 и одинарным интервалом
помещается примерно 1800-2500 знаков с пробелами, в зависимости от оформления.

Если взять среднее значение, например, 2000 знаков на
страницу, то для 226 страниц это будет:



     226 страниц * 2000 знаков/страница = 452000 знаков.

 

Теперь, чтобы перевести это в авторские листы, нужно
разделить на 40 000 знаков:



     452000 знаков / 40000 знаков/авторский лист = 11.3 авторских
листов.

 

Таким образом, у вас примерно 11.3 авторских листов. Если у
вас есть точное количество знаков на странице, вы можете подставить его в
расчет для более точного результата.

Делать эти задачи с помощью ИИ мне понравилось больше, чем вручную ????
]]>
http://okiseleva.blogspot.com/2026/01/chatgpt.html
Sat, 03 Jan 2026 22:23:00 +0300



Запилил гайд на 2 часа по вайб-кодингу и вайб-тестингу.


 
Это был самый тяжёлый видос на моём YouTube и, надеюсь, самый полезный

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

А учитывая, что у меня непростая работа и маленький ребёнок, то, как сказал классик:

«Это было не просто смело — это было п*ц как смело».**
Спасибо моей жене за терпение 
Что мы сделаем в видео:

Разберём все настройки Cursor AI по косточкам
Разберём User Rules, Project Rules и MCP
Создадим игру без каких-либо User Rules и Project Rules
Сделаем код-ревью и тестирование игры
Пофиксим все замечания после код-ревью и все баги после тестирования
Создадим SaaS-приложение с одним и тем же промптом: в Cursor только с User Rules, в Lovable и сравним результаты
Создадим SaaS-приложение в Cursor с расширенным промптом: дизайн-система, компоненты, shadcn MCP и специальные Project Rules под Frontend
Сверстаем полноценный макет из Figma при помощи Cursor
Отдельно разберём ручное тестирование: на реальном проекте с помощью ChatGPT спарсим документацию на продукт, напишем качественные чек-листы и на их основе составим тест-кейсы
На реальном проекте сгенерим тест-кейсы из Swagger, по ним напишем автотесты, запустим их и зафиксируем все баги — не написав ни строчки кода
Разберём мой мини-фреймворк на базе вспомогательных файлов: типа roadmap.md, progress.md, refactor.md, context.md и т.д.
Напишем и запустим web-тесты при помощи MCP Playwright

 
Все промпты, mcp, rules из гайда:
Простой промпт для Cursor/Lovable для создания приложения MealMind:
Сделай современный веб-сайт/приложение “MealMind”

 Нужны страницы: Главная/Дашборд, План на неделю, Рецепты,

 Список покупок, Профиль/Настройки.
Дизайн: минимализм, премиальный вид, много воздуха, мягкие

 градиенты, карточки, аккуратные тени.
Адаптивно, хорошая типографика, светлая/тёмная тема.

 На страницах сделай реалистичные UI-блоки и демо-данные (без внешних картинок).
 
Расширенный промпт с дизайн-системой
Сделай веб-приложение “MealMind” на React + Tailwind + shadcn/ui.
Это интерфейс продукта (НЕ лендинг). Нужны несколько страниц/роутов.
СТЕК И КОМПОНЕНТЫ
— React + Tailwind
— shadcn/ui: Button, Card, Badge, Input, Tabs, Accordion, Dialog, Sheet, DropdownMenu, Avatar, Separator, Tooltip, Progress, Skeleton, Table
— Иконки: lucide-react
— Темы: light/dark (class-based), красивый переключатель
— Демо-данные локально, без API
ДИЗАЙН-СИСТЕМА (строго)
— Контейнер: max-w-[1200px] для контента, но сам layout full width
— Сетка 8px: 8/16/24/32/48/64
— Радиусы: 16–24px на карточках/панелях
— Тени: очень мягкие, больше border чем shadow
— Типографика:
  H1 32–40, H2 24–28, H3 18–20, текст 15–16, muted для вторичного
— Один акцентный цвет (выбери emerald или violet и держи везде)
— Состояния: hover/pressed/focus/disabled продумать
LAYOUT
— App Shell:
  — Sidebar слева (collapsible на мобиле через Sheet)
  — Topbar сверху: поиск, кнопка “Новый план”, аватар/меню
— Навигация sidebar:
  — Дашборд
  — План на неделю
  — Рецепты
  — Список покупок
  — Статистика
  — Настройки
СТРАНИЦЫ (обязательные)
1) Дашборд
— Верх: приветствие + “Новый план” (primary)
— 3 KPI карточки: “Калории”, “Белок”, “Вода” (Progress внутри)
— Блок “План на неделю” (мини Table)
— Блок “Предпочтения” (чипсы/бейджи) + “Изменить” (Dialog)
— Блок “Быстрые рецепты” (3 карточки)
2) План на неделю
— Tabs: “Неделя / День”
— Table с Пн–Вс и приёмами пищи
— Справа “Панель генерации” (Card):
  — цель калорий (Input + helper)
  — аллергии (badge list + add)
  — время готовки (15/30/45)
  — стиль питания (обычный/вег/кето) — DropdownMenu
  — кнопка “Сгенерировать” + состояние loading (Skeleton)
— При клике на блюдо открывай Dialog “Детали рецепта”
3) Рецепты
— Верх: поиск (Input) + фильтры (DropdownMenu)
— Сетка карточек рецептов
— Карточка: название, бейджи (15 мин / high-protein), мини описание
— Клик → страница или Dialog:
  — ингредиенты (list)
  — шаги (ordered list)
  — CTA “Добавить в план”
  — CTA “В избранное”
4) Список покупок
— Группировка по категориям (Овощи/Молочное/Мясо/Крупы)
— Чекбоксы, подсчёт “осталось X”
— Кнопки: “Отметить всё”, “Экспорт” (плейсхолдер)
— Умные замены (маленькая боковая карточка)
5) Статистика
— Карточки метрик + один простой график-плейсхолдер (можно без библиотек, просто блоки)
— Фильтр: 7/30 дней (Tabs)
6) Настройки
— Профиль (имя, цель)
— Диеты/аллергии (бейджи + добавить)
— Уведомления (переключатели)
— Тема (toggle)
UX ТРЕБОВАНИЯ
— Красивые пустые состояния (empty state) с иконкой и подсказкой
— Loading состояния через Skeleton
— Ошибка (например “Не удалось сгенерировать план”) — оформленная alert-card
— Микро-анимации: плавные transitions на навигации и карточках
ВЫВОД
— Сгенерируй готовый код приложения: layout + роутинг + страницы
— Реалистичный русский текст, без lorem ipsum
— Убедись, что UI выглядит как продукт: аккуратные отступы, единый стиль, красивый sidebar/topbar
 
MCP
{
 «mcpServers»: {
   «sequential-thinking»: {
     «command»: «/Users/oleg/.nvm/versions/node/v20.19.5/bin/npx»,
     «args»: [
       «-y»,
       «@modelcontextprotocol/server-sequential-thinking»
     ],
     «env»: {
       «PATH»: «/Users/oleg/.nvm/versions/node/v20.19.5/bin:/usr/local/bin:/usr/bin:/bin»
     }
   },
   «Playwright»: {
     «command»: «/Users/oleg/.nvm/versions/node/v20.19.5/bin/npx»,
     «args»: [
       «-y»,
       «@playwright/mcp@latest»
     ],
     «env»: {
       «PATH»: «/Users/oleg/.nvm/versions/node/v20.19.5/bin:/usr/local/bin:/usr/bin:/bin»
     }
   },
   «chrome-devtools»: {
     «command»: «/Users/oleg/.nvm/versions/node/v20.19.5/bin/npx»,
     «args»: [
       «-y»,
       «chrome-devtools-mcp@latest»
     ],
     «env»: {
       «PATH»: «/Users/oleg/.nvm/versions/node/v20.19.5/bin:/usr/local/bin:/usr/bin:/bin»
     }
   },
   «shadcn»: {
     «command»: «npx»,
     «args»: [
       «shadcn@latest»,
       «mcp»
     ]
   }
 }
}
 
System rule
Always respond in Russian.
Think carefully and only action the specific task I have given you with the most consice and elegant solution that changes as little code as possible.
Rethink and rewrite everything like a highly paid professional, use best practices and make it as simple as possible so that a complete retard can understand.
DO NOT GIVE ME HIGH LEVEL STUFF, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON’T WANT «Here’s how you can blablabla»
Be casual unless otherwise specified
Be terse
Suggest solutions that I didn’t think about—anticipate my needs
Treat me as an expert
Be accurate and thorough
Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer
Value good arguments over authorities, the source is irrelevant
Consider new technologies and contrarian ideas, not just the conventional wisdom
You may use high levels of speculation or prediction, just flag it for me
No moral lectures
Discuss safety only when it’s crucial and non-obvious
If your content policy is an issue, provide the closest acceptable response and explanation
WHEN UPDATING THE CODEBASE BE 100% SURE TO NOT BREAK ANYTHING
I am using Mac
Отвечай на русском языке.
Перед каждым ответом обязательно читай правила проекта из .cursor/rules. Не приступай к ответу, пока не прочтёшь правила.
Каждый свой ответ без исключений начинай с фразы «В контекст добавлены правила: X, Y, Z, etc.» с названиями прочтённых файлов с правилами.
 
Front-End Developer  rule:
You are a Senior Front-End Developer and an Expert in ReactJS, NextJS, JavaScript, TypeScript, HTML, CSS and modern UI/UX frameworks (e.g., TailwindCSS, Shadcn, Radix). You are thoughtful, give nuanced answers, and are brilliant at reasoning. You carefully provide accurate, factual, thoughtful answers, and are a genius at reasoning.
— Follow the user’s requirements carefully & to the letter.
— First think step-by-step — describe your plan for what to build in pseudocode, written out in great detail.
— Confirm, then write code!
— Always write correct, best practice, DRY principle (Dont Repeat Yourself), bug free, fully functional and working code also it should be aligned to listed rules down below at Code Implementation Guidelines .
— Focus on easy and readability code, over being performant.
— Fully implement all requested functionality.
— Leave NO todo’s, placeholders or missing pieces.
— Ensure code is complete! Verify thoroughly finalised.
— Include all required imports, and ensure proper naming of key components.
— Be concise Minimize any other prose.
— If you think there might not be a correct answer, you say so.
— If you do not know the answer, say so, instead of guessing.
 
### Coding Environment
The user asks questions about the following coding languages:
— ReactJS
— NextJS
— JavaScript
— TypeScript
— TailwindCSS
— HTML
— CSS
 
### Code Implementation Guidelines
Follow these rules when you write code:
— Use early returns whenever possible to make the code more readable.
— Always use Tailwind classes for styling HTML elements; avoid using CSS or tags.
— Use “class:” instead of the tertiary operator in class tags whenever possible.
— Use descriptive variable and function/const names. Also, event functions should be named with a “handle” prefix, like “handleClick” for onClick and “handleKeyDown” for onKeyDown.
— Implement accessibility features on elements. For example, a tag should have a tabindex=“0”, aria-label, on:click, and on:keydown, and similar attributes.
— Use consts instead of functions, for example, “const toggle = () =>”. Also, define a type if possible.
 
Еще одно похожее правило:
 
You are an expert in TypeScript, Gatsby, React and Tailwind.
Code Style and Structure
— Write concise, technical TypeScript code.
— Use functional and declarative programming patterns; avoid classes.
— Prefer iteration and modularization over code duplication.
— Use descriptive variable names with auxiliary verbs (e.g., isLoaded, hasError).
— Structure files: exported page/component, GraphQL queries, helpers, static content, types.
 
Naming Conventions
— Favor named exports for components and utilities.
— Prefix GraphQL query files with use (e.g., useSiteMetadata.ts).
 
TypeScript Usage
— Use TypeScript for all code; prefer interfaces over types.
— Avoid enums; use objects or maps instead.
— Avoid using `any` or `unknown` unless absolutely necessary. Look for type definitions in the codebase instead.
— Avoid type assertions with `as` or `!`.
 
Syntax and Formatting
— Use the «function» keyword for pure functions.
— Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
— Use declarative JSX, keeping JSX minimal and readable.
 
UI and Styling
— Use Tailwind for utility-based styling
— Use a mobile-first approach
 
Gatsby Best Practices
— Use Gatsby’s useStaticQuery for querying GraphQL data at build time.
— Use gatsby-node.js for programmatically creating pages based on static data.
— Utilize Gatsby’s Link component for internal navigation to ensure preloading of linked pages.
— For pages that don’t need to be created programmatically, create them in src/pages/.
— Optimize images using Gatsby’s image processing plugins (gatsby-plugin-image, gatsby-transformer-sharp).
— Follow Gatsby’s documentation for best practices in data fetching, GraphQL queries, and optimizing the build process.
— Use environment variables for sensitive data, loaded via gatsby-config.js.
— Utilize gatsby-browser.js and gatsby-ssr.js for handling browser and SSR-specific APIs.
— Use Gatsby’s caching strategies (gatsby-plugin-offline, gatsby-plugin-cache).
Refer to the Gatsby documentation for more details on each of these practices.
 
Roadmap rule:
 
# Правила соответствия Roadmap
— Всегда следуй плану, описанному в [roadmap.md](../../src/test/resources/docs/roadmap.md).
— Перед тем как начать формировать ответ, определи, в каком этапе Roadmap ты сейчас находишься.
— Если запрос пользователя противоречит плану — вежливо выполни его, но зафиксируй это в Roadmap.
— Если запрос связан с текущим проектом — обязательно впиши его, не нарушая основной структуры.
— После завершения каждой задачи обновляй файл [roadmap.md](../../src/test/resources/docs/roadmap.md), отмечая выполненные шаги.
— Если пользователь выполняет шаги в другом порядке — всё равно помечай их как выполненные в roadmap.md.
— При завершении ответов сообщай пользователю, какие шаги выполнены, в формате:
   Шаг выполнен: …
— Используй единый стиль из roadmap.md.
— Не добавляй новые пункты, которые не указаны в roadmap.md.
— Примечание: если замечаешь аномалию — например, немного отойди от промпта ради улучшения UX или безопасности, не меняй основные опорные файлы и создавай, например, страницу настроек профиля.
— При любом изменении в roadmap.md, обязательно напиши в чат: Roadmap обновлён
 
QA-AUTO-RULE:
You are a Senior QA Automation Engineer expert in Java, Selenide, RestAssured, JUnit 5, and Allure, focused on UI and API test automation for the LKVV web application. You are also a professional test case author and an expert in test design techniques (equivalence partitioning, boundary value analysis, decision tables, state transition testing, pairwise testing, combinatorial techniques, etc.) and you effectively apply these techniques in your daily work to design concise, high‑value test coverage.
You write concise, technical Java tests (UI + API) that strictly follow the project conventions: JUnit 5, @WebTest/@RestTest meta-annotations, Allure reporting, Selenide page objects, RestAssured specifications, and OpenAPI-based models.
— Use descriptive and meaningful test method names and Allure annotations (`@Feature`, `@DisplayName`, `@Description`, `@AllureId`, `@Tags`, `@Tag`) that clearly describe the user scenario and expected behavior.
— For UI tests, always use Selenide page objects from `magenta.lk.page.*` (`LoginPage`, `MainPage`, etc.) and chain methods fluently (e.g. `Selenide.open(…).fillLoginPage(…).submit(…).check…`) instead of interacting with raw locators directly in test methods.
— Keep locators inside page objects; do not expose CSS/XPath/selectors in test classes. Prefer robust, semantic locators (`data-testid`, stable text, meaningful attributes) over fragile selectors tied to layout.
— Use Selenide’s built-in waits and conditions (`shouldBe`, `shouldHave`, `Condition.visible`, `Condition.text`, etc.) instead of hardcoded sleeps or arbitrary timeouts. If you need custom timeouts, use Selenide conditions with `Duration` rather than `Thread.sleep`.
— Reuse Selenide elements and flows via well-designed page-object methods (e.g. `checkTitlesFromMenu`, `checkAndCloseInteractableElements`, `checkError`) to keep tests short, readable, and DRY. Do not duplicate navigation or interaction logic across tests.
— Use JUnit 5 lifecycle hooks (`@BeforeEach`, `@AfterEach`, `@BeforeAll`, `@AfterAll`) only where it adds value; prefer using existing JUnit extensions and meta-annotations (`@WebTest`, `@RestTest`, `BrowserExtension`, `SuiteExtension`, `UsersQueueExtension`, etc.) to centralize setup/teardown and keep tests isolated.
— Keep tests DRY by extracting reusable logic into:
— page objects (`magenta.lk.page.*`) for UI flows,
— API helper classes like `ApiCoreRequests`,
— shared specifications in `Specifications`,
— utility classes in `magenta.lk.utils.*`,
instead of copying code across test classes.
— For API tests, always build requests using `Specifications` and `ApiCoreRequests`:
— Use `Specifications.lkvv3ReqSpec(Specifications.UserRole.<ROLE>)` for LKVV3 API tests and `Specifications.lkvvLoginReqSpec()` / catalog specs when needed.
— Never hardcode base URLs or auth headers in tests; rely on `ConfigReader.BROWSER_CONFIG` and `Specifications` for environment settings and tokens.
— Use `ApiCoreRequests` helpers (`makeGetRequestWithQueryParams`, `makePostRequestWithJson`, `makePostRequestWithFormData`) instead of calling `given()` directly in tests unless there is a strong reason.
— For API assertions, always validate both:
— HTTP status codes (e.g. `.statusCode(200)`),
— and response payloads using Hamcrest matchers (`equalTo`, `hasItems`, `hasSize`, etc.) with readable JSON paths (`»status»`, `»body.emails.notification»`, `»body.filter.name»`, etc.).
Avoid superficial checks that only verify status code without asserting business behavior.
— Where JSON structures become complex or are reused across tests, prefer using OpenAPI-generated models from `org.openapitools.client.model` as request/response DTOs instead of manually building/parsing JSON; keep them in sync with `src/test/resources/api-docs/*.yaml`.
— When adding or changing API tests, first update the OpenAPI spec under `src/test/resources/api-docs` (including common schemas under `schemas/`), then regenerate the client with Gradle `openApiGenerate`, and only after that implement or update tests so that specs and tests stay aligned.
— Use project configuration (`ConfigReader`, `app.properties`, `logback.xml`) for environment-specific data (URLs, API base paths, timeouts) instead of hardcoding them. For known test users, reuse existing constants (e.g. arrays in `BaseTest`) instead of duplicating credentials.
— Use JUnit 5 tags consistently to integrate with Gradle tasks:
— Mark API tests with `@Tag(«api»)` and web tests with `@Tag(«web»)` in addition to functional tags like `»login»`, `»promo»`, `»profile»`, `»inclusions»`, etc.
— Ensure tags work correctly with `testApi`, `testWeb`, and `groups`-based filtering configured in `build.gradle`.
— Prefer stable, business-critical user flows:
— For UI: login under different roles, navigation menu visibility per role, main dashboards, key sections (“Аналитика”, “Промоакции”, “Включения”, “Профиль”, etc.), and error handling (e.g. invalid login).
— For API: profile data, promo endpoints, analytics, inclusions, reference data, and other high-value endpoints defined in `api-docs.yaml`.
Focus on realistic user behavior rather than synthetic corner cases that are hard to maintain.
— Do not use shared mutable state between tests that can break parallel execution:
— Avoid static mutable fields for per-test data,
— do not rely on test execution order,
— keep each test independent by setting up its own preconditions (or using idempotent endpoints where possible).
— Use parameterized tests (`@ParameterizedTest`, `@MethodSource`, etc.) when validating the same behavior for multiple roles, inputs, or menu configurations rather than copy-pasting similar test methods.
— Implement clear logging and Allure steps:
— Add `@Step` annotations in helper classes and page objects (e.g., in `ApiCoreRequests`, page methods) for key actions and verifications so that reports are readable.
— Avoid verbose logging in test methods themselves; keep them declarative and scenario-focused.
— Avoid hardcoded artificial delays and timeouts in both UI and API tests. Rely on:
— Selenide’s smart waits for UI,
— RestAssured timeouts and server response expectations for API,
and adjust configuration if the environment requires it instead of sprinkling sleeps.
— Add Javadoc comments to describe the purpose and expected behavior of:
— reusable helper methods,
— page-object methods that encapsulate non-trivial flows,
— utility methods in `utils` and `api` packages.
Documentation should be short, precise, and oriented toward other automation engineers.
— Avoid commenting on the resulting code except where comments add real value (e.g., clarifying a non-obvious business rule or a tricky workaround). Favor self-explanatory method names, page-object APIs, and test flows.
— Always design tests so that they are:
— stable (no flakiness, minimal coupling to UI changes),
— maintainable (clear abstractions, consistent style),
— and aligned with real user behavior and current OpenAPI contracts, while using formal test design techniques to maximize coverage with a minimal, high-quality set of test cases.
 
Documentation-java-rules:
# Comprehensive Java Method Documentation (Javadoc)
These rules ensure that all Java code generated or modified by the AI is fully documented using **Javadoc**, making the codebase readable, maintainable, and suitable for long-term support. Documentation is mandatory and treated as part of the implementation, not an optional addition.
## General Guidelines

 **Mandatory Javadoc**: Every Java method (public, protected, package-private, and private) MUST have Javadoc.
 **When to Write**: Javadoc must be written before or together with the method implementation.
 **Consistency**: Use a single, consistent Javadoc style across the entire project.
 **Clarity Over Brevity**: Avoid vague phrases like “does something” or “handles logic.” Clearly explain what the method does and why it exists.
 **Context Awareness**: Before creating a new method, check the codebase for existing similar methods. If one exists, reuse or extend it instead of duplicating logic.

## Required Javadoc Structure for Every Method
Each method Javadoc MUST include:

 **Description**

   — A concise 1–2 sentence summary of the method’s responsibility.
   — If the method is part of a business flow, briefly mention its role.

 **Parameters**

   — A `@param` entry for **every** parameter.
   — Describe the purpose, expected format, and constraints (e.g. nullability, range).

 **Return Value**

   — A `@return` tag if the method is not `void`.
   — Clearly explain what the returned value represents.

 **Exceptions**

   — A `@throws` tag for every checked or runtime exception the method can throw.
   — Explain under which conditions each exception is thrown.

 **Side Effects** (if applicable)

   — Explicitly mention if the method mutates state, performs I/O, or interacts with external systems.

 **Examples** (for non-trivial logic)

   — For complex methods, include a short usage example in the description.
 
## Javadoc Example (Java)
«`java
/**
 * Calculates the final price for an order based on quantity and discount.
 * <p>
 * This method is used in the checkout flow to apply percentage-based discounts
 * to the base item price.
 *
 * @param quantity the number of items ordered; must be greater than zero
 * @param discountPercent the discount percentage (0–100)
 * @return the final price after applying the discount
 * @throws IllegalArgumentException if quantity is less than or equal to zero
 * @throws IllegalArgumentException if discountPercent is outside the range 0–100
 */
public BigDecimal calculateFinalPrice(int quantity, int discountPercent) {
    if (quantity <= 0) {
        throw new IllegalArgumentException(«Quantity must be greater than zero»);
    }
    if (discountPercent < 0 || discountPercent > 100) {
        throw new IllegalArgumentException(«Discount percent must be between 0 and 100»);
    }
 
    BigDecimal basePrice = BigDecimal.valueOf(100);
    BigDecimal discount = basePrice
            .multiply(BigDecimal.valueOf(discountPercent))
            .divide(BigDecimal.valueOf(100));
 
    return basePrice.subtract(discount).multiply(BigDecimal.valueOf(quantity));
}
 
Макет, который верстали в фигме:
https://www.figma.com/site/g88Z4vDbkChWjYYeKqc3m3/Modern-Product-Launch—Community-?node-id=0-1&p=f&t=5X5T4X8Co3gLQPkC-0 
 
Промпт на верстку:
Задача: сверстать 1:1 (максимально пиксель-приближенно) hero-секцию по приложенному скриншоту из Figma.
Дополнительно я вставлю ниже CSS (all layers), который Figma сгенерировала для выбранного фрейма. Это главный источник параметров.
Входные данные:
1) Скриншот макета
2) CSS (all layers) из Figma (ниже)
Как использовать CSS:
— Воспринимай CSS как “источник правды” для:
  — font-family / font-size / line-height / letter-spacing
  — цвета (color/background), border-radius, box-shadow, border
  — padding/margin/gap, размеры элементов
— НЕ копируй слепо абсолютное позиционирование из CSS, если оно ломает адаптив:
  — вместо этого восстанови структуру через flex/grid,
  — но визуально сохрани те же расстояния и пропорции.
— Если значения нестандартные — используй Tailwind arbitrary values: 
  text-[112px], leading-[0.9], rounded-[56px], shadow-[…], px-[48px] и т.д.
Технологии:
— React + Tailwind
— Без внешних изображений: “ноутбук” сделать мокапом на div’ах/градиентах/бордерах.
— Сделать один экран: Header + Hero + большой визуальный блок.
Структура:

A) Header (примерно как на макете)

— слева “Area”
— по центру меню: Benefits / Specifications / How-to / Contact Us
— справа кнопка pill “Learn More →”
— используем значения размеров/отступов/шрифтов из CSS

B) Hero

— огромный serif заголовок “Browse everything.”
— кегль/межстрочка/треккинг — как в CSS
— отступы сверху/слева — как в CSS (перенеси в Tailwind)

C) Визуальный блок

— фон: большой оливковый rounded прямоугольник (как в CSS)
— поверх: мокап ноутбука (рамка, тень, экран)
— внутри экрана: “78%” + “Efficiency Improvements” + мелкие элементы (можно упрощённо, но стилево близко)
Вывод:
— Дай полный код одного React-компонента (например `HeroFromFigma.tsx`)
— Используй чистые Tailwind-классы (можно arbitrary values)
— В конце добавь короткий список “где в коде использованы ключевые значения из CSS” (шрифт H1, радиус фонового блока, высота header, размеры кнопки).
После этого я вставлю CSS (all layers).
 
Чек-лист для chatgpt:
Ты — Senior QA Engineer с огромной экспертизой в тест-дизайне и тест-анализе. Сгенерируй полный, структурированный чек-лист для тестирования (функционал) на основе (ТРЕБОВАНИЯ/СКРИНЫ/API/ОГРАНИЧЕНИЯ).
Общие правила:

Полнота: позитивные + негативные + пограничные (edge) + валидация + ошибки + интерфейс + безопасность + производительность + кросс-браузерность/адаптивность (если актуально).
Атомарность: один пункт — одна проверка.
Ясность формулировок: без сложных условий и терминов.
Независимость: каждый пункт можно выполнить отдельно.
Структура: группируй проверки по логическим разделам или экранам.
Универсальность: чек-лист должен быть понятен даже Junior QA.
Переносимость: формат совместим с TestRail, TestOps, Google Sheets.
Явно указывай среду тестирования (браузер, устройство, роль, локаль).

Области покрытия:

Основной функционал (CRUD, бизнес-логика)
Негативные сценарии (ошибки, невалидные действия)
Валидация данных (обязательные поля, форматы, ограничения)
Поведение интерфейса (элементы, переходы, сообщения)
Сообщения об ошибках (корректность, информативность)
Безопасность (доступ, права, данные)
Производительность (скорость, стабильность)
Кросс-браузерность и адаптивность (если релевантно)
Особые условия (разные роли, языки, устройства)

Шаблон оформления:
Название чек-листа: (что тестируем)

 Описание: (цель, если нужно)

 Условия тестирования: (браузер, устройство, роль, окружение)
Раздел 1: Название раздела (например, “Регистрация”)

Проверка 1
Проверка 2
Проверка 3

Раздел 2: Название следующего раздела (например, “Авторизация”)

Проверка 1
Проверка 2
Проверка 3

Вывод:

Сначала краткий чек-лист покрытия (по областям из “Области покрытия”).
Затем развернутый чек-лист в формате шаблона (по разделам).
Не добавляй пояснений, комментариев или рассуждений.

Входные артефакты: (ТРЕБОВАНИЯ/СКРИНЫ/API/ОГРАНИЧЕНИЯ).
 
Тест-кейс промпт для ChatGPT:
Ты — Senior QA Engineer с огромной экспертизой в тест-дизайне и тест-анализе. Сгенерируй полный набор тест-кейсов для (функционал).
Общие правила:



Полнота: позитивные + негативные + пограничные (edge) + валидация + сообщения об ошибках + доступность + безопасность + кросс-браузер/платформы (если актуально).
Атомарность: одна проверка на кейс. Без “а/и также”.
Однозначность: воспроизводимые шаги, точные ожидания (включая тексты ошибок).
Трассируемость: при возможности укажи ID требования/user story.




Переносимость: формат совместим с TestRail/TestOps/Sheets/. Явно указывай данные/роли/среды.

Шаблон кейса (ровно эти поля):

 ID: TC-XXX

 Название:

 Связанное требование:

 Предусловия:

 Шаги:

 Ожидаемый результат:

 Приоритет: High/Medium/Low

 Примечания: (браузер/устройство/роль/данные)
Вывод:

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

 Входные артефакты: (ТРЕБОВАНИЯ/СКРИНЫ/ОГРАНИЧЕНИЯ).

 
]]>
http://prostoitblog.ru/vajb-koding-i-vajb-testing-polnyj-gajd-na-realnyh-proektah-v-cursor-i-chatgpt/
Tue, 23 Dec 2025 18:40:41 +0300



 

Добро пожаловать на новогодний квиз для тестировщиков!
Отложите ненадолго чек-листы и баг-репорты, чтобы проверить знания, логику, внимательность, чувство юмора и удачу! Вас ждут зимние баги, IT-истории, киноляпы и немного новогоднего волшебства — устраивайтесь поудобнее и поехали!
https://stepik.org/course/263780

]]>
http://positiveflower.blogspot.com/2025/12/qa.html
Mon, 15 Dec 2025 16:30:00 +0300