- Специфические тесты
- Автоматизация это дополнение
- Коварные баги
- Креативность человека
- Agile
- Дорогой софт
- Автоматизация всегда отстает
- Человеческий взгляд на продукт
- Неожиданные места
- Ригидные автотесты
- Мобильное тестирование
- Веб-формы
- Воспроизведение багов
Сегодня автоматизированное тестирование принято воспринимать как ключ от всех проблем. В некотором смысле это действительно так. Автоматизированное тестирование хорошо подходит для проведения регрессии или проверки старого кода.
Но это не уменьшает значимости ручного, исследовательского тестирования. Лучшие результаты в таком тестировании всегда показывает человек. В современных наборах автотестов, все более крупных и сложных, разобраться может только 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-тестировщик быстро примет информацию об ошибке, обработает, воспроизведет и сделает баг-репорт для разработчика.
Когда тестирование ручное, то время от принятия бага от пользователя до его исправления – самое короткое.
И да, ручное тестирование это круто само по себе.