Skip to content

Latest commit

 

History

History
88 lines (54 loc) · 15.2 KB

perspektivy-professii.md

File metadata and controls

88 lines (54 loc) · 15.2 KB
Raw

Перспективы профессии

Сколько лет еще продержится ручное тестирование? Заменит ли автоматизация мануальщиков?

Почему современная разработка нуждается в manual-тестировщиках:

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

То, что у нас принято называть “пользовательским опытом” (user experience, UX) - самая первая и главная причина, почему сейчас необходимо ручное тестирование, и почему оно будет необходимо всегда. Мы все бываем критичны к чужой работе, и разработчики критикуют тестировщиков, и зачастую по делу! Но когда дело касается не функциональности, а впечатлений человека, клиента, то нет и не будет замены человеческому глазу, его внимательности, его склонности замечать приятное. Хотя простые smoke-тесты можно автоматизировать, намного лучше они получаются у людей. Намного быстрее тестировщик прокликает приложение и увидит, готово ли оно к тщательному тестированию, чем это сделают скрипты, добавляя лишний этап. Использовать автотесты здесь не лучшая идея. Потом, только человек способен хорошо проверить, например, нюансы локализации в продукте, нацеленном на международный рынок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тренды тестирования и перспективные области:

  • Big Data Testing;
  • Internet of Things;
  • Artificial Intelligence (AI) and Machine Learning (ML);
  • Blockchain Testing;
  • QAOps;
  • Quality engineering (QE);
  • Codeless Automated Testing.

Источники:

Доп. материал: