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

20-21 мая 2016 года в Санкт-Петербурге прошла уже 19-я по счету международная конференция “SQA Days”. Мероприятие проходило в три потока, и за два дня конференции здесь прозвучало 57 докладов на различные темы: сам процесс тестирования, принципы построения команды тестировщиков, профессиональный рост и мотивация QA-специалиста.

Доклады по автоматизации тестирования шли отдельным потоком. Многие выступления были посвящены таким тенденциям, как DevOps, Continuous Delivery. Рассказываем о самых интересных докладах SQA Days-19.

Jenkins 2.0: Организуем тестирование в составе Continuous Delivery (Олег Ненашев)

Олег – член core team в open-source проекте Jenkins, работает в компании CloudBees, где развивает CloudBees Jenkins Platform. Олег затронул тему Continuous Delivery, а также задачи, возникающие при внедрении этой методологии.



При Continuous Delivery тестирование продукта происходит короткими циклами на всех стадиях, тесты максимально автоматизированы. В случае необходимости, Continuous Delivery предполагает быстрый откат к предыдущей версии продукта. В данной методологии инфраструктура становится критичной для проекта. Как только происходит сбой, мы сразу начинаем нести потери, особенно, если нужно откатить изменения, а не выпустить новый функционал. Инфраструктура меняется вместе с продуктом и должна тестироваться наравне с ним. В рамках Continuous Delivery — это, конечно же, короткие циклы, разбиение системы на модули. Что нужно для организации подобного тестирования? Параллелизация процессов в проекте, версионирование кода и процедур сборки, воспроизводимость тестов и сборок, тестирование на реальном релизе.

Для внедрения Continuous Delivery необходима система автоматизации. Олег рассказал о новых возможностях Jenkins 2.0 и акцентировал внимание на новой технологии Pipeline as code. Классической моделью взаимодействия с Jenkins является пользовательский веб-интерфейс. От пользователя требуется создать вручную новую задачу, а затем дополнитьеё деталями. В связи с этим требуются дополнительные усилия для создания и управления проектами, к тому же настройки Jenkins-задач хранятся отдельно от кода проекта. Этот подход не дает возможности применять лучшие методики Continuous Integration/Continuous Delivery. Jenkins Pipeline позволяет описывать процесс сборки в виде кода, благодаря чему конфигурацию Jenkins-задач можно хранить в системе контроля версий вместе с кодом проекта, отслеживать изменения и тестировать вместе с проектом.



В заключение Олег рассказал об успешном применении Pipeline в CloudBees Jenkins Platform, а также сделал вывод, что Pipeline as code снижает затраты на поддержку автоматизации и может применяться для Continuous Delivery.

Как перестать бояться и начать автоматизировать. Или не начать (Алексей Лязгунов)

Этот доклад в первую очередь будет интересен:

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

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

• Сократить время тестирования. На первый взгляд, цель хорошая, но всё зависит от того, что нужно автоматизировать. Например, если это новый функционал, то продолжительность тестирования значительно увеличится. Поэтому нужно понимать, что если необходимо протестировать быстро и прямо сейчас, то, наверное, не стоит автоматизировать.
• Увеличить число проверок / покрытие.
• Обеспечить более частые проверки. Одна из основных целей автоматизации.
• Уменьшить влияние «человеческого фактора». По мнению Алексея, сомнительная цель, но в некоторых случаях — хорошая цель. Действительно, иногда нужно, чтобы тест выполнялся по заданным последовательным шагам. Но необходимо понимать, что довольно часто тесты не отлавливают дефекты, которые сможет обнаружить человек.
• Удешевить тестирование. Автоматизация — это дорого, за новую практику нужно платить, причем постоянно.
• Внедрить новые виды тестирования. Автоматизация позволяет делать то, что мы не можем делать руками.
• Сократить время выпуска нового релиза. Хорошая цель, но вначале достичь ее несколько тяжело, так как должен быть некий базовый набор тестов.
• Заменить ручного тестировщика автотестами.
• Быстрое получение текущего состояния. Отличная цель. Например, мы хотим узнать, стоит ли отдавать билд в тестирование, и для этого запускаем определенный набор тестов.
• Автоматизация ручных сценариев. С точки зрения докладчика — это плохая цель. Конечно, хорошо автоматизировать набор приемочных сценариев, однако, если мы будем покрывать автотестами более детально и широко, то столкнемся с рядом трудностей. Во-первых, ручные сценарии — это, в основном, UI-тесты, что является самой дорогой и ненадежной автоматизацией. Далее, разная детализация тестов, разное разбиение проверок по сценариям. Иногда лучше использовать разные интерфейсы (например, создать пользователя лучше через API, чем заполнять формы на фронтенде). Также не все ручные тесты автоматизируются, как и не для всех возможных проверок есть ручные сценарии.
• Автоматизировать регрессионное тестирование. Если мы хотим автоматизировать регрессивное тестирование, то нужно понимать, что темпы написания новых автотестов должны быть такими же, как и темпы развития продукта. Если есть возможность, то можно ставить перед собой такую цель, в противном случае лучше автоматизировать регрессивное тестирование только на уровне модуля или компонета.
• Автоматизация упростит тестирование.

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

