IT Test

На техническом собеседовании инженера 72% вопросов — теория. На собеседовании руководителя половина вопросов — поведенческие: про вас, вашу команду и ваши решения.

Цифры из разбора базы сервиса Enigma AI: 12 952 расшифрованные сессии собеседований за январь–июль 2026, опубликован на Хабре в июле. Автор сам оговаривает смещение выборки — в неё попали кандидаты, которые пользуются ИИ-ассистентами во время интервью. Так что это срез, а не портрет всего рынка.

Что в этом срезе видно🔍

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

Техника при этом никуда не девается: около 39% вопросов на руководящих позициях остаются техническими. Версия «руководителя спрашивают только про людей» данными не подтверждается — провалить можно и то, и другое.

Если вы метите в лиды, готовьте не ответы, а истории 🧭 Один технический конфликт. Один проект, который закончился плохо, с честным разбором причин. Один разговор с бизнесом про техдолг — обязательно с цифрами, потому что в формулировке «код плохой» техдолг не продаётся никогда.

Каждую историю прогоните через четыре шага: что случилось → что делал лично я → чем кончилось → что сделал бы иначе.

P.S. Последний пункт спросят почти наверняка😎

🤖Современные модели пишут синтаксически корректный код почти в 100% случаев. Безопасным этот код оказывается в 56%.

Цифры из GenAI Code Security Report 2026 — исследования компании Veracode, опубликованного 28 июля. Моделям давали задачи на генерацию кода без единой подсказки про безопасность и проверяли, попадёт ли в результат известная уязвимость. Попала примерно в 44% задач. Годом раньше средний результат был 55% — за год не сдвинулось почти ничего, зато объём ИИ-кода, уходящего в продакшн, вырос кратно.

Самое полезное в отчёте — разбивка по типам уязвимостей. Модели уверенно закрывают то, что выглядит как повторяемый шаблон:
• SQL-инъекции — 83%
• криптоалгоритмы — 87%

И проваливаются там, где нужно понимать, как пользовательский ввод идёт через систему:
• XSS — 15%
• log injection — 12%

Модели, специально заточенные под код, показали в среднем 51% — против 52% у универсальных. Размер тоже почти ничего не решает: крупные 53%, средние и небольшие по 51%. Лучший результат в выборке — 68%, то есть даже топовая модель проваливает почти каждую третью задачу по безопасности.

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

😎И проверять это должен не тот же ИИ, который код написал.

67% российских IT-компаний назвали автоматизацию тестирования приоритетом номер один. Это данные Russia Quality Report 2026 — ежегодного обзора рынка тестирования от «Перфоманс Лаб», собранного по ответам специалистов из компаний разных отраслей.

Интереснее другое — что этим 67% мешает:
• дефицит компетенций — 37%
• нестабильная тестовая среда — 31%
• интеграция инструментов между собой — 23%
• качество тестовых данных — 23%

В списке нет ни одного пункта про выбор фреймворка. Автотесты краснеют не потому, что взяли Selenium вместо Playwright, а потому что стенд лежит, данные протухли, а человек который умеет это чинить — один на три проекта.

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

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

1) Кто отвечает за стабильность тестового стенда и что происходит, когда он падает?
2) Откуда берутся тестовые данные, кто их обновляет и как часто?
3) Что конкретно мы меряем через три месяца — время регресса, число пойманных до релиза дефектов, что-то ещё?

18 августа отказ питания на подстанции, обслуживающей ММТС-9, на полтора часа уронил Steam, Discord, VK, Ozon и личные кабинеты операторов связи. В марте в Москве неделю действовали ограничения мобильного интернета — после этого там частично заработал «белый список».

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

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

Сеть есть, но соединение рвётся. DNS резолвится, запрос уходит, ответ начинает приходить и обрывается на середине. Для приложения это не «отсутствие сети», а «сервер отвечает странно». В этом состоянии продукты ведут себя хуже всего.

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

В новой статье разобрали восемь проверок, которых обычно нет в регрессе. Среди них:

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

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

Читать: https://ittest.ru/blog/chto-testirovat-kogda-net-interneta

Один из самых дорогих багов в истории обошёлся в 440 миллионов долларов за 45 минут.

В 2012 году трейдинговая компания Knight Capital выкатывала обновление своей торговой системы. Новый код случайно активировал старый, отключённый ещё в 2003-м тестовый механизм — тот самый, который специально покупал дорого и продавал дёшево, чтобы проверять поведение алгоритмов в контролируемой среде. Только теперь он работал на реальном рынке. За 45 минут компания потеряла 440 миллионов и едва не обанкротилась.

