Тестирование ПО 2026: гайд по QA, инструментам, карьере

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

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

Что такое QA в 2026: вышло из тени

QA больше не отдел «проверить перед продом»

Ещё десять лет назад QA часто воспринимали как команду, которая получает готовую сборку, заводит баги в Jira и героически спасает релиз в пятницу вечером. В 2026 году такой подход выглядит как технический долг, только в организационной форме. Современное тестирование ПО начинается задолго до первого клика по интерфейсу: с требований, архитектурных решений, API-контрактов, пользовательских сценариев, рисков безопасности и стоимости отказа.

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

Quality Assurance против Testing

Testing — это проверка продукта: руками, автотестами, нагрузкой, сканерами, эмуляторами, моками. QA шире: это процесс обеспечения качества. В него входят критерии готовности, стратегия тестирования, тест-дизайн, автоматизация, контроль flaky-тестов, работа с инцидентами, анализ дефектов и улучшение delivery-процесса.

• Tester проверяет конкретную функцию и фиксирует отклонения.
• QA Engineer проектирует проверки и управляет рисками качества.
• QA Automation пишет и поддерживает автотесты.
• SDET строит тестовую инфраструктуру почти как разработчик.
• QA Lead отвечает за процессы, людей, метрики и зрелость качества.

Почему QA стал заметнее

Причина не в моде на красивые должности. Продукты стали сложнее. Типичная система в 2026 году — это веб, мобильное приложение, несколько backend-сервисов, очереди, платежи, аналитика, feature flags, интеграции с внешними провайдерами и CI/CD, который выкатывает изменения хоть каждый день. Один дефект может стоить не только денег, но и доверия: сбой в финтехе, утечка персональных данных, ошибка в медицинском сервисе или падение маркетплейса в день распродажи быстро превращаются в публичный кейс.

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

Виды тестирования: unit, integration, e2e, perf, sec

Unit: быстрые проверки на уровне кода

Unit-тесты проверяют маленькие изолированные части системы: функцию, метод, класс, компонент. Их обычно пишут разработчики, но QA должен понимать, что именно покрыто, а где остаются риски. Хороший unit-тест выполняется за миллисекунды, не ходит в реальную базу, не зависит от сети и даёт точный сигнал: сломалась конкретная логика.

В зрелых командах unit-покрытие часто держат в диапазоне 60-90% для критичного бизнес-кода, но сама цифра не священная. 95% покрытия бесполезны, если тесты проверяют только happy path. Для расчёта скидок, лимитов, налогов, скоринга, прав доступа и биллинга важнее покрыть граничные значения, ошибки округления, пустые состояния и конфликтные правила.

Integration и contract: проверяем стыки

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

Для микросервисов особенно важны contract-тесты. Они фиксируют договор между consumer и provider: какие поля есть в ответе, какие типы допустимы, какие статусы возвращаются при ошибках. Если команда меняет API без обратной совместимости, contract-тест должен упасть раньше, чем это увидит мобильное приложение в продакшене.

E2E, performance и security

E2E-тесты проверяют путь пользователя целиком: регистрация, вход, поиск товара, добавление в корзину, оплата, получение подтверждения. Это ближе всего к реальной жизни, но дороже всего в поддержке. Браузерные сценарии медленнее unit-тестов в десятки и сотни раз, зависят от данных, окружения, сети и UI. Поэтому e2e используют выборочно: для критичных сценариев, а не для каждой кнопки.

Performance-тестирование отвечает за скорость и устойчивость: сколько RPS держит сервис, где начинается деградация, как ведёт себя база при 10 000 одновременных пользователей, что происходит после 2 часов нагрузки. Security-проверки ищут уязвимости: XSS, SQL injection, небезопасные прямые ссылки на объекты, слабую авторизацию, утечки токенов. В 2026 году тестирование ПО без базовой безопасности выглядит неполным, особенно для финтеха, e-commerce, HRTech, EdTech и B2B SaaS.

Тип проверки	Что ловит	Скорость	Кто чаще отвечает
Unit	Ошибки логики в малых модулях	Миллисекунды-секунды	Разработчик
Integration	Проблемы на стыках сервисов	Секунды-минуты	Dev и QA
E2E	Сломанные пользовательские сценарии	Минуты	QA Automation
Performance	Падение скорости и устойчивости	Минуты-часы	Performance Engineer
Security	Уязвимости и ошибки доступа	От минут до дней	Security QA, AppSec

Ручное vs автоматизированное

Manual QA не умер, но изменился

Каждый год кто-то торжественно хоронит ручное тестирование. Обычно это люди, которые потом три дня чинят автотест, упавший из-за изменённого селектора. Manual QA в 2026 году жив, но роль стала требовательнее. Компании всё меньше готовы платить за простое прохождение чек-листа без понимания продукта, API, логов и данных.

Ручной QA особенно полезен там, где важны исследовательское мышление, UX, неоднозначные требования, новые функции и риск неизвестных дефектов. Автотест хорошо проверяет то, что уже формализовано. Человек лучше находит странности: непонятную формулировку, неверный порядок действий, конфликт бизнес-правил, раздражающий сценарий, который формально «работает».

Где автоматизация окупается

Автоматизация нужна, когда проверка повторяется часто, сценарий стабилен, цена регресса высока, а ручное выполнение съедает часы команды. Классические кандидаты: авторизация, оплата, создание заказа, расчёт тарифа, API-контракты, миграции, критичные интеграции, smoke-набор перед релизом.

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

• Автоматизируйте частые регрессионные проверки.
• Оставляйте руками исследовательские сценарии и ранние фичи.
• Не автоматизируйте одноразовые проверки без бизнес-риска.
• Пересматривайте набор раз в 1-2 спринта, иначе он зарастёт мусором.
• Следите за flaky rate: если нестабильных тестов больше 3-5%, доверие к прогону падает.

Гибрид стал нормой

На рынке всё чаще ищут не «manual или auto», а QA-инженера с гибридным профилем. От Middle обычно ждут SQL, Postman, DevTools, понимание HTTP, базовый скриптинг на Python или JavaScript, умение читать логи и работать с CI. От Senior — архитектуру автотестов, моки, контейнеры, тестовые данные, метрики качества и способность объяснить, почему этот тест должен быть на уровне API, а не UI.

Ручное и автоматизированное тестирование ПО не конкурируют, если команда понимает их назначение. Ручные проверки дают разведку, гибкость и продуктовую чувствительность. Автотесты дают скорость, повторяемость и защиту от регресса. Сильный QA умеет выбирать инструмент под риск, а не под моду.

Фреймворки: pytest, Jest, Playwright, Selenium, Cypress

pytest и Jest: база для кода и API

pytest остаётся одним из самых практичных инструментов для Python-проектов. Его любят за простую структуру тестов, fixtures, параметризацию, плагины и хорошую читаемость. Он подходит для unit, API, интеграционных и даже некоторых end-to-end проверок. В backend-командах на Python pytest часто становится стандартом де-факто: быстро стартует, легко расширяется, нормально живёт в CI.

Jest занимает похожую позицию в JavaScript и TypeScript-экосистеме. Его используют для unit-тестов, React-компонентов, Node.js-сервисов и утилит. В 2026 году Jest всё ещё распространён, хотя рядом активно живут Vitest и Testing Library. Для QA важно не столько название раннера, сколько понимание принципов: изоляция, моки, snapshot-тесты, покрытие граничных случаев, скорость выполнения.

Playwright, Selenium и Cypress

Playwright заметно усилился как инструмент для браузерной автоматизации. Он поддерживает Chromium, Firefox и WebKit, умеет работать с несколькими вкладками, перехватывать сеть, делать trace, скриншоты и видео. Для современных веб-приложений на React, Vue, Angular и Svelte это часто первый кандидат, особенно если команда пишет на TypeScript.

Selenium не исчез. Он старше, тяжелее, местами менее удобен, зато в enterprise-среде живёт долго: банки, страховые, крупные корпорации, старые тестовые стенды, Java-стек, Selenium Grid. Если продукту 12 лет и вокруг него выросла инфраструктура, никто не перепишет её только потому, что в блоге красиво показали Playwright trace viewer.

Cypress остаётся сильным выбором для фронтенд-команд, которым важна удобная отладка и плотная интеграция с браузером. Его часто используют разработчики для компонентных и e2e-тестов. Ограничения тоже есть: исторически Cypress был менее гибок в multi-tab и некоторых cross-browser сценариях, хотя платформа развивалась. Выбор зависит от продукта, стека и команды.

Инструмент	Где силён	Язык	Типичный сценарий
pytest	Backend, API, интеграции	Python	Сервисные и API-тесты
Jest	Frontend, Node.js	JavaScript/TypeScript	Unit и компонентные тесты
Playwright	Современный web e2e	TypeScript, Python, Java, .NET	Критичные UI-сценарии
Selenium	Enterprise и legacy	Java, Python, C#, JS	Большие долгоживущие наборы
Cypress	Frontend-команды	JavaScript/TypeScript	UI и компонентные проверки

Как выбирать без религиозных войн

Инструмент должен отвечать на четыре вопроса: кто будет писать тесты, где они будут запускаться, как быстро команда сможет их чинить и какой риск они закрывают. Для Python-backend логичен pytest. Для TypeScript-фронтенда — Playwright или Cypress. Для старого Java-enterprise — Selenium может быть рациональнее новой моды.

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

AI в тестировании: Testim, Mabl, генерация тестов

Что AI уже делает полезно

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

Testim, Mabl и похожие платформы используют машинное обучение для стабилизации UI-тестов, self-healing локаторов, визуальных проверок и генерации сценариев. Для команд без большой automation-инфраструктуры это может ускорить старт. Но цена обычно enterprise-уровня: от сотен до тысяч долларов в месяц в зависимости от числа прогонов, пользователей и интеграций. Для стартапа на ранней стадии это не всегда рационально.

Генерация тестов: удобно, но не магия

LLM хорошо пишет черновики: «сгенерируй негативные сценарии для формы регистрации», «покрой API метод cases для 400/401/409/500», «создай Playwright-тест по этому user story». Проблема в том, что модель не знает реальных бизнес-ограничений, исторических дефектов, скрытых интеграций и того, что продакт вчера в чате назвал «временным решением на квартал».

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

• Хороший кейс: быстро получить список проверок по новой фиче.
• Хороший кейс: сгенерировать boilerplate для Playwright, pytest или Jest.
• Хороший кейс: разобрать stack trace и предложить вероятную причину падения.
• Плохой кейс: без ревью принять AI-тесты в критичный пайплайн.
• Плохой кейс: отправлять в публичную модель персональные данные или закрытый код.

Новые требования к QA

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

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

Test pyramid и стратегии тестирования

Пирамида всё ещё работает

Test pyramid — простая идея: внизу много быстрых unit-тестов, выше меньше интеграционных, ещё выше немного e2e. Чем выше уровень, тем дороже тест, тем медленнее прогон и тем сложнее диагностика. Эта модель не идеальна для всех продуктов, но как базовая гигиена работает до сих пор.

Типичная здоровая пропорция для web-сервиса может выглядеть так: 60-70% unit и компонентных тестов, 20-30% API и integration, 5-10% e2e. Для embedded, игр, data-платформ или мобильных приложений расклад будет другим. Главное — не строить перевёрнутую пирамиду, где сотни UI-тестов пытаются доказать то, что дешевле проверить на уровне функции или API.

Стратегия начинается с рисков

Стратегия тестирования — это не документ на 40 страниц, который никто не открывает. Это набор решений: что проверяем, на каком уровне, какими инструментами, с какими данными, как часто, кто владелец, какой сигнал блокирует релиз. Хорошая стратегия помещается в несколько страниц и обновляется вместе с продуктом.

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

