The practical story telling how Devops changed the culture of quality in the Bank. Recently Devops became mainstream topic. But only few people have a deep understanding how to apply it to the process of software quality assurance. Some believe that the Devops kills manual testing.
I will talk about changes it makes to the role of QA engineers themself. The discussion main point is NOT about tools or technologies. It’s NOT about the “silver bullet” for your problems with the quality of products.
Instead, I will show you an integrated approach which we used for quality assurance. It allowed us to significantly reduce the cost of finding and fixing defects. This approach has also accelerated the development and delivery value to our customers and made the whole process more transparent and predictable.
1. DevOps guide
for awesome
quality
assurance
Вы хотите, чтобы у вас каждая
фича «протаскивалась» до
production за 3 часа? Тогда вам
нужно вывести своё
тестирование на продвинутый
уровень!
2.
3. Пару слов о себе:
• Devops
• Agile Testing couch
• Руководитель автоматизации тестирования
• В QA c 2012 года
• В IT с 2007 года
• В Альфа Банке внедряю Облака
• Немного пишу код =)
• Люблю Linux
4. А что же было
раньше?
Регресс регрессом
погонял.
5. Как было:
UI-
приемка и
регресс
Автотесты
Unit-тесты*
Unit-тесты:
• Черный ящик для всех. Никто не
знал что именно покрыто
юнит-тестами, а что не покрыто.
• Все на усмотрение разработчика.
• Code coverage не считался.
* Unit-тесты - тесты, которые пишутся разработчиками
7. • E2E-тесты - любые интеграционные тесты, проверяющие
межкомпонентное или межсистемное взаимодействие
• Selenium-тесты - UI-тесты, эмулирующие действия
пользователя в браузере
8. Как было:
UI-
приемка и
регресс
Автотесты
Unit-тесты
UI-приемка:
• Приемочное тестирование новой
функциональности.
• Осуществляли аналитики, в
заключительных итерациях
привлекая тестера для написания
ТМ.
UI-тесты - тесты, которые проверяют то, что видит пользователь
15. Как сейчас:
Автотесты (e2e, UI)
e2e-тесты, компонентные тесты
Unit-тесты
Unit-тесты:
• Тесты на ту часть кода,
которая не исполняет какую-
либо бизнес-логику.
• Пишутся разработчиками.
• Учитываются в подсчете code
coverage.
UI-приемка
16. Test coverage - тестовое покрытие требований, в %;
1 требование = min 2 тест-кейса (RUP)
17. Как сейчас:
Автотесты (e2e, UI)
e2e-тесты, компонентные тесты
Unit-тесты
E2E тесты:
• Проверяют взаимодействие с
внешними слоями (API, UI);
• Пишут "тестер-разработчик"
или “аналитик-тестер”;
• Исполняются на mocks;
• Часть документации проекта.
UI-приемка
18. Как сейчас:
Автотесты (e2e, UI)
e2e-тесты, компонентные тесты
Unit-тесты
Компонентные тесты:
• Проверяют только одну
компоненту внутри API или UI;
• Являются частью
документации проекта;
• Пишутся в паре "тестер-
разработчик" или “тестер-
аналитик”
UI-приемка
19. Как сейчас:
Автотесты (e2e, UI)
e2e-тесты, компонентные тесты
Unit-тесты
UI-приемка
Автотесты e2e:
• Интеграционные UI тесты
полного цикла. Проверяют
взаимодействие всех слоев
приложения с внешними
системами.
• Разрабатываются в паре
"автотестер-тестер".
20. Как сейчас:
Автотесты (e2e, UI)
e2e-тесты, компонентные тесты
Unit-тесты
UI-приемка
Автотесты UI:
• Компонентные тест-кейсы,
которые проверяют UI с точки
зрения конечного
пользователя. Исполняются на
мокированном API.
• Разрабатываются в паре
"автотестер-тестер".
21. Как сейчас:
Автотесты (e2e, UI)
e2e-тесты, компонентные тесты
Unit-тесты
UI-приемка
UI приемка:
• Ручное тестирование изменения
артефакта, который в рамках
новой версии был изменен.
• Проводится тестировщиком и
имеет жесткое ограничение по
времени.
22. Как сейчас:
Автотесты (e2e, UI)
e2e-тесты, компонентные тесты
Unit-тесты
UI-приемка
30-90 % - code
coverege
40 %
50 % - отставание
в 1 user story
10 % - ручное
тестирование
25. Стратегия
Тестировщик участвует в
review юнит-тестов на полноту
test coverage;
Тестировщик в паре с
разработчиком пишет
юнит-тесты;
Max время приемки -
30 минут;
Обучаем всех тестировщиков
программировать.
30. Specification by Example:
API: Аналитик с тестировщиком генерируют два артефакта для проекта:
1.UML диаграмма. Используем PlantUML. Диаграмма находится в
репозитории проекта;
2.Test-case в нотации BDD в репозитории проекта - каркас для
юнит-тестов. Парная разработка с тестировщиком;
Во время сборки проекта генерируется html-документ в artifactory,
как документация к релизу;
35. Specification by Example:
UI: Проектирование тест-кейсов происходит на user-story:
1.Тестировщик с разработчиком автотестов в паре для
user-story описывает все возможные случаи в BDD сразу
в коде проекта автотестов;
2.В тест-кейсах для автотестов всегда точное отражение
того, какими функциональными требованиями обладает
US;
38. В итоге - чудо:
• Документация для проекта хранится в коде:
• Документация версионируется;
• Документация актуальная, потому что тестировщики и аналитики
вынуждены поддерживать её,
иначе автотесты будут «ломаться»;
• Визуализация тестового покрытия (test coverage);
• Сбор статистики и метрик по тестированию и качества проекта;
45. Внедрение TDD
Разработчики пишут юнит-тесты на API, UI
Покрытие кода тестами (unit-tests, e2e);
Code coverage не менее 25%;
Парное программирование;
46. Разработка автотестов
• Разработчики автотестов разрабатывают интеграционные и UI
автотесты с отставанием в один спринт
• Автотесты запускаются при каждом pull request
• Парное программирование с кем-нибудь из команды;
• Доработка фреймворка с автотестами: время прогона каждой
сборки с автотестами не должно превышать 30 минут.
• Автоматизация тестирования адаптивности и кроссбраузерности;
51. 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
52. 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. Возвращает целочисленное
значение
55. Встраиваем запуск нагрузочного
тестирования в Pipeliene проекта.
Нагрузочное тестирование запускается в
момент запуска регрессионных автотестов,
после установки приложения на стенд.
58. Метрики по
тестированию
Как мы понимаем,
что достигли цели?
В каждом проекте для
оценки качества должно
использоваться не менее
5 различных метрик.
59. Как померить качество?
… или как мы гарантируем себе, что в погоне за
быстрым деплоем мы не ухудшаем качество
продукта?
60. МЕТРИКИ КАЧЕСТВА
Code coverage
Дефекты, обнаруженные в
продакшне
Качество исправления
дефектов
% автоматизации
тестового покрытия
(e2e UI, unit тесты)
Test coverage
Частота проведения
регрессии
Дефекты, обнаруженные
при интеграции
61. $: есть ли выгода?
… метрики, которые мы используем для понимания
выгодно ли то, что мы делаем для Бизнеса.
63. Автоматизация
• Весь регресс автоматизирован;
• Автоматизируем подсчет test coverage;
• Интегрируем отчеты результатов автотестов в jira pipeline;
• Автоматизируем сбор метрик с помощью jira;
68. Немножко программист:
– Обладает навыками программирования на Java или на JS;
– Понимает алгоритмы на начальном уровне;
Супертестировщик – это…
69. Немножко аналитик:
– Знает архитектуру тестируемого приложения;
– Не тестирует «черный ящик» и может залезть в код;
– Осуществляет приемочное тестирование;
Супертестировщик – это…
70. И просто крутой QA engineer:
– Владеет техниками тест-дизайна;
– Умеет проектировать тестовую модель с точки зрения
используемой пирамиды;
– Пишет/проектирует модульные тесты;
Супертестировщик – это…
73. Эволюция тестировщика до супертестировщика
4 level
Написание
тестовой
документации
сразу в коде:
BDD тесты на
API и E2E UI
3 level
Тестирование
документации
на этапе
аналитики
2 level
Самостоятельная
доработка
автотестов сразу
в коде
1 level
Самостоятельное
сопровождение
автотестов
75. 1 автоматизатор = 2 команды
Намеренно создали дефицит ресурса
• Автоматизатор разрабатывает только фреймворк для
приложения команды
• Учит тестировщика писать BDD тесты с использованием
фреймворка
• Обучает 2х тестировщиков из своих команд
• Передает сопровождение разработанных автотестов
команде
76. Совет: обезопасьте себя
• Если есть крутой специалист - пусть он всю работу делает
чужими руками парной сессией.
• Выделяйте время для максимального шаринга экспертизы
между людьми.
• Обучая людей будьте готовы к тому, что они попросят
повышения ЗП
• Придумайте систему мотивации для уже “выросших”
супертестировщиков
78. Внутреннее сommunity
• Коммуникации = знания и обмен информацией
• Обмен опытом
• Предотвращение дублирования одной и той работы в разных
командах
• Мотивация людей для развития