Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ

CEE-SEC(R)
29. Oct 2016
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
1 von 17

Más contenido relacionado

Was ist angesagt?

Обеспечение качества: Практические советыОбеспечение качества: Практические советы
Обеспечение качества: Практические советыSQALab
Тестируем производительность с помощью SeleniumТестируем производительность с помощью Selenium
Тестируем производительность с помощью SeleniumSQALab
Serious+performance+testingSerious+performance+testing
Serious+performance+testingAlexei Lupan
Тестирование инсталляторовТестирование инсталляторов
Тестирование инсталляторовSQALab
Ошибки начинающего специалиста по нагрузочному тестированию и как их избежатьОшибки начинающего специалиста по нагрузочному тестированию и как их избежать
Ошибки начинающего специалиста по нагрузочному тестированию и как их избежатьSQALab
Нагрузка и автоматизация в большой организации. Движение к DevOpsНагрузка и автоматизация в большой организации. Движение к DevOps
Нагрузка и автоматизация в большой организации. Движение к DevOpsSQALab

Was ist angesagt?(20)

Destacado

Управление IT-зависимостьюУправление IT-зависимостью
Управление IT-зависимостьюCEE-SEC(R)
Process и Case Management в информационной системе: Process и Case Management в информационной системе:
Process и Case Management в информационной системе: CEE-SEC(R)
Webium: Page Objects in PythonWebium: Page Objects in Python
Webium: Page Objects in PythonIgor Khrol
Reliable Scrum: итеративная разработка и жесткие срокиReliable Scrum: итеративная разработка и жесткие сроки
Reliable Scrum: итеративная разработка и жесткие срокиCEE-SEC(R)
Поиск багов при тестировании переходов с веба в мобильное приложениеПоиск багов при тестировании переходов с веба в мобильное приложение
Поиск багов при тестировании переходов с веба в мобильное приложениеSQALab
Лучшие тестировщики - наши пользователиЛучшие тестировщики - наши пользователи
Лучшие тестировщики - наши пользователиSQALab

Destacado(20)

Similar a Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ

Cовременные подходы организации процессов разработкиCовременные подходы организации процессов разработки
Cовременные подходы организации процессов разработкиАлександр Шамрай
QAFest. Роль тестирования в DevopsQAFest. Роль тестирования в Devops
QAFest. Роль тестирования в DevopsАнастасия Асеева
Система управления жизненным циклом разработки программного обеспечения Devpr...Система управления жизненным циклом разработки программного обеспечения Devpr...
Система управления жизненным циклом разработки программного обеспечения Devpr...Evgeny Savitsky
Jubula – TDD UI QA Automation ToolJubula – TDD UI QA Automation Tool
Jubula – TDD UI QA Automation ToolCOMAQA.BY
Web application testing architectureWeb application testing architecture
Web application testing architectureAndrey Lazarev
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеSQALab

Similar a Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ(20)

Más de CEE-SEC(R)

Подбор и адаптация методологий разработки ПО под различные типы производствен...Подбор и адаптация методологий разработки ПО под различные типы производствен...
Подбор и адаптация методологий разработки ПО под различные типы производствен...CEE-SEC(R)
Проектный офис и аналитикПроектный офис и аналитик
Проектный офис и аналитикCEE-SEC(R)
Онлайн-революция: от ранних репозиториев – к современным МООС-курсамОнлайн-революция: от ранних репозиториев – к современным МООС-курсам
Онлайн-революция: от ранних репозиториев – к современным МООС-курсамCEE-SEC(R)
Массовый параллелизм для гетерогенных вычислений на C++ для беспилотных автом...Массовый параллелизм для гетерогенных вычислений на C++ для беспилотных автом...
Массовый параллелизм для гетерогенных вычислений на C++ для беспилотных автом...CEE-SEC(R)
Как компании с вузами вместе ИТ специалиста готовили или Чем ИТ компания може...Как компании с вузами вместе ИТ специалиста готовили или Чем ИТ компания може...
Как компании с вузами вместе ИТ специалиста готовили или Чем ИТ компания може...CEE-SEC(R)
«Знак качества» как инструмент анализа восприятия продукта клиентами«Знак качества» как инструмент анализа восприятия продукта клиентами
«Знак качества» как инструмент анализа восприятия продукта клиентамиCEE-SEC(R)

