Какие инструменты облачного тестинга используют в Яндексе? Как устроено тестирование в Badoo? Что представляет собой система автоматизированного frontend-тестирования в Wrike?



Пару недель назад наш Wrike Tech club собрал около 150 специалистов по тестированию, чтобы обсудить в питерском офисе компании насущные, вечные и, на первый взгляд, почти неразрешимые проблемы QA в больших (и не очень) проектах. Как и обещали, делимся видео и презентациями со встречи.

Совещания могут заполнять все доступное время, если с ними не бороться. Мы это проверили, проведя опрос об организации работы 1400 офисных сотрудников. 34% признались, что посещают более 6 совещаний в неделю.
Какие же важные решения они принимают в итоге? Практически никакие. 46% сказали, что большинство этих совещаний посвящены отчету о текущем положении дел и «редко» или «никогда» не оканчиваются ясным списком решений по вопросу. Получается пустая трата времени, к тому же не заложенная в план проекта. А значит, участникам таких совещаний придется либо работать сверхурочно, либо переносить дедлайн.
Получив результаты опроса, мы задумались о том, есть ли способы бороться с нерациональной тратой времени (помимо перехода на Wrike, разумеется) и начали искать исследования по этому поводу. Выводы, к которым мы пришли, под катом.

Angular 2 сегодня считают этаким «new kid on the block». Он многим интересен, без его упоминания не обходится практически ни одна крупная front-end конференция, и уже сейчас он готов бросить вызов React. Но до лучей абсолютной славы еще далеко — официального релиза еще не было, хотя в бою фреймворк может попробовать любой желающий. Мы в Wrike, например, уже вовсю используем Angular 2 в продакшне.

Ребята из Google активно привлекают внимание к новому фрейворку и даже недавно провели 48-часовой онлайн хакатон ANGULAR ATTACK, который собрал несколько сотен участников. По его результатам было опубликовано более 270 работ. В этой статье я хочу поделиться опытом своего участия в хакатоне, впечатлениями и наблюдениями, которые могут вам помочь в подобных состязаниях. Добро пожаловать под кат.

Какие инструменты облачного тестинга используют в Яндексе? Как устроено Selenium-тестирование в Badoo? Что представляет собой система автоматизированного frontend-тестирования в Wrike?

19 мая в питерском офисе Wrike состоится встреча специалистов по тестированию, где мы обсудим насущные, вечные и, на первый взгляд, почти неразрешимые проблемы QA в больших (и не очень) проектах.

Чуть больше года назад мы в Wrike начали использовать для планирования метод целей и ключевых результатов (Objectives and Key Results, OKR). Его придумали и впервые применили для в Intel, потом подхватили в Google, Oracle, LinkedIn и Twitter. Метод универсален, хорошо помогает фокусироваться на целях, повышает инициативность и стимулирует работу между разными командами в компании. Плюс его можно отлично реализовать, используя инструменты нашего сервиса, что для нас было одним из ключевых требований.

Если вы ищете подходящий подход к планированию и оценке эффективности командной работы или даже лично для себя, предлагаем присмотреться к OKR внимательнее.

Теоретики управления проектами говорят, что до 78% проектов не выполняются в срок, либо выходят за рамки бюджета. Любой, кто сталкивался с задержками проекта и срывом дедлайна сразу назовет вероятные причины. Это плохо сформулированные цели проекта, нереалистичные сроки, нехватка ресурсов и неэффективная коммуникация в команде.

Отток клиентов, он же churn, — главный враг состаренного и онлайн-бизнеса с моделью платной подписки. Пользователям свойственно быстро мигрировать с одних приложений и сервисов на другие, и сохранить клиентскую базу можно, лишь сохраняя взаимодействие с пользователями на протяжении всего времени использования сервиса. В Wrike мы выработали несколько принципов общения с клиентами, чтобы сделать общение более персонализированным и попробовать вывести его за рамки обычных продаж. Подробнее о них под катом.

О хранении данных в Parquet-файлах не так много информации на Хабре, поэтому надеемся, рассказ об опыте Wrike по его внедрению в связке со Spark вам пригодится.
В частности, в этой статье вы узнаете:

— зачем нужен “паркет”;
— как он устроен;
— когда стоит его использовать;
— в каких случаях он не очень удобен.

За десять лет назад мир вокруг нас незаметно, но значительно изменился. Вспомним 2006-й. Facebook только-только открыл свободную регистрацию для всех, у кого есть электронная почта, включая компании. Телефонные звонки и телеконференции в качестве основного средства делового общения начали вытесняться электронной перепиской и мессенджерами. В Fortune считали лучшими местами для работы не Google и Boston Consulting Group, а биотех-гиганта Genentech и сеть продуктовых магазинов Wegman.

Очевидно, что с 2006 года очень многое изменилось, а следующая декада обещает еще больше кардинальных перемен. Давайте на минутку отвлечемся от текущей работы и попробуем заглянуть в будущее, чтобы оно не застигло нас врасплох.

Недавно мы опросили 850 человек по всему миру, чтобы узнать, как мобильные телефоны и планшеты изменили их подход к работе за последний год.

Основной целью опроса было определить приоритеты и направления разработки мобильных приложений Wrike, но результаты получились достаточно интересными сами по себе. Они показывают, как бум приложений для совместной работы и повышения продуктивности влияет на рабочие привычки и, возможно, будут полезны тем, кто интересуется этим рынком.

Будущее электронной почты вызывает дискуссии уже не первый год, но, похоже, что это будущее существует. Хотя email все больше уступает по функциональности многочисленным облачным сервисам для общения и совместной работы, слухи о скорой смерти почты сильно преувеличены. Согласно исследованиям, это все еще самое важное средство деловых коммуникаций. Почта опережает социальные сети и мессенджеры в силу привычки и простоты использования. А раз нам еще придется какое-то время с ней жить, стоит подумать над более эффективной организацией работы с email.

Почему определенные недостатки языка JavaScript в реалиях разработки такого большого проекта, как наш, оказываются критическими? Как решить проблемы JS, когда количество кода превышает 2 млн строк, а команда насчитывает более 20 человек и постоянно растет? Об этом — в докладе фронтенд тимлида Wrike в рамках митапа, проведенного в нашем офисе совместно с сообществом Piter JS.

Число команд, которые используют Wrike для ведения проектов и совместной работы, в декабре превысило 10 000. Компания растет, и год назад мы столкнулись с необходимостью многократно увеличить службу поддержки (с 20 до 60 человек в перспективе).

Нам нужно было реорганизовать процесс отбора и обучения новых сотрудников, чтобы, с одной стороны, быстро расширить команду, а с другой — сохранить жесткие требования к качеству работы команды. Мы хотим рассказать, что мы для этого сделали.

Привет, Хабр! Мы, Wrike, ежедневно сталкиваемся с потоком данных от сотен тысяч пользователей. Все эти сведения необходимо сохранять, обрабатывать и извлекать из них ценность. Справиться с этим колоссальным объёмом данных нам помогает Apache Spark.

Мы не будем делать введение в Spark или описывать его положительные и отрицательные стороны. Об этом вы можете почитать здесь, здесь или в официальной документации. В данной статье мы делаем упор на библиотеку Spark SQL и её практическое применение для анализа больших данных.

Вторая часть докладов с нашей встречи Wrike фронтенд-разработчиков, посвященная решениям, помогающим поддерживать большой объем legacy кода в оптимальном состоянии. Делимся видеозаписями и презентациями самых интересных выступлений об инструментах и подходах, позволяющих сделать процесс веб-разработки более эффективным.

Недавно в компании Wrike прошла встреча фронтенд-разработчиков. Спикеры из IT-компаний Петербурга и Москвы поделились своими решениями, помогающими облегчить работу со старым кодом, который имеет свойство накапливаться в течение жизненного цикла продукта, отвлекая от новых бизнес-задач. Отдельная часть докладов была посвящена языку Dart, а также причинам, пожиданиям и непосредственно самому процессу перехода с JavaScript на Dart. Делимся видеозаписями и презентациями самых интересных докладов. Часть 1.

Полнотекстовый поиск используется в Wrike почти повсеместно. Поиск в шапке страницы дает возможность быстрого доступа к последним задачам с сортировкой по дате обновления, с совпадением по названию. Такой вариант поиска представлен в разделах «Моя работа» и «Панель задач».
Поиск в списке задач работает по всем полям: название, описание, имена файлов вложений, авторы, комментарии, дата изменения. Максимальный приоритет у задач, активность по которым связана с текущим пользователем, с фразовым совпадением в названии, описании или в комментариях.
Упрощенный вариант поиска по названиям используется:

• при расстановке зависимостей для диаграммы Ганта (предшествующая и последующая задачи),
• при добавлении ссылок на задачи по названиям (меншенинг),
• при добавлении подзадач.

В этих разделах используется instant search с неявным wildcard: пользователь последовательно вводит u, up, upd, update, а поисковые запросы принимают вид: u*, up*, upd*, update*.
Кроме того, wildcards можно использовать во всех вариантах поиска.
Таким образом, часто приходят “тяжелые” поисковые запросы, вызывающие многократное чтение индекса, повышенную нагрузку по CPU/IO на серверах и, как следствие, общие задержки в обработке запросов в “часы-пик”.
В данной статье мы поделимся своим способом решения проблемы производительности.
Речь пойдет об ускорении поиска при работе с поисковым сервером Apache Solr через партиционирование коллекций. Описанный способ был нами опробован на версиях 4.9.0 и 4.10.2.

«Мобилизация» рабочих процессов в компаниях означает, что на телефон или планшет переносится все больше функций для совместной работы. Для Wrike, как кроссплатформенного сервиса управления проектами, важно, чтобы функционал мобильного приложения был абсолютно полноценным, удобным и не ограничивал пользователей в работе. И когда встала задача создать Rich Text Editor с поддержкой совместного редактирования описания задач, мы, оценив возможности существующих WebView компонентов, решили пойти своим путем и реализовали собственный нативный инструмент.

Как мы уже упоминали в предыдущем посте, Wrike провел масштабный опрос более 1400 человек. Среди них — руководители и сотрудники из самых разных отделов, от бухгалтерии до маркетинга и ИТ. Респондентов спрашивали, что они сами считают главными факторами стресса и препятствиями на пути к продуктивной работе. Основная цель опроса — убедиться, что мы развиваем Wrike в востребованном направлении.

Однако результаты могут заинтересовать и более широкий круг читателей: тех, кто управляет людьми и ставит задачи в компаниях (чтобы понять, над чем стоит поработать), и тех, кто над этими задачами работает (хотя бы чтобы знать, что они не одиноки в своем недовольстве).

Потому что выводы опроса не самые утешительные.

Недавно Wrike опросил 1468 человек, чтобы выяснить, какие вещи мешают им продуктивно работать каждый день. Причина №1, актуальная для 60% участников, — необходимость постоянно переключаться между слишком большим количеством задач. 49% вынуждены ждать действий со стороны других людей для продолжения работы. 40% тратят слишком много времени на переписку по электронной почте. Есть в списке и бесконечные совещания, и проблемы с выставлением приоритетов, и непрерывные новые запросы от начальства, и другие «прелести» рабочих будней.

Такие опросы Wrike, понятное дело, проводит не из спортивного интереса. Это, по сути, исследования рыночного спроса, которые позволяют лучше понять, на какие проблемы потребителя нужно целиться со своим сервисом. Как учил своих студентов гарвардский профессор Теодор Левитт, люди покупают не сверла длиной в 4 дюйма, а дырки глубиной в 4 дюйма.

Этот пост посвящается «дыркам» и «сверлам» для маркетологов.