Techleads Meetup #1
Мобильный веб: назад в будущее"
Виталий Шароватов, Mobile Web Team Lead и Руслан Байрамкулов, Senior Mobile Web QA Engineer (Badoo)
Описание:
Количество пользователей мобильных устройств уже давно превысило количество пользователей стационарных компьютеров и ноутбуков. В свою очередь мобильный веб — это самая быстрорастущая мобильная платформа (по данным comScore, 2015). И если будущее не за этой платформой, то как минимум, она будет его заметной частью.
Давным-давно для Мобильного веба в Badoo были «тёмные времена». Использовались дизайны нативных платформ и эмитировалось их поведение. Даже релизы случались раз в неделю-две. Около года назад ситуация начала меняться в лучшую сторону. Мобильная веб версия Badoo догнала по количеству фич остальные платформы и показала существенный рост по всем показателям. Теперь мобильный веб релизится каждый день.
В докладе мы расскажем о том, что неправильного происходит с процессами внутри и снаружи команды. Для примера возьмем как собственные грабли, так и чужие, но такие распространённые ошибки организации работы.
О том, что не помогло, рассказывать не будем, а о том, что сработало, ничего не утаим. Эта информация поможет вам работать в удовольствие. В ассортименте истории о том:
— как один автоматизатор всю регрессию покрыл;
— как подружились продакты-дизайнеры с командой разработки;
— как жадные программисты забрали себе всю ответственность;
— пуркуа QA любит сидеть с девелоперами плечом к плечу;
— зачем нужно не спускать глаз с багов, ломающих автоматизацию, и как заканчивать фичу после того, как закончили фичу.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
Techleads Meetup #1
Мобильный веб: назад в будущее"
Виталий Шароватов, Mobile Web Team Lead и Руслан Байрамкулов, Senior Mobile Web QA Engineer (Badoo)
Описание:
Количество пользователей мобильных устройств уже давно превысило количество пользователей стационарных компьютеров и ноутбуков. В свою очередь мобильный веб — это самая быстрорастущая мобильная платформа (по данным comScore, 2015). И если будущее не за этой платформой, то как минимум, она будет его заметной частью.
Давным-давно для Мобильного веба в Badoo были «тёмные времена». Использовались дизайны нативных платформ и эмитировалось их поведение. Даже релизы случались раз в неделю-две. Около года назад ситуация начала меняться в лучшую сторону. Мобильная веб версия Badoo догнала по количеству фич остальные платформы и показала существенный рост по всем показателям. Теперь мобильный веб релизится каждый день.
В докладе мы расскажем о том, что неправильного происходит с процессами внутри и снаружи команды. Для примера возьмем как собственные грабли, так и чужие, но такие распространённые ошибки организации работы.
О том, что не помогло, рассказывать не будем, а о том, что сработало, ничего не утаим. Эта информация поможет вам работать в удовольствие. В ассортименте истории о том:
— как один автоматизатор всю регрессию покрыл;
— как подружились продакты-дизайнеры с командой разработки;
— как жадные программисты забрали себе всю ответственность;
— пуркуа QA любит сидеть с девелоперами плечом к плечу;
— зачем нужно не спускать глаз с багов, ломающих автоматизацию, и как заканчивать фичу после того, как закончили фичу.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac404fest
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Управление компанией с использованием метода критического цепи (МКЦ)Евгений Пикулев
Частная презентация, рассказывающая о недостатках метода критического пути, и о достоинствах метода критической цепи. Полезна для собственников и руководителей компаний.
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Юлия Викторова; Александр Тарасов. DevOps без булшита.ScrumTrek
В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac404fest
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Управление компанией с использованием метода критического цепи (МКЦ)Евгений Пикулев
Частная презентация, рассказывающая о недостатках метода критического пути, и о достоинствах метода критической цепи. Полезна для собственников и руководителей компаний.
JS Lab2017_Алексей Зеленюк_Сбалансированное окружение для вашей продуктивностиGeeksLab Odessa
JS Lab2017, 25 марта, Одесса
Алексей Зеленюк (Application Architect at Eleks Software)
Сбалансированное окружение для вашей продуктивности
Для построения больших веб-приложений необходим хороший фундамент: процесс сборки, тестирования и интеграции, анализа качества кода и отладки. Новые технологии и безнес-требования создают новые требования к окружению, усложняя его. Как построить надежное окружение, сохранив при этом его гибкость и простоту?
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...QAFest
В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик.
Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества.
В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика
•Как безболезненно добавить практики XP и Kanban в Scrum процесс
•Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход
Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования
•Быстрое создание и поддержка тестовой документации, миф или реальность?
•Быстрое внедрение автоматизации
•Тестирование нефункциональных требований
Шаги, необходимые для старта DevOps-трансформации:
1. Выбрать сервис
2. Выявить, кто имеет отношение к сервису
3. Построить Value Stream Map
4. Создать временную команду
5. Поставить задачу
6. Вернуться к пункту 1
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
2. Здрасьте, это я!
к.ф.-м.н., PMP
Менеджер
менеджеров
Автор
http://pmarcor.com/
Соорганизатор
http://pmsamara.com/
3. О чем речь
• Большое количество
параллельных проектов
• Проекты с разным
процессом
• Широкий спектр
технологий
• Короткие или не очень
длительные проекты
• Команда тестирования
1-5 тестировщиков на
проект
• Сложный софт
4. А конкретнее?
– Одна но большая или много,
но маленьких?
• сервис или команды?
– Как всѐ успевать?
• о параллельных проектах
– Как работать комфортно?
• о сохранении и переключении контекста
7. Команда: «Чисто» Сервис
Не работает, так как:
• Никто не понимает, что
происходит
• Никто не отвечает за
результат
• Неясные приоритеты
• Позднее включение
Работает:
• Компактные задачи вне
контекста
• Формализованные
процессы
8. Команда: 1:1 Dev
PM1 PM2
Project1 Project2 Project3 Project4
Dev Dev
Dev Dev Dev
Dev Dev Dev
QСE QСE QСE QСE
QСE QСE QСE QСE
9.
10. Команда: 1:1 с dev
Недостатки:
• Феодальная
раздробленность
• Эндемичность
• Нет дома
Работает:
• большие, длительные,
итеративные проекты
• четкое соотношение
количества участников
команды
• не только тестирование
12. Команда: Что дает?
Достоинства:
• Есть команда проекта
Возможно раннее
подключение
• Есть отдел тестирования
Переключение между ПМ-
ами и проектами
• Синергия проектов
Недостатки:
• Конфликты интересов
между проектами
14. 1. Планирование
• Не совмещать проекты
с одинаковой датой
выпуска
• Участие в процессе
оценивания
• Совмещать проекты
со схожим профилем
• Помнить об отпусках
• Промежуточные
итерации в разные дни
• Приоритеты
определяют ПМ-ы
15. 2. Делать впрок
• Раннее подключение
• Тестирование
спецификации, архитектуры
• Анализ рисков и
тестирование «от рисков»
• Тестирование ранних
билдов, модульное
тестирование
• Серый ящик
• Больше информации для
дебага
• Экономить итерации
16. 3. Борьба с простоями
• Запасная задача/Plan B,
+ полдня
• Сделайте мне билд
• Деление full-test-а
• Отложенные недотесты
• Тестирование аналога/
прототипа
• Запасной environment
• Борьба с блокерами
• Проработка чеклиста/
use-case-а
17. 4. Борьба с пробками
• Деление времени
• Сказать как
можно раньше
• Уточнение задачи
• Пропустить билд /
часть задач
• Фокусировка
• Сужение покрытия
• Критерии останова
• Тесты в фоне
18. 4. Борьба с пробками (2)
Тестирование по
спирали:
• программисты
• приемка
• smoke
• изменения
• приоритеты
• регресс
19. 5. Déjà vu. Не изобретать
велосипед
– Переходы
• Проекты
• Команды
• Функционал
– General Checklist
• Платформа,
• Технология,
• Процесс
– Cross-review
– Обобщения known-
issues и invalid
20. Результаты
– более равномерная
загрузка, меньше
авралов
– меньше трудозатрат
– критичные дефекты
раньше
– больше пространства
для манѐвра
Осталось только…
22. Переключение
контекста: Процесс
– Баги проверяют те же, кто
нашел.
– По возможности, не
делить день.
– Несколько проектов в
неделю.
– Схожий профиль.
– По двое.
– Разные роли в разных
проектах
23. Переключение контекста:
Инструменты
– Traceability matrix (тесты на
билды)
– Нет тесткейсам!
– Чеклисты
– Протоколы сессионных тестов
– Границы разных
тестов/четкая стратегия
– Приоритеты
– Анализ wontfix-ов и
инвалидов
24. Результат: удобнее
– больше
разнообразия
– выше
эффективность
– легче
подключение к
проекту
25. Спасибо!
Калугин Александр
info@pmarcor.com
http://pmarcor.com/ http://pmsamara.com
@pmarcor
Ваши вопросы?