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

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

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

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

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

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

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

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

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

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

Выход из этой ситуации — создание специальной программы, которая будет служить конструктором тестов. Данная программа должна иметь простой и понятный интерфейс, с помощь которого тест-аналитики (или даже системные и/или бизнес-аналитики) смогут составлять автоматизированные тесты. Такая программа будет использовать заранее разработанный и сопровождаемый набор библиотек и функций (фреймворк), позволяющих работать с тестируемым приложением. Таким образом, разработчики автоматизированных тестов будут заниматься разработкой и сопровождением фреймворка, не отвлекаясь на создание автоматизированных тестов, а тест-аналитики будут создавать автоматизированные тесты, не обладая при этом навыками программирования.

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

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