testengineer.ru

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

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

Автор

Дата

Категория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

Последние публикации

Последние комментарии