Прежде чем написать что у нас рост — я посмотрел в графики, чтобы удостовериться :)
Вы конечно правы, может так случиться что через какое-то время эксперименты на WinPhone перестанут себя оправдывать. Тогда мы будем использовать что-то другое, возможно и Android для экспериментов.

Привет, NetBUG!
Ваш цинизм понятен и он вполне справедлив. Как и любой другой сервис, мы естественно заинтересованы в повышении количества наших пользователей. Мы живем за счет них и делаем нашу работу для них.
Но справедливости ради, должен заметить, что пользователей своих мы любим и стараемся сделать все возможное, чтобы они получили то, зачем пришли. Каждый день мы работаем над придумыванием новых фич и улучшением тех фич, которые у нас уже есть. Мы удаляем то, что потеряло актуальность, «освежаем» интерфейс, пытаемся понравится новым пользователям и удержать старых.
Все это не работало бы, если бы реальные отношения не создавались. Люди приходят за знакомствами, они их получают.

Привет, immaculate!

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

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

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

Цели «не иметь windows разработчиков в штате» у нас нет. Платформа приносит немало дохода, даже просто в денежном эквиваленте, а уж то, что мы тестируемся на платформе и экспериментируем, только добавляет положительных моментов от поддержки этой платформы.
Ну и сказать что доля WinPhone падает я не могу — у нас она растет.

Привет, Nagg!
Спасибо за фидбек.
Дизайн для платформ у нас сильно зависит от продактов. Нельзя сказать что он не соответствует гайдам для андроида , но у нас куча своих «фишечек», которые просто так не реализуешь, используя сторонние библиотеки из вашего списка.
К тому же, как Слава написал, в WinPhone команде минимальное количество человек, что сокращает оверхед на коммуникации до минимума.
Наверняка есть компании, в которых эксперименты, подобные нашим, можно делать и на Android и на iOS, но у нас вот именно такая конфигурация работает очень хорошо.
При этом фичи, которые мы опробовали на WinPhone, часто делаются в таком порядке: после WinPhone делаем на Android, затем на iOS. Фичи при этом эволюционируют — улучшаются и дорабатываются. И в iOS, к примеру, попадают максимально «отполированными», что не всегда требуется на Android.

По поводу симфони: мы бы вероятно смотрели в эту сторону, если бы использовали этот фреймворк в работе. Равно как и любой другой фреймворк. Но поскольку для написания кода сайта наши программисты ничего кроме самописного фреймворка не используют, то мы не стали рассматривать «фреймворки для разработки с возможностью написания тестов» и выбрали фреймворк для тестов — phpUnit. На нем мы пишем сейчас все виды тестов, кроме тестов для клиентов мобильных приложений из-за понятных ограничений. Для моков (в том числе БД) используем самописные классы, стандартные phpUnit'овские моки почти не используем. Причина в том, что код наш изначально не писался так, чтобы быть тестируемым, благодаря чему не везде есть возможность использовать классические подходы к мокам/стабам. Я планирую написать статью про это.

«Там в докладе звучали цифры по покрытию, если учитывать и Selenium тесты, то какое покрытие получается? Или тяжело это подсчитать?» — это действительно тяжело посчитать, т.к. при таком подсчете получится сравнивание несравнимых категорий. Выше я описал почему. Если же использовать оценку «по фичам», то процентов 70 «фич» на сайте у нас покрыто селениум-тестами и мы ежедневно стремимся к увеличению.

В идеальном мире, в котором пишут книжки про юнит-тестирование, говорят о том, что тестировать надо в том числе и метод извлечения данных из базы из приведенного вами примера. Любой юнит должен быть покрыт тестом. Мы же живем в реальном мире, где нет идеала к сожалению. Где код изначально редко проектируется с оглядкой на тестирование (стартап же, ё-маё, взлетит — напишем тесты!!11), где редко можно наблюдать тот же пресловутый MVC (например), а скорее некий эрзац и проч., и проч.
Поэтому даже если очень сильно захотеть, редко получается следовать рекомендациям умов великих, и приходится изобретать очередной велосипед с квадратными колесами. И часто приходится идти на компромиссы в том или ином случае, что оправдано. Ведь вы для чего пишете тесты? Чтобы было красиво? Потому что где-то прочитали что так правильно? Я уверен что нет. Вы их пишете чтобы тестировать свой код. И до тех пор, пока ваши тесты справляются с поставленной задачей, вы имеете полное право считать имеющиеся тесты хорошими.

Спасибо за вопросы про тестирование!
2. Покрытие кода селениум-тестами нами оценивается, но это немного не то, что принято понимать под остальным покрытием. Именно поэтому Алексей ответил «Нет». Попробую объяснить позицию подробнее.
Если брать юнит-тесты для примера, то там покрытие совершенно четко можно считать по строкам, выполненным во время прогона теста. Немного про то, как мы это считаем, я уже писал. Для селениум-тестов, как впрочем и для любых тестов более высокого уровня, это будет неправдой. Потому что даже после простого открытия страницы в браузе уже выполнится немало строк кода, которые посчитаются покрытыми тестом, хотя это не так. Поэтому для селениум-тестов мы делаем оценку покрытия «по фичам». Т.е. по участкам функционала сайта. Понятно что такое покрытие сложно считать автоматически, поэтому мы этого и не делаем, хотя объединение покрытия юнит-тестов и интеграционных тестов кажется логичным на первый взгляд.
3. Да, на основе сценариев. Это тесно связано с предыдущим пунктом: берется раздел сайта или «фича» и покрывается тестом. Практикуем как позитивные сценарии (в большем приоритете), так и негативные (в меньшем приоритете). Например пытаемся зарегистрироваться на сайте, в том числе мурными и невалидными данными с проверкой на спецсимволы, обход авторизации, получение писем подтверждения, переход и инвалидация ссылок из письма и проч. Таким образом у нас покрывается «фича» Регистрация Пользователя.

В релиз может попадать от одной до нескольких десятков задач. В среднем ежедневно уходит 20-30 задач в одну выкладку. В обе выкладки, около 50 задач, соответственно.

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

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

Пока не пробовали, но идеи такие давно витают. Де-факто тесты (не для кавериджа, а для задач, билдов и т.д.) мы итак гоняем в облаке. Набор из десятка виртуалок, из которых берется самая свободная и запускаются на ней тесты.
В общем-то такой же принцип можно применить и к девелоперским машинам, но тут возникают проблемы с окружением. Если виртуалки еще более-менее можно продублировать с точки зрения продакшеновских машин — ресурсы, версии софта и библиотек, то с клиентскими машинами такое будет очень сложно провернуть.

Быстрее — только многопоточный запуск может помочь. К сожалению с xdebug'ом, собирающим покрытие, тесты идут медленнее, это факт.
Тесты для сбора покрытия мы гоняем на виртуалке с 32 гигабайтами оперативной памяти и 24ю ядрами Intel Xeon 2.93GHz. При этом из упомянутых 2,5 часов процентов 70 времени уходит именно на прогон всех тестов.
Вероятно, скоро мы придем к вопросу оптимизации еще раз, так как количество тестов с каждым днем увеличивается. Если придумаем что-нибудь, обязательно напишем об этом и отдадим в opensource.

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

На «тяжелые» провайдеры зенда и симфони тоже бы с удовольствием посмотрел. При беглом осмотре кода симфони я увидел только статичные данные в провайдерах. Может переписали уже?

Я понимаю о чем вы говорите. Действительно, с этой точки зрения архитектура выглядит не очень оптимальной.
Мы, чтобы не натыкаться на подобные подводные камни, используем простое правило в нашем проекте — «data provider'ы должны возвращать только статичные данные». Никаких объектов, никакой хитрой логики. Если нужны различные объекты в тестах, то в датапровайдерах надо возвращать правила или параметры для создания таких объектов. А сами объекты надо создавать уже в тестах или setUp'е и очищать в tearDown'е.
Это, конечно, не исключает сбор провайдеров при запуске тестов с фильтром, но существенно облегчает этот процесс.
Более того, то, что провайдеры инициализируются задолго до выполнения тестов ведет к еще одной проблеме — нарушению изоляции. Объект, созданный перед всем набором тестов может быть изменен каким-нибудь тестом до нужного и в нужный тест объект может прийти измененным.
Это еще одна причина, почему мы запрещаем инициализацию объектов в провайдерах.
То же самое справедливо и для некоторых других методов фреймворка, вы совершенно правы.
Для автоматического контроля ситуации мы даже добавили в нашу запускалку тестов специальный тест, который проверяет состояние объектов между тестами — «SanityCheck». Правило + автоматическая проверка спасают :-).

Не пробовали. Спасибо за ссылку, очень интересно.

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

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

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

Спасибо за вопросы!

Нет, над issue10 мы не работали. Проблем с выборочным запуском тестов так же не имели. --filter вполне себе справляется с нашими задачами.

По поводу понятности кода phpunit — тоже особых проблем не испытывали. Код замечательно читается и дорабатывается + хорошая документация. С чем именно у вас были проблемы? Уверен что сообщество поможет ответить на ваши вопросы.

От части таким тест-планом выступает набор автотестов. Отдельно от этого ничего не ведем. Ну если не считать описание фич в confluence, которое ведется продактами и корректируется по ходу реализации.

Шот это просто папка с гитом, где счекаучена ветка задачи + настройки nginx, чтобы можно было зайдя по определенным точкам входа увидеть веб-морду, апи для клиентов и т.д. Эта папка выгружается на одну из машин в боевом окружении, где и тестируется.
По другим ресурсам — базам, мемкешам, демонам — они не изолированы, вы правы. И риски о которых вы говорите тоже имеются, никуда от этого не деться. Но мы минимизируем эти риски, когда тестируем задачу до шотов — в девел окружении. Где все вышеперечисленные ресурсы отделены от продакшена.
Интеграционные селениум-тесты гоняются в двух окружениях — девелоперском и стейджинговом. Для них используется отдельный пулл объектов, не затрагивающий основных пользователей ресурса.
Для девел-окружения, где (и только где) гоняются еще и юнит-тесты и функциональные тесты, отдельных снапшотов с данными не используем. Данные после сетов тестов либо роллбечим в транзакциях (где это возможно), либо используем моки таблиц. У нас есть свои классы/механизмы для этого, мы подменяем на лету таблицы и запросы к ним в коде. Таблицы делаются темповыми (за небольшими исключениями) и сами удаляются после тестов движком БД. Для тех мест, где нельзя использовать темповые таблицы, есть оффлайновый скрипт, который пробегается и чистит такие таблицы.
Безусловно, бывают ситуации, когда тесты все же оставляют данные в девелоперских базах, но это не критично, ибо 1) используем подход «каждый тест должен сам для себя готовить данные, независимо от того, что в БД или других общих ресурсах было до него» и 2) ничто не мешает в любой момент перезалить девелоперскую БД.

6. Ручное тестирование есть и флоу у него ничем не отличается от описанного выше. Задачи (новые фичи, багфиксы и т.п.) приходят в QA сразу после выполнения. На этот момент задача уже прошла code-review и прогнаны автоматом юнит-тесты (в тикете в джире есть репорт об этом). Тестировщики тестят это в девелоперском окружении, если все хорошо — следующий этап это тестирование задачи в шоте. Шот — это пре-продакшен для отдельной ветки кода. Если, опять же, все хорошо, то следующий этап — тестирование билда из смерженных фич на стейджинге. Ну и все что протестировано на стейджинге, уезжает в продакшен. Все эти этапы тестирования включают как ручное, так и автоматизированное тестирование. Интеграционные тесты QA-инженеры пишут на phpUnit, с использованием Selenium WD. Ручное тестирование включает в себя как регрессионные проверки фич, для которых по тем или иным причинам еще нет селениум-тестов, так и exploratory-тестирование фич. Ну и проверка фронтенда (верстка, js и т.д.) в разных браузерах, в зависимости от популярности по статистике посещения.

Про флоу мы уже писали в статьях тут и тут. Но отдельной статьи, посвященной именно флоу, у нас еще не было. Обязательно напишем. Так же, как Влад уже написал, готовится отдельная статья про автоматизированные откаты задач из ветки релиза.