«Мне не обязательно уметь автоматизировать, чтобы решать сложные технические задачи»
Поговорили с Алиной, авторкой блога «Багов бояться — в прод не ходить» про роль автоматизации в жизни тестировщиков. Это интервью должно было быть частью дебатов по вопросу «Нужно ли мануальному тестировщику уметь автоматизировать в грядущем году?», но в итоге выходит как манифест моей позиции.
Меня зовут Оля Артемьева. Я — тестировщица, исследовательница и авторка канала «Тестирование и жизнь». Пятнадцать лет в тестировании, написала примерно пять автотестов лет шесть назад.
Необходимо ли тестировщику в 2026 году уметь автоматизировать?
Автоматизация — это один инструмент из десятка, а не мерило профессионализма.
Существует множество вакансий, где ценятся другие навыки: работа с неопределенностью, тест-анализ, понимание рисков, знание домена. В моей практике в Крипто-Про всю автоматизацию делали разработчики — и технических задач у нас было более чем достаточно: от настройки тестовых стендов до особенностей работы физических криптографических устройств.
Я часто слышу, что вакансий с автоматизацией больше. Возможно. Но тестировщице не нужны все вакансии мира, обычно достаточно одной работы в один момент времени.
Почему, на твой взгляд, идея о необходимости автоматизации для всех тестировщиков стала такой популярной?
Потому что люди, принимающие решения о найме, думают, что понимают тестирование. На самом деле они видят только автоматизацию — и принимают её за всю профессию.
Майкл Болтон разделяет два понятия: checking (проверка) и testing (тестирование). Через проверки мы подтверждаем известное: «Эта кнопка работает?». А когда тестируем — исследуем неизвестное: «Какие проблемы здесь могут быть?». Первое легко автоматизировать, второе — нет.
Авторство: @ansh120022
Но менеджеры и лидеры видят только checking. Для них тестирование выглядит как «прокликать форму» — то, что можно делать вручную или быстрее автоматизировать. Как скрепки на заводе. Поэтому и появляются термины «ручное» и «автоматизированное» тестирование — как будто это одно и то же действие, просто выполненное разными способами. А многие часто используют слово «автоматическое», и это скрывает постоянную необходимость человека в этом процессе — разбирать результаты тестов, расследовать проблемы, постоянно поддерживать и развивать систему.
Вторая причина — кодоцентричность IT. Почти все лидеры выросли из разработчиков. Для них сложность = код. Если ты не пишешь код, значит, твоя работа простая. Навык программирования приравнивается к техническим скиллам вообще, хотя я находила проблемы в коде разработчиков через code review, не написав ни строчки своего.
Это касается не только тестировщиков — аналитики, технические писатели, менеджеры сталкиваются с тем же. Если твоя работа не в коде, ее не видно и не ценят.
Какие задачи ручного тестирования невозможно заменить автоматизацией — ни сейчас, ни в ближайшие годы?
Исследование новой функциональности. Когда делаем новую фичу, никто не знает, как она работает на самом деле. Автотест может проверить только то, что в него заложили, а человек видит всю картину и следует вопросу «а что если?». Это помогает найти проблемы в краевых случаях и сложных сценариях, выяснить какие могут быть сложности у пользователей. Многие вещи можно понять, только поработав уже с готовой программой, как не анализируй заранее.
Работа с неопределенностью: анализ требований, сбор потребностей, оценка рисков. Автоматизация лучше всего работает там, где есть четкие правила. Но большая часть работы тестировщика — разбираться с тем, что неочевидно, противоречиво или вообще не задокументировано.
А что насчет LLM? Сейчас много шума про то, что AI напишет тест-кейсы и заменит тестировщиков. Попробуйте сами: дайте ChatGPT описание чего-то сложнее формы регистрации — и посмотрите на результат. Тест-кейсы получаются поверхностными, не учитывают контекст, пропускают критичные сценарии.
И, чтобы научить LLM генерировать что-то полезное, нужна огромная человеческая работа: подготовка требований, настройка промптов, проверка результатов. То есть опять нужен тестировщик.
И даже автоматизация результатов LLM часто требует другой LLM, настройки метрик и исследовательской работы — человеческой.
Какие примеры из практики показывают, что качественный ручной тест может быть ценнее автотеста?
Автотест как любая программа делает ровно то, что в нем написано. Человек же видит всю картину. Разные люди тестируют по-разному — и именно это помогает шире охватить неожиданные риски и проблемы.
Крайне редко автотесты работают идеально. Куда чаще — нестабильные прогоны, непонятные или неполные отчеты, проверки, которые проверяют то, что проще проверить.
Тестирование с автоматизацией и без не конкурируют, а отвечают за разные задачи в продукте.
В моей практике больше всего пользы приносят юнит- и интеграционные тесты, позволяя тестировщикам заниматься действительно сложными вещами. E2E тесты UI, с которых до сих пор начинают автоматизацию многие тестировщики, конечно, зрелищнее. Смотрите, машина нажимает на кнопки как человек! Но на деле они дорогие, хрупкие и требуют много ресурсов для поддержки.
Вспомню кейс из своей работы в Крипто-Про. До сих пор горжусь системой, которую я настраивала для тестирования VPN-шлюза. Кластер из трех виртуальных машин: одна управляющая и две ноды, балансировщик (с этим мне помогал наш девопс), виртуальная машина с клиентом, виртуальная машина в защищенной сети, на которой поднят веб-сервер и запущена страничка с «Hello world!». И только после этого я начала исследовать систему и нашла проблемы, которые ни один автотест не выявил бы — сложности с настройкой инфраструктуры, поддержка разнообразия сценариев и краевых данных.
Горжусь не потому что это технически сложно и интересно (хотя и это тоже), а потому что именно здесь я поняла: мне не обязательно уметь автоматизировать, чтобы решать сложные технические задачи.
Есть ли команды или типы продуктов, где автоматизация скорее вредит, чем помогает?
Да. И таких ситуаций больше, чем кажется.
Сначала уточню: когда говорят про автоматизацию тестировщиками, обычно имеют в виду регрессионные E2E-тесты и интеграционные тесты. Но это не вся автоматизация: низкоуровневые тесты и вспомогательные инструменты приносят намного больше пользы. Дальше буду говорить именно про регрессионную автоматизацию, которую делают тестировщики.
Любая автоматизация — это разработка ПО со всеми ее особенностями: проектирование, разработка, поддержка, развитие. Автоматизация дает быструю обратную связь и уверенность, что конкретные сценарии работают. Но она всегда требует ресурсов.
Когда автоматизация вредит?
Быстро меняющиеся продукты. Если функциональность регулярно переделывается, тесты ломаются быстрее, чем приносят пользу. Вы тратите время на переписывание автотестов вместо исследования новых фич.
Редкие релизы с большими изменениями. Если релизы раз в квартал и каждый раз много нового, регрессия занимает мало времени от всего тестирования. Автоматизировать это нерационально — проще прогнать ключевые сценарии вручную. А если и автоматизировать, то начинать с юнит-тестов в коде, а не с UI.
Стартапы в поиске product-market fit. Продукт может полностью измениться через месяц. Зачем тратить неделю на автотесты, которые выбросят?
Автоматизация тестирования — инструмент, а не серебряная пуля. Иногда лучший выбор — не автоматизировать вообще.
Почему, по твоему мнению, компании продолжают нанимать ручных тестировщиков, несмотря на тренд автоматизации?
Потому что у компаний есть задачи, которые автоматизацией не решить.
Тестирование — это не одна профессия, а целый спектр специализаций. Есть тестировщики-автоматизаторы, которые строят фреймворки и поддерживают инфраструктуру. Есть эксперты по тест-анализу и работе с рисками. Есть специалисты по безопасности, нагрузочному тестированию, доменные эксперты в медицине, финансах, криптографии.
Идея «идеального тестировщика, который умеет все» — это миф. В реальности люди выбирают направление, которое им интересно, и развиваются в нем. Компании это понимают и ищут тех, кто решает их конкретные задачи.
Пример: если вы делаете медицинское ПО, вам нужен тестировщик, который понимает медицину (возможно, сам бывший врач). Автоматизация здесь может быть одним из инструментов, но не главным навыком.
Компании нанимают специалистов под свои задачи, а не «ручных тестировщиков вопреки тренду»: автоматизация далеко не всегда в приоритете.
Какие навыки следует развивать ручному тестировщику в 2026 году? Куда расти без знания кода?
Сначала хочу развенчать популярный миф: «не заниматься автоматизацией» ≠ «не знать кода». Я читаю pull request, понимаю архитектуру систем, работаю с API и базами данных, помогаю разработчикам улучшать их тесты. И не пишу автотесты сама.
«Знание кода» — размытое понятие. Написать Hello, World? Понимать синтаксис? Реализовать сортировку пузырьком? Писать автотесты в готовом фреймворке? Это все разные навыки для разных задач.
Примеры направлений для роста:
— Техническое понимание систем — как устроены веб-приложения, API, базы данных, сети. Умение читать логи и понимать архитектуру. И разрабатывать стратегию тестирования на этой базе.
Тест-анализ и работа с рисками — строить тестовые модели, приоритизировать проверки, задавать правильные вопросы.
Экспертиза в домене — финансы, медицина, e-commerce, криптография. Глубокое понимание предметной области делает вас незаменимым.
Работа с людьми и неопределенностью — собирать требования, выстраивать тестовую стратегию, работать с аналитиками и разработчиками.
Но главное: никто не знает, что развивать именно вам, кроме вас самих. Это поле для исследования.
Посмотрите на задачи, которые вам интересны. Изучите вакансии в вашей области. Поговорите с опытными тестировщиками, которые работают там, куда вы хотите прийти. Соберите профиль специалиста, которым хотите стать. Попробуйте разное и смотрите, что дает результаты.
Ваш путь — это ваше исследование, а не готовый роадмап из сети.
Что бы ты сказала новичку, который сомневается: идти в автоматизацию или развиваться в глубину ручного направления?
Идите за тем, что вам интересно и что дает результаты уже сейчас. Не за тем, что «все говорят» и «всем известно».
Давайте честно про цену.
Автоматизация с нуля — это минимум год, а в реальности еще больше. Слишком интенсивные и плохо спроектированные курсы. Работа, где не остается времени на практику, а результаты хотят еще вчера. Или прямо говорят заниматься автоматизацией в свое свободное время. Ожидания, что FullStack будет работать за двоих.
Мы слышим голоса тех, у кого получилось. Но мало кто рассказывает про свои стартовые условия. Когнитивные и эмоциональные ресурсы, возможность учиться после работы, а не готовить ужин или проверять домашку. В конце концов, полузабытый курс программирования в институте.
Мы мало слышим про то, чего это обучение людям стоило. Про выгорание, бросание курсов и новые попытки. Про слезы от усталости и ощущение полного провала, когда ты просто не можешь это сделать, даже если прикладываешь все силы.
Конечно, если бы вам предложили проснуться с навыками программирования на уровне мидл-программиста и парой фреймворков в придачу — не думаю, чтобы кто-нибудь отказался. Если вы попадаете в тренды, то искать свое место на рынке проще, чем если вы редкая специалистка. Но в реальности за освоением этих трендов стоит очень большая работа и много усилий.
Поэтому взвесьте: готовы ли вы заплатить эту цену? И главное — за что именно?
Возможно, вам не нужна автоматизация как таковая. Может быть, достаточно базового понимания программирования — как устроены программы, какие есть подходы к их разработке. Это принесет результаты быстрее, чем годичные курсы по Playwright. Или вам стоит вложиться в понимание архитектуры приложений. Или освоить специфику вашего домена.
Используйте продуктовый подход к своей карьере:
изучайте реальность, а не верьте мнению, что «ручное тестирование умирает»
выдвигайте гипотезы: «Если я изучу X, смогу ли я решать задачи Y?»
начинайте с MVP — пройдите короткий курс, решите небольшую задачу на работе
смотрите на результаты и решайте, двигаться дальше или развернуться
Все так же, как в Agile, только с вашей карьерой.
И главное: не поддавайтесь на ложную дихотомию «автоматизация или ручное тестирование». Это не выбор из двух вариантов. Это разные инструменты и специализации в одной профессии. Можно знать и то, и другое в разной степени. Можно выбрать третий путь — безопасность, тест-анализ, тест-менеджмент. Вариантов всегда больше, чем кажется.
Я год работаю в команде, где никто не пытается объяснить мне, как делать мою работу, а просто ценят мою экспертизу. Я просто делаю то, что умею лучше всего, приношу идеи, советуюсь, думаю вместе с коллегами. Это должно быть нормой, но встречается так редко, что до сих пор восхищает меня.
Такие команды действительно существуют и встречаются чаще, чем единороги.