Далее Алексей вводит понятие «Три ДО»: Автоматизация — это Добро, Дорого, Долго. Это список вопросов, но который стоит ответить при внедрении автоматизации.

Автоматизация — это Добро:

• Какие проблемы я хочу решить, внедряя автоматизацию?
• Мои ожидания от автоматизации — не заблуждения?
• Есть ли поддержка и понимание руководства и команды?
• Знаю ли я, как встроить автоматизацию в процесс?

Автоматизация — это Дорого:

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

Автоматизация — это Долго:

1. Я понимаю, что польза от автоматизации не мгновенна?
2. Я знаю, что все участники разработки будут вовлечены и нужно поменять подход к разработке?
3. Я понимаю, что, начав, не смогу остановиться?
4. Достаточно ли долог проект, чтобы насладиться плодами автоматизации?
5. Я готов тратить время на исследования в автоматизации?

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

Оценка методологии автоматизации — MBT (Дмитрий Химион)

Технически доклад получился сильным и качественным. Он был посвящен методологии Model Based Testing (MBT) и ее применимости в рамках Agile.

Если говорить кратко, то MBT — это один из способов организации тестов в рамках своей системы автоматизированного тестирования. Любое приложение — это state machine.



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

Дмитрий сравнивает MBT с традиционным подходом к автоматизированному тестированию. Любое состояние, как и любой переход из одного состояния в другое, описывается однократно и используются единожды при генерации тестов комбинаторным механизмом. Объем изменений примерно такой же, как у разработчиков. В случае использовании линейных сценариев, даже когда мы имеем хорошую модульную систему автоматизированного тестирования, когда общий код вынесен, и необходимо, например, добавить новые шаги, то мы должны исправить все тесты, которые используют новую функциональность. С увеличением количества тестов, продолжительность их разработки и актуализации будет увеличиваться. MBT выгодно применять при гибкой разработке ПО. Agile-методология предполагает всегда рабочий продукт, короткие спринты. Все команды, которые работают в рамках Agile, в идеале стремятся завершить тестирование в момент завершения разработки. Учитывая, что генерируемый тестовый набор может быть гибко изменен путем модификации модели, а временные затраты при этом примерно равны разработке функциональности, то при правильной организации MBT-автоматизация либо успевает за разработкой, либо, если разработка увеличивает сроки, не успевает, и в таком случае происходит увеличение продолжительности спринта.

Далее Дмитрий описал концепцию MBT-фреймворка, архитектурная схема которого изображена ниже. Source — внешний источник, с которого строится модель. Test Model — модель тестируемой системы, которая переводится с внешнего источника в программный вид. Generator читает модель в виде графа и формирует пути (тестовые последовательности). Restriction tool — механизм ограничения генерации тестовых последовательностей. Test Manager отвечает за выполнение системы и агрегацию результатов. Logger — модуль для ведения логов.



Подводя итоги, Дмитрий выделил положительные моменты использования MBT. Данная методология работает на минимизацию объема кода. MBT позволяет обеспечить высокое тестовое покрытие за счет комбинаторики. Медотология применима в Agile, так как время на актуализацию модели, в большинстве случаев, будет соответствовать времени разработки новой функциональности. Из недостатков использования MBT — ограниченный выбор инструментария. Кроме того, модули, которые изображены серым цветом на предыдущем рисунке, придется реализовывать своими силами.