Роль тестирования в Devops

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

Transcript

1. Роль тестирования в Devops Вы хотите, чтобы у вас каждая фича «протаскивалась» до production за 3 часа? Тогда вам нужно вывести своё тестирование на продвинутый уровень!
2. Роль тестирования в Devops Вы хотите, чтобы у вас каждая фича «протаскивалась» до production за 3 часа? Тогда вам нужно вывести своё тестирование на продвинутый уровень!
3. Пару слов о себе: • Devops евангелист • Agile Testing тренер • Руководитель автоматизации тестирования • В QA c 2012 года • В IT с 2007 года • В АльфаБанке внедряю Облака • Немного пишу код =) • Люблю Linux
4. Терминология Что означают все эти словечки или как меня понимать?
5. Термины Unit-тесты - тесты, которые пишутся разработчиками; 
 E2E-тесты - любые интеграционные тесты, проверяющие межкомпонентное или межсистемное взаимодействие;
 Selenium-тесты - UI-тесты, эмулирующие действия пользователя в браузере;
 UI-тесты - тесты, которые проверяют то, что видит пользователь;
 Test coverage - тестовое покрытие требований, в%. 
 Production/бой - стенд с приложением для конечного пользователя;
 Mocks - "заглушки" для внешних систем, слоев; Супертестировщики - тестировщики, которые самостоятельно поддерживают автотесты, и немного умеют программировать;
6. Пирамида тестирования - как способ визуализации того, как мы меняем тестирование
7. Как было: UI- приемка и регресс Автотесты Unit-тесты Unit-тесты: черный ящик для всех. Никто не знает что именно покрыто юнит-тестами, а что не покрыто. Все на личном усмотрени и разработчика. Code coverage не считается.
 Автотесты: автоматизированные UI E2E сценарии, покрывающие ТМ регресса. Не все проекты покрыты. Отсутствие доверия к автотестам приводит к тому, что Т. дублирует ручным тестированием автоматизированные проверки. 
 UI-приемка: приемочное тестирование новой функциональности. Осуществляют аналитики, в заключительных итерациях привлекая тестера для написания ТМ. 
 Регресс: регрессионое тестирование стабильной версии релиза на неухудшение. Осуществляется Т. от 2 дней до 2 недель, в зависимости от системы.
8. Цели, которые мы поставили себе: 1. Наличие собственной экспертизы в виде “идеальных” супертестировщиков 2. Прозрачность всех процессов тестирования в команде 3. Изменить процесс автоматизации тестирования в соответствии с новой пирамидой тестирования 4. Изменить процесс написания документации
9. Стратегия Функциональное ручное тестирование: • Обучаем всех тестировщиков программировать. Хотим: все становятся супертестировщиками; • Тестировщик в паре с разработчиком пишет юнит-тесты; • Тестировщик участвует в review юнит-тестов на полноту test coverage; • Max время приемки - 30 минут;
10. Стратегия Автоматизация: • Весь регресс автоматизирован; • Автоматизируем подсчет test coverage; • Интегрируем отчеты результатов автотестов в jira pipeline; • Автоматизируем сбор метрик с помощью jira; • Автоматически генерируем документацию, используя подход Specification by Example;
11. Стратегия Инженерные практики: • Покрытие кода тестами (unit-tests, e2e); • Code coverage не менее 25%; • Парное программирование; • Докерная гибридная инфраструктура для автотестов; • Доработка фреймворка с автотестами: время прогона каждой сборки с автотестами не должно превышать 30 минут. • Автоматизация тестирования адаптивности и кроссбраузерности;
12. Стратегия Процессные особенности: • Прозрачность тестирования; • Автотесты больше не сервис для команды, а часть самого продукта; • Учимся принимать риски;
13. Как сейчас: Автотесты (e2e, UI) e2e-тесты, компонентные тесты Unit-тесты Unit-тесты: тесты на ту часть кода, которая не исполняет какую-либо бизнес-логику. Пишутся разработчиками. Учитываются в подсчете code coverage. UI-приемка
14. Как сейчас: Автотесты (e2e, UI) e2e-тесты, компонентные тесты Unit-тесты E2E тесты: интеграционные тесты, которые проверяют взаимодействие с внешними слоями (API, UI). Пишутся в паре "тестер-разработчик" или "аналитик-тестер". Исполняются на mocks и являются частью документации проекта. UI-приемка
15. Как сейчас: Автотесты (e2e, UI) e2e-тесты, компонентные тесты Unit-тесты Компонентные тесты: пишутся в паре "тестер-разработчик" или "тестер-аналитик", проверяют только одну компоненту внутри API или UI. Являются частью документации проекта. UI-приемка
16. Как сейчас: Автотесты (e2e, UI) e2e-тесты, компонентные тесты Unit-тесты UI-приемка Автотесты e2e: интеграционные UI тесты полного цикла. Проверяют взаимодействие всех слоев приложения со внешними системами. Разрабатываются в паре "автотестер-тестер".
17. Как сейчас: Автотесты (e2e, UI) e2e-тесты, компонентные тесты Unit-тесты UI-приемка Автотесты UI: компонентные тест- кейсы на front, которые проверяют UI с точки зрения конечного пользователя. Исполняются на мокированном API. Разрабатываются в паре "автотестер-тестер".
18. Как сейчас: Автотесты (e2e, UI) e2e-тесты, компонентные тесты Unit-тесты UI-приемка UI приемка: ручное тестирование изменения артефакта, который в рамках новой версии был изменен. Проводится тестировщиком и имеет жесткое ограничение по времени.
19. Идеальный тестировщик, кто он? Какие люди нам нужны для достижения цели?
20. Супертестировщик – это… • Тестировщик немножко программист: – Обладает навыками программирования на Java или на JS; – Понимает алгоритмы на начальном уровне; • Тестировщик немножко аналитик: – Знает архитектуру тестируемого приложения; – Не тестирует «черный ящик» и может залезть в код; – Осуществляет приемочное тестирование; • Тестировщик крутой QA engineer: – Владеет техниками тест-дизайна; – Умеет проектировать тестовую модель с точки зрения используемой пирамиды; – Пишет/проектирует модульные тесты;
21. Нужны крутые тестровщики • Подбор людей с экспертизой • Обучение тестировщиков • На каждую проектную команду 0.5 автотестера • Коммуникации • Организация и развитие community сообщества внутри Альфа Лабы; • Выращивание собственных клонов =)
22. Визуализация качества продукта для команды: • SonarQube и Zephyr автоматически проверяют code coverage и test coverage (SonarQube контролирует SLA качества кода для проекта) • Визуализация качества продукта с помощью дашбордов • (Визуализировано состояние качества кода по всему проекту) • Мониторинг производительности API • Мониторинг производительности Front
23. Функциональное тестирование (автотесты + ручное) 80% - автотесты 20 % - ручное тестирование
24. Ручное тестирование • Тестировщик осуществляет руками только приемочное тестирование • Тестировщик тестирует каждую стабильную версию • Тестировщик ревьюит юнит-тесты • На каждую проектную команду 0.5 автотестера • Подготавливаем смоук-сеты для команды (автотесты+ручные тесты) • Избавляемся от «балласта» /Не делаем лишнюю работу • Коммуникации
25. Specification of Example: API: Аналитик с тестировщиком генерируют два артефакта для проекта: 1. UML диаграмма. Используем для этого фреймворк, например PluntUML. Диаграмма находится в репозитории проекта; 2. Test-case в нотации BDD в репозитории проекта - каркас для юнит-тестов. Парная разработка с тестировщиком; Во время сборки билда генерируется html-документ в artifactory, как документация к релизу; UI: Проектирование тест-кейсов происходит на user-story: 1. Тестировщик с разработчиком автотестов в паре для user-story описывает все возможные случаи в BDD сразу в коде проекта автотестов; 2. В тест-кейсах для автотестов всегда точное отражение того, какими функциональными требованиями обладает US;
26. В итоге - чудо: • Документация для проекта хранится в коде: • Документация версионируется; • Документация актуальная, потому что тестировщики и аналитики будут вынуждены поддерживать её в актуальном состоянии, иначе автотесты будут «ломаться»; • Визуализация тестового покрытия (test coverege); • Сбор статистики и метрик по тестированию и качества проекта;
27. Проектирование тест-кейсов – важнейшая часть тестирования Почему?
28. Зачем мы это делаем? • Тестируем требования • Проектируем тестовую модель • Приоретизируем и категоризируем тест-кейсы
29. Test-case как документация проекта Зачем качественно проектировать тестовую модель и гарантировать тестовое покрытие 100% ?
30. REST-сервис Функциональная логика Вход Выход Внешняя БД Внешний сервис
31. Жизненный цикл ТМ Проектирование ТМ на APi Парная разработка тест- кейсов с аналитиком Парная доработка тест- кейсов с разработчиком Ревью pull request с API на полноту ТМ Проектирование ТМ на UI, подготовка тест.данных Парная разработка автоматизированных тест- кейсов на Ui, с автотестером
32. Автоматизация тестирования: • Внедрение TDD • Разработчики пишут юнит-тесты на API, UI также и на legacy системы • Автотесты как инструмент автоматического контроля качества при pull request • Разработчики автотестов разрабатывают интеграционные и UI автотесты с отставанием в один спринт • Регрессионное тестирование 100% автоматизировано • Инфраструктура для автотестов позволяет делать любой регресс за 30 минут
33. Unit- тестирование
34. Тесты на API, как документация к коду
35. Автогенерация спецификации на API
36. Автогенерация спецификации на API
37. Иерархия тестовой модели
38. Метрики по тестированию Как мы измеряем, что достигли цели? В каждом проекте для оценки качества должно использоваться не менее 5 различных метрик.
39. Как померить качество? … или как мы гарантируем себе, что в погоне за быстрым деплоем мы не ухудшаем качество продукта?
40. Метрики качества • % автоматизации тестового покрытия (e2e UI, unit тесты) • Test coverage • Частота проведения регрессии • Качество исправления дефектов • Дефекты, обнаруженные в продакшне • Code coverege
41. $: есть ли выгода? … метрики, которые мы используем для понимания выгодно ли то, что мы делаем для Бизнеса.
42. Метрики “Цена/Время” • Окно автоматизации тестирования • Окна анализа результатов тестирования • Время на создание автоматизированных тестов • Время на поддержку автоматизированных тестов • Окно тестирования =< 30 мин.
43. Используемый стек технологий Какие инструменты мы используем для достижения цели
44. Инструменты и технологии • Selenium Webdriver, Selenium Grid, Jbehave (BDD), Java, Serenity, Junit, Galen Framework, Ansible, Docker, Mesos+marathon, Azure Pack, Jenkins 2.0 Что хотим попробовать: • Selenide, WebdriverIO, Allure
45. Целевая схема инфраструктуры для автотестов …или как выжать максимум пользы от того что имеем.
46. git Mesos Slave Mesos Slave Mesos Slave Mesos Slave CI Pipeline CI Autotests CLI Number Of Containers CLI Create Selenium Grid Repo Autotests projects Repo Docker Images Mesos master marathon REST API Кластер c произвольным количеством VM c различными физ. характеристиками и в различных VLAN, ОС: Centos 7.2 Инфраструктурное ПО: • ansible • docker • zookeeper • mesos • marathon
47. Pipeline single job autotests Selenium chrome node Selenium firefox node Selenium chrome node Selenium firefox node Jenkins: Job1 cli Number Of Containers cli Create Selenium Grid Selenium Hub Maven, JDK Selenium Grid Mesos master marathon REST API Hub, node запущены в docker- контейнерах cli Delete Selenium Grid
48. Pipeline CLI Number of Containers git Jenkins: Job1 CLI Number Of Containers Repo Autotests projects Входные параметры: • Наименование проекта (git repo) • Max время прогона автотестов - 30 мин • Наименования docker images (необязательно) 1. Подсчитывает количество .story файлов или test-сетов в проекте 2. Исключает skipped тест-ы 3. Считает по формуле, какое количество контейнеров-nodes необходимо поднять в selenium grid 4. Возвращает целочисленное значение
49. Целевая схема нагрузочного тестирования Продукт должен быть не только без багов, но и быстро работать
50. 1. Разрабатываем централизованное хранилище моков, которое переиспользуется разработчиками, тестировщиками для автотестирования и нагрузочного тестирования. 2. Встраиваем запуск нагрузочного тестирования в Pipeliene проекта. Нагрузочное тестирование запускается в момент запуска регрессионных автотестов, после установки приложения на стенд. 3. Автоматизируем анализ результатов автотестов на основании предустановленного SLA. 4. Снимает метрики: скорость загрузки страницы и время отклика REST- сервиса (мидловая часть).
51. Выводы:
52. Артефакт доставить до боя мы можем даже быстрее, чем за 3 часа
53. И напоследок: • Доставлять артефакты до клиента за 3 часа не так уж и сложно ;-) • “Наполеоновские” планы должны учитывать то, что devops - это еще история про людей • Вы больше времени потратите на выстраивание коммуникаций внутри команды, чем на саму техническую реализацию • Вы больше усилий потратите на привитие культуры, чем на изучение какого-то нового инструментария
54. Мои контакты: @travieso_nastya traviesonastya anastasia.aseeva