Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Parallels, Денис Чернилевский, "Проблемы роста системы тестирования большого продукта"

2,442 views

Published on

  • Be the first to comment

  • Be the first to like this

Parallels, Денис Чернилевский, "Проблемы роста системы тестирования большого продукта"

  1. 1. проблемы ростасистемы тестирования большого продукта
  2. 2. кто мы ?• мы - automation QA• мы выпускаем большой продукт (платформу) – автоматизация облачных услуг и хостинга – 5000 сервис провайдеров - партнеров – 10 миллионов конечных пользователей• 4 года - опыт автоматизации тестирования• 5 команд автоматизации + outsourcing• 100 разработчиков продукта
  3. 3. пирамида проблем ???level 4. ??level 3. стоимость поддержкиlevel 2. проблемы ростаlevel 1. физиологический
  4. 4. ??? level 1:физиологические потребности 4
  5. 5. система запуска тестов
  6. 6. система сбора результатов
  7. 7. репорт результатов
  8. 8. ??? level 2:проблемы роста
  9. 9. ???проблема первая: изменения в продукте
  10. 10. изменения в продукте• регулярные изменения - это неизбежно• больше пользователей – чаще изменения• больше тестов – сложнее контроль
  11. 11. изменения в продукте - проблема ?• необходима адаптация кода• изменения UI заметны только после запуска• изменения в бизнес логике – еще больнее
  12. 12. изменения в продукте: история• 20 экранов UI• 10 типов бизнес - объектов• 100 тест кейсов • 1000 экранов UI • 300 типов бизнес - объектов • 10000 тест кейсов
  13. 13. изменения в продукте: последствия 3 человека поддержка тестов другие изменение UI изменение бизнес- логики
  14. 14. как решать ?• генерация Java описаний UI страниц• business-objects builders
  15. 15. генерация кода UI контролов• вместе со сборкой продукта• анализатор кода UI страниц продукта• Java описания UI страниц• поля в классах – Selenium control objects
  16. 16. генерация кода UI контролов: пример
  17. 17. profit ?• известны все контролы на странице• изменения контролов не ломают тесты• удаление контрола заметно на стадии компиляции
  18. 18. изменения UI: итог• минус 1 человек на поддержку заметны сразу не влияют на тесты
  19. 19. изменения бизнес-логики продукта• сложное дерево связанности• чем сложнее тест сценарии, тем сложнее зависимости Account Billing Contact method User Group Role Permissions
  20. 20. изменения бизнес-логики: история• 2-3 уровня зависимостей объектов• 20 типов объектов• 5-10 уровней зависимостей объектов• 300 типов объектов
  21. 21. business-objects builders• пока в ручную• отдельный уровень библиотек• фиксированная логика связанности• генерации объекта по-умолчанию
  22. 22. попытаться сразу правильно?• метрика автотестера - количество тесткейсов!• 20 объектов и 2 уровня связанности• не напрягает при небольшом объеме кода...
  23. 23. business-objects builders: пример
  24. 24. profit ?• легкость оперирования объектами• не переживаем о зависимостях• единая логика конфигурации - НЕ в тестах
  25. 25. business-objects builders: итог• сокращение времени исправления багов на 50%• минус строк кода тестов• 1 исправление чинит много тестов• минус 1 человек на поддержку
  26. 26. уровни в тестовой библиотеке собственно тесты business-object builders библиотеки бизнес-объектов Java описания UI страниц платформенный уровень Selenium Log4j SSH UI elements
  27. 27. ???проблема вторая: стабильность запуска тестов
  28. 28. когда это проблема ?• несколько команд и общие компоненты• разрастается тестовая инфраструктура• большое кол-во параллельных запусков
  29. 29. стабильность запуска тестов: история• 1 платформа: Lin• 2 конфигурации• 100 тесткейсов• 8 инсталляций на 2-х серверах • 4 платформы: Win, Win x64, Lin, Lin x64 • 5 конфигураций на каждой платформе • 10000 тесткейсов • 100 инсталляций на 15-ти серверах
  30. 30. стабильность запуска тестов: последствия• 1 проблема ломала 10 запусков• 1 человек – разбор, перезапуск тестов• 1 человек – поддержка инфраструктуры успешно пройдены ошибки из-за инфраструктурных проблем
  31. 31. как решать ?• “stable artifact”• load management• мониторинг инфраструктуры
  32. 32. stable artifact: зависимости компонент• история успешности запусков• 1 проблема ломает 1 запуск build deployment BVT tool customer integration upgrade tests performance stability tests
  33. 33. load management• мониторинг серверов• автоматическая очистка• запуски на наименее загруженных серверах• предотвращение перегрузки• сложнее восстановить, чем предотвратить!
  34. 34. мониторинг инфраструктуры• third-party система мониторинга серверов• слежение за критическими компонентами• наличие истории• уменьшение кол-ва “cannot reproduce” багов
  35. 35. ???проблема третья:10000 тесткейсов
  36. 36. 10000 тесткейсов - проблема ?• много тесткейсов – много падений в тестах• 2000 падений - сложнее найти уникальные• качество разбора падает
  37. 37. 10000 тесткейсов: история• 100 тесткейсов на 1 платформе• 5% failed → 5 репортов• 1/2 часа на разбор • 10000 тесткейсов на 4 платформах • 5% failed → 2000 репортов • 5 дней на разбор
  38. 38. 10000 тесткейсов: последствия• не успеваем разбирать• 50% тестов• теряем regression баги• 1 человек – на разбор тестов
  39. 39. как решать ?• разделение на RED, GREEN группы• GREEN bugs культура в Dev команде• constant dashboard
  40. 40. RED, GREEN test группы• “теория разбитых окон”• не даем разбиваться GREEN группам• уменьшаем размер RED групп
  41. 41. GREEN bugs культура• GREEN баг – приоритет ASAP для Dev команды• GREEN “дежурный” в Dev команде• Dev + QA контроль количества GREEN багов
  42. 42. constant dashboard• constant GREEN дешевле• быстрая реакция на новые проблемы• короче жизнь бага →дешевле фикс
  43. 43. ??? level 3: стоимостьподдержки
  44. 44. level 3: стоимость поддержки• те же проблемы: вид сбоку• синхронный коммит тестов и продукта• 1 test failure → 1 баг• ускорение конфигурации test-а
  45. 45. ???
  46. 46. automation QAhttp://vk.com/parallels_aqa

×