Автор: Алименков Николай.
На последнем Agile Gathering V мне неоднократно задавали вопрос: "Как можно писать acceptance тесты на несуществующий функционал?". Я приводил примеры написания таких тестов с использованием некоторых фреймворков. Но потом я в очередной раз задумался о самом понятии acceptance теста. Acceptance (приемочное) тестирование служит для того, чтобы принимать сделанный функционал и делать выводы о его готовности. Когда функционал принят, то все acceptance тесты переходят в разряд регрессионных тестов (для проверки работоспособности существующего функционала).
С ручными acceptance тестами все просто. Берем acceptance критерии, которые предоставляет заказчик (одна из причин, почему QA должны участвовать в планировании и тесно работать с заказчиками при подготовке тестов), снабжаем данными и оформляем в виде тест кейса. Когда функционал готов, то тест кейс прогоняется и делается вывод о его готовности. Проблема только в том, что для повторения написанных тестов необходимо опять непосредственное участие QA. Поэтому многие команды прибегают к автоматизации данных тестов постфактум, то есть когда функционал уже принят. И тут появляется несколько проблем. Во первую очередь при автоматизации тратится изрядное количество времени (часто больше чем при написании ручного теста). При этом время на автоматизацию выделяется уже в следующей итерации, что нарушает ее scope и затрудняет планирование. В добавок после автоматизации изначальный тест кейс в принципе не представляет интереса и может быть "утилизирован" (явная демонстрация излишков на производстве).
Еще сложнее дело обстоит, когда функционал не принимается по причине непрохождения нескольких тестов. Теперь автоматизация невозможна, так как не на чем автоматизировать (мы пока считаем, что автоматизация без готового функционала не может быть выполнена) и для повторной проверки понадобится опять прогонять все тесты в ручном режиме.
Неочевидная проблема заключается в том, что ручное тестирование склонно к компромисам. Я попытаюсь пояснить на примере веб приложения. Предположим заказчик хотел иметь кнопку для перехода на другую страницу. Разработчики посчитали нужным сделать вместо этого ссылку. При проверке QA (уставший после рабочего дня или же просто по невнимательности) подумал что ссылка тоже неплохо и принял функционал. И тут проявляется парадокс готового функционала: "Автоматизация acceptance теста на готовом функционале ограничивает его рамками конкретной реализации". Если на странице не будет кнопки, то ее нажатие никто не зафиксирует. Изначально автоматизированный тест "беспощаден" и не пропустит неточность даже если будет прогоняться 1000 раз.
Есть еще один парадокс - парадокс "отложенной работы". Он заключается в том, что когда что-то откладывается на потом, то обычно либо не делается вовсе, либо делается "спустя рукава". Это же можно сказать об автоматизации acceptance тестов в будущем. Обычно на это не хватает времени по причине гонки за новым функционалом.
На мой взгляд современные средства для acceptance тестирования позволяют достаточно легко писать тесты наперед. Это помогает разработчикам повысить уверенность в законченности своей работы и правильности (полноте) требуемого функционала без постоянного взаимодействия с QA. Таким образом команда становится более целостной и помогает друг другу достигнуть единой цели - разработки качественного продукта.
У нас с Алексеем Кривицким в планах проведение тренингов по acceptance тестированию, в которых будут освещаться эта и другие проблемы. Ждите анонсов на сайте и в рассылках. ;)
На последнем Agile Gathering V мне неоднократно задавали вопрос: "Как можно писать acceptance тесты на несуществующий функционал?". Я приводил примеры написания таких тестов с использованием некоторых фреймворков. Но потом я в очередной раз задумался о самом понятии acceptance теста. Acceptance (приемочное) тестирование служит для того, чтобы принимать сделанный функционал и делать выводы о его готовности. Когда функционал принят, то все acceptance тесты переходят в разряд регрессионных тестов (для проверки работоспособности существующего функционала).
С ручными acceptance тестами все просто. Берем acceptance критерии, которые предоставляет заказчик (одна из причин, почему QA должны участвовать в планировании и тесно работать с заказчиками при подготовке тестов), снабжаем данными и оформляем в виде тест кейса. Когда функционал готов, то тест кейс прогоняется и делается вывод о его готовности. Проблема только в том, что для повторения написанных тестов необходимо опять непосредственное участие QA. Поэтому многие команды прибегают к автоматизации данных тестов постфактум, то есть когда функционал уже принят. И тут появляется несколько проблем. Во первую очередь при автоматизации тратится изрядное количество времени (часто больше чем при написании ручного теста). При этом время на автоматизацию выделяется уже в следующей итерации, что нарушает ее scope и затрудняет планирование. В добавок после автоматизации изначальный тест кейс в принципе не представляет интереса и может быть "утилизирован" (явная демонстрация излишков на производстве).
Еще сложнее дело обстоит, когда функционал не принимается по причине непрохождения нескольких тестов. Теперь автоматизация невозможна, так как не на чем автоматизировать (мы пока считаем, что автоматизация без готового функционала не может быть выполнена) и для повторной проверки понадобится опять прогонять все тесты в ручном режиме.
Неочевидная проблема заключается в том, что ручное тестирование склонно к компромисам. Я попытаюсь пояснить на примере веб приложения. Предположим заказчик хотел иметь кнопку для перехода на другую страницу. Разработчики посчитали нужным сделать вместо этого ссылку. При проверке QA (уставший после рабочего дня или же просто по невнимательности) подумал что ссылка тоже неплохо и принял функционал. И тут проявляется парадокс готового функционала: "Автоматизация acceptance теста на готовом функционале ограничивает его рамками конкретной реализации". Если на странице не будет кнопки, то ее нажатие никто не зафиксирует. Изначально автоматизированный тест "беспощаден" и не пропустит неточность даже если будет прогоняться 1000 раз.
Есть еще один парадокс - парадокс "отложенной работы". Он заключается в том, что когда что-то откладывается на потом, то обычно либо не делается вовсе, либо делается "спустя рукава". Это же можно сказать об автоматизации acceptance тестов в будущем. Обычно на это не хватает времени по причине гонки за новым функционалом.
На мой взгляд современные средства для acceptance тестирования позволяют достаточно легко писать тесты наперед. Это помогает разработчикам повысить уверенность в законченности своей работы и правильности (полноте) требуемого функционала без постоянного взаимодействия с QA. Таким образом команда становится более целостной и помогает друг другу достигнуть единой цели - разработки качественного продукта.
У нас с Алексеем Кривицким в планах проведение тренингов по acceptance тестированию, в которых будут освещаться эта и другие проблемы. Ждите анонсов на сайте и в рассылках. ;)