1. проблемы роста
системы тестирования
большого продукта

2. кто мы ?
• мы - automation QA
• мы выпускаем большой продукт (платформу)
– автоматизация облачных услуг и хостинга
– 5000 сервис провайдеров - партнеров
– 10 миллионов конечных пользователей
• 4 года - опыт автоматизации тестирования
• 5 команд автоматизации + outsourcing
• 100 разработчиков продукта

3. пирамида проблем
???
level 4. ??
level 3. стоимость поддержки
level 2. проблемы роста
level 1. физиологический

4. ???
level 1:
физиологические
потребности
4

5. система запуска тестов

6. система сбора результатов

7. репорт результатов

8. ???
level 2:
проблемы роста

9. ???
проблема первая:
изменения в
продукте

10. изменения в продукте
• регулярные изменения - это
неизбежно
• больше пользователей –
чаще изменения
• больше тестов – сложнее
контроль

11. изменения в продукте - проблема ?
• необходима адаптация кода
• изменения UI заметны только после запуска
• изменения в бизнес логике – еще больнее

12. изменения в продукте: история
• 20 экранов UI
• 10 типов бизнес - объектов
• 100 тест кейсов
• 1000 экранов UI
• 300 типов бизнес - объектов
• 10000 тест кейсов

13. изменения в продукте: последствия
3 человека
поддержка тестов другие
изменение
UI
изменение
бизнес-
логики

14. как решать ?
• генерация Java описаний UI страниц
• business-objects builders

15. генерация кода UI контролов
• вместе со сборкой продукта
• анализатор кода UI страниц продукта
• Java описания UI страниц
• поля в классах – Selenium control objects

16. генерация кода UI контролов: пример

17. profit ?
• известны все контролы на странице
• изменения контролов не ломают тесты
• удаление контрола заметно на стадии компиляции

18. изменения UI: итог
• минус 1 человек на поддержку
заметны
сразу
не влияют на
тесты

19. изменения бизнес-логики продукта
• сложное дерево связанности
• чем сложнее тест сценарии, тем сложнее
зависимости
Account
Billing
Contact method
User
Group Role
Permissions

20. изменения бизнес-логики: история
• 2-3 уровня зависимостей объектов
• 20 типов объектов
• 5-10 уровней зависимостей объектов
• 300 типов объектов

21. business-objects builders
• пока в ручную
• отдельный уровень библиотек
• фиксированная логика связанности
• генерации объекта по-умолчанию

22. попытаться сразу правильно?
• метрика автотестера - количество тесткейсов!
• 20 объектов и 2 уровня связанности
• не напрягает при небольшом объеме кода...

23. business-objects builders: пример

24. profit ?
• легкость оперирования объектами
• не переживаем о зависимостях
• единая логика конфигурации - НЕ в тестах

25. business-objects builders: итог
• сокращение времени исправления багов на 50%
• минус строк кода тестов
• 1 исправление чинит много тестов
• минус 1 человек на поддержку

26. уровни в тестовой библиотеке
собственно тесты
business-object builders
библиотеки бизнес-объектов
Java описания UI страниц
платформенный уровень
Selenium Log4j SSH UI elements

27. ???
проблема вторая:
стабильность
запуска тестов

28. когда это проблема ?
• несколько команд и общие компоненты
• разрастается тестовая инфраструктура
• большое кол-во параллельных запусков

29. стабильность запуска тестов: история
• 1 платформа: Lin
• 2 конфигурации
• 100 тесткейсов
• 8 инсталляций на 2-х серверах
• 4 платформы: Win, Win x64, Lin, Lin x64
• 5 конфигураций на каждой платформе
• 10000 тесткейсов
• 100 инсталляций на 15-ти серверах

30. стабильность запуска тестов: последствия
• 1 проблема ломала 10 запусков
• 1 человек – разбор, перезапуск тестов
• 1 человек – поддержка инфраструктуры
успешно
пройдены
ошибки из-за
инфраструктурных
проблем

31. как решать ?
• “stable artifact”
• load management
• мониторинг инфраструктуры

32. stable artifact: зависимости компонент
• история успешности запусков
• 1 проблема ломает 1 запуск
build
deployment BVT
tool
customer integration
upgrade tests
performance stability
tests

33. load management
• мониторинг серверов
• автоматическая очистка
• запуски на наименее
загруженных серверах
• предотвращение перегрузки
• сложнее восстановить, чем
предотвратить!

34. мониторинг инфраструктуры
• third-party система мониторинга серверов
• слежение за критическими компонентами
• наличие истории
• уменьшение кол-ва “cannot reproduce” багов

35. ???
проблема третья:
10000 тесткейсов

36. 10000 тесткейсов - проблема ?
• много тесткейсов – много падений в тестах
• 2000 падений - сложнее найти уникальные
• качество разбора падает

37. 10000 тесткейсов: история
• 100 тесткейсов на 1 платформе
• 5% failed → 5 репортов
• 1/2 часа на разбор
• 10000 тесткейсов на 4 платформах
• 5% failed → 2000 репортов
• 5 дней на разбор

38. 10000 тесткейсов: последствия
• не успеваем разбирать
• 50% тестов
• теряем regression баги
• 1 человек – на разбор тестов

39. как решать ?
• разделение на RED, GREEN группы
• GREEN bugs культура в Dev команде
• constant dashboard

40. RED, GREEN test группы
• “теория разбитых окон”
• не даем разбиваться GREEN группам
• уменьшаем размер RED групп

41. GREEN bugs культура
• GREEN баг – приоритет ASAP
для Dev команды
• GREEN “дежурный” в Dev
команде
• Dev + QA контроль количества
GREEN багов

42. constant dashboard
• constant GREEN дешевле
• быстрая реакция на новые проблемы
• короче жизнь бага →дешевле фикс

43. ???
level 3:
стоимость
поддержки

44. level 3: стоимость поддержки
• те же проблемы: вид сбоку
• синхронный коммит тестов и продукта
• 1 test failure → 1 баг
• ускорение конфигурации test-а

45. ???

46. automation QA
http://vk.com/parallels_aqa