В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
QA Fest 2019. Петр Тарасенко. QA Hackathon - The Cookbook 22
QA Fes 2016. Анастасия Асеева. Роль тестирования в Devops
1. Роль
тестирования
в Devops
Вы хотите, чтобы у вас каждая
фича «протаскивалась» до
production за 3 часа? Тогда вам
нужно вывести своё
тестирование на продвинутый
уровень!
2. Роль
тестирования
в Devops
Вы хотите, чтобы у вас каждая
фича «протаскивалась» до
production за 3 часа? Тогда вам
нужно вывести своё
тестирование на продвинутый
уровень!
3. Пару слов о себе:
• Devops евангелист
• Agile Testing тренер
• Руководитель автоматизации тестирования
• В QA c 2012 года
• В IT с 2007 года
• В АльфаБанке внедряю Облака
• Немного пишу код =)
• Люблю Linux
5. Термины
Unit-тесты - тесты, которые пишутся разработчиками;
E2E-тесты - любые интеграционные тесты, проверяющие межкомпонентное
или межсистемное взаимодействие;
Selenium-тесты - UI-тесты, эмулирующие действия пользователя в
браузере;
UI-тесты - тесты, которые проверяют то, что видит пользователь;
Test coverage - тестовое покрытие требований, в%.
Production/бой - стенд с приложением для конечного пользователя;
Mocks - "заглушки" для внешних систем, слоев;
Супертестировщики - тестировщики, которые самостоятельно
поддерживают автотесты, и немного умеют программировать;
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 минут.
• Автоматизация тестирования адаптивности и кроссбраузерности;
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 приемка: ручное тестирование
изменения артефакта, который в
рамках новой версии был изменен.
Проводится тестировщиком и имеет
жесткое ограничение по времени.
20. Супертестировщик – это…
• Тестировщик немножко программист:
– Обладает навыками программирования на Java или на JS;
– Понимает алгоритмы на начальном уровне;
• Тестировщик немножко аналитик:
– Знает архитектуру тестируемого приложения;
– Не тестирует «черный ящик» и может залезть в код;
– Осуществляет приемочное тестирование;
• Тестировщик крутой QA engineer:
– Владеет техниками тест-дизайна;
– Умеет проектировать тестовую модель с точки зрения используемой
пирамиды;
– Пишет/проектирует модульные тесты;
21. Нужны крутые тестровщики
• Подбор людей с экспертизой
• Обучение тестировщиков
• На каждую проектную команду 0.5 автотестера
• Коммуникации
• Организация и развитие community сообщества внутри Альфа Лабы;
• Выращивание собственных клонов =)
22. Визуализация качества продукта для команды:
• SonarQube и Zephyr автоматически проверяют code coverage и test
coverage (SonarQube контролирует SLA качества кода для проекта)
• Визуализация качества продукта с помощью дашбордов
• (Визуализировано состояние качества кода по всему проекту)
• Мониторинг производительности API
• Мониторинг производительности Front
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);
• Сбор статистики и метрик по тестированию и качества проекта;
32. Автоматизация тестирования:
• Внедрение TDD
• Разработчики пишут юнит-тесты на API, UI также и на legacy системы
• Автотесты как инструмент автоматического контроля качества при
pull request
• Разработчики автотестов разрабатывают интеграционные и UI
автотесты с отставанием в один спринт
• Регрессионное тестирование 100% автоматизировано
• Инфраструктура для автотестов позволяет делать любой регресс за
30 минут
38. Метрики по
тестированию
Как мы измеряем, что
достигли цели?
В каждом проекте для
оценки качества должно
использоваться не менее
5 различных метрик.
39. Как померить качество?
… или как мы гарантируем себе, что в погоне за
быстрым деплоем мы не ухудшаем качество
продукта?
40. Метрики качества
• % автоматизации тестового покрытия (e2e UI, unit
тесты)
• Test coverage
• Частота проведения регрессии
• Качество исправления дефектов
• Дефекты, обнаруженные в продакшне
• Code coverege
41. $: есть ли выгода?
… метрики, которые мы используем для понимания
выгодно ли то, что мы делаем для Бизнеса.
42. Метрики “Цена/Время”
• Окно автоматизации тестирования
• Окна анализа результатов тестирования
• Время на создание автоматизированных тестов
• Время на поддержку автоматизированных
тестов
• Окно тестирования =< 30 мин.
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. Возвращает целочисленное
значение
50. 1. Разрабатываем централизованное хранилище моков, которое
переиспользуется разработчиками, тестировщиками для
автотестирования и нагрузочного тестирования.
2. Встраиваем запуск нагрузочного тестирования в Pipeliene проекта.
Нагрузочное тестирование запускается в момент запуска
регрессионных автотестов, после установки приложения на стенд.
3. Автоматизируем анализ результатов автотестов на основании
предустановленного SLA.
4. Снимает метрики: скорость загрузки страницы и время отклика REST-
сервиса (мидловая часть).
53. И напоследок:
• Доставлять артефакты до клиента за 3 часа не так уж и сложно ;-)
• “Наполеоновские” планы должны учитывать то, что devops - это
еще история про людей
• Вы больше времени потратите на выстраивание коммуникаций
внутри команды, чем на саму техническую реализацию
• Вы больше усилий потратите на привитие культуры, чем на
изучение какого-то нового инструментария