1. Определите критичные пользовательские пути.
2. Разделите риски по цене ошибки: деньги, данные, безопасность, репутация, UX.
3. Выберите уровень проверки: unit, API, integration, e2e, perf, sec.
4. Настройте минимальный smoke-набор для каждого релиза.
5. Добавьте метрики: defect leakage, flaky rate, время прогона, покрытие критичных сценариев.
6. Пересматривайте стратегию после крупных инцидентов и архитектурных изменений.

Метрики без театра

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

Тестирование ПО становится управляемым, когда команда видит качество как систему, а не как героизм одного Senior QA. Если каждый релиз зависит от конкретного человека, который «помнит, куда нажать», это риск. Если проверки описаны, автоматизированы там, где надо, и встроены в pipeline, команда может выпускать чаще и спокойнее.

Грейды QA: Junior, Middle, Senior, Lead

Junior: не просто «кликает»

Junior QA в 2026 году — это специалист, который умеет работать по готовым требованиям, писать понятные баг-репорты, составлять чек-листы, пользоваться DevTools, Postman, SQL на базовом уровне и понимать клиент-серверную архитектуру. От него не ждут проектирования стратегии, но ждут аккуратности и обучаемости.

Порог входа вырос. «Прошёл курс, знаю, что такое баг» уже мало. Нужны HTTP-методы, статусы ответов, JSON, cookies, local storage, базовые SELECT-запросы, понимание мобильных платформ и умение воспроизвести дефект без драматического описания «оно не работает».

Middle и Senior: автономность и инженерная глубина

Middle QA берёт фичу и сам понимает, как её проверять. Он уточняет требования, проектирует тесты, готовит данные, проверяет API, умеет читать логи, заводит дефекты с нормальной диагностикой, участвует в регрессии и может поддерживать автотесты. Обычно это уровень 1,5-3 года опыта, хотя календарь не заменяет компетенции.

Senior QA отвечает не только за свои задачи, но и за качество подхода. Он видит архитектурные риски, предлагает уровни автоматизации, помогает разработчикам писать тестируемый код, разбирает инциденты, снижает flaky rate, строит тестовые данные, настраивает CI-прогоны и объясняет бизнесу, почему релиз лучше отложить на день. Senior часто пишет код не хуже junior-разработчика, особенно если это automation или SDET-профиль.

Lead: люди, процессы и ответственность

QA Lead управляет качеством на уровне команды или нескольких команд. Его работа — не только распределить задачи. Он отвечает за стратегию, найм, развитие специалистов, стандарты автотестов, метрики, взаимодействие с разработкой и продуктом, качество релизного процесса. В зрелых компаниях Lead влияет на Definition of Done, release policy и postmortem-практики.

Грейд	Опыт	Что должен уметь	Главный маркер
Junior	0-1,5 года	Чек-листы, баги, базовый API, SQL, DevTools	Работает по понятной задаче
Middle	1,5-3 года	Тест-дизайн, API, логи, регрессия, базовая автоматизация	Ведёт фичу автономно
Senior	3-6 лет	Стратегия, архитектура тестов, CI, риски, наставничество	Улучшает систему качества
Lead	5+ лет	Процессы, найм, метрики, релизы, управление командой	Отвечает за качество направления

Грейд — это не медаль за выслугу лет. Можно пять лет выполнять однотипную ручную регрессию и остаться на уровне уверенного Middle. А можно за три года вырасти до Senior, если постоянно брать сложные зоны: API, автоматизацию, производительность, тестовые данные, инциденты и архитектурные обсуждения.

Зарплаты QA в РФ 2026

Рынок стал жёстче к входу

Зарплаты QA в России в 2026 году сильно зависят от грейда, специализации, города, домена и формата работы. По открытым данным hh.ru, Хабр Карьеры, Dream Job, GetGrade и зарплатных обзоров, массовый диапазон для тестировщиков находится примерно между 90 и 250 тыс. ₽ gross в месяц, но автоматизаторы, SDET и лиды в финтехе могут получать заметно выше.

Junior-позиции стали менее дружелюбными. Компании не хотят тратить 6 месяцев на человека, который не понимает API и SQL. Зато Middle+ с автоматизацией, backend-контекстом, Kafka, Docker, CI/CD и опытом микросервисов остаются востребованными. Вакансии с Java, Python, TypeScript, Playwright, Selenium, REST, SQL и Linux стабильно выглядят сильнее, чем «ручное тестирование сайта по чек-листу».

Ориентиры по деньгам

Ниже — практичная вилка для РФ на 2026 год. Это не обещание оффера, а рыночный ориентир: gross до НДФЛ, для коммерческого IT, без экстремальных выбросов вроде редких офферов на 700-900 тыс. ₽.

Грейд	Manual QA	QA Automation	SDET / Lead
Junior	60-100 тыс. ₽	80-130 тыс. ₽	Редко
Middle	120-190 тыс. ₽	170-270 тыс. ₽	220-320 тыс. ₽
Senior	200-300 тыс. ₽	260-420 тыс. ₽	320-500 тыс. ₽
Lead	250-380 тыс. ₽	350-550 тыс. ₽	450-650 тыс. ₽

Москва и крупный финтех обычно платят на 15-35% выше регионального рынка. Санкт-Петербург близок к Москве в сильных компаниях, но медиана чаще ниже. Удалёнка по РФ может быть как московской, так и региональной: всё зависит от работодателя. Международные контракты для QA из РФ встречаются, но из-за платежей, налогов и комплаенса стали сложнее, чем в 2020-2021 годах.

Что сильнее всего влияет на оффер

• Автоматизация: Python, Java, TypeScript, Playwright, Selenium, pytest, Jest.
• Backend-навыки: REST, gRPC, SQL, очереди, Docker, Linux, логи.
• Домен: финтех, e-commerce, telecom и enterprise обычно платят выше простых контентных проектов.
• Ответственность: релизы, инциденты, стратегия, наставничество, ownership.
• Английский: B1-B2 открывает больше удалённых и продуктовых вакансий.

Главный вывод простой: тестирование ПО оплачивается тем выше, чем ближе специалист к инженерным решениям и бизнес-рискам. Человек, который проверяет формы, стоит дешевле. Инженер, который предотвращает падение платежей, ускоряет релизы и снижает число продакшен-инцидентов, стоит дороже.

Сертификации: ISTQB, AAT

ISTQB: полезная база, но не пропуск в профессию

ISTQB остаётся самой узнаваемой международной сертификацией для тестировщиков. Foundation Level покрывает терминологию, жизненный цикл разработки, уровни и виды тестирования, техники тест-дизайна, управление дефектами и базовые процессы. Для Junior это хороший способ систематизировать знания и говорить с командой на одном языке.

Но сертификат не заменяет опыт. Работодатель скорее спросит, как вы тестировали API, почему выбрали такие классы эквивалентности, как локализовали дефект и что делали с нестабильными автотестами. Бумага помогает пройти первичный фильтр, особенно в enterprise и аутсорсе, но не спасает на техническом интервью.

AAT и автоматизация

AAT обычно используют как обозначение сертификаций и программ по автоматизированному тестированию, включая практики acceptance automation и инструменты автотестов. В отличие от базового ISTQB, такие программы ценны только там, где есть практика: код, CI, реальные фреймворки, отчёты, работа с тестовыми данными.

Если выбирать обучение, смотрите не на громкое название, а на содержание. В программе должны быть HTTP, API, SQL, Git, CI/CD, один язык программирования, Page Object или Screenplay-подход, моки, отчёты, параллельный запуск, Docker хотя бы на базовом уровне. Без этого курс по автоматизации превращается в набор красивых скриншотов.

