Если вы работали на каком-нибудь крупном проекте, то могли заметить, что некоторые тесты автоматизированы. Я имею ввиду не Unit – тесты, которые обычно пишут сами разработчики, а обычные функциональные тесты, которые выполняются мануальными тестировщиками. Это повлекло к появлению отдельных разработчиков в тестировании, которые называются инженерами – тестировщиками или просто автоматизаторами.
Написание автотестов довольно трудоёмкий и затратный процесс, не всегда есть смысл в их написании. Автоматизация имеет свои преимущества и недостатки. Поэтому для начала надо разобраться во всех особенностях, прежде, чем приступим к написанию автотестов.
Повторяемость тестов
Автотесты должны быть повторяемыми и проходить всегда по одному и тому же сценарию, чтобы разработчики могли на них полагаться. Не следует автоматизировать тест, если он будет выполняться единожды. Исключение может составить разве что тестирование большого количества данных или скрипта для перенаправления ссылок, когда таких ссылок тоже очень много.
Надежность скриптов
Автотесты должны отрабатывать стабильно и не быть зависимыми от своей среды расположения. Если после прохождения автотестов результат их отработки не может быть точно определён или есть риск ложного срабатывания модуля валидации, то смысла в таких тестах нет.
Время получения результата
Автоматизированные тесты должны получать результат быстрее, чем это сделает мануальный тестировщик. Ведь дополнительное время тратится ещё и на написание этих тестов.
Роль автоматизированных тестов в Agile среде
Тесты позволяют быстро довести до сведения разработчиков некорректную работу отдельных модулей. Особенно это важно, если данные модули до этого стабильно работали, а их некорректная работа связана с изменениями в коде.
Когда должны быть автоматизированы пользовательские действия?
Как правило, автоматизированные тесты пишутся после создания разработчиками модулей. В этом случае мы знаем локаторы всех необходимых нам элементов. Однако, общая структура приложения и его функции известны заранее, также заранее и известно, что мы будем автоматизировать. Поэтому общий скелет фреймворка пишется после согласования технической документации. Как показывает практика, в крупных компаниях такой скелет фреймворка “гуляет” от проекта к проекту, вносятся лишь необходимые поправки, связанные с особенностью приложения.
