Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.

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

В продуктовой разработке постоянно и довольно остро стоит вопрос эффективности. Как построить процесс так, чтобы он был оптимален с точки зрения бизнеса, роста сотрудников, изменяемости, прозрачности и многих других факторов? Где та самая «серебряная пуля», которая позволит решить сразу все проблемы и избавит вас как руководителя от головной боли?

На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии разработки: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы и подходы, фреймворки и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?

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

Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Badoo. Это уже третий мой пост подряд в нашем блоге на Хабре. Но на всякий случай представлюсь снова: я – Илья Агеев, руковожу QA в Badoo.

На этот пост меня подтолкнула публикация «Почему я ворую книги, бедные авторы, и как это исправить», а именно — скепсис и возражения на мой комментарий о том, что я не читаю плохие книги. Мне предложили рассказать, как я выбираю книги для чтения и что именно читаю. Ну я и повелся.
Оформить список было сравнительно просто, FBReader любезно хранил на GoogleDrive все скачанные книги с того момента, как там появилась эта услуга. Предлагаю вашему вниманию список прочитанного мной за 2,5 года из жанров фентези и фантастики.

Предисловие переводчика

С сегодняшнего дня начинаю публикацию переведенных мною с английского языка отрывков из произведения Роберта Хайнлайна «Заберите себе правительство» («Take Back Your Government») – руководства для начинающих политиков, написанного Хайнлайном в конце 40-х годов. Часть этого материала уже опубликована мною в ЖЖ, но, думаю, начинать читать хорошую книгу сразу с середины — неправильно, поэтому начинаю публиковать с начала.

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

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

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

Но если вы проводите за своим инструментом до 80% рабочего времени, то желательно убедиться, что вы не тратите время впустую и что работа доставляет вам удовольствие. В этой статье я бы хотел немного рассказать про те инструменты, которыми я лично пользуюсь каждый день, и про то, как они улучшают user experience (и, часто, продуктивность) при работе с консолью и с удаленными серверами в частности.

Проблемы ssh

При работе с удаленными серверами по ssh есть много вещей, которые могут фрустрировать, но основных проблем две, и первая из них принципиально неразрешима в рамках ssh:

1. При высоком round-trip latency (>100 ms) пользовательский ввод появляется с ощутимой задержкой, а при использовании мобильного интернета с edge (latency 1000 ms) работа становится подобна пытке
2. При временных проблемах (несколько минут) с доставкой пакетов, соединение может порваться с write failed: broken pipe, причем узнаете вы об этом только при попытке ввода или при использовании настроек вроде keepaliveinterval

Первая проблема неразрешима потому, что ssh by-design является просто транспортом для байтов, и существующие приложения на это поведение расчитывают. Поскольку ssh не пытается интерпретировать этот поток байтов, он не может осуществлять предиктивный ввод. Лично для меня именно эта проблема наиболее актуальна, поскольку мне приходится работать с серверами в европе и США, и во втором случае задержка составляет около 200 мс и является принципиально неустранимой, по крайней мере до изобретения квантовой коммуникации или чего-нибудь подобного. Вторая же проблема проявляется в наших условиях относительно редко, но всё же неприятно переустанавливать все соединения при сбоях сети (и перезапускать упавшие приложения, если они почему-то не были запущены в screen).

Журнал Forbes обратил внимание на интересную тему, о которой не принято говорить: зависимость зарплаты сотрудника от стажа работы в компании. Выясняется, что на максимальную зарплату могут рассчитывать вовсе не лояльные сотрудники, а совсем наоборот — те, кто часто меняет работу.

У этого явления существует несколько причин. Одна из них — кадровая политика большинства компаний, которая устанавливает потолок на максимальное повышение зарплаты сотрудника. В среднем, в 2013 году зарплаты внутри компаний повышались на 3%. Слабые сотрудники могут рассчитывать на прибавку 1,3%, а самые лучшие — на 4,5%, но не более того. Это примерно соответствует уровню инфляции (2,1% за прошлый год).

В то же время при смене работодателя средняя прибавка к зарплате составляет от 10% до 20%, а иногда и больше.

Disclaimer: Я работаю в Google на позиции инженера уже почти 4 года.

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

Думаю, все ниже написанное почти в полной мере справедливо и для других похожих компаний. Поэтому я буду писать “компания” вместо Google. Не ручаюсь, но подозреваю (и подозрения подтверждаются большим количеством знакомых), что примерно то же самое можно сказать и о Microsoft, и о Facebook, и об Amazon, и о других приличных больших компаниях.

