DevOps guide for awesome quality assurance
0 likes354 views
Документ представляет руководство по внедрению DevOps для повышения качества обеспечения, описывая изменения в подходах к тестированию, включая автоматизацию, парное программирование и интеграцию тестов в код. Он акцентирует внимание на важности прозрачности тестирования, новых ролей (супертестировщиков) и метрик качества. Приводятся примеры инструментов и технологий, необходимых для создания эффективной инфраструктуры тестирования.
DevOps guide for awesome quality assurance
- 1. DevOps guide for awesome quality assurance Вы хотите, чтобы у вас каждая фича «протаскивалась» до production за 3 часа? Тогда вам нужно вывести своё тестирование на продвинутый уровень!
- 3. Пару слов о себе: • Devops • Agile Testing couch • Руководитель автоматизации тестирования • В QA c 2012 года • В IT с 2007 года • В Альфа Банке внедряю Облака • Немного пишу код =) • Люблю Linux
- 4. А что же было раньше? Регресс регрессом погонял.
- 5. Как было: UI- приемка и регресс Автотесты Unit-тесты* Unit-тесты: • Черный ящик для всех. Никто не знал что именно покрыто юнит-тестами, а что не покрыто. • Все на усмотрение разработчика. • Code coverage не считался. * Unit-тесты - тесты, которые пишутся разработчиками
- 6. Как было: UI- приемка и регресс Автотесты Unit-тесты Автотесты: Автоматизированные UI E2E сценарии, покрывающие ТМ* регресса. - Не все проекты имели автотесты - Отсутствие доверия у команды к автотестам - Дублировалось ручным тестированием *ТМ - тестовая модель
- 7. • E2E-тесты - любые интеграционные тесты, проверяющие межкомпонентное или межсистемное взаимодействие • Selenium-тесты - UI-тесты, эмулирующие действия пользователя в браузере
- 8. Как было: UI- приемка и регресс Автотесты Unit-тесты UI-приемка: • Приемочное тестирование новой функциональности. • Осуществляли аналитики, в заключительных итерациях привлекая тестера для написания ТМ. UI-тесты - тесты, которые проверяют то, что видит пользователь
- 9. Как было: UI- приемка и регресс Автотесты Unit-тесты Регресс: • Регрессионное тестирование стабильной версии релиза на не ухудшение. • Длилось от 2 дней до 2 недель, в зависимости от системы.
- 10. Как было: UI- приемка и регресс Автотесты Unit-тесты max 20 % Не более 30 %: появляются с опозданием 50 % - ручная работа
- 11. Что “болело”: Чтобы назначить лечение, надо диагностировать болезнь.
- 12. Отсутствие собственной экспертизы Автоматизация тестирования Непрозрачность Экспертиза Документация Автоматизация тестирования “отстает” от разработки самого продукта Непрозрачность всех процессов тестирования для команды Документация отнимает много времени и “пишется в стол”
- 13. Что и как мы изменили? При внедрении DevOps, как культуры, процесс тестирования эволюционировал.
- 14. Пирамида тестирования - способ визуализации того, как мы меняем тестирование
- 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 % - ручное тестирование
- 24. Manual testing 20 % от всего test coverаge - ручное тестирование
- 25. Стратегия Тестировщик участвует в review юнит-тестов на полноту test coverage; Тестировщик в паре с разработчиком пишет юнит-тесты; Max время приемки - 30 минут; Обучаем всех тестировщиков программировать.
- 27. SCRUM PROCESS TESTING QA EngeenerUser Story Artefact 30 минут 3 часа User Story PRODUCT
- 28. Документация как код Как решить проблему устаревшей документации? Или той, что пишется “в стол”?
- 29. Test-case как документация проекта Зачем качественно проектировать тестовую модель и гарантировать тестовое покрытие в 100% ?
- 30. Specification by Example: API: Аналитик с тестировщиком генерируют два артефакта для проекта: 1.UML диаграмма. Используем PlantUML. Диаграмма находится в репозитории проекта; 2.Test-case в нотации BDD в репозитории проекта - каркас для юнит-тестов. Парная разработка с тестировщиком; Во время сборки проекта генерируется html-документ в artifactory, как документация к релизу;
- 33. Зачем мы это делаем? • Тестируем требования • Проектируем тестовую модель • Приоритезируем и категоризируем тест-кейсы
- 34. REST-сервис Функциональная логикаВход Выход Внешняя БД Внешний сервис
- 35. Specification by Example: UI: Проектирование тест-кейсов происходит на user-story: 1.Тестировщик с разработчиком автотестов в паре для user-story описывает все возможные случаи в BDD сразу в коде проекта автотестов; 2.В тест-кейсах для автотестов всегда точное отражение того, какими функциональными требованиями обладает US;
- 38. В итоге - чудо: • Документация для проекта хранится в коде: • Документация версионируется; • Документация актуальная, потому что тестировщики и аналитики вынуждены поддерживать её, иначе автотесты будут «ломаться»; • Визуализация тестового покрытия (test coverage); • Сбор статистики и метрик по тестированию и качества проекта;
- 40. Тесты на API, как документация к коду
- 45. Внедрение TDD Разработчики пишут юнит-тесты на API, UI Покрытие кода тестами (unit-tests, e2e); Code coverage не менее 25%; Парное программирование;
- 46. Разработка автотестов • Разработчики автотестов разрабатывают интеграционные и UI автотесты с отставанием в один спринт • Автотесты запускаются при каждом pull request • Парное программирование с кем-нибудь из команды; • Доработка фреймворка с автотестами: время прогона каждой сборки с автотестами не должно превышать 30 минут. • Автоматизация тестирования адаптивности и кроссбраузерности;
- 47. Инфраструктура Инфраструктура для автотестов позволяет делать любой регресс за 30 минут
- 48. Инфраструктура для автотестов …или как выжать максимум пользы от того что имеем.
- 49. Инструменты и технологии • Selenium Webdriver • Selenium Grid • Ansible • Docker • Mesos + marathon • Azure Pack • Jenkins 2.0
- 50. 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
- 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. Возвращает целочисленное значение
- 53. Целевая схема нагрузочного тестирования Продукт должен быть не только без багов, но и быстро работать
- 54. Разрабатываем централизованное хранилище моков Переиспользуется разработчиками, тестировщиками для автотестирования и нагрузочного тестирования.
- 55. Встраиваем запуск нагрузочного тестирования в Pipeliene проекта. Нагрузочное тестирование запускается в момент запуска регрессионных автотестов, после установки приложения на стенд.
- 56. Автоматизируем анализ результатов автотестов на основании предустановленного SLA.
- 57. Снимаем метрики: - скорость загрузки страницы (UI) - время отклика REST-сервиса (API)
- 58. Метрики по тестированию Как мы понимаем, что достигли цели? В каждом проекте для оценки качества должно использоваться не менее 5 различных метрик.
- 59. Как померить качество? … или как мы гарантируем себе, что в погоне за быстрым деплоем мы не ухудшаем качество продукта?
- 60. МЕТРИКИ КАЧЕСТВА Code coverage Дефекты, обнаруженные в продакшне Качество исправления дефектов % автоматизации тестового покрытия (e2e UI, unit тесты) Test coverage Частота проведения регрессии Дефекты, обнаруженные при интеграции
- 61. $: есть ли выгода? … метрики, которые мы используем для понимания выгодно ли то, что мы делаем для Бизнеса.
- 62. МЕТРИКИ “ЦЕНА/КАЧЕСТВО” Окна анализа результатов тестирования Окно автоматизации тестирования Время на создание автоматизированных тестов Окно тестирования =< 30 мин
- 63. Автоматизация • Весь регресс автоматизирован; • Автоматизируем подсчет test coverage; • Интегрируем отчеты результатов автотестов в jira pipeline; • Автоматизируем сбор метрик с помощью jira;
- 65. Процессные изменения • Прозрачность тестирования; • Учимся принимать риски;
- 66. КОММУНИКАЦИИ
- 67. Супертестировщик - кто же он? Т-образность: cross domain skills & attitudes
- 68. Немножко программист: – Обладает навыками программирования на Java или на JS; – Понимает алгоритмы на начальном уровне; Супертестировщик – это…
- 69. Немножко аналитик: – Знает архитектуру тестируемого приложения; – Не тестирует «черный ящик» и может залезть в код; – Осуществляет приемочное тестирование; Супертестировщик – это…
- 70. И просто крутой QA engineer: – Владеет техниками тест-дизайна; – Умеет проектировать тестовую модель с точки зрения используемой пирамиды; – Пишет/проектирует модульные тесты; Супертестировщик – это…
- 71. ВАЖНО! • Тестер • Тестировщик • QC engineer Не синонимы QA engineer QA engineer <> QC engineer
- 72. Нужны крутые тестировщики Вы не найдете идеальных людей для себя! Ищите людей с потенциалом для обучения.
- 73. Эволюция тестировщика до супертестировщика 4 level Написание тестовой документации сразу в коде: BDD тесты на API и E2E UI 3 level Тестирование документации на этапе аналитики 2 level Самостоятельная доработка автотестов сразу в коде 1 level Самостоятельное сопровождение автотестов
- 74. Что же мы сделали?
- 75. 1 автоматизатор = 2 команды Намеренно создали дефицит ресурса • Автоматизатор разрабатывает только фреймворк для приложения команды • Учит тестировщика писать BDD тесты с использованием фреймворка • Обучает 2х тестировщиков из своих команд • Передает сопровождение разработанных автотестов команде
- 76. Совет: обезопасьте себя • Если есть крутой специалист - пусть он всю работу делает чужими руками парной сессией. • Выделяйте время для максимального шаринга экспертизы между людьми. • Обучая людей будьте готовы к тому, что они попросят повышения ЗП • Придумайте систему мотивации для уже “выросших” супертестировщиков
- 77. Внутреннее community тестировщиков Зачем коммуникации нужны и как их развивать?
- 78. Внутреннее сommunity • Коммуникации = знания и обмен информацией • Обмен опытом • Предотвращение дублирования одной и той работы в разных командах • Мотивация людей для развития
- 79. Выводы
- 80. Devops - это не только автоматизация всего и всея
- 81. Недостаточно внедрить технологию и сделать CI и CD при отсутствии культуры качества
- 82. Функциональные “колодцы” есть не только между dev и ops. Являются ли ваши тестировщики частью Dev?
- 83. DevOps - это в первую очередь история про людей, а не про технологии.
- 84. Вы потратите больше времени на выстраивание коммуникаций внутри команды, чем на настройку Pipeline
- 85. Devops не может существовать без Agile и инженерных практик.