Scrum глазами тестировщика или как создать стратегию для любой задачиIT61
Елена Кузнецова, QA engineer в VIAcode
https://vk.com/nedotroga401
Как я попала в scrum-команду и это изменило мое представление о тестировании и разработке программного обеспечения. Я расскажу как заменить чек-листы стратегиями, что диаграммы связей - это не страшно, почему общаться с клиентом каждый день - здорово, а четкие требования не сделают продукт лучше.
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Scrum глазами тестировщика или как создать стратегию для любой задачиIT61
Елена Кузнецова, QA engineer в VIAcode
https://vk.com/nedotroga401
Как я попала в scrum-команду и это изменило мое представление о тестировании и разработке программного обеспечения. Я расскажу как заменить чек-листы стратегиями, что диаграммы связей - это не страшно, почему общаться с клиентом каждый день - здорово, а четкие требования не сделают продукт лучше.
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
Out-of-the-box WebDriver API provides two main classes: WebDriver and WebElement. Webium library helps you to extend it to whatever deep UI object structure you need. You can describe basic elements (e.g. Button, Input), construct complex elements (e.g. Calendar) from small pieces and at the end put it all together into your Page Objects. Webium is free and open-source. In my speech I’ll present your how to use it effectively if you want to write Selenium tests in Python.
Игры с огнём: знакомимся с BDD и Cucumber фреймворком BDDfireSQALab
This document discusses BDDfire, a Behavior-Driven Development framework for Ruby. BDDfire includes Capybara for writing acceptance tests, Poltergeist for headless browser testing, parallel_tests for parallel test execution, and tools like Rubocop, CukeSniffer, Yard, RestClient, Axe, Gatling, and Docker to integrate with other development and testing processes. The workshop demonstrated how to set up a BDD project with BDDfire, write tests using Gherkin syntax and predefined steps, and run tests on different browsers and servers.
Практический доклад о том, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование.
В докладе рассмотрены основные проблемы, с которыми команда столкнулась при внедрении и способы их устранения.
Продемонстрированы результаты, которых смогли достичь в течении полугода.
Доклад содержит большое количество лайфхаков и обзоров инструментария, который использовался для достижения цели.
Система управления жизненным циклом разработки программного обеспечения Devpr...Evgeny Savitsky
Devprom - российская компания-разработчик инструментов в области управления проектами
Дата образования: июнь 2008
Количество сотрудников: 9 человек
Количество загрузок дистрибутива: 8600
Количество зарегистрированных пользователей: 4800
Цикл выпуска новых версий продукта: 1 месяц
Андрей Сильчук: "Автоматическое тестирование".Hub-IT-School
Выступление Андрея Сильчука об автоматическом тестировании ПО на Hub QA meetup #1.
Больше мероприятий:
https://vk.com/hub.itschool
https://facebook.com/Hub.IT.School
Автоматическое тестирование и с чем его едятMarina Peregud
Agenda
Автоматизация? Какая еще автоматизация? Автоматическое тестирование ПО. Зачем вообще?
Отличие от мануального тестирования ПО, или Ручник vs человек разумный.
Имею желание, но не имею возможности, или какие знания были бы полезны в этой области.
Когда стоит внедрять автоматизацию.
ROI и другие непонятные слова на три буквы.
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Владимир Никонов "Вызовы при разработке enterprise продукта"Fwdays
В докладе мы рассмотрим этапы развития приложения, начиная от монолитного Web приложения, до распределенной платформы по управлению бизнес-процессами. Покажем этапы развития, задачи и вызовы, которые возникали на каждом их них. Проанализируем различные аспекты, влияющие на развитие архитектуры, такие как бизнес-требования, технологические тренды и возможные ограничения.
Glib Rybalko, GlobalLogic’s Test Lead, consultant and trainer was among 26 known Ukrainian and international experts who took a word on IT Weekend Ukraine 2013. Glib discussed features of automated software testing, benefits and feasibility of using this approach on various projects. During his speech, Glib pointed all necessary steps of automated testing implementation and gave homework for those who were interested in this field and wanted to implement it in their projects.
Онлайн-революция: от ранних репозиториев – к современным МООС-курсамCEE-SEC(R)
This document summarizes the evolution of online education from early content repositories to modern massive open online courses (MOOCs). It describes three stages of development: 1) early content repositories with downloadable materials, 2) addition of video lectures and social integration, and 3) current MOOCs with massive enrollments, open access, and online delivery. The largest MOOC providers, Coursera and edX, are discussed. Trends include using analytics from learner data and blended learning. Feedback indicates MOOCs attract diverse learners and help master concepts. Future work involves specialization courses and project-based learning on Coursera and edX.
Массовый параллелизм для гетерогенных вычислений на C++ для беспилотных автом...CEE-SEC(R)
Michael Wong presented on how SYCL and heterogeneous programming can help develop software for self-driving cars. He discussed that graph programming is well-suited for machine vision and machine learning tasks required for autonomous vehicles. SYCL combines C++ and OpenCL to allow developing software today targeting a wide range of future accelerator hardware through its use of open standards and ability to build computation graphs at compile-time. Codeplay provides products like ComputeCpp that implement SYCL and help deliver embedded intelligence.
Проблемы процесса разработки с точки зрения тестированияCEE-SEC(R)
The document announces a software engineering conference to take place October 28-29 in Moscow, Russia. The conference will address development process issues from a testing perspective over three sessions: "We Demand Code Freeze!", "We Need Priorities!", and "We Want to Know!". It also provides biographical information on the speaker Nikita Syskov, who has 10 years of testing experience including managing 7 projects and conducting over 250 internal trainings.
2. Кратко о проекте
• Заказчик – О’КЕЙ
• Интернет-магазин
• Платформа IBM WebSphere Commerce
3. Цели и задачи
Цели:
• Уменьшение трудозатрат на
регрессионное тестирование
• Оптимизация использования
имеющихся ресурсов
• Уменьшение времени на
релиз
Задачи:
• Разработка собственной
утилиты сборки
• Поиск ресурсов для
автоматизации тестирования
• Подготовка тестов
5. Бюджет – обоснование необходимости
автоматизации тестирования
• экономия времени на регрессионное тестирование
• сравнительно небольшая стоимость поддержки автотестов по
сравнению с ручным тестированием
• окупаемость процесса автоматизации за предсказуемое время
• более строгий контроль качества разработки
7. Тестовое окружение – основные факторы
• железо (если требуется)
• инструменты автоматизации
• стоимость лицензий специализированного ПО и операционных
систем
8. С чего начать?
• Ресурсы
• Люди
• Бюджет
• Тестовое окружение
• Тесты
• База регрессионных тестов
9. А кому и зачем это нужно?
• Команде тестирования
• Команде разработки
• Руководителю проекта
• Заказчику
ЗАЧЕМ?
Предсказуемое время для получения точного результата
10. Технические особенности проекта, на
которые нельзя закрыть глаза
• Платформа IBM WebSphere Commerce
• Не имеет своей системы сборки
• Различие окружений dev, test, stage, prod
11. Технические особенности проекта, на
которые нельзя закрыть глаза
• Разные ветки разработки - разные окружения – разные
конфигурационные файлы
• Различие в идентификаторах публикуемых магазинов
(особенность WSC)
• Внутренние идентификаторы доступности товаров в SOLR –
различается от окружений
12. Технические особенности проекта, на
которые нельзя закрыть глаза
DEV
TEST
STAGE
Module
Module, system
Module, system, integration
13. Выгода
• Исходные данные:
• 6 чел/дней - ручное регрессионное тестирование версии (Tmanual)
• 132 чел/дня – разработка утилиты сборки и автоматизация (Tauto)
• 20 – 23 новые версии в год (С)
• Бесплатный инструмент Selenium/Selenium Grid
• Расчет: Tmanual * С > Tauto * C
• Вывод: срок окупаемости автотестирования: 1-1,5 года
14. Масштабируемость
• Увеличение числа nodes, hubs, scripts
• Test script - программа, использующая библиотеку Selenium для выполнения тестов;
• NODE - запускает браузеры и выполняет действия запрограммированные в Test script'е;
• HUB - выполняет роль сервера, который получает запросы от Test script'а и направляет их на выполнение в NODE'ы.
• Различные конфигурации тестовых систем (ОС + версия браузера)
15. Что мы имеем
Универсальный процесс
• Установка current PROD версии на тестовое окружение
• Сборка и установка изменений на тестовое окружение
• Загрузка тестовых данных (каталоги, цены, изображения, etc.)
• Запуск тестовых скриптов из Selenium Grid
• Сбор и публикация результатов
Время проведения - ночь
16. Выводы
• Высокая скорость проверки
• Удобное масштабирование окружений и поддержка тестов
• Сокращение трудозатрат на регресс
• 100 % результат после исполнения тестов
• Плюсик в карму
Всем добрый день. Меня зовут Анастасия и я хочу сегодня рассказать о том, как мы выстраивали процесс автоматизации тестирования на проекте интернет-магазин Окей. Думаю, что в связи с тенденциями текущего времени наш опыт может пригодиться.
Для начала - пару слов о проекте. Интернет магазин окей реалзиуется на базе платформы IBM WebSphere Commerce. Опыт работы с этой платформой - не однозначный из за технических особенностей платформы, а также из за организации самого проекта. Относительно функционала важно отметить то, что по сути один сайт интернет магазина содержит в себе несколько так называемых подсайтов для гипермаркетов. Дело в том, что покупатель делает заказ на конкретный гипермаркет. Проект реализуется уже в течение двух лет, и за это время мы плавно подошли к тому, что настало время внедрить в проекте автотесты. И вот как это было:
Собственно, необходимость объяснялась тем, что стало слишком много времени уходить на регрессионное тестирование и на локализацию ошибок. Уменьшение времени на эти активности без потери качества, а так же простота локализации ошибок стали нашими главными целями в вопросе внедрения автотестов. И для их достижения был определен следующий круг задач:
- разработка собственной утилиты борки (мы помним, что платформа свой утилиты не предоставляет)
- Подготовка тестов
- выделение времени и людей для организации процессов автоматизации тестирования.
Когда встает вопрос о необходимости автоматизировать что либо в контексте тестирования, закономерно встает вопрос "с чего начать, за какую из задач взяться?". Когда мы задали этот вопрос себе, то поняли,
что первое, за что мы возьмемся - это РЕСУРСЫ. Ресурсы мы разделяли так:
Люди. В организационной структуре проекта люди выделяются под потребности, и если на какой то момент для человека нет задач, то он высвобождается из проекта в так называемый пул. Для нашего проекта был выделен тестировщик-автоматизатор. Одному ему было бы справляться тяжело, поэтому технический руководитель нашего проекта и инженер по технической поддержке выделяли свое время соразмерно своему кругу задач для поднятия автоматизации.
У проекта есть определенный бюджет. Единственный источник этого ресурса - заказчик, который дает согласие на такие работы. Поэтому ему необходимо их обосновать. И тут могут подойти следующие доводы:
- экономия времени на регрессионное тестирование
- сравнительно небольшая стоимость поддержки автотестов по сравнению с ручным тестированием
- окупаемость процесса автоматизации за предсказуемое время
- более строгий контроль качества разработки
Когда мы начинаем говорить о бюджете, нельзя не сказать о стоимости технологических решений, которые будут использоваться. Третий вид ресурса, о котором стоит задуматься - тестовое окружение. Под это понятие определяем следующие пункты:
- железо (если требуется, например, сервера)
- инструменты автоматизации
- стоимость лицензий специализированного ПО и операционных систем
Второй пункт, который мы рассматриваем - это тесты. Руководством проекта должно быть принято решение, какого рода автоматизация должна быть внедрена: функциональное, нефункциональное тестирование или же все вместе. Мы приняли решение на данном этапе автоматизировать проверку интерфейса и функционала, нагрузочное тестирование в рамках данного рассказа мы рассматривать не будем.
Проект уже, можно сказать, зрелый, за время его существования на нем проработали несколько тестировщиков, и общими усилиями была выделена определенная база регрессионных тестов. Именно их было решено автоматизировать, сделав их более "атомарными".
Осознав круг задач, кто-то может махнуть рукой и спросить, а зачем все это нужно? А главное - кому? Не проще ли оставить все как есть, не вводя в проект новые риски?
Так, в неформальной обстановке мы пришли к выводу, что в первую очередь это нужно нам самим - команде тестирования. Приложив усилия в начале процесса на его становление, мы получим ожидаемый результат в последствии, сможем предсказывать выходной уровень качества.
По мере обсуждения и развития темы, нас поддержали коллеги-разработчики. Для них - это возможность непосредственного наблюдения и точного выявления ошибок, а так же возможность точного воспроизведения конкретных багов.
Наконец, автоматизация нужна и руководителю проектов. Это помогает при планировании релизов давать более четкие оценки.
Ну и в завершении, для заказчика будет аргументом то, что плюсы от автотестов окупятся за обозримый срок.
Все это позволяет нам корректно определять время для получения точного результата.
Говоря об автоматизации на проекте, стоит упомянуть о некоторых его технических особенностях. Как я уже говорила, платформа IBM WebSphere Commerce не имеет никакой своей системы сборки. На старте проекта она была написана командой разработки самостоятельно. Первые сборки же вообще проводились вручную,но на данный момент создана своя утилита. Еще одна важная особенность - это различие окружений разработчиков, тестировщиков, стэйджа и прода.
Различия заключаются вот в чем. Первое - в один момент в реализации может быть несколько версий, что в принципе нормальная ситуация. Это уже требует различных окружений с различными конфигурационными файлами. Второе - WebSphere Commerce берет идентификаторы публикуемых магазинов из своего некоего пула, соответственно, поэтому, идентификаторы одного и того же магазина на различных окружениях различаются. Ну и третье - платформа поиска SOLR так же имеет свои
внутренние уникальные идентификаторы в поисковом индексе для определния доступности товаров в магазинах, что являлось специальной ее кастомизацией. (заказчику необходимо было использовать один и тот же каталог продаж в нескольких магазинах.Но при этом ещё и нужно было определённые товары скрывать в определённых магазинах.)
Поскольку автоматизация вводится уже сильно после старта проекта, мы имеем уже вполне устоявшийся план тестирования на наших окружениях, которые, как мы видим, сильно различаются, и, к сожалению, нам проходилось выполнять одни и те же тесты по несколько раз. Во-первых, на dev окружении выполняются ручные модульные тесты. После этого, на test окружении - модульные и часть системны тестов, которые касаются именно сайта. Финальной проверкой перед передачей на приемочное тестирование заказчику служит проверка на stage-окружении. На нем выполняются модульные, системные и интеграционные тесты.
Когда принималось решение о внедрении автоматизации, были подсчитаны количественные показатели выгоды. Что мы имели: на каждую версию, поставляемую в PROD, мы тратили 6 человеко-дней на регрессионное тестирование на stage-окружении. С учетом 20-23 версий в год, мы получали 120-132 человеко-часов только на регресс. По подсчетам, на внедрение автоматизации была дана оценка в 132 человеко/дня, в которую так же входит написание своей утилиты сборки. Как видим, затраты сопоставимы. Так же, было решено использовать бесплатный инструмент Selenium Grid, который полностью покрывает наши потребности в использовании.
На старте работ по внедрению автоматизации трудозатраты превосходили время, затраченное на ручное тестирование. Однако, с течением времени, процесс окупился. Срок окупаемости – примерно полтора года.
Внедренное решение на основе Selenium Grid позволило нам быстро расширить архитектуру нашей автоматизации на все тестовые окружения за счет увеличения числа нод, хабов и скриптов. А уже внутри каждого кластера, образуемого ими, мы можем поднимать сколько угодно конфигураций тестовых машин (ОС и версия бразуера).
В общем итоге мы получили универсальный процесс обновления, осуществляемый по ночам:
- установка текущей ПРОД версии на тестовое окружение
- сборка и установка изменений
- загрузка тестовых данных
- запуск тестовых скриптов
- сборка и публикация результатов прогона тестов.
22. Выводы от всех наших действий могут быть следующими:
увеличение скорости проверки и сокращение трудозатрат на регресс с 6 человеко-дней до 4-6 часов.
удобное масштабирование окружений и поддержка тестов. При желании увеличить регрессионную базу тестов это будет сделать легко
100 процентный результат после исполнения автотестов