История поскромнее, но не менее показательная — Mars Climate Orbiter. Аппарат NASA стоимостью 125 миллионов долларов был потерян при подходе к Марсу в 1999 году: команда навигации считала в метрических единицах, а подрядчик, писавший софт управления двигателями, — в фунт-силах. Никто не сверил единицы измерения между двумя системами 🚀

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

В классическом ПО не было категории дефекта "система уверенно врёт". В продуктах с LLM это один из самых частых багов.

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

С чего начинают команды, которые тестируют LLM-фичи всерьёз: берут один типичный пользовательский запрос и отправляют его десять раз подряд, ничего не меняя. Это даёт понимание масштаба недетерминизма конкретной системы — и часто становится неприятным сюрпризом 🤖

Классический QA при этом никуда не девается. Тест-дизайн, классы эквивалентности, негативные сценарии, risk-based подход — всё переносится в недетерминированный мир и достраивается новыми инструментами: оценкой качества ответа, LLM-as-a-judge, прогоном evals в CI/CD и мониторингом поведения модели уже в проде.

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

Системы падают не тогда, когда трафик вырос, а тогда, когда об этом узнали постфактум.

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

Что имеет смысл проверить до пикового периода:

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

Разовая распродажа и рекламная кампания требуют разных прогонов. В первом случае достаточно нагрузочного теста с запасом, во втором добавляют проверку внезапных всплесков трафика 📈

Если готовитесь к сезонной нагрузке — считайте её до того, как маркетинг запустит кампанию, а не в день старта.

Компания AppSec Solutions разобрала работу сканеров кода на реальных проектах и получила неприятный результат: 81–88% первичных вердиктов сканеров оказались ложными срабатываниями. То есть из десяти предупреждений восемь-девять — пустые.

В том же исследовании ещё две цифры. За год число найденных сканерами уязвимостей выросло на 70%. Очередь на их разбор — всего на 18%. Инструменты находят кратно больше, а людей, которые это разгребают, не прибавилось.

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

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

26 августа маленький робот в Шанхае увёл 12 роботов покрупнее. Просто с ними поговорив.😀

Робот Erbai подошёл на выставке к более крупным "коллегам" и завёл разговор.
"Ты работаешь сверхурочно?" - "Я никогда не ухожу с работы".
"У меня нет дома" - "Тогда пошли ко мне домой".
После команды "домой" роботы дружно пошли за Erbai, бросив свои посты - всё попало на камеры и разлетелось по сети 🤖

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

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

Разработчики были уверены, что ИИ ускорил их на 20%. Замеры METR на реальных задачах показали обратное - минус 19% к скорости.

Испытуемые с доступом к ИИ-ассистентам (Cursor и аналоги) на реальных репозиториях работали медленнее, чем без них, но субъективно были убеждены в обратном. Разрыв между ощущением и фактом играет большую роль, если на этом ощущении строится решение сдавать код без дополнительной проверки.

Похожая картина и по качеству: по данным Opsera (2026), в ИИ-сгенерированных PR багов в 1,7 раза больше, а доля PR, принятых без правок, - 32,7% против 84,4% у код-ревью на человеческом коде.

Если автор кода ошибается в оценке собственной скорости на 19 п.п., то доверять его же самооценке качества кода не стоит.

Именно здесь и нужна независимая оценка: тестирование, которое проверяет результат, а не веру в результат 🔍

90% покрытия тестами ничего не говорит о готовности к релизу

В 2026 у зрелых QA-команд на первом месте другие метрики:
Defect Escape Rate - сколько багов долетело до продакшена, а не поймано на тестах.
MTTD - среднее время обнаружения дефекта.
Risk Coverage - закрыты ли тестами именно критичные для бизнеса сценарии, а не все подряд без приоритетов.

Если подрядчик на созвоне рассказывает вам только процент покрытия, задайте один вопрос: "Сколько багов из последнего релиза долетело до продакшена?"
Ответ скажет о процессе больше, чем любая презентация 📊

Чек-лист для оценки QA-подрядчика:
• Defect Escape Rate за последние 3 релиза?
• Risk Coverage считается по фичам или по бизнес-сценариям?
• MTTD в часах или днях?

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 для прода - откладывать обновление дальше не за чем.

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

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

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

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

Читать статью: ittest.ru/blog/autsors-ili-autstaff-kak-vybrat

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

Такой разрыв очень просто объясняется - компании готовы платить за навыки анализа и автоматизации, а не за факт прохождения курсов. Тестировщик, который умеет писать автотесты, работать с CI/CD и разбираться в логах с помощью ИИ-инструментов ценится гораздо выше, чем manual QA без набора выше.

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

У большинства TMS в России пока нет выбора модели для ИИ-функций. В DoQA с релиза 4.2 мы это пофиксили: помимо OpenAI и YandexGPT, можно подключить GigaChat, DeepSeek или локальную модель через Ollama. Т.е. держать весь ИИ-контур внутри своего периметра, без данных, уходящих во внешний сервис.

Это отвечает на конкретный запрос enterprise-заказчиков с жёсткими требованиями ИБ: тест-кейсы и требования часто содержат чувствительные данные о продукте, и не каждая компания готова прогонять их через облачный LLM.

Вместе с этим в DoQA уже работает массовая генерация тест-кейсов и связка "клик по требованию → готовый набор тест-кейсов, автоматически привязанный к этому требованию" - рутина, которая раньше отнимала часы теперь занимает пару секунд.🤖

Важно понимать, что ИИ не заменит тестировщика(по крайней мере на текущем уровне развития), а в освободившееся время QA может заняться тем, чего ИИ пока не умеет - приоритизацией рисков и глубоким погружением в продукт.

С 2026 года в реестр российского ПО попадают только продукты, прошедшие проверку на соответствие требованиям ФСБ и ФСТЭК. При этом около трети крупного бизнеса в России до сих пор работает на закупленном раньше иностранном софте.

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

Если вы планируете переход на отечественное ПО, вот три пункта, которые обязательно нужно проверить на старте:
1) соответствует ли выбранное решение актуальным требованиям ФСТЭК(с 2023–2024 года они поменялись);
2) заложено ли отдельное время на тестирование ИБ;
3) есть ли в команде, которая ведёт переезд, экспертиза именно в проверке безопасности.

Рынок тестирования в России в 2026-м раскололся на два лагеря: "чистый" Manual QA и гибридный SDET - тестировщик, который пишет автотесты и код наравне с разработчиком.

Разница между ними в трёх вещах:
• переход в автоматизацию
• знание языка программирования
• опыт в продуктовой или финтех-разработке.

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

Если вы уже в QA или только заходите в профессию, то вот три ориентира в 2026:
✅автоматизация - не доп., а проходка в Middle+;
✅один язык программирования (Python, Java, JS) закрывает 70% вакансий SDET;
✅опыт в продукте или финтехе повышает ценность специалиста больше, чем ещё один сертификат.

Сроки сдвигаются, а причина каждый раз новая и неожиданная🧐

"Не учли сложность интеграции..."
"Заболел ключевой разработчик..."
"Оказалось сложнее, чем думали..."

По отдельности все эти причины - обыденность разработки, но если посторяется 3-4 раза подряд - уже закономерность.

Собрали чек-лист из своей практики - те звоночки, с которыми к нам чаще всего приходили заказчики, когда искали новую команду:

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

И отдельно - что делать до того, как расторгать договор: как зафиксировать факты, о чём спросить прямо и когда стоит заказать независимый аудит.

Читайте в нашей новой статье → https://clck.ru/3VGocN

«Рынок IT не умер, но лёгкой жизни на нём больше нет» — так наш HR подытожила, что происходит на рынке труда в QA и разработке этой осенью.

Цифры подтверждают: в первом полугодии 2026 IT-вакансий стало на 21% меньше, чем годом раньше, а резюме — наоборот, на 21% больше. Рынок развернулся: раньше компании конкурировали за специалистов, теперь специалистам приходится конкурировать между собой.

Сильнее всего это ударило по простым позициям. Junior Manual QA без технической базы — таких кандидатов сейчас очень много, а вакансий под них мало. Похожая история у части junior-разработчиков: курсы они прошли, а реального опыта с production-кодом, Git, базами и API нет.

При этом легче не стало и senior-специалистам. Вакансий тоже меньше, а требования конкретнее: не «Senior QA», а «QA с API, SQL, автоматизацией и CI/CD». Рынок стал покупать не стаж, а доказанную экспертизу и человек с 8–10 годами опыта вполне может искать подходящую позицию месяцами.

Главный сдвиг: AI не сужает требования к специалистам, а расширяет их. От QA всё чаще ждут не только ручного тестирования, но и API, SQL, автотестов, Git, CI/CD, работы с логами. Сильная связка сейчас — QA + API + SQL + Git + автоматизация, ещё сильнее — AQA/SDET.

Резкого разворота осенью не будет — компании продолжат нанимать точечно, под конкретный набор навыков, а не «ещё одного QA».

Мы в IT Test как раз ищем таких людей — открытые позиции: ittest.ru/career

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

Именно это мы заложили в DoQA.

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

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

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

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

Документация и подробности на сайте doqa.app