Автоматизированное тестирование НИКОГДА не заменит ручное

Сегодня автоматизированное тестирование принято воспринимать как ключ от всех проблем. В некотором смысле это действительно так. Автоматизированное тестирование хорошо подходит для проведения регрессии или проверки старого кода.

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

Это вкратце, почему современная разработка нуждаются в manual-тестировщиках. Подробнее – дальше.

Существует огромный массив специфических тестов, которые должны быть ручными

То, что у нас принято называть “пользовательским опытом” (user experience, UI) — самая первая и главная причина, почему в 2021 году необходимо ручное тестирование, и почему оно будет необходимо всегда. Мы все бываем критичны к чужой работе, и разработчики критикуют тестировщиков, и зачастую по делу! Но когда дело касается не функциональности, а впечатлений человека, клиента, то нет и не будет замены человеческому глазу, его внимательности, его склонности замечать приятное.

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

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

Автоматизированное тестирование — лишь дополнение к ручному

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

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

Баги там, где их не ждешь

Даже когда тестируешь по специальным, продуманным use cases, только люди-тестировщики могут найти баги в неожиданных местах.

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

Люди по умолчанию нацелены на креативность и анализ

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

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

В Agile тестовые скрипты надо постоянно переписывать

Работа по agile-методологии ведет к постоянным изменениям в интерфейсе и функциональности продукта. И каждый раз нужно переписывать автоматизированные скрипты.

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

Автоматизация небольших проектов обходится слишком дорого

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

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

Когда пытаешься понять потенциальный ROI (возврат вложенных денег) на покупку софта для автоматизации, то необходимо не забывать учитывать и дополнительные “человеко-часы”, связанные с интеграцией софта в проект.

Автоматизация может “отставать от разработки”

Существует разница между нашими надеждами, которые мы возлагаем на автоматизацию, и тем, что она реально может дать.

С постоянным обновлением скриптов в Agile, очень тяжело удерживать автоматизированное тестирование в одном темпе с разработкой. Нет нужды в автоматическом тестировании багов, которые уже устарели. Хорошая автоматизация начинается сразу, и никогда не “отстает” больше, чем на один спринт.

Если у команды нет лишнего ресурса на то чтобы держать автоматизацию в одном темпе с разработкой, то, может быть, лучше и не автоматизировать (если это не большой крупный проект, в котором есть шансы наладить процесс).

Ручные тестировщики смотрят на продукт как “клиенты”

Человек учится все время, и делает это — все еще — намного быстрее, чем искусственный интеллект, при всей скорости ИИ в обработке данных.

Поскольку люди-тестировщики ведут себя как пользователи, они способны помочь не только с проверкой продукта. Иногда тестировщики могут выступать в роли BA и направлять развитие продукта, исходя из своего опыта его тестирования.

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

Маркус Гартнер, MONDI GROUP

Автоматизация не поможет найти ошибки, о которых не знали

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

Автоматизированное тестирование никогда не станет альтернативой исследовательского тестирования, которое проводит человек.

Ошибки в неожиданных местах могут быть найдены только человеком.

Правильное тестирование должно быть изменяемым

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

Сочетанием “повторения хорошего” и “вариации неизвестного”, обеспечивается полное покрытие продукта.

Мобильные девайсы: сложные use cases

Мобильные девайсы, с их огромным парком, с проблемами в совместимости и взаимодействии, очень редко могут быть покрыты автоматизированными скриптами. Например, события выхода из Wi-Fi -покрытия и возвращения туда, одновременный запуск 5-10 приложений, комбинация установленных разрешений на девайсе, получение звонка и SMS — это “непредсказуемо, а значит не-автоматизируемо”.

Или например изменение настроек свайпа, или количества одновременных касаний, также может повлиять на мобильные приложения. Понятно, что если нужно качественное мобильное приложение, то без manual-тестировщика не обойдешься.

Ручное тестирование это больше, чем список pass/fail в стандартном отчете

Тестирование по списку pass/fail полезная вещь, в компаниях в большей части так тестируют сетевые функции. Но в некоторых сложных проектах не обойтись без более тщательного тестирования. Особенно веб-формы: автоматический скрипт без проблем заполнит форму на странице, но не сможет надежно проверить, сохранятся ли данные, если пользователь ушел со страницы и вернулся.

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

Только ручные тестировщики быстро воспроизведут ошибку, замеченную клиентом

Рассчитываешь выловить все баги до деплоя? Так никогда не бывает — пользователи будут сообщать о найденных багах.

Только manual-тестировщик быстро примет информацию об ошибке, обработает, воспроизведет и сделает баг-репорт для разработчика.

Когда тестирование ручное, то время от принятия бага от пользователя до его исправления – самое короткое.

И да, ручное тестирование это круто само по себе.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

9 КОММЕНТАРИИ

Подписаться
Уведомить о
guest

9 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
andy
andy
2 лет назад

Автоматизированное тестирование уже заменяет ручное просто по соображением экономии. Пока это не очень заметно в России, т к. стоимость труда у нас низкая и держать ручного тестировщика за 50-60 тысяч ненакладно. Но на западе массово отказываются от ручных QA в пользу автоматизированных

Ольга
Ольга
2 лет назад
Ответить на  andy

Работаю в аутсорсе — регулярно на американские и европейские проекты набирают manual QA.

andy
andy
2 лет назад
Ответить на  Ольга

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

Максим
Максим
2 лет назад
Ответить на  andy

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

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

Максим1
Максим1
1 год назад
Ответить на  Максим

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

Kirill
Kirill
2 лет назад

Думаю, что ручное тестирование будет нужно всегда. На наш век хватит ещё что процентов.

predtecha.m@gmail.com
predtecha.m@gmail.com
2 лет назад

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

Максим1
Максим1
1 год назад
Ответить на  predtecha.m@gmail.com

поддерживаю

Максим1
Максим1
1 год назад

«но не сможет надежно проверить, сохранятся ли данные, если пользователь ушел со страницы и вернулся.»
Уверены?
» человек явно заметит проблемы со скоростью загрузки или сохранения данных в какой-то части приложения. Скорость это не то, что можно хорошо протестировать автотестами.»
Уверены?

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас