Home

Автор: Джо Колантонио (Joe Colantonio), Пол Гроссман (Paul Grossman)

Оригинал статьи: https://www.joecolantonio.com/2016/05/26/5-secrets-test-automation/

Перевод: Ольга Алифанова

В эпизоде TestTalks Пол Гроссман рассказал про свои пять секретов автоматизации тестирования (то есть про пять вещей, которые ни в коем случае не нужно делать, если вы хотите эффективно автоматизировать).

Ниже – краткое содержание интервью с ним.

Отсутствие документации

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

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

Первое, что сделал Пол, когда стал разбираться в унаследованной от предшественника системе автотестов – это убедился, что каждое внесенное разработкой или тестировщиком изменение внятно документировалось.

Отсутствие модульного дизайна

Пол отметил важный момент: автоматизация – это программирование. Лучшие практики разработки, которые применяются при создании приложений, должны аналогичным образом воплощаться в создании автотестов.

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

Я верю в "послойный подход", при котором, если что-то меняется, вам нужно внести изменения в одном и только одном месте, которое отвечает за эту функциональность.

Отсутствие поддержки со стороны команды или менеджмента

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

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

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

К тому же не все можно автоматизировать на 100%, и есть еще нефункциональное тестирование.

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

Отсутствие найденных багов

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

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

Отсутствие метрик и ROI

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

Внедряйте метрики тестирования, демонстрирующие, что именно вы делаете и в каком объеме. Отслеживайте ROI вашей автоматизации, чтобы продемонстрировать, как именно ваши автотесты помогли компании.

Обсудить в форуме