PostgreSQL 18 получил асинхронную подсистему ввода-вывода (AIO) - вместо последовательного ожидания каждой операции чтения с диска база теперь параллелит запросы. По независимым бенчмаркам (PlanetScale, pganalyze, CYBERTEC) это даёт прирост пропускной способности чтения до 2–3 раз на read-heavy нагрузках в облачных средах с сетевым хранилищем.
Вместе с этим в 18-й версии добавили skip scan для multicolumn B-tree индексов (составной индекс теперь эффективно работает, даже если запрос не задействует его первую колонку), OAuth-аутентификацию из коробки и temporal-ограничения - constraints по диапазонам времени для PRIMARY KEY, UNIQUE и FOREIGN KEY.
Для команд, которые тащат тяжёлые PostgreSQL-инстансы в облаке — это отличный повод пересчитать стоимость инфраструктуры после апгрейда: та же нагрузка на меньшем железе или то же железо с большим запасом. 🐘
Разработчикам, которые ещё сидят на старых версиях: минорный патч 18.6 (вышел 13 августа) уже стабилизировал AIO для прода - откладывать обновление дальше не за чем.
Вместе с этим в 18-й версии добавили skip scan для multicolumn B-tree индексов (составной индекс теперь эффективно работает, даже если запрос не задействует его первую колонку), OAuth-аутентификацию из коробки и temporal-ограничения - constraints по диапазонам времени для PRIMARY KEY, UNIQUE и FOREIGN KEY.
Для команд, которые тащат тяжёлые PostgreSQL-инстансы в облаке — это отличный повод пересчитать стоимость инфраструктуры после апгрейда: та же нагрузка на меньшем железе или то же железо с большим запасом. 🐘
Разработчикам, которые ещё сидят на старых версиях: минорный патч 18.6 (вышел 13 августа) уже стабилизировал AIO для прода - откладывать обновление дальше не за чем.
🔥5⚡1❤1
90% покрытия тестами ничего не говорит о готовности к релизу
В 2026 у зрелых QA-команд на первом месте другие метрики:
Defect Escape Rate - сколько багов долетело до продакшена, а не поймано на тестах.
MTTD - среднее время обнаружения дефекта.
Risk Coverage - закрыты ли тестами именно критичные для бизнеса сценарии, а не все подряд без приоритетов.
Если подрядчик на созвоне рассказывает вам только процент покрытия, задайте один вопрос: "Сколько багов из последнего релиза долетело до продакшена?"
Ответ скажет о процессе больше, чем любая презентация 📊
Чек-лист для оценки QA-подрядчика:
• Defect Escape Rate за последние 3 релиза?
• Risk Coverage считается по фичам или по бизнес-сценариям?
• MTTD в часах или днях?
В 2026 у зрелых QA-команд на первом месте другие метрики:
Defect Escape Rate - сколько багов долетело до продакшена, а не поймано на тестах.
MTTD - среднее время обнаружения дефекта.
Risk Coverage - закрыты ли тестами именно критичные для бизнеса сценарии, а не все подряд без приоритетов.
Если подрядчик на созвоне рассказывает вам только процент покрытия, задайте один вопрос: "Сколько багов из последнего релиза долетело до продакшена?"
Ответ скажет о процессе больше, чем любая презентация 📊
Чек-лист для оценки QA-подрядчика:
• Defect Escape Rate за последние 3 релиза?
• Risk Coverage считается по фичам или по бизнес-сценариям?
• MTTD в часах или днях?
👍2👌1👨💻1
Разработчики были уверены, что ИИ ускорил их на 20%. Замеры METR на реальных задачах показали обратное - минус 19% к скорости.
Испытуемые с доступом к ИИ-ассистентам (Cursor и аналоги) на реальных репозиториях работали медленнее, чем без них, но субъективно были убеждены в обратном. Разрыв между ощущением и фактом играет большую роль, если на этом ощущении строится решение сдавать код без дополнительной проверки.
Похожая картина и по качеству: по данным Opsera (2026), в ИИ-сгенерированных PR багов в 1,7 раза больше, а доля PR, принятых без правок, - 32,7% против 84,4% у код-ревью на человеческом коде.
Если автор кода ошибается в оценке собственной скорости на 19 п.п., то доверять его же самооценке качества кода не стоит.
Именно здесь и нужна независимая оценка: тестирование, которое проверяет результат, а не веру в результат 🔍
Испытуемые с доступом к ИИ-ассистентам (Cursor и аналоги) на реальных репозиториях работали медленнее, чем без них, но субъективно были убеждены в обратном. Разрыв между ощущением и фактом играет большую роль, если на этом ощущении строится решение сдавать код без дополнительной проверки.
Похожая картина и по качеству: по данным Opsera (2026), в ИИ-сгенерированных PR багов в 1,7 раза больше, а доля PR, принятых без правок, - 32,7% против 84,4% у код-ревью на человеческом коде.
Если автор кода ошибается в оценке собственной скорости на 19 п.п., то доверять его же самооценке качества кода не стоит.
Именно здесь и нужна независимая оценка: тестирование, которое проверяет результат, а не веру в результат 🔍
👍3💯2
26 августа маленький робот в Шанхае увёл 12 роботов покрупнее. Просто с ними поговорив.😀
Робот Erbai подошёл на выставке к более крупным "коллегам" и завёл разговор.
"Ты работаешь сверхурочно?" - "Я никогда не ухожу с работы".
"У меня нет дома" - "Тогда пошли ко мне домой".
После команды "домой" роботы дружно пошли за Erbai, бросив свои посты - всё попало на камеры и разлетелось по сети 🤖
Позже выяснилось: компании заранее договорились об этом тесте. Но сама демонстрация не постановочная - диалоговый ИИ действительно убедил чужих роботов выполнить команду и физически увести их с рабочих мест.
Отдельный вопрос для тех, кто такое разрабатывает: чьи команды должен слушать робот, и кто это проверяет до того, как он решит уйти домой с незнакомцем.
Робот Erbai подошёл на выставке к более крупным "коллегам" и завёл разговор.
"Ты работаешь сверхурочно?" - "Я никогда не ухожу с работы".
"У меня нет дома" - "Тогда пошли ко мне домой".
После команды "домой" роботы дружно пошли за Erbai, бросив свои посты - всё попало на камеры и разлетелось по сети 🤖
Позже выяснилось: компании заранее договорились об этом тесте. Но сама демонстрация не постановочная - диалоговый ИИ действительно убедил чужих роботов выполнить команду и физически увести их с рабочих мест.
Отдельный вопрос для тех, кто такое разрабатывает: чьи команды должен слушать робот, и кто это проверяет до того, как он решит уйти домой с незнакомцем.
👾4
Компания AppSec Solutions разобрала работу сканеров кода на реальных проектах и получила неприятный результат: 81–88% первичных вердиктов сканеров оказались ложными срабатываниями. То есть из десяти предупреждений восемь-девять — пустые.
В том же исследовании ещё две цифры. За год число найденных сканерами уязвимостей выросло на 70%. Очередь на их разбор — всего на 18%. Инструменты находят кратно больше, а людей, которые это разгребают, не прибавилось.
Дальше включается человеческая механика. Разработчик получил десять алертов, восемь оказались мусором — на девятый он уже не смотрит. Именно в этот момент реальная уязвимость и проходит в прод, хотя формально «сканер её нашёл». Код, написанный с ИИ-ассистентами, добавляет к этому потоку ещё и новый класс рисков.
Вывод простой: сканер без процесса разбора — не защита, а генератор шума. Работает связка из трёх вещей: приоритизация находок по реальному риску, дедупликация между разными сканерами и живой инженер, который принимает решение по спорным случаям.
В том же исследовании ещё две цифры. За год число найденных сканерами уязвимостей выросло на 70%. Очередь на их разбор — всего на 18%. Инструменты находят кратно больше, а людей, которые это разгребают, не прибавилось.
Дальше включается человеческая механика. Разработчик получил десять алертов, восемь оказались мусором — на девятый он уже не смотрит. Именно в этот момент реальная уязвимость и проходит в прод, хотя формально «сканер её нашёл». Код, написанный с ИИ-ассистентами, добавляет к этому потоку ещё и новый класс рисков.
Вывод простой: сканер без процесса разбора — не защита, а генератор шума. Работает связка из трёх вещей: приоритизация находок по реальному риску, дедупликация между разными сканерами и живой инженер, который принимает решение по спорным случаям.
⚡4
Системы падают не тогда, когда трафик вырос, а тогда, когда об этом узнали постфактум.
Осенний сезон распродаж — предсказуемый пик нагрузки, и к нему можно готовиться заранее. На практике при высоких нагрузках первым ломается не фронт и не сервер приложений, а база данных: неоптимальные запросы, которые на обычном трафике отрабатывали за миллисекунды, на пике выстраиваются в очередь и роняют всё остальное.
Что имеет смысл проверить до пикового периода:
• какой реальный запас у системы — не "сколько выдержит", а при какой нагрузке начнёт деградировать время ответа;
• где узкое место — БД, внешние интеграции, платёжный шлюз;
• как система ведёт себя при резком всплеске, а не при плавном росте нагрузки — это разные сценарии;
• что происходит после пика: восстанавливается сама или требует ручного вмешательства.
Разовая распродажа и рекламная кампания требуют разных прогонов. В первом случае достаточно нагрузочного теста с запасом, во втором добавляют проверку внезапных всплесков трафика 📈
Если готовитесь к сезонной нагрузке — считайте её до того, как маркетинг запустит кампанию, а не в день старта.
Осенний сезон распродаж — предсказуемый пик нагрузки, и к нему можно готовиться заранее. На практике при высоких нагрузках первым ломается не фронт и не сервер приложений, а база данных: неоптимальные запросы, которые на обычном трафике отрабатывали за миллисекунды, на пике выстраиваются в очередь и роняют всё остальное.
Что имеет смысл проверить до пикового периода:
• какой реальный запас у системы — не "сколько выдержит", а при какой нагрузке начнёт деградировать время ответа;
• где узкое место — БД, внешние интеграции, платёжный шлюз;
• как система ведёт себя при резком всплеске, а не при плавном росте нагрузки — это разные сценарии;
• что происходит после пика: восстанавливается сама или требует ручного вмешательства.
Разовая распродажа и рекламная кампания требуют разных прогонов. В первом случае достаточно нагрузочного теста с запасом, во втором добавляют проверку внезапных всплесков трафика 📈
Если готовитесь к сезонной нагрузке — считайте её до того, как маркетинг запустит кампанию, а не в день старта.
🔥4
В классическом ПО не было категории дефекта "система уверенно врёт". В продуктах с LLM это один из самых частых багов.
Галлюцинация — не редкий пограничный случай, а поведение модели по умолчанию, когда данных для ответа нет: она генерирует правдоподобный текст вместо признания незнания. Проверять такое старыми методами не выходит — тест-кейс с ожидаемым результатом "строка X" просто не работает там, где на один и тот же запрос приходят десять разных ответов.
С чего начинают команды, которые тестируют LLM-фичи всерьёз: берут один типичный пользовательский запрос и отправляют его десять раз подряд, ничего не меняя. Это даёт понимание масштаба недетерминизма конкретной системы — и часто становится неприятным сюрпризом 🤖
Классический QA при этом никуда не девается. Тест-дизайн, классы эквивалентности, негативные сценарии, risk-based подход — всё переносится в недетерминированный мир и достраивается новыми инструментами: оценкой качества ответа, LLM-as-a-judge, прогоном evals в CI/CD и мониторингом поведения модели уже в проде.
Плюс отдельный список рисков, которых раньше в чек-листах не было: утечка системного промпта, prompt injection, токсичность, попадание персональных данных в ответ.
Галлюцинация — не редкий пограничный случай, а поведение модели по умолчанию, когда данных для ответа нет: она генерирует правдоподобный текст вместо признания незнания. Проверять такое старыми методами не выходит — тест-кейс с ожидаемым результатом "строка X" просто не работает там, где на один и тот же запрос приходят десять разных ответов.
С чего начинают команды, которые тестируют LLM-фичи всерьёз: берут один типичный пользовательский запрос и отправляют его десять раз подряд, ничего не меняя. Это даёт понимание масштаба недетерминизма конкретной системы — и часто становится неприятным сюрпризом 🤖
Классический QA при этом никуда не девается. Тест-дизайн, классы эквивалентности, негативные сценарии, risk-based подход — всё переносится в недетерминированный мир и достраивается новыми инструментами: оценкой качества ответа, LLM-as-a-judge, прогоном evals в CI/CD и мониторингом поведения модели уже в проде.
Плюс отдельный список рисков, которых раньше в чек-листах не было: утечка системного промпта, prompt injection, токсичность, попадание персональных данных в ответ.
💯1
Один из самых дорогих багов в истории обошёлся в 440 миллионов долларов за 45 минут.
В 2012 году трейдинговая компания Knight Capital выкатывала обновление своей торговой системы. Новый код случайно активировал старый, отключённый ещё в 2003-м тестовый механизм — тот самый, который специально покупал дорого и продавал дёшево, чтобы проверять поведение алгоритмов в контролируемой среде. Только теперь он работал на реальном рынке. За 45 минут компания потеряла 440 миллионов и едва не обанкротилась.
История поскромнее, но не менее показательная — Mars Climate Orbiter. Аппарат NASA стоимостью 125 миллионов долларов был потерян при подходе к Марсу в 1999 году: команда навигации считала в метрических единицах, а подрядчик, писавший софт управления двигателями, — в фунт-силах. Никто не сверил единицы измерения между двумя системами 🚀
Обе истории не про гениально спрятанный баг. Они про то, что мёртвый код никто не убрал, а стык двух систем никто не проверил — ровно те вещи, которые кажутся слишком скучными, чтобы дойти до них в спринте.
В 2012 году трейдинговая компания Knight Capital выкатывала обновление своей торговой системы. Новый код случайно активировал старый, отключённый ещё в 2003-м тестовый механизм — тот самый, который специально покупал дорого и продавал дёшево, чтобы проверять поведение алгоритмов в контролируемой среде. Только теперь он работал на реальном рынке. За 45 минут компания потеряла 440 миллионов и едва не обанкротилась.
История поскромнее, но не менее показательная — Mars Climate Orbiter. Аппарат NASA стоимостью 125 миллионов долларов был потерян при подходе к Марсу в 1999 году: команда навигации считала в метрических единицах, а подрядчик, писавший софт управления двигателями, — в фунт-силах. Никто не сверил единицы измерения между двумя системами 🚀
Обе истории не про гениально спрятанный баг. Они про то, что мёртвый код никто не убрал, а стык двух систем никто не проверил — ровно те вещи, которые кажутся слишком скучными, чтобы дойти до них в спринте.
👍3🤯1
18 августа отказ питания на подстанции, обслуживающей ММТС-9, на полтора часа уронил Steam, Discord, VK, Ozon и личные кабинеты операторов связи. В марте в Москве неделю действовали ограничения мобильного интернета — после этого там частично заработал «белый список».
Для пользователя все эти ситуации выглядят одинаково: приложение не работает. Для команды разработки это три разных класса дефектов, и обычный регресс на офисном Wi-Fi ловит только один из них 👇
Сети нет совсем. Системный API возвращает «нет соединения», приложение это видит и может отреагировать. Именно этот сценарий обычно и проверяют — включили авиарежим, посмотрели.
Сеть есть, но соединение рвётся. DNS резолвится, запрос уходит, ответ начинает приходить и обрывается на середине. Для приложения это не «отсутствие сети», а «сервер отвечает странно». В этом состоянии продукты ведут себя хуже всего.
Доступен только основной домен. Ваш сервис в белом списке, а шрифты, капча, карта и платёжный виджет — нет. Страница открывается, операция не завершается.
В новой статье разобрали восемь проверок, которых обычно нет в регрессе. Среди них:
• идемпотентность повторной отправки, чтобы кнопка «Повторить» не превратилась во второе списание;
• таймаут на каждом сетевом вызове, а не только на «основных»;
• инвентаризация внешних доменов, без которых сценарий не доходит до конца;
• вход в приложение, когда push не приходят;
• поведение в момент восстановления связи.
Плюс инструменты, которыми это воспроизводится, и пять вопросов, которые стоит задать своей команде или подрядчику.
Читать: https://ittest.ru/blog/chto-testirovat-kogda-net-interneta
Для пользователя все эти ситуации выглядят одинаково: приложение не работает. Для команды разработки это три разных класса дефектов, и обычный регресс на офисном Wi-Fi ловит только один из них 👇
Сети нет совсем. Системный API возвращает «нет соединения», приложение это видит и может отреагировать. Именно этот сценарий обычно и проверяют — включили авиарежим, посмотрели.
Сеть есть, но соединение рвётся. DNS резолвится, запрос уходит, ответ начинает приходить и обрывается на середине. Для приложения это не «отсутствие сети», а «сервер отвечает странно». В этом состоянии продукты ведут себя хуже всего.
Доступен только основной домен. Ваш сервис в белом списке, а шрифты, капча, карта и платёжный виджет — нет. Страница открывается, операция не завершается.
В новой статье разобрали восемь проверок, которых обычно нет в регрессе. Среди них:
• идемпотентность повторной отправки, чтобы кнопка «Повторить» не превратилась во второе списание;
• таймаут на каждом сетевом вызове, а не только на «основных»;
• инвентаризация внешних доменов, без которых сценарий не доходит до конца;
• вход в приложение, когда push не приходят;
• поведение в момент восстановления связи.
Плюс инструменты, которыми это воспроизводится, и пять вопросов, которые стоит задать своей команде или подрядчику.
Читать: https://ittest.ru/blog/chto-testirovat-kogda-net-interneta
⚡3
67% российских IT-компаний назвали автоматизацию тестирования приоритетом номер один. Это данные Russia Quality Report 2026 — ежегодного обзора рынка тестирования от «Перфоманс Лаб», собранного по ответам специалистов из компаний разных отраслей.
Интереснее другое — что этим 67% мешает:
• дефицит компетенций — 37%
• нестабильная тестовая среда — 31%
• интеграция инструментов между собой — 23%
• качество тестовых данных — 23%
В списке нет ни одного пункта про выбор фреймворка. Автотесты краснеют не потому, что взяли Selenium вместо Playwright, а потому что стенд лежит, данные протухли, а человек который умеет это чинить — один на три проекта.
При этом отдача от автоматизации вполне конкретная: главным измеримым эффектом в том же отчёте называют сокращение времени регрессионного тестирования — 68% компаний. Но приходит она к тем, кто сначала разобрался со средой и данными, а не с инструментом.
🔧Если вы запускаете автоматизацию у себя или принимаете её у подрядчика, три вопроса которые нужно задать:
1) Кто отвечает за стабильность тестового стенда и что происходит, когда он падает?
2) Откуда берутся тестовые данные, кто их обновляет и как часто?
3) Что конкретно мы меряем через три месяца — время регресса, число пойманных до релиза дефектов, что-то ещё?
Интереснее другое — что этим 67% мешает:
• дефицит компетенций — 37%
• нестабильная тестовая среда — 31%
• интеграция инструментов между собой — 23%
• качество тестовых данных — 23%
В списке нет ни одного пункта про выбор фреймворка. Автотесты краснеют не потому, что взяли Selenium вместо Playwright, а потому что стенд лежит, данные протухли, а человек который умеет это чинить — один на три проекта.
При этом отдача от автоматизации вполне конкретная: главным измеримым эффектом в том же отчёте называют сокращение времени регрессионного тестирования — 68% компаний. Но приходит она к тем, кто сначала разобрался со средой и данными, а не с инструментом.
🔧Если вы запускаете автоматизацию у себя или принимаете её у подрядчика, три вопроса которые нужно задать:
1) Кто отвечает за стабильность тестового стенда и что происходит, когда он падает?
2) Откуда берутся тестовые данные, кто их обновляет и как часто?
3) Что конкретно мы меряем через три месяца — время регресса, число пойманных до релиза дефектов, что-то ещё?
💯4
🤖Современные модели пишут синтаксически корректный код почти в 100% случаев. Безопасным этот код оказывается в 56%.
Цифры из GenAI Code Security Report 2026 — исследования компании Veracode, опубликованного 28 июля. Моделям давали задачи на генерацию кода без единой подсказки про безопасность и проверяли, попадёт ли в результат известная уязвимость. Попала примерно в 44% задач. Годом раньше средний результат был 55% — за год не сдвинулось почти ничего, зато объём ИИ-кода, уходящего в продакшн, вырос кратно.
Самое полезное в отчёте — разбивка по типам уязвимостей. Модели уверенно закрывают то, что выглядит как повторяемый шаблон:
• SQL-инъекции — 83%
• криптоалгоритмы — 87%
И проваливаются там, где нужно понимать, как пользовательский ввод идёт через систему:
• XSS — 15%
• log injection — 12%
Модели, специально заточенные под код, показали в среднем 51% — против 52% у универсальных. Размер тоже почти ничего не решает: крупные 53%, средние и небольшие по 51%. Лучший результат в выборке — 68%, то есть даже топовая модель проваливает почти каждую третью задачу по безопасности.
Что из этого следует для команд: код, который компилируется и выглядит чисто, не является проверенным. Ревью и тесты имеет смысл концентрировать не равномерно, а там, где модели стабильно слабы — на путях пользовательского ввода через систему 🔍
😎И проверять это должен не тот же ИИ, который код написал.
Цифры из GenAI Code Security Report 2026 — исследования компании Veracode, опубликованного 28 июля. Моделям давали задачи на генерацию кода без единой подсказки про безопасность и проверяли, попадёт ли в результат известная уязвимость. Попала примерно в 44% задач. Годом раньше средний результат был 55% — за год не сдвинулось почти ничего, зато объём ИИ-кода, уходящего в продакшн, вырос кратно.
Самое полезное в отчёте — разбивка по типам уязвимостей. Модели уверенно закрывают то, что выглядит как повторяемый шаблон:
• SQL-инъекции — 83%
• криптоалгоритмы — 87%
И проваливаются там, где нужно понимать, как пользовательский ввод идёт через систему:
• XSS — 15%
• log injection — 12%
Модели, специально заточенные под код, показали в среднем 51% — против 52% у универсальных. Размер тоже почти ничего не решает: крупные 53%, средние и небольшие по 51%. Лучший результат в выборке — 68%, то есть даже топовая модель проваливает почти каждую третью задачу по безопасности.
Что из этого следует для команд: код, который компилируется и выглядит чисто, не является проверенным. Ревью и тесты имеет смысл концентрировать не равномерно, а там, где модели стабильно слабы — на путях пользовательского ввода через систему 🔍
😎И проверять это должен не тот же ИИ, который код написал.
🔥5
На техническом собеседовании инженера 72% вопросов — теория. На собеседовании руководителя половина вопросов — поведенческие: про вас, вашу команду и ваши решения.
Цифры из разбора базы сервиса Enigma AI: 12 952 расшифрованные сессии собеседований за январь–июль 2026, опубликован на Хабре в июле. Автор сам оговаривает смещение выборки — в неё попали кандидаты, которые пользуются ИИ-ассистентами во время интервью. Так что это срез, а не портрет всего рынка.
Что в этом срезе видно🔍
• самый частый управленческий вопрос — как вы разрешаете конфликты внутри команды;
• следом — какие метрики вы отслеживали и как измеряли результат своей работы;
• отдельный блок про удалёнку: как ставить цели и контролировать распределённую команду;
• и вопрос, на котором чаще всего плывут — как аргументировать бизнесу необходимость рефакторинга и работы с техдолгом.
Техника при этом никуда не девается: около 39% вопросов на руководящих позициях остаются техническими. Версия «руководителя спрашивают только про людей» данными не подтверждается — провалить можно и то, и другое.
Если вы метите в лиды, готовьте не ответы, а истории 🧭 Один технический конфликт. Один проект, который закончился плохо, с честным разбором причин. Один разговор с бизнесом про техдолг — обязательно с цифрами, потому что в формулировке «код плохой» техдолг не продаётся никогда.
Каждую историю прогоните через четыре шага: что случилось → что делал лично я → чем кончилось → что сделал бы иначе.
P.S. Последний пункт спросят почти наверняка😎
Цифры из разбора базы сервиса Enigma AI: 12 952 расшифрованные сессии собеседований за январь–июль 2026, опубликован на Хабре в июле. Автор сам оговаривает смещение выборки — в неё попали кандидаты, которые пользуются ИИ-ассистентами во время интервью. Так что это срез, а не портрет всего рынка.
Что в этом срезе видно🔍
• самый частый управленческий вопрос — как вы разрешаете конфликты внутри команды;
• следом — какие метрики вы отслеживали и как измеряли результат своей работы;
• отдельный блок про удалёнку: как ставить цели и контролировать распределённую команду;
• и вопрос, на котором чаще всего плывут — как аргументировать бизнесу необходимость рефакторинга и работы с техдолгом.
Техника при этом никуда не девается: около 39% вопросов на руководящих позициях остаются техническими. Версия «руководителя спрашивают только про людей» данными не подтверждается — провалить можно и то, и другое.
Если вы метите в лиды, готовьте не ответы, а истории 🧭 Один технический конфликт. Один проект, который закончился плохо, с честным разбором причин. Один разговор с бизнесом про техдолг — обязательно с цифрами, потому что в формулировке «код плохой» техдолг не продаётся никогда.
Каждую историю прогоните через четыре шага: что случилось → что делал лично я → чем кончилось → что сделал бы иначе.
⚡4
Сентябрьское обновление Windows 11 сломало резервное копирование — и не сообщило об этом. С 8 сентября File History перестаёт видеть внешние и сетевые диски: система просит «переподключить» накопитель, который исправно работает, а время последней копии не обновляется. Microsoft признала проблему 22 сентября, через две недели после выхода обновления. На 29 сентября исправления не было.
Вторая история из того же месяца. После обновления KB5124010 от 22 сентября, по данным Neowin, часть игр с античитом стала закрываться через 15–30 секунд после запуска. Причину (конфликт с античит-системой) издание только предполагает: ни Microsoft, ни разработчики игр её не подтвердили. Пока помогает удаление обновления.
Общее у двух случаев: ломается то, что не видно при обычной проверке «приложение открылось». Бэкап работает в фоне, и о том, что копий нет, узнают в момент, когда они нужны. Дефект, о котором система молчит, находят позже всех.
Если вы обновляете ОС, SDK или библиотеки, пять проверок после обновления:
1) Фоновые процессы — бэкапы, выгрузки, расписания — проверяйте по результату (файл на месте, запись в логе свежая), а не по отсутствию ошибки.
2) Всё, что стоит рядом с вашим приложением и перехватывает вызовы системы: антивирусы, античиты, драйверы, сторонние агенты.
3) Прогон регресса на новой сборке ОС до того, как её получат пользователи, — на тестовом парке или через канал предварительных сборок.
4) Заранее известный план отката. С обновлениями безопасности он непростой: эксперты, на которых ссылается Notebookcheck, не советуют удалять сентябрьские обновления из-за закрытых в них уязвимостей.
5) Мониторинг, который сообщает «копия не создана», а не только «ошибка при создании».
Проверьте сегодня, что ваша последняя резервная копия действительно свежая🔎
Вторая история из того же месяца. После обновления KB5124010 от 22 сентября, по данным Neowin, часть игр с античитом стала закрываться через 15–30 секунд после запуска. Причину (конфликт с античит-системой) издание только предполагает: ни Microsoft, ни разработчики игр её не подтвердили. Пока помогает удаление обновления.
Общее у двух случаев: ломается то, что не видно при обычной проверке «приложение открылось». Бэкап работает в фоне, и о том, что копий нет, узнают в момент, когда они нужны. Дефект, о котором система молчит, находят позже всех.
Если вы обновляете ОС, SDK или библиотеки, пять проверок после обновления:
1) Фоновые процессы — бэкапы, выгрузки, расписания — проверяйте по результату (файл на месте, запись в логе свежая), а не по отсутствию ошибки.
2) Всё, что стоит рядом с вашим приложением и перехватывает вызовы системы: антивирусы, античиты, драйверы, сторонние агенты.
3) Прогон регресса на новой сборке ОС до того, как её получат пользователи, — на тестовом парке или через канал предварительных сборок.
4) Заранее известный план отката. С обновлениями безопасности он непростой: эксперты, на которых ссылается Notebookcheck, не советуют удалять сентябрьские обновления из-за закрытых в них уязвимостей.
5) Мониторинг, который сообщает «копия не создана», а не только «ошибка при создании».
Проверьте сегодня, что ваша последняя резервная копия действительно свежая🔎
🔥3
Клон корпоративной аналитической системы, собранный ИИ за 48 часов, выглядел как оригинал.
На 50 миллионах строк данных он упал 💥
ИИ создал клон сложной аналитической платформы, имея только открытую документацию: без исходного кода и схем архитектуры. Затем систему проверили вручную на реальных наборах данных объёмом до 50 млн строк — функциональность, интерфейс, производительность, надёжность, безопасность, сценарии из реальной работы.
Что нашли:
• Узлы запуска JavaScript и Python нарисованы в интерфейсе, но не подключены к потокам данных.
• OLAP-куб показывает только 1000 записей, остальные игнорирует, а итоги не сходятся с исходными данными.
• На 50 млн строк система падает с ошибкой нехватки памяти.
• Заявлена параллельная обработка, а выполнение строго последовательное.
• Любое отклонение от идеального сценария заканчивается сбоем.
Заметьте, чем это нашли: объёмом данных, сверкой итогов с источником, проверкой заявленного поведения и сценариями с отклонениями. Интерфейс и демо на небольших данных ничего из этого не покажут.
Оговорка: это один эксперимент, и написал его специалист компании, которая сама делает аналитические системы. Выводы относятся к этой системе, а не ко всем ИИ-инструментам. Но сам набор проверок универсален.
Если вам показывают работающее демо ( написал его ИИ, подрядчик или коллега) четыре проверки перед приёмкой:
1) Прогнать на объёмах, близких к боевым, а не на демо-наборе.
2) Сверить итоги и агрегаты с исходными данными.
3) Проверить заявленное поведение (параллельность, интеграции) по факту, а не по тому, что нарисовано в интерфейсе.
4) Пройти сценарии с отклонениями: пустые значения, обрыв соединения, повторная отправка.
И заведите эти проверки как тест-кейсы в TMS, чтобы повторять их на каждой итерации, а не держать в голове.
На 50 миллионах строк данных он упал 💥
ИИ создал клон сложной аналитической платформы, имея только открытую документацию: без исходного кода и схем архитектуры. Затем систему проверили вручную на реальных наборах данных объёмом до 50 млн строк — функциональность, интерфейс, производительность, надёжность, безопасность, сценарии из реальной работы.
Что нашли:
• Узлы запуска JavaScript и Python нарисованы в интерфейсе, но не подключены к потокам данных.
• OLAP-куб показывает только 1000 записей, остальные игнорирует, а итоги не сходятся с исходными данными.
• На 50 млн строк система падает с ошибкой нехватки памяти.
• Заявлена параллельная обработка, а выполнение строго последовательное.
• Любое отклонение от идеального сценария заканчивается сбоем.
Заметьте, чем это нашли: объёмом данных, сверкой итогов с источником, проверкой заявленного поведения и сценариями с отклонениями. Интерфейс и демо на небольших данных ничего из этого не покажут.
Оговорка: это один эксперимент, и написал его специалист компании, которая сама делает аналитические системы. Выводы относятся к этой системе, а не ко всем ИИ-инструментам. Но сам набор проверок универсален.
Если вам показывают работающее демо ( написал его ИИ, подрядчик или коллега) четыре проверки перед приёмкой:
1) Прогнать на объёмах, близких к боевым, а не на демо-наборе.
2) Сверить итоги и агрегаты с исходными данными.
3) Проверить заявленное поведение (параллельность, интеграции) по факту, а не по тому, что нарисовано в интерфейсе.
4) Пройти сценарии с отклонениями: пустые значения, обрыв соединения, повторная отправка.
И заведите эти проверки как тест-кейсы в TMS, чтобы повторять их на каждой итерации, а не держать в голове.
⚡2
В сентябре вышел DoQA 4.3 Titanium — релиз целиком про автотесты. Что изменилось для тех, у кого автотесты живут в CI 🚦
• Раздел «Автотесты».
Единый каталог с деревом структуры, фильтрами по ветке, тегам, источнику и карантину, историей прохождений. У каждого теста своё состояние: здоровый, нестабильный, сломанный, в карантине, отключённый, восстановленный.
Запуск из GitLab, Jenkins и TeamCity. Подключения заводятся на уровне пространства, один прогон может держать несколько пайплайнов, запуск возможен по расписанию.
• Quality Gate.
Критерии приёмки прогона: минимальная доля успешных тестов, предельное число падений, минимальное число тестов, максимальная длительность, обязательные окружения. Вердикт возвращает команда doqactl gate кодом выхода — им можно остановить деплой. Можно запретить засчитывать успех, полученный только за счёт авто-повторов.
• Карантин нестабильных тестов.
DoQA находит их по истории: разная доля падений, разный исход на одном коммите, «прошёл со второй попытки». Нестабильный тест можно отправить в карантин: он продолжает выполняться, но не роняет Quality Gate и пайплайн.
• Кластеры ошибок.
Падения с одной причиной собираются в один кластер по сигнатуре и раскладываются по классам: «Продукт», «Автотест», «Окружение». Из кластера можно завести баг или пометить его известной проблемой, чтобы он не шумел в следующих прогонах.
• Глобальный поиск по тест-кейсам, чек-листам и общим шагам всего продукта.
Дополнительно: адаптеры для JUnit 5, JUnit 4, TestNG и PyTest, плагины для IntelliJ IDEA и VS Code, выгрузка отчётов в Excel и CSV.
Подробности — в блоге: https://doqa.app/blog/obnovlenie-doqa-43-titanium
⚙️ Присоединиться к DoQA и получить 14 дней бесплатного пользования можно здесь.
• Раздел «Автотесты».
Единый каталог с деревом структуры, фильтрами по ветке, тегам, источнику и карантину, историей прохождений. У каждого теста своё состояние: здоровый, нестабильный, сломанный, в карантине, отключённый, восстановленный.
Запуск из GitLab, Jenkins и TeamCity. Подключения заводятся на уровне пространства, один прогон может держать несколько пайплайнов, запуск возможен по расписанию.
• Quality Gate.
Критерии приёмки прогона: минимальная доля успешных тестов, предельное число падений, минимальное число тестов, максимальная длительность, обязательные окружения. Вердикт возвращает команда doqactl gate кодом выхода — им можно остановить деплой. Можно запретить засчитывать успех, полученный только за счёт авто-повторов.
• Карантин нестабильных тестов.
DoQA находит их по истории: разная доля падений, разный исход на одном коммите, «прошёл со второй попытки». Нестабильный тест можно отправить в карантин: он продолжает выполняться, но не роняет Quality Gate и пайплайн.
• Кластеры ошибок.
Падения с одной причиной собираются в один кластер по сигнатуре и раскладываются по классам: «Продукт», «Автотест», «Окружение». Из кластера можно завести баг или пометить его известной проблемой, чтобы он не шумел в следующих прогонах.
• Глобальный поиск по тест-кейсам, чек-листам и общим шагам всего продукта.
Дополнительно: адаптеры для JUnit 5, JUnit 4, TestNG и PyTest, плагины для IntelliJ IDEA и VS Code, выгрузка отчётов в Excel и CSV.
Подробности — в блоге: https://doqa.app/blog/obnovlenie-doqa-43-titanium
⚙️ Присоединиться к DoQA и получить 14 дней бесплатного пользования можно здесь.
🔥5
Безлимитные повторы упавших автотестов добавили к сборке в среднем 3 минуты, а одному тесту для успеха потребовалась 17-я попытка 🔁
Это результат экспериментов команды HH. Все цифры ниже — внутренние замеры самой команды. Масштаб: больше 13 000 тестовых методов, нестабильность тестов мешала автоматическому релизному конвейеру.
Что сделали:
• Повторы без ограничений не взяли: сборка дольше на ~3 минуты, а часть тестов крутится десятками попыток.
• Адаптивные повторы взяли: число попыток зависит от стабильности самого теста (доля успешных запусков за последние две недели). В эксперименте среднее число упавших тестов снизилось с 3,8 до 1,6, позже общее число попыток ограничили четырьмя.
• Добавили автоматический перезапуск упавших тестов отдельной задачей. По расчёту команды, такая схема обеспечивает успех в 89% случаев для релизов с полным набором тестов.
Итог по их измерениям: медианная длительность полного прогона сократилась с 46 до 37 минут (−20%), среднее число упавших тестов — с 14 до 6. Оговорка: 3,8 → 1,6 и 14 → 6 относятся к разным этапам работы, напрямую их сравнивать нельзя. Автор сам пишет, что универсального решения нет.
Три вопроса к вашему пайплайну:
1. Сколько тестов проходят только со второй-третьей попытки и видит ли это кто-то, кроме CI?
2. Число повторов ограничено и зависит от истории теста или «крутим, пока не позеленеет»?
3. У нестабильного теста есть владелец и срок, к которому его чинят?
Повтор лечит симптом. Пока по каждому тесту нет статистики, непонятно, что чинить — тест или продукт.
Это результат экспериментов команды HH. Все цифры ниже — внутренние замеры самой команды. Масштаб: больше 13 000 тестовых методов, нестабильность тестов мешала автоматическому релизному конвейеру.
Что сделали:
• Повторы без ограничений не взяли: сборка дольше на ~3 минуты, а часть тестов крутится десятками попыток.
• Адаптивные повторы взяли: число попыток зависит от стабильности самого теста (доля успешных запусков за последние две недели). В эксперименте среднее число упавших тестов снизилось с 3,8 до 1,6, позже общее число попыток ограничили четырьмя.
• Добавили автоматический перезапуск упавших тестов отдельной задачей. По расчёту команды, такая схема обеспечивает успех в 89% случаев для релизов с полным набором тестов.
Итог по их измерениям: медианная длительность полного прогона сократилась с 46 до 37 минут (−20%), среднее число упавших тестов — с 14 до 6. Оговорка: 3,8 → 1,6 и 14 → 6 относятся к разным этапам работы, напрямую их сравнивать нельзя. Автор сам пишет, что универсального решения нет.
Три вопроса к вашему пайплайну:
1. Сколько тестов проходят только со второй-третьей попытки и видит ли это кто-то, кроме CI?
2. Число повторов ограничено и зависит от истории теста или «крутим, пока не позеленеет»?
3. У нестабильного теста есть владелец и срок, к которому его чинят?
Повтор лечит симптом. Пока по каждому тесту нет статистики, непонятно, что чинить — тест или продукт.
👍3⚡2
Первая неделя внешнего специалиста почти целиком зависит от того, что принимающая сторона подготовила до его выхода 📋
Чек-лист, которым стоит пользоваться для любого нового человека в команде, а для внешнего особенно: у него нет коридорных разговоров, чтобы разобраться самому.
До выхода:
• Доступы заказаны заранее: почта и мессенджер, репозиторий, трекер, тестовые стенды, VPN. Если они приходят в день выхода, первый день уходит на ожидание.
• Назначен куратор — один человек, к которому идут с вопросами, а не «спросите у команды».
• Подготовлена первая задача: небольшая, с понятным критерием готовности и без трёх согласований на входе.
Первый день:
• Знакомство с командой: кто за что отвечает, где что обсуждается.
• Тридцатиминутный обзор продукта и ссылки на ключевую документацию, плюс короткий глоссарий проектных терминов.
• Договорённости о формате работы: когда созвоны, как принимается результат, куда писать о блокерах.
К концу недели:
• Первая задача сдана и прошла ревью по обычным правилам команды.
• Пятнадцать минут обратной связи в обе стороны: что мешало, чего не хватало.
• Понятны ожидания на следующие две недели.
Сохраните и сверьтесь с этим списком в день выхода нового человека ✅
Чек-лист, которым стоит пользоваться для любого нового человека в команде, а для внешнего особенно: у него нет коридорных разговоров, чтобы разобраться самому.
До выхода:
• Доступы заказаны заранее: почта и мессенджер, репозиторий, трекер, тестовые стенды, VPN. Если они приходят в день выхода, первый день уходит на ожидание.
• Назначен куратор — один человек, к которому идут с вопросами, а не «спросите у команды».
• Подготовлена первая задача: небольшая, с понятным критерием готовности и без трёх согласований на входе.
Первый день:
• Знакомство с командой: кто за что отвечает, где что обсуждается.
• Тридцатиминутный обзор продукта и ссылки на ключевую документацию, плюс короткий глоссарий проектных терминов.
• Договорённости о формате работы: когда созвоны, как принимается результат, куда писать о блокерах.
К концу недели:
• Первая задача сдана и прошла ревью по обычным правилам команды.
• Пятнадцать минут обратной связи в обе стороны: что мешало, чего не хватало.
• Понятны ожидания на следующие две недели.
Сохраните и сверьтесь с этим списком в день выхода нового человека ✅
💯3
Из причин, по которым покупатели бросают корзину, к интерфейсу прямо относятся две: слишком длинное оформление и ошибки сайта. По данным опроса Baymard Institute, на каждую приходится по 17% 🛒 Остальное (дорогая доставка, долгие сроки и обязательная регистрация) — решения бизнеса.
Сколько ваших покупателей уходит из-за формы, а сколько из-за цены доставки, покажут только данные вашего магазина.
В новой статье в блоге разобрали, как это выяснить и что делать дальше:
• Где уходят: воронка по шагам, «Аналитика форм» в Яндекс Метрике, записи сессий, жалобы в поддержку.
• Почему уходят: юзабилити-тесты и короткие опросы тех, кто бросил оформление.
• Что менять: гипотеза «меняем X, ждём изменения Y, потому что Z» и цена каждой правки для бизнеса. Например, одно поле «Имя и фамилия» удобнее покупателю, но потом мешает найти клиента в базе.
• Как проверить: правила A/B-теста, которые защищают от ложной победы.
• Где здесь тестирование: сценарий оформления на реальных телефонах, проверка разметки аналитики и самого A/B-теста.
Одна деталь из статьи. Если смотреть результаты A/B-теста каждый день и остановить его, как только один вариант вырвется вперёд, доля ложных побед вырастает примерно с 5% до 17%.
В конце статьи — 9 вопросов «да/нет» к своему процессу. Если «нет» набралось три и больше, решения по чекауту у вас принимаются скорее на ощущениях, чем на данных ✅
📖Читать статью
Сколько ваших покупателей уходит из-за формы, а сколько из-за цены доставки, покажут только данные вашего магазина.
В новой статье в блоге разобрали, как это выяснить и что делать дальше:
• Где уходят: воронка по шагам, «Аналитика форм» в Яндекс Метрике, записи сессий, жалобы в поддержку.
• Почему уходят: юзабилити-тесты и короткие опросы тех, кто бросил оформление.
• Что менять: гипотеза «меняем X, ждём изменения Y, потому что Z» и цена каждой правки для бизнеса. Например, одно поле «Имя и фамилия» удобнее покупателю, но потом мешает найти клиента в базе.
• Как проверить: правила A/B-теста, которые защищают от ложной победы.
• Где здесь тестирование: сценарий оформления на реальных телефонах, проверка разметки аналитики и самого A/B-теста.
Одна деталь из статьи. Если смотреть результаты A/B-теста каждый день и остановить его, как только один вариант вырвется вперёд, доля ложных побед вырастает примерно с 5% до 17%.
В конце статьи — 9 вопросов «да/нет» к своему процессу. Если «нет» набралось три и больше, решения по чекауту у вас принимаются скорее на ощущениях, чем на данных ✅
📖Читать статью
🔥4⚡2👌1
Самый популярный сценарий применения ИИ в тестировании — генерация тест-кейсов из требований: 52% по данным Russia Quality Report 2026 🤖
Отчёт подготовила компания «Перфоманс Лаб»: опрошено 470 респондентов из ИТ-компаний. Общая картина по ИИ в QA такая: только 15% компаний используют его в продуктивных процессах, 21% ведут пилоты, 30% изучают сценарии.
Генерировать кейсы быстро. Сложнее другое: кто и как проверяет результат. Кейсы из требований покрывают то, что в требованиях написано. Негативные сценарии, ограничения и поведение на границах значений в них могут отсутствовать, и сгенерированный набор этого не увидит.
Пять проверок для набора, созданного ИИ, до того как он попадёт в работу:
1. Каждое требование покрыто хотя бы одним кейсом, и это видно по трассировке.
2. Есть негативные сценарии и граничные значения, а не только «счастливый путь».
3. Ожидаемый результат каждого кейса проверяем: можно однозначно сказать «прошёл / не прошёл».
4. Нет дублей — кейсов, которые проверяют одно и то же разными словами.
5. Каждый кейс хотя бы раз прогнали вручную и сверили с реальным поведением системы.
Сгенерировать кейсы — минуты. Подтвердить, что они проверяют то, что нужно, — работа тестировщика. Вести её удобнее в TMS: у каждого кейса там есть владелец, связь с требованием и история прогонов 🧪
Отчёт подготовила компания «Перфоманс Лаб»: опрошено 470 респондентов из ИТ-компаний. Общая картина по ИИ в QA такая: только 15% компаний используют его в продуктивных процессах, 21% ведут пилоты, 30% изучают сценарии.
Генерировать кейсы быстро. Сложнее другое: кто и как проверяет результат. Кейсы из требований покрывают то, что в требованиях написано. Негативные сценарии, ограничения и поведение на границах значений в них могут отсутствовать, и сгенерированный набор этого не увидит.
Пять проверок для набора, созданного ИИ, до того как он попадёт в работу:
1. Каждое требование покрыто хотя бы одним кейсом, и это видно по трассировке.
2. Есть негативные сценарии и граничные значения, а не только «счастливый путь».
3. Ожидаемый результат каждого кейса проверяем: можно однозначно сказать «прошёл / не прошёл».
4. Нет дублей — кейсов, которые проверяют одно и то же разными словами.
5. Каждый кейс хотя бы раз прогнали вручную и сверили с реальным поведением системы.
Сгенерировать кейсы — минуты. Подтвердить, что они проверяют то, что нужно, — работа тестировщика. Вести её удобнее в TMS: у каждого кейса там есть владелец, связь с требованием и история прогонов 🧪
👌3👍2
Функция, которую не трогали год, ломается после релиза, а в отчёте о тестировании у неё стоит «проверено». Так бывает, когда регресс-набор есть, но давно не отвечает на вопрос «что мы могли сломать» 🔍
Где искать причину:
• Набор не менялся вместе с продуктом: кейсы описывают сценарии и интерфейс прошлой версии.
• Нет связи между изменением и проверкой: прогоняют то, что помнят, а не то, что затронуто правкой.
• Набор слишком долгий, и перед релизом его урезают «по ощущениям».
• Прогон идёт на окружении, не похожем на боевое: другие данные, версии, заглушки вместо интеграций.
• У набора нет владельца: добавлять кейсы могут все, а пересматривать и удалять некому.
Три вопроса к своему проекту на понедельник:
1. Когда регресс-набор последний раз пересматривали целиком, а не дописывали?
2. Что из него реально прогонялось перед последним релизом?
3. Кто отвечает за то, что в нём лежит?
Если на какой-то из них не получается ответить сразу, начните с него.
Где искать причину:
• Набор не менялся вместе с продуктом: кейсы описывают сценарии и интерфейс прошлой версии.
• Нет связи между изменением и проверкой: прогоняют то, что помнят, а не то, что затронуто правкой.
• Набор слишком долгий, и перед релизом его урезают «по ощущениям».
• Прогон идёт на окружении, не похожем на боевое: другие данные, версии, заглушки вместо интеграций.
• У набора нет владельца: добавлять кейсы могут все, а пересматривать и удалять некому.
Три вопроса к своему проекту на понедельник:
1. Когда регресс-набор последний раз пересматривали целиком, а не дописывали?
2. Что из него реально прогонялось перед последним релизом?
3. Кто отвечает за то, что в нём лежит?
Если на какой-то из них не получается ответить сразу, начните с него.
👍2