5 июня 2018

5 лучших практик автоматизации тестирования

Test Engineer Noveo Анастасия продолжает делиться интересными статьями. Настя, спасибо за перевод и искреннее желание делиться своими знаниями!

В этой статье мне бы хотелось сфокусироваться на пяти лучших практиках автоматизации тестирования, которые я наблюдал, пока сам приобретал эти навыки написания автотестов. Все они сопровождаются примерами для лучшего понимания. Надо отметить, что они больше относятся именно к написанию сценариев автоматизированного тестирования, нежели к разработке тестов в рамках какого-либо конкретного фреймворка. Что ж, начнём!

Noveo automated testing

1. Не надо запускать все UI-тесты во всех браузерах / мобильных устройствах / операционных системах

Мне встречались люди, которые выражали желание запускать все UI-автотесты во всех требуемых браузерах. Действительно ли это необходимо? Я думаю, что нет. Используйте свои профессиональные навыки, чтобы продумать тесты, покрывающие проверками все компоненты интерфейса, и используйте их только как кроссбраузерные. Таким образом, вы сэкономите кучу времени на прохождении и поддержке тестов.

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

Вопрос: почему мы не можем протестировать добавление разных комбинаций товаров через API вместо того, чтобы покрывать эти функции интерфейсными тестами?

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

2. Сведите к минимуму автоматизацию сценариев UI и E2E

Не стоит писать тонны UI-тестов. Тесты интерфейса — самые дорогие, а также самые трудозатратные с позиции разработки и поддержки. В то же время они могут протестировать всё то, что не получится проверить с помощью API-тестов. UI-тесты должны быть направлены на проверку небольшого числа важных пользовательских сценариев, покрывающих бОльшую часть функционала. В идеале максимум проверок должно совершаться с помощью юнит-тестов, чуть меньше — с помощь интеграционных (в т.ч. и проверок API), и минимум — с помощью тестов пользовательского интерфейса. Это хорошо иллюстрирует известная пирамида тестирования:

Пример: допустим, мы тестируем строку поиска Google. Тогда нам надо протестировать только один UI-сценарий, чтобы убедиться, что поиск корректно отображает результаты. Запросы, вводимые в строку поиска (в том числе запрещенные символы, невалидные значения и т.д.), могут быть легко проверены с помощью обращения к API поисковой системы.

3. Не включайте в тест-комплект стабильно падающие тесты

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

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

4. Помните про CI (continuous integration) и параллельное исполнение при разработке UI-тестов.

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

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

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

В качестве другой иллюстрации можно взять PayPal: если один пользователь будет добавлять новую карту в рамках тест-кейса №1, и в это же время другой пользователь попытается удалить ее в рамках параллельно выполняемого тест-кейса №2, могут возникнуть сбои, т.к. к тому моменту, когда второй пользователь попытается удалить карту, она может быть еще не добавлена первым пользователем. Одним из возможных правильных подходов будет раздельный логин для этих двух тестов (или выполнение одного из действий с помощью команд к API с целью экономии времени).

Еще один важный момент относительно CI и удаленного выполнения тестов, о котором стоит помнить, — хранить все файлы с зависимостями внутри своего проекта, как и другие файлы, относящиеся к нему, чтобы не возникло проблем при удаленном запуске тестов. Кроме того, убедитесь, что ваши автотесты не требуют никакого, даже малейшего, ручного вмешательства, иначе их невозможно будет запустить в рамках continuous integration.

5. Наладьте строгий процесс ревью

Очень важно сделать строгое ревью частью процесса разработки автотестов, особенно в большой команде. Это необходимо, потому что иногда в моей практике были ситуации, когда стабильно работавшие автотесты “ломались” из-за комита одного из членов команды. В идеале каждый член команды должен делать код-ревью, чтобы убедиться, что их собственные тесты ничего не испортят, но в большой команде это может стать невозможным. Поэтому можно ввести правило, что, например, код не может быть принят, если как минимум 3-4 члена команды не одобрили его. Ревью не обязательно проводить оффлайн: их лучше проводить и логировать с помощью инструментов вроде Crucible, Github, Bitbucket и т.д., потому что в этом случае каждый сможет посмотреть комментарии к предыдущим комитам и не допустить старых ошибок в собственном коде.

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

Оригинал статьи: http://toolsqa.com/blogs/five-most-important-automation-best-practices/

Автор: Муфаддал Муним, разработчик автоматизированных тестов для веб-сервисов с девятилетним опытом, контрибьютор open source фреймворка serenity-demos.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: