Большинство QA-специалистов, с которыми я работал, пришли в эту область без технического образованием, и большинство из них были самоучками.

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

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

Какие лучшие практики есть в автоматизации тестирования?

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

1. Один тест — одна проверка

• Тесты должны быть простыми. У них должна быть одна единственная цель.

Пользователи в один момент времени взаимодействуют с приложением с одной единственной целью, а после ее достижения переходят к какой-то другой второстепенной цели.

Сквозные тесты не только должны вести себя как пользователь; они должны имитировать намерения пользователя.

• Закладывая несколько проверок в один тест, вы намереваетесь убить «двух зайцев одним выстрелом», но на самом деле в случае падения теста такой подход превращается в сущий кошмар.

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

Это приводит к тому, что тест сообщает только о ПЕРВОЙ неудачной проверке. В этом случае тест не сможет сообщить вам и вашей команде о ДРУГИХ возможных сбоях

2. Делайте тесты короткими

• Чем длиннее тест, тем больше он содержит точек возможного падения. Тесты с более чем 10 шагами следует пересмотреть.

Можно ли еще оптимизировать тест?

Добавляете ли вы предварительные условия в качестве этапа тестирования?

В случае если путь пользователя включает более 10 шагов, обсуждали ли вы этот момент с UX/UI-дизайнером?

3. Оптимизируйте предварительные условия

• Уделите время предварительным условиям. Оптимизируйте их в рамках вашего тест-сьюта.

• Пусть предварительные условия теста будут максимально пригодными для повторного использования.

Рассмотрите возможность использования хелперов для предварительных условий или использования файлов фикстур для управления настройкой данных теста.

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

4. Сосредоточьтесь на пути пользователя p0

• Раздутые наборы тестов обременяют всех участников процесса.

Бизнес, как правило, больше всего заботится о критическом пути и лучше приспосабливается к ошибкам с более низким приоритетом.

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

5. Пишите тесты так, чтобы их можно было прочитать

• Непонятные вашим коллегам тесты гарантируют, что команде придется потратить лишнее время на устранение ошибок.

Рассмотрите возможность использования Gherkin или кастомизируйте написание шагов теста на удобочитаемом английском языке.

Всегда руководствуйтесь здравым смыслом при именовании переменных или функций. Не увлекайтесь аббревиатурами и акронимами.

• Команде разработки нравятся читабельные тесты.

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

Наличие удобочитаемых тестов также вселяет в них чувство уверенности в проводимом тестировании.

Приглашаем всех желающих на открытое занятие по cypress. На вебинаре мы разберём основы HTML/JS и напишем пару e2e-тестов с помощью cypress. Регистрация по ссылке.