Перевод статьи “Test smart: how to apply automation and stay sane?”

За последнее десятилетие автоматизация стала неотъемлемой частью в мире тестирования. Сегодня, с появлением большого количества инструментов, перед специалистами стоит задача грамотно и эффективно её применять.

Во время путешествия по Тоскане я заглянула в музей Леонардо да Винчи. Меня поразило количество проектов, созданных Леонардо. Особенно запомнилась автоматическая машина для чеканки золота, предназначенная для флорентийских ткачей.

🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks

Желание повысить эффективность с помощью автоматизации — штука не новая. А может, Леонардо да Винчи просто значительно опережал своё время?

Сегодня автоматизация — это уже не просто тренд. Она вышла за рамки производства и стала обязательной частью цифровых процессов. Разработка (и тестирование) становятся всё более эффективными благодаря CI/CD-пайплайнам, которые активно используют agile-команды. В QA появляются новые роли — инженеры по автоматизации тестирования. Автоматизация сильно влияет на отрасль, и с появлением всё большего числа AI-инструментов можно ожидать ещё больше перемен.

Хайп вокруг автоматизации никуда не делся

Меньше десяти лет назад вокруг автоматизации в QA разгорелся настоящий ажиотаж: казалось, что с внедрением CI/CD можно автоматизировать вообще всё — в том числе и тестирование. Помню, как в QA-среде шли жаркие споры — что нас ждёт дальше? И, если честно, оптимизма было немного. Многие тестировщики чувствовали уязвимость — автоматизация сместила привычные роли и породила неуверенность в завтрашнем дне.

Сокращение релизных циклов действительно потребовало усиленной автоматизации. Тестирование нужно было проводить быстрее — в условиях так называемой «быстрой разработки», иначе QA становился узким местом. Agile-команды начали автоматизировать рутинные проверки, например end-to-end тесты, чтобы освободить время для более сложных, но всё ещё ручных подходов — например, исследовательского тестирования. Наиболее востребованными были Selenium и Cypress — фреймворки, требующие хотя бы базовых знаний кода. Такая модель сохранялась до 2020-х годов.

Спустя несколько лет появились инструменты автоматизации, основанные на искуственном интеллекте. Некоторые из них вообще не требуют навыков программирования (прощайте, старые добрые Selenium и Cypress!). То, что раньше отнимало значительное количество времени и ресурсов, теперь можно автоматизировать с минимальными усилиями — просто записав тест с помощью AI-инструмента.

Можно ли полностью положиться на автоматизацию?

Хотя инструменты автоматизации (включая те, что работают на базе ИИ) отлично справляются с функциональными тестами, основанными на чётких требованиях, остаются вопросы: способна ли машина адекватно оценивать нефункциональные характеристики, такие как удобство использования? И достаточно ли чувствительны современные решения, чтобы корректно проверять доступность продукта для пользователей с особыми потребностями? На практике в этих областях по-прежнему применяются ручные методы тестирования.

Автоматизированное тестирование имеет и другие ограничения. Если команда начинает сокращать время на ручную проверку и полагаться исключительно на список автотестов, которые якобы подтверждают готовность продукта к релизу, это может создать иллюзию полной уверенности в качестве. Однако если тесты охватывают лишь функциональность A и B, а C и D остаются без внимания — появление новых дефектов становится почти неизбежным.

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

Как отмечает Кейт Дэймс, у ручного тестирования есть свои плюсы и минусы:

«Люди хорошо замечают несоответствия. Они также умеют разбираться, почему что-то не работает или где кроется ошибка. Зато технологии намного лучше справляются с рутиной — с повторением одного и того же снова, снова и снова. Когда человек устаёт, отвлекается или просто привыкает к тому, что перед ним, технология, наоборот, чувствует себя в своей стихии, повторяя одно и то же бесконечно».

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

Автоматизация ради автоматизации — плохая идея

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

Мне понравилась идея, которой поделилась Ирина Супрун. Она сказала:

