Vladimir Trandafilov - When you need your system of cross browser testing

1. Когда нужна своя система кросс-
браузерного тестирования и как ее сделать:
техническая платформа и ROI обоснование
Владимир Трандафилов

2. Докладчик
Владимир Трандафилов, Украина
Quality Control Engineer (Test Automation), Infopulse
• ~2 лет в автоматизации
• QA engineer, преподаватель, тренер
• Ph.D.
/in/vladimir-trandafilov-ph-d-5a1150bb/
Информация

3. Кросс-браузерность
Кросс-браузерность – это свойство сайта отображаться
и работать во всех популярных браузерах идентично
[wiki].• История возникновения термина («Война браузеров»: статья / фильм)
• Стандарт W3C для браузеров
• Статистика по браузерам: W3school, Clickly, StatCounter, NetMarketShare, GoogleAnalytics
• Как тестировать:
• скриншотер BrowserShots
• виртуализация: VMware workstation, Windows Virtual PC, Oracle VirtualBox
• эмуляторы: IETester, BrowserSandbox
• облачные решения: Multibrowser, CrossBrowserTesting, BrowserStack, SauceLabs,
Lunascape, Browsera
Cross-browser testing – фундаментальная статья по теме от Mozilla Development Network
Обзор проблемы, варианты решения

4. Кросс-браузерность
Возможные случаи, в которых необходимо создание
собственного окружения:
• Желание заказчика (хочу и все!)
• Облако не покрывает все требования (нет нужного браузера)
• Бдительность заказчика (минимум сторонних ресурсов)
• Существующее окружение (что-то уже есть)
• Финансовая сторона (облака дороже)
* Всегда нужно помнить о наличии времени на создание
Собственное окружение

5. Проблема
Специфика проекта и требования к тестированию:
• Миграция только front end части c AS + Flash на JS + HTML5 (Angular 2)
• Повышенные требования к безопасности (минимум третьесторонних ресурсов)
• Пять поддерживаемых браузеров по две версии каждого
• Тесты должны быть полностью автоматизированы (~100%)
• Тестовое окружение отсутствует
• Использование Ranorex для автоматизации
• Интеграция процесса тестирования с Jenkins
• Трекинг результатов тестирования в TestLink
Chrome Firefox Safari EDGE IE
54, latest 50, latest 9, 10 13, 14 10, 11
Постановка задачи

6. Решение
Стоимость облачного решения:
𝐶𝑐.𝑠. 𝑛 𝑚 = 𝑛 𝑚 ∙ с 𝑝.𝑚.,
где: 𝑛 𝑚 – предположительное количество месяцев
использования;
с 𝑝.𝑚. – стоимость «облачного» пакета в месяц,
определяется количеством одновременных
потоков и предоставляемым временем для
выполнения автотестов.
ROI обоснование
𝐶, $
𝑡, 𝑚𝑜𝑛𝑡ℎ𝑠
𝐶𝑐.𝑠. 𝑛 𝑚
𝐶 𝑜.𝑠.
𝑅𝑂𝐼
Стоимость собственного окружения:
𝐶 𝑜.𝑠. = 𝐶𝑐𝑟 + 𝐶𝑙𝑖𝑐 = const,
где: 𝐶𝑐𝑟 – суммарная стоимость создания (работа
DevOps) и настройки (работа QA automation);
𝐶𝑙𝑖𝑐 – суммарная стоимость необходимых
лицензий.
Точка ROI: 𝑛 𝑚
𝑅𝑂𝐼
=
𝐶 𝑐𝑟+𝐶𝑙𝑖𝑐
с 𝑝.𝑚.
= 6,8 ≅ 7 𝑚𝑜𝑛𝑡ℎ.

7. Решение
Continuous delivery
New build
Auto-deployment on DEV
Run Smoke auto-tests
Run E2E and Regression
auto-tests
Pre-deployment approval
Manual deployment on QA
Post-deployment approval
Pre-deployment approval
Manual Deployment on UAT
Infopulse QA
Customer’s QA
DEV
QA
UAT
Development
bugfix
User acceptance tests
Ready for
Prod

8. Решение
Структура окружения

9. Решение
Для каждого типа тестирования (smoke, e2e, regression)
создаются по две job’ы: base и multi-browser
base job – параметризированная job’а, в
которой настроены управление кодом,
сборка (чтоб получить *.exe), интеграция
с TestLink и e-mail уведомления
параметры: BROWSER_VERSION,
FE_BUILD_NUMBER, node
Структура job
multi-browser job – pipeline job’а, которая
с помощью Groovy скрипта запускает
base job на нужном узле с нужным
браузером и определяет номер
последней стабильной сборки front end
для его привязки к результатам
тестирования

10. Результаты
Как это выглядит в Jenkins
Chrome_v54
Firefox_v50

11. Результаты
Как это выглядит в TestLink

12. Результаты
Особенности системы
по крайней мере в одном браузере
есть 1 «упавший» тест
все тесты во всех браузерах
прошли успешно

13. Результаты
E-mail уведомления и отчеты

14. Вопросы
5 минут.
Вопросы также можно будет задать в лаунж зоне