Сертификация	Кому полезна	Что даёт	Ограничение
ISTQB Foundation	Junior, Manual QA, аналитикам	Базовую терминологию и системность	Мало практики
ISTQB Advanced	Middle+, Lead	Глубину по менеджменту, аналитике, техникам	Нужен опыт, иначе сухо
AAT / Automation QA	QA Automation, SDET	Практику автотестов и CI	Качество сильно зависит от программы

Что важнее сертификата

Для рынка РФ в 2026 году портфолио часто убедительнее сертификата. Небольшой GitHub-проект с pytest или Playwright, API-тестами, отчётом Allure и запуском в GitHub Actions покажет больше, чем строка «прошёл курс». Для Junior это особенно важно: коммерческого опыта нет, значит надо показать инженерное мышление.

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

Куда расти: SDET, Performance Engineer, Security QA

SDET: QA с инженерным позвоночником

SDET — Software Development Engineer in Test — это роль для тех, кому нравится качество, но хочется больше кода и инфраструктуры. SDET проектирует фреймворки автотестов, пишет библиотеки, строит test harness, готовит данные, настраивает параллельные прогоны, интегрирует проверки в CI/CD и помогает разработчикам делать код тестируемым.

От SDET ждут уверенный язык программирования, понимание архитектуры приложений, контейнеров, сетей, баз данных и наблюдаемости. Это уже не «автоматизатор, который записывает клики». Хороший SDET может спорить о контракте API, предложить мок-сервис, ускорить прогон с 50 до 12 минут и убрать половину flaky-тестов.

Performance Engineer: скорость стоит денег

Performance-направление подходит тем, кто любит цифры, графики и неприятные вопросы вроде «почему p95 вырос с 300 мс до 1,8 секунды?». Performance Engineer строит нагрузочные профили, моделирует пользователей, анализирует latency, throughput, CPU, память, базы данных, кеши, очереди и сетевые задержки.

Инструменты зависят от стека: JMeter, k6, Gatling, Locust, Grafana, Prometheus, OpenTelemetry, APM-системы. Важна не только способность «дать нагрузку», а умение интерпретировать результат. 1 000 RPS в вакууме ничего не значат, если профиль не похож на реальное поведение пользователей, а тестовый стенд в 4 раза слабее прода.

Security QA: качество без дыр

Security QA находится между классическим тестированием и AppSec. Специалист проверяет авторизацию, права доступа, обработку пользовательского ввода, хранение токенов, конфигурации, зависимости, API, мобильные клиенты. Базовый набор знаний: OWASP Top 10, Burp Suite, ZAP, JWT, OAuth2, CORS, SQL injection, XSS, IDOR, SSRF, секреты в репозитории.

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

Трек	Что учить	Кому подходит	Потолок в РФ
SDET	Код, CI/CD, фреймворки, Docker, API	QA, которым нравится разработка	400-650 тыс. ₽
Performance Engineer	k6/JMeter, Linux, БД, метрики, APM	Тем, кто любит диагностику и системы	350-600 тыс. ₽
Security QA	OWASP, Burp, авторизация, web security	Тем, кто любит искать слабые места	350-650 тыс. ₽

Лучший карьерный ход — не пытаться выучить всё сразу. Выберите один трек на 6-9 месяцев, соберите практический проект, внедрите навык на текущей работе и зафиксируйте результат в резюме: ускорил регрессию на 40%, снизил flaky rate с 12 до 4%, нашёл критичную IDOR-уязвимость, внедрил smoke в CI. Рынок любит не списки технологий, а доказанные эффекты.

Глубже на тему — исследования it-institute.ru

На партнёрском портале it-institute.ru опубликована подборка релевантных исследований с медианами, выборками и методологией:

• Инженерные метрики: DORA и что измерять
• DevEx и Productivity Engineering: тренды
• DevSecOps и безопасная поставка ПО
• Зарплаты IT-разработчиков 2024–2026

Партнёрские проекты

• Agency-IT — IT-аутсорсинг и команды на проект

FAQ о тестирование ПО

Следите за обновлениями itech-news.ru — мы держим эту страницу актуальной.