«Не стоит автоматизировать что-то просто ради самой автоматизации или ради достижения какого-то процента покрытия, который кто-то когда-то назвал обязательным. Это не обязательно — особенно если у вас ограниченные ресурсы. Единственное, что действительно обязательно — это выпустить продукт, которым будут с удовольствием пользоваться клиенты, и при этом быть прибыльной компанией. А если вы всё-таки решили, что автоматизация нужна — делайте её на самом низком возможном уровне. Не пишите end-to-end тест, если достаточно юнит-теста».

Эта идея хорошо согласуется с популярной концепцией пирамиды тестирования (Test Automation Pyramid). Согласно ей, чем ниже уровень тестов, тем больше их нужно автоматизировать.

Что касается визуализации, мне ближе модель перевёрнутой пирамиды тестирования — так называемый фильтр ошибок, предложенный Ноем Сассманом. Юнит-тесты способны обнаружить ошибки на ранних стадиях разработки, в то время как интеграционные и UI (end-to-end) тесты выявляют их на более поздних этапах.

Звучит немного идеалистично, но почему бы не стремиться к более умному подходу к автоматизации? Чем раньше будут выявлены ошибки (например, на этапе юнит-тестов), тем меньше времени и усилий потребуется для их исправления в дальнейшем.

И не удивляйтесь, если ваше покрытие тестами будет включать лишь 20% автоматизированных end-to-end тестов. Это вполне может быть нормой в конкретной ситуации. Например, я работала над проектом, где автоматизация была ограничена из-за зависимостей между несколькими компонентами продукта. Поэтому были автоматизированы только те тесты, которые можно было покрыть. В противном случае это было бы пустой тратой времени и усилий.

Также важно, чтобы команда определила, какие части продукта наиболее подвержены рискам, и сосредоточила усилия на их автоматизации. Например, для e-commerce продуктов критически важен процесс оформления заказа. Тесты, которые проверяют этот процесс, идеально подходят для автоматизации.

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

Автоматизация всё равно требует участия человека

Помимо выбора того, что автоматизировать, стоит помнить, что результаты автоматических тестов всё равно должны контролироваться людьми. Даже если уведомление приходит из пайплайна, оно направляется к человеку (тестировщику или разработчику), который проверяет, возникли ли баги или регрессия.

Кроме того, возникает вопрос, кто будет поддерживать автоматизированные тесты в случае внесения изменений в продукт. Например, некоторые тесты могут стать избыточными или обновленные функции должны быть учтены в наборе автоматических тестов. Я бы не стала полагаться на ИИ, даже если инструмент на базе ИИ утверждает, что он «самовосстанавливающийся» и «самоуправляемый». Человек всё равно должен контролировать этот процесс.

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

Будущее автоматизации

Трудно предсказать, что произойдет в QA-сфере через 10–20 лет. Однако, по словам некоторых экспертов отрасли, автоматизация (как текущая тенденция в QA) может выйти на новый уровень в ближайшие годы. Следующий шаг — автономное тестирование (что немного напоминает автономное вождение — привет Илону Маску). Это означает, что ИИ-боты будут выполнять все тесты вместо людей… Но готовы ли мы к этому?

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

Сможет ли технология ИИ в будущем интегрировать эти ценности? Время покажет… В любом случае, я уверена, что специалисты по тестированию всё равно будут вносить свой вклад в качество цифровых продуктов и в будущем.

В целом, я поддерживаю идею сбалансированного тестирования: автоматизация не заменит человеческую креативность, но повторяющиеся тесты должны быть автоматизированы. Автоматизация должна дать команде (и тестировщику, если он есть) возможность применить свои знания и навыки в более сложных областях продукта и сосредоточиться на UX. Да, мы можем оптимизировать процессы тестирования и сократить время отклика, автоматизируя определённую часть тестов. Однако потребность в ручном тестировании возрастёт, как только ваш продукт станет доступен пользователям.

Смотрите также: Автономное тестирование и его инструменты