Вступление
Привет! Меня зовут Илья, я работаю Manual QA в команде, которая отвечает за качество продукта с большим количеством микросервисов, API и регулярными релизами. Если вы хоть раз писали тест-кейсы по тикету из Jira, потом руками собирали Postman-коллекцию по OpenAPI-спецификации, а после ревью документации обнаруживали, что половину сценариев забыли — эта статья для вас.
Хочется поговорить о том, что происходит с QA в 2026-м и правда ли, что «нас вот-вот заменит ИИ». Но не в формате очередного треда в духе «всё пропало» или «всё отлично, завтра уволим половину отдела». А по-взрослому: с опытом, цифрами, ограничениями и выводами. То есть попробовать не просто порассуждать, а разобрать тему как небольшое исследование: что реально меняется, где ИИ помогает, а где начинается та самая реальность, которая не влезает в красивую презентацию.
Моки — достаточно крутой инструмент, если использовать его правильно.
И все-таки лично для меня писать и поддерживать тесты на моках всегда было отдельным видом боли. Думаю, все знакомы с ситуацией: добавил в метод новый аргумент — и пошёл в 30 тест-кейсов проставлять заглушки. И это только от одного нового аргумента.
Не так давно мне попался ноутбук Acer TravelMate B1 TMB118 с 4 ГБ DDR4. Благодаря размеру и маленькому потреблению он идеально подошел под эксплуатацию в виде печатной машинки и простенького редактора кода.
Начиная писать Flutter-приложение, для стейт-менеджмента часто хватает простого setState или решения по типу BLoC/Cubit без излишеств. Но с течением жизни проекта ваши блоки могут начать превращаться в god objects. Внутри хендлеров могут находиться и запросы в сервисы, и валидация, и эмиттеры состояния, а для крупной страницы точно одним ивентом не обойдешься. В таких условиях разработка сильно затрудняется, становится сложно поддерживать и масштабировать проект, снижается тестируемость.
Не так давно я ездила на конференцию, где в том числе разбиралась важность мягких навыков, хотя вообще конференция то была по моделям ИИ и по тестированию. Но даже сюда, в святую святых для меня, в тестирование, запихали эти их «важные» навыки. Я перечислю основные мягкие навыки, которые разбирались. Адаптивность, коммуникабельность, стрессоустойчивость, тайм менеджмент, эмоциональный интеллект, обучаемость. Именно они сейчас в топе у HR и тимлидов.
Давайте разберемся, что это за навыки и почему «Баба-яга против!». Я действительно против.
Когда в проекте появляются сложные сценарии: нестабильный бэкенд, редкие ошибки, зависимость от внешних сервисов, классические инструменты тестирования могут тормозить. Любая правка требует участия сервера, а воспроизведение бага превращается в квест.
В этот момент прокси-инструменты вроде Proxyman начинают играть совсем другую роль. Это уже не просто «посмотреть запросы», а полноценный слой управления трафиком.
Меня зовут Станислав, я Test-инженер в KODE, в этой статье разберу, как использовать Proxyman Scripts не как вспомогательную фичу, а как инструмент автоматизации тестирования.
Синтетические тесты в вакууме не показывают реальной пользы нейросетей. Индустрии пора переходить на метрики, где во главе угла стоят люди и жизненный контекст
От переводчика:Читать полностью »
“В больших проектах есть необходимость контролировать очень много критичных частей, и не всегда есть время на их контроль вручную”
Работая в Сбере, я столкнулся с тем, что общепринятым инструментом для функционального тестирования в моем трайбе был JMeter. Нравится ли мне это? Вопрос второстепенный. Приходилось работать с тем, что есть. По мере того как разрастались наши компоненты и их функциональность - разрастались и JMeter-тесты. Если кто не сталкивался - вся логика JMeter-тестов описана в файле с расширением .jmxЧитать полностью »