На Хабре довольно много упоминаний о BDD. К сожалению, статьи, которые я читал, так и не дали мне ответа на вопрос «а зачем мне все это нужно?» Ответ пришел с неожиданной стороны. Когда я всерьез занялся вопросом автоматизации приемочного тестирования, мне под руку попалась книга Gojko Adzic (не уверен в транскрипции, поэтому не стал переводить имя автора) Specification By Example.
Читая ее, я не уставал удивляться: каждая новая глава описывала шишки, которые я набивал на своем личном опыте, и предлагала решения аналогичные или лучшие, чем те, к которым я приходил сам методом проб и ошибок.

Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.

Предисловие переводчика: В мире написано столько книг по личной эффективности и тайм-менеджменту, что берясь за этот перевод я безусловно задавал себе вопрос: «А есть ли здесь вообще что-то новое, ради чего эту статью стоит переводить, и главное читать»? Сначала мне казалось, что я ответил на этот вопрос «да», однако реальность оказалась несколько сложнее. 

Сейчас я думаю, что сказать что-то новое человеку, который прочитал хотя бы 2-3 книги по тайм-менеджменту и личной эффективности практически невозможно. Однако существует огромная пропасть между тему, что люди знают, и тем, что люди делают. Поэтому если у вас уже есть какой-то багаж знаний по личной эффективности, я советую вместо вопроса «это что-то, чего я не знаю?» задавать другие вопросы:

1. Согласен ли я с написанным?
2. Если да, поступаю ли я так?
3. Если нет, почему и что я могу сделать чтобы начать поступать правильно? 

Уверен, так статья принесет вам гораздо больше пользы.

Должен сказать, что я с огромным удовольствиям ходил по ссылкам в этой статье, особенно по тем, которые описывают эксперименты Криса (такие как переключение между 90-часовой и 20-часовой рабочими неделями). Поэтому я принял решение сохранить все эти ссылки в переведенной статье.

Также хотел бы сделать замечание для любителей красивого русского языка. Я довольно долго думал, менять ли «продуктивность»  на более близкие родному уху «производительность» и «личную эффективность», но в итоге решил оставить всё как есть – главным образом из-за невозможности использования одного и того же слова в разных контекстах.

В качестве последнего пожелания – это довольно длинная статья, поэтому читайте продуктивно: не переключайтесь между задачами в процессе чтения; делайте перерывы если ощущаете усталость и потерю концентрации; записывайте полезные мысли, не надеясь на память.

Приятного чтения!

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

Отказ от электронной почты сегодня сравним с отказом от телефонного номера: вы должны быть действительно на своей волне, чтобы на это отважиться.

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

Давайте обсудим 11 самых неловких моментов, которые привносит в нашу жизнь электронная переписка.

Переведено компанией-локализатором Alconost

Слухи о выходе Civilization V и XCOM на Linux появились ещё в октябре прошлого года, но тогда они так и остались слухами, основанными лишь на неправильно выставленных товарах на Амазоне. Выход XCOM был подтверждён не так давно, поклонники же 4X-стратегий рассчитывали лишь на новую Civilization: Beyond Earth да на следующую часть основной серии.

Но вчера Civilization V вместе со всеми дополнениями действительно вышла для Linux (включая Steam OS, разумеется). Все желающие могут приобрести её в Steam со скидкой 75%.

Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.

Одним из самых главных изменений является поведение команды git push. Теперь по умолчанию (если не указана ветка) push будет осуществлен только в текущую ветку. Git 1.* по умолчанию делал push во все ветки, которые были изменены локально. Конечно же можно вернуться к прежнему поведению, для этого служит опция push.default.

Поведение Git 1.*:

git config --global push.default matching

Новое поведение по умолчанию в Git 2.0:

git config --global push.default simple

Другие изменения:

Этот пост понравится мизантропам: ведь он про то, что нет ничего бесполезнее, чем чужой успех. Вот если бы было место, где люди честно бы делились своими планами, а потом можно было бы следить поэтапно за их реализацией и фиксировать не только удачи, но и провалы в итоге… Ой, я же пишу в блоге такого проекта. Заходим на «СмартПрогресс», выбираем меню Цели, сортировку «проваленные», добавляем параметр «лучшие за все время» — и смотрим список самых громких фейлов на проекте.



Поскольку каждая история сопровождается подробным описанием, можно разобрать причины чужих неудач достаточно подробно — настолько, насколько пользователи позволяют себе быть откровенными. Ведь мы не хотим совершить ошибку, которую совершают все, кто изучают чужие истории успеха, забывая истории неудач – ошибку выжившего.

Реми Кулом (слева) с компьютерной программой Crazy Stone против гроссмейстера Норимото Ёды

В 1994 году компьютер обыграл чемпиона мира по шашкам, в 1997 году — по шахматам. Сегодня компьютеры превосходят людей абсолютно во всех популярных играх с полной информацией, кроме одной — го.

У классической игры с 2500-летней историей очень простые правила, но компьютерные программы даже близко не могут подобраться к победе над лучшими гроссмейстерами, пишет Wired.

Прошлый раз я писал про чужие баги. Честно будет написать теперь про наши. Они бывают трёх основных типов:

1. Когда косякнули мы, и это реально мы.
2. Когда виноват внешний курьер, почта или кто-то ещё — но клиент всё равно считает это косяком магазина (и, в целом, прав в этом).
3. Когда есть брак в товаре, и виноват производитель – но клиент брал у нас, поэтому ответственность за косяк должна быть тоже на нас.

Когда-то мы думали, что достаточно уменьшить до минимума количество косяков первого типа, и всё будет отлично. Но нет, этого оказалось мало. Дело в том, что покупатель не особо разделяет в своём мировоззрении товар, продавца и доставку. И если в 6:15 утра в Иркутске в его дом стучит страшное небритое лицо с посылкой – это тоже лицо компании.

Теперь давайте расскажу с примерами, в том числе по обратной связи с Хабра.

Предприниматели с большим энтузиазмом берут на вооружение инструменты верификации будущей прибыли. Идея A/B-тестирования упала в благодатную почву. Больше нет необходимости ломать голову над цветом кнопки, можно сразу же тестировать и выбирать лучшее.

Напомню как это делается: вы создаете две страницы, разница которых будет заключаться только в цвете кнопки “оформления заказа”. Затем вы, случайным образом, половине посетителей сайта показываете страницу №1, а другой половине — страницу №2. В результате, на одной из страниц, пользователи нажмут кнопку оформления заказа больше, чем тоже самое количество других пользователей на другой странице.

Следует ли из этого, что цвет кнопки влияет на количество оформленных заказов? Давайте проведём мысленный эксперимент. У нас будет две команды, по пять человек в каждой. Одна команда будет в красных футболках, другая — в синих. Каждый член команды будет подбрасывать монетку и записывать что выпало: орёл или решка. Пусть каждый подбросит монетку, скажем, три раза. После, посчитаем количество полученных “орлов” для каждой из команд.

Мы увидим, что одна из команд набрала больше “орлов” чем другая. Можно ли сделать вывод, что цвет футболки определил победителя? Следует ли нам одевать красную (синию) футболку, когда мы собираемся зарабатывать больше “орлов”?

Вступив некоторое время назад на скользкую тропу под названием «Я хочу написать свою игру», я пришёл к выводу, что процесс этот, несмотря на давнюю историю и большое количество успешных примеров, для начинающих разработчиков является весьма таинственным и слегка отдаёт шаманством. Я ни в коем случае не утверждаю, что в сети нет информации на эту тему, но вся она делится на две большие категории:

1. Глобальные общефилософские рассуждения из разряда «10 причин, почему тебе не надо становиться инди-разработчиком игр»;
2. Узко специализированные туториалы, решающие конкретную задачу: «Поворачиваем изображение в %framework_name% на произвольный угол при помощи %tool_name%»

Связующее звено между этими двумя категориями весьма размыто, а, между тем, это бесконечно важные этапы выбора идеи, формализации, перевод её в план. Именно на этой составляющей я хочу остановиться сегодня.
Следует помнить, что формальное описание проекта необходимо для переговоров с инвесторами любого типа: будь то знакомый, у которого ты попросишь взаймы, или Kickstarter, — от тебя в любом случае потребуют внятную презентацию.
Итак, если уже принято решение о том, что разработка игр — это твоё, есть примерное понимание, как должен выглядеть будущий шедевр, но ты не можешь связно рассказать это всё даже своему другу, не говоря уже о потенциальной команде, то добро пожаловать под кат, там много текста. Надеюсь, эта статья будет полезна, как юным разработчикам, так и маститым разрабам, которые создают отличный код, но не дружат с маркетингом.

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

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

Это не success-story, а какой-то «way of the failures» человека, который хочет создать что-то свое, что-то классное и полезное для многих, быть честным, свободным и работать на самого себя. Если это про вас, то прошу вас, прочитайте этот пост и не наступайте на мои грабли. Уделите 10 минут. Я постараюсь говорить коротко и по существу.

Наткнулись недавно на винрарную подборку шуток про баги, авторства небезызвестного Юрия Нестеренко (который YuN). Подумали — а почему бы не нарисовать комиксы по ним? Пока осилили где-то половину, но выкладываем, что есть.