среда, 19 февраля 2014 г.

Без тестировщиков: тестирование интерфейса на основе документации

   На SQA Days 12 мы обсуждали "будущее тестирования". Каким оно будет через десять лет? Умные роботы, которые сами ищут баги, а лучше и сразу их исправляют?


   И вот не так давно мы начали работу над новым проектом, и для документирования API на этом проекте разработчики воспользовались сервисом apiary.

   Обычно мы пишем тесты для API на Python, запуская nosetests и получаем отчёт в Jenkins CI. Если проект активно развивается, то API постоянно расширяется и изменяется, тесты постоянно необходимо поддерживать в актуальном состоянии.
   То есть мы каждый день начинаем с проверки последних запусков автоматизированных тестов и общения с разработчиком, который подсказывает нам, как мы можем протестировать новые функции, которые он добавил вчера.
   Казалось бы, как можно иначе?


   - разработчик пишет код
   - разработчик пишет unit тесты (если пишет, да)
   - разработчик обновляет документацию (не известно когда и мы, конечно, не застрахованы от ошибок и опечаток в документации)
   - автоматизаторы обновляют интеграционные тесты.

   Сервис apiary позволяет изменить этот подход, исключив явно лишние шаги из этого списка.
   У вас есть документация, описывающая все запросы к вашему API интерфейсу, и вы можете запускать автоматизированные тесты, которые будут посылать запросы, основываясь на описанных в документации примерах.
   И теперь всё выглядит вот так:

   - разработчик пишет код
   - разработчик обновляет документацию
   - автоматизированные тесты на основе документации проводят интеграционное тестирование (проверяем работоспособность нового кода и актуальность документации)

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

   Встречайте инструмент Судья Dredd
      ссылка на репозиторий
      статья в блоге с описанием инструмента

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