Когда автоматизировать пользовательские истории?

Если вы работали в гибкой среде в качестве QA, скорее всего, вы столкнулись бы с какой-то автоматизацией тестирования. Я не имею в виду автоматизацию модульного тестирования, которая, как правило, ориентирована на разработчика, а автоматизацию функционального приемочного тестирования, которая обычно выполняется QA или новой модной ролью разработчика программного обеспечения в тестировании.

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

Повторяемость

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

Надежность

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

Время

Автоматические тесты также должны сэкономить нам время. Если простой тест занимает 10 минут, но тот же результат можно определить вручную за 1 минуту, то лучше не автоматизировать такие тесты.

Защитная сетка

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

Когда следует автоматизировать рассказы?

В типичном спринте, скажем, есть 7 историй, привязанных к спринту, из которых 5 являются хорошими кандидатами на автоматизацию на основе вышеуказанных критериев. Но когда лучше всего автоматизировать эти истории? Должны ли мы писать автоматизированные тесты по мере разработки функций? Стоит ли нам подождать, пока функция будет разработана, а затем написать автоматизированные тесты? Подождем до конца спринта, а потом автоматизируем истории?

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

В других случаях, когда речь идет о внедрении новой функции в приложение, как мы узнаем, как будет выглядеть конечный продукт, чтобы иметь возможность заранее писать тесты? Здесь я не говорю о файлах функций, которые заранее описывают приемочные тесты, а о фактических фикстурах или тестах на селен (реализация тестов), которые выполняются против доставленного кода.

Суть в том, что любой тест, который будет проводиться более одного раза, должен быть автоматизирован. И какие тесты мы собираемся выполнять более одного раза? Регрессионные тесты. А что такое регрессионные тесты? Тесты, которые определяют, снизилась ли функциональность приложения в результате новых модификаций и функций.

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

Проблема с попыткой написать автоматические тесты для функции в процессе ее разработки заключается в том, что вы потенциально можете потратить много времени и много усилий на написание автоматизированных сценариев для чего-то нестабильного и подверженного постоянным изменениям во время спринта. Более того, сколько раз мы видели, как история переносится в спринт, а затем выводится из спринта? Затем мы зря потратили время на создание сценария для чего-то, что не вошло в систему.

Некоторые организации даже вводят строгое правило, что история не может быть завершена, пока она не будет полностью автоматизирована! Собираемся ли мы остановить выпуск важной функции, потому что QA не смог или не смог вовремя обеспечить автоматизацию по разным причинам? Или история не готова, потому что у нас нет автоматизированного скрипта для проверки наличия кнопки на странице. Шутки в сторону?

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

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