Shift left та Shift Right підходи
до тестування
Який настрій у вас ?
1 2
3
• Олег Заревич
• DevOps  SRE engineer
• В тестуванні з 2012
• Більше 5 років займався
автоматизацією
• Фанат Microsoft стеку
• Ментор та спікер
• Пишу тут
https://medium.com/@olegzarevych
Тестування в SLDC
Проблема
• Довгий зворотній зв’язок
• Призводить до збільшення ціни
• Уповільнює реліз
Антипатерни
• Нічний запуск тестів
• Ручні регресії довжиною у вічність
Shift Left testing
• Shift Left – підхід у якому ми зміщуємо тестування у сторону
розробки та дизайну
• Приципи:
• Testability in mind
• Фокус на автоматизацію
• Швидке та часте виконання тестів
• Починаємо з низу тестової піраміди
Види тестів
• Static code analysis – Sonar, PMD, FindBug
• UnitIntegration tests
• Contract tests – pact.io
• E2E test – API, UI
• Security tests
• Compliance tests
Quality gates
• Запуск на машині розробника
• IDE
• Pre-commit hook
• Запуск на CI
• При створенні PR чи вітки
E2E tests in Shift left
• Тести повинні бути стабільними
• Повинні швидко виконуватись
• Запуск з однієї команди
• Не повинні залежати від тестових даних
Security testing
• Автоматизація базових перевірок безпеки
• Dependency scanning
• Security testing automation – BDD security, Gauntlt
Compliance testing
• Перевірка інфраструктури на відповідність стандартам
• Docker image scanning – Clair, Container Structure Tests
• Infrastructure tests – terratest
Shift Right testing
• Shift Right – зміщення тестування після деплоя на продакшин
• Але не обов’язково що саме на продакшин
• Аксіома - Ваша система впаде у продакшені
• Ціль – бути до того готовим та швидко реагувати
Smoke testing on prod
• Маленький набір тестів
• Тести повинні покривати основні бізнес сценарії
• Стабільні та швидкі
APM & Monitoring
• Отримувати дані про стан системи – Response time, error rate
• Бачити стан hardware – CPU, memory, networking
• Бізнес метрики
• Трейсинг помилок та збір логів
• Нотифікації про проблеми
• Tools – Prometheus, Datadog, Dynatrace
• Tracing – AppInsight, ELK, Jaeger
Synthetics checks
• Synthetic API monitoring
• Real User Monitoring
• Отримуємо доступність сервісу
• Отримуємо повідомлення коли щось йде не так
• Tools – Postman, Pingdom, Datadog
Canary releases
• Техніка розгортання сервісу,
коли доступ до нової версії
отримує певний %
користувачів
• Після певного часу, по
відсутності помилок, доступ
отримують більше або всі
користувачі
• Легко відкотитись назад
Chaos engineering
• Виконується на продакшині
• Моделюється проблема
• Повне завантаження CPU чи memory
• Зупинка сервісу
• Аналізуємо бізнес метрики
• Результат – мінімізуємо зону ураження
• Tools – Gremlin, Chaos Monkey
Summary
• Всі практики та підходи залежать від контексту
• Shift Left & Shift Right – це не ціль, а шлях
• Якість – командна відповідальність
• Не обовязково реалізовувати підхід, достатньо його
запропонувати

ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування»

  • 1.
    Shift left таShift Right підходи до тестування
  • 2.
  • 3.
    • Олег Заревич •DevOps SRE engineer • В тестуванні з 2012 • Більше 5 років займався автоматизацією • Фанат Microsoft стеку • Ментор та спікер • Пишу тут https://medium.com/@olegzarevych
  • 4.
  • 5.
    Проблема • Довгий зворотнійзв’язок • Призводить до збільшення ціни • Уповільнює реліз
  • 6.
    Антипатерни • Нічний запусктестів • Ручні регресії довжиною у вічність
  • 8.
    Shift Left testing •Shift Left – підхід у якому ми зміщуємо тестування у сторону розробки та дизайну • Приципи: • Testability in mind • Фокус на автоматизацію • Швидке та часте виконання тестів • Починаємо з низу тестової піраміди
  • 9.
    Види тестів • Staticcode analysis – Sonar, PMD, FindBug • UnitIntegration tests • Contract tests – pact.io • E2E test – API, UI • Security tests • Compliance tests
  • 10.
    Quality gates • Запускна машині розробника • IDE • Pre-commit hook • Запуск на CI • При створенні PR чи вітки
  • 11.
    E2E tests inShift left • Тести повинні бути стабільними • Повинні швидко виконуватись • Запуск з однієї команди • Не повинні залежати від тестових даних
  • 12.
    Security testing • Автоматизаціябазових перевірок безпеки • Dependency scanning • Security testing automation – BDD security, Gauntlt
  • 13.
    Compliance testing • Перевіркаінфраструктури на відповідність стандартам • Docker image scanning – Clair, Container Structure Tests • Infrastructure tests – terratest
  • 14.
    Shift Right testing •Shift Right – зміщення тестування після деплоя на продакшин • Але не обов’язково що саме на продакшин • Аксіома - Ваша система впаде у продакшені • Ціль – бути до того готовим та швидко реагувати
  • 15.
    Smoke testing onprod • Маленький набір тестів • Тести повинні покривати основні бізнес сценарії • Стабільні та швидкі
  • 16.
    APM & Monitoring •Отримувати дані про стан системи – Response time, error rate • Бачити стан hardware – CPU, memory, networking • Бізнес метрики • Трейсинг помилок та збір логів • Нотифікації про проблеми • Tools – Prometheus, Datadog, Dynatrace • Tracing – AppInsight, ELK, Jaeger
  • 17.
    Synthetics checks • SyntheticAPI monitoring • Real User Monitoring • Отримуємо доступність сервісу • Отримуємо повідомлення коли щось йде не так • Tools – Postman, Pingdom, Datadog
  • 18.
    Canary releases • Технікарозгортання сервісу, коли доступ до нової версії отримує певний % користувачів • Після певного часу, по відсутності помилок, доступ отримують більше або всі користувачі • Легко відкотитись назад
  • 19.
    Chaos engineering • Виконуєтьсяна продакшині • Моделюється проблема • Повне завантаження CPU чи memory • Зупинка сервісу • Аналізуємо бізнес метрики • Результат – мінімізуємо зону ураження • Tools – Gremlin, Chaos Monkey
  • 20.
    Summary • Всі практикита підходи залежать від контексту • Shift Left & Shift Right – це не ціль, а шлях • Якість – командна відповідальність • Не обовязково реалізовувати підхід, достатньо його запропонувати