Home

Автор: Адам Саттерфилд (Adam Satterfield)

Оригинал статьи: http://www.abodeqa.com/2017/11/16/3-misconceptions-test-automation/

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

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

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

1)     Автоматизация заменит тестировщиков

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

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

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

2)     Вначале нужно автоматизировать UI-тесты

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

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

UI-тесты проще писать, но если у вас множество UI-тестов и очень мало юнит- и интеграционных тестов, то вы получили «мороженое» вместо тест-пирамиды. Вы построили массивный репозиторий тестов, которым невозможно управлять, и ваша команда автоматизации утонет в переписывании тест-кейсов.

3)     Автоматизаторы просто кодируют ручные тест-кейсы

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

К примеру, предположим, что у вас есть тестировщик, работающий над функциональностью RegEx, и для валидации функциональности нужно создать 500 000 документов на пользовательском Google-диске. Вместо того, чтобы тратить недели на создание документов – если вы предоставите им свободу действий – они потратят около суток на использование API Google для создания скрипта, который можно повторно использовать, и который генерирут документы по запросу.

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

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

Тест-автоматизация – важная часть современной разработки ПО. Убедитесь, что у вас есть время на формулирование весомой стратегии, как получить от нее максимум пользы.

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