Más de CEE-SEC(R)(20)

Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ

Hinweis der Redaktion

  1. Всем добрый день. Меня зовут Анастасия и я хочу сегодня рассказать о том, как мы выстраивали процесс автоматизации тестирования на проекте интернет-магазин Окей. Думаю, что в связи с тенденциями текущего времени наш опыт может пригодиться.
  2. Для начала - пару слов о проекте. Интернет магазин окей реалзиуется на базе платформы IBM WebSphere Commerce. Опыт работы с этой платформой - не однозначный из за технических особенностей платформы, а также из за организации самого проекта. Относительно функционала важно отметить то, что по сути один сайт интернет магазина содержит в себе несколько так называемых подсайтов для гипермаркетов. Дело в том, что покупатель делает заказ на конкретный гипермаркет. Проект реализуется уже в течение двух лет, и за это время мы плавно подошли к тому, что настало время внедрить в проекте автотесты. И вот как это было:
  3. Собственно, необходимость объяснялась тем, что стало слишком много времени уходить на регрессионное тестирование и на локализацию ошибок. Уменьшение времени на эти активности без потери качества, а так же простота локализации ошибок стали нашими главными целями в вопросе внедрения автотестов. И для их достижения был определен следующий круг задач: - разработка собственной утилиты борки (мы помним, что платформа свой утилиты не предоставляет) - Подготовка тестов - выделение времени и людей для организации процессов автоматизации тестирования.
  4. Когда встает вопрос о необходимости автоматизировать что либо в контексте тестирования, закономерно встает вопрос "с чего начать, за какую из задач взяться?". Когда мы задали этот вопрос себе, то поняли, что первое, за что мы возьмемся - это РЕСУРСЫ. Ресурсы мы разделяли так: Люди. В организационной структуре проекта люди выделяются под потребности, и если на какой то момент для человека нет задач, то он высвобождается из проекта в так называемый пул. Для нашего проекта был выделен тестировщик-автоматизатор. Одному ему было бы справляться тяжело, поэтому технический руководитель нашего проекта и инженер по технической поддержке выделяли свое время соразмерно своему кругу задач для поднятия автоматизации. У проекта есть определенный бюджет. Единственный источник этого ресурса - заказчик, который дает согласие на такие работы. Поэтому ему необходимо их обосновать. И тут могут подойти следующие доводы:
  5. - экономия времени на регрессионное тестирование - сравнительно небольшая стоимость поддержки автотестов по сравнению с ручным тестированием - окупаемость процесса автоматизации за предсказуемое время - более строгий контроль качества разработки
  6. Когда мы начинаем говорить о бюджете, нельзя не сказать о стоимости технологических решений, которые будут использоваться. Третий вид ресурса, о котором стоит задуматься - тестовое окружение. Под это понятие определяем следующие пункты:
  7. - железо (если требуется, например, сервера) - инструменты автоматизации - стоимость лицензий специализированного ПО и операционных систем
  8. Второй пункт, который мы рассматриваем - это тесты. Руководством проекта должно быть принято решение, какого рода автоматизация должна быть внедрена: функциональное, нефункциональное тестирование или же все вместе. Мы приняли решение на данном этапе автоматизировать проверку интерфейса и функционала, нагрузочное тестирование в рамках данного рассказа мы рассматривать не будем. Проект уже, можно сказать, зрелый, за время его существования на нем проработали несколько тестировщиков, и общими усилиями была выделена определенная база регрессионных тестов. Именно их было решено автоматизировать, сделав их более "атомарными".
  9. Осознав круг задач, кто-то может махнуть рукой и спросить, а зачем все это нужно? А главное - кому? Не проще ли оставить все как есть, не вводя в проект новые риски? Так, в неформальной обстановке мы пришли к выводу, что в первую очередь это нужно нам самим - команде тестирования. Приложив усилия в начале процесса на его становление, мы получим ожидаемый результат в последствии, сможем предсказывать выходной уровень качества. По мере обсуждения и развития темы, нас поддержали коллеги-разработчики. Для них - это возможность непосредственного наблюдения и точного выявления ошибок, а так же возможность точного воспроизведения конкретных багов. Наконец, автоматизация нужна и руководителю проектов. Это помогает при планировании релизов давать более четкие оценки. Ну и в завершении, для заказчика будет аргументом то, что плюсы от автотестов окупятся за обозримый срок. Все это позволяет нам корректно определять время для получения точного результата.
  10. Говоря об автоматизации на проекте, стоит упомянуть о некоторых его технических особенностях. Как я уже говорила, платформа IBM WebSphere Commerce не имеет никакой своей системы сборки. На старте проекта она была написана командой разработки самостоятельно. Первые сборки же вообще проводились вручную,но на данный момент создана своя утилита. Еще одна важная особенность - это различие окружений разработчиков, тестировщиков, стэйджа и прода.
  11. Различия заключаются вот в чем. Первое - в один момент в реализации может быть несколько версий, что в принципе нормальная ситуация. Это уже требует различных окружений с различными конфигурационными файлами. Второе - WebSphere Commerce берет идентификаторы публикуемых магазинов из своего некоего пула, соответственно, поэтому, идентификаторы одного и того же магазина на различных окружениях различаются. Ну и третье - платформа поиска SOLR так же имеет свои внутренние уникальные идентификаторы в поисковом индексе для определния доступности товаров в магазинах, что являлось специальной ее кастомизацией. (заказчику необходимо было использовать один и тот же каталог продаж в нескольких магазинах.Но при этом ещё и нужно было определённые товары скрывать в определённых магазинах.)
  12. Поскольку автоматизация вводится уже сильно после старта проекта, мы имеем уже вполне устоявшийся план тестирования на наших окружениях, которые, как мы видим, сильно различаются, и, к сожалению, нам проходилось выполнять одни и те же тесты по несколько раз. Во-первых, на dev окружении выполняются ручные модульные тесты. После этого, на test окружении - модульные и часть системны тестов, которые касаются именно сайта. Финальной проверкой перед передачей на приемочное тестирование заказчику служит проверка на stage-окружении. На нем выполняются модульные, системные и интеграционные тесты.
  13. Когда принималось решение о внедрении автоматизации, были подсчитаны количественные показатели выгоды. Что мы имели: на каждую версию, поставляемую в PROD, мы тратили 6 человеко-дней на регрессионное тестирование на stage-окружении. С учетом 20-23 версий в год, мы получали 120-132 человеко-часов только на регресс. По подсчетам, на внедрение автоматизации была дана оценка в 132 человеко/дня, в которую так же входит написание своей утилиты сборки. Как видим, затраты сопоставимы. Так же, было решено использовать бесплатный инструмент Selenium Grid, который полностью покрывает наши потребности в использовании. На старте работ по внедрению автоматизации трудозатраты превосходили время, затраченное на ручное тестирование. Однако, с течением времени, процесс окупился. Срок окупаемости – примерно полтора года.
  14. Внедренное решение на основе Selenium Grid позволило нам быстро расширить архитектуру нашей автоматизации на все тестовые окружения за счет увеличения числа нод, хабов и скриптов. А уже внутри каждого кластера, образуемого ими, мы можем поднимать сколько угодно конфигураций тестовых машин (ОС и версия бразуера).
  15. В общем итоге мы получили универсальный процесс обновления, осуществляемый по ночам: - установка текущей ПРОД версии на тестовое окружение - сборка и установка изменений - загрузка тестовых данных - запуск тестовых скриптов - сборка и публикация результатов прогона тестов.
  16. 22. Выводы от всех наших действий могут быть следующими: увеличение скорости проверки и сокращение трудозатрат на регресс с 6 человеко-дней до 4-6 часов. удобное масштабирование окружений и поддержка тестов. При желании увеличить регрессионную базу тестов это будет сделать легко 100 процентный результат после исполнения автотестов