• Добро пожаловать на борт: вводим новых разработчиков в команду
    +9

    Подозреваю, что лайкают мемасики, хотя в душе надеюсь, что все-таки статью (:

  • Ошибки новичка Unity, испытанные на собственной шкуре
    0
    Мне кажется, Bookvarenko говорит про гигайбайт веса САМОГО Юнити. Среды разработки. Что, кажется, правда — у меня сейчас со всеми модулями папка с редактором (без Mono) весит 6 с небольшим гигабайт.

    С другой стороны, я совершенно не понимаю, как это может иметь какое-то серьёзное значение.

    А мои собранные на Юнити игры весят по 25-30 мегов на мобилки и 400 под десктоп (со всеми ресурсами).

    Так что я не совсем могу понять эту претензию (:
  • Ошибки новичка Unity, испытанные на собственной шкуре
    0
    Это такое весьма абстрактное «проще». Имплементировать это может быть чуть-чуть сложнее, а экономия памяти будет сколько, сотня-другая килобайт? При том, сколько памяти занимают игры на Unity сами собой это абсолютно не принципиальная разница.

    Но да, так, конечно, делать правильнее.
  • Ошибки новичка Unity, испытанные на собственной шкуре
    0
    Благодарю, я иногда дно (:
  • Ошибки новичка Unity, испытанные на собственной шкуре
    +1
    Пару раз видел когда это приводило к всплескам ярости «Хабр не для рекламы!» и занижению как статьи так и кармы. Я не очень в восторге от такой перспективы, так что если счастливее меня прямые упоминания не сделают — постараюсь их избежать (:
  • Ошибки новичка Unity, испытанные на собственной шкуре
    +2
    Очень хочется определиться с начальным уровнем аудитории. Это кто-то, понимающий хоть что-то в программировании и ему не надо будет объяснять что такое класс или условный оператор, или это человек, впервые севший за компьютер? Пока не могу однозначно решить.
  • Ошибки новичка Unity, испытанные на собственной шкуре
    0
    SRP я упоминаю чуть ниже (:
  • Ошибки новичка Unity, испытанные на собственной шкуре
    +1
    Дааа, самому бы сначала не полениться и разобраться со ScriptableObject до конца т.т
    А то, в принципе-то, необходимости в них нет, они просто делают удобнее, поэтому как до некритичной темы я постоянно ленюсь до них добраться. Так что это ошибка новичка, которую я делаю всё время (:
  • Ошибки новичка Unity, испытанные на собственной шкуре
    0
    Благодарю, исправлюсь (:
  • Ошибки новичка Unity, испытанные на собственной шкуре
    0
    Наверное, мы уже достаточно глубоко в ветке комментов и сюда никто не залезет? Наш дебютный проект — store.steampowered.com/app/375560/DungeonRift
  • Ошибки новичка Unity, испытанные на собственной шкуре
    +1

    Виталий, это низко.

  • Ошибки новичка Unity, испытанные на собственной шкуре
    0
    Хабр не любит пиара — и конкретизация нашей игры пост богаче не сделает (:
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    +1
    Я уже поплакал из-за того как плохо построил этот комментарий. Надо было его сначала раз 10 перечитать, скорее всего решил бы ничего не писать :-D

    У QA (как, впрочем, и у рядового разработчика) есть однозначный технический потолок, пробить который достаточно сложно. Можно уйти в тим-лиды, можно углубиться в смежные области (например, аналитику и безопасность), а без этого профессиональный рост (и рост заработной платы) начинают сильно замедлятся. Именно про такие шаги я и писал (:
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    0
    Мы в Badoo примерно так и разрабатываем. Разработчик берёт задачу из пула, если задача с ходу не ясна — к нему присоединяется QA-инженер (если всё понятно сразу — QA подключается уже после первого resolve) и дальше они работают над задачей сообща, включая все возможные циклы reopen'ов.

    Непосредственно над каждой задачей архитектора нет, но есть код-ревью, во время которого сообща решаются любые архитектурные вопросы.
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    +1
    image
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    0
    Ну конечно не такой, как ты, Виталий.
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    0
    Никогда ещё не работал в физически распределённой команде, у нас разработка и тестирование работают совместно всегда. Очень интересно узнать, как что работает при вашей схеме :)
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    0
    Тестировщик, слепо следующий написанным кем-то другим кейсам — это самое начало карьеры тестировщика. Как программист, который переводит написанный кем-то другим алгоритм в код. Такие практики имеют право на существование, но кажутся мне менее эффективными (хоть и потенциально более надёжными), чем программисты, сами разрабатывающие свою систему и тестировщики, сами прорабатывающий план тестирования компонента.
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    0
    К сожалению, программисты-новички так тестировщиков и видят. Спасательный круг, который их выручит от пендюлей руководства.

    И уже от руководства зависит, будет ли меняться такое отношение. Если во всех багах винят только тестировщиков — программисты будут становиться всё расслабленнее и проект рано или поздно увязнет. Если ответственность распределяется поровну (или в некоторых случаях даже преимущественно на разработчика), то и сами разработчики начинают меньше уповать на тестирование вместо самих себя.
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    +2
    Давайте не будем вдаваться в споры о том, какая специальность важнее) Любой толковый специалист на своём месте — человек очень важный и ценный.
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    0
    Я вот совсем пропустил этот этап обучения, всё познавал уже на собственных шишках)

    Но по отзывам могу порекомендовать три книжки:
    Скучную, но дельную «Testing computer software» от Cem Kaner и Jack L. Falk
    Более читаемую, но менее интересную для опытного специалиста «Software Testing» от Ron Patton
    Отличное пособие по тест-дизайну «A Practitioner’s Guide to Software Test Design» от Lee Copeland

    Ну и что-нибудь вроде «Как тестируют в Google» чтобы узнать о реальных практиках. Ну или почитать другие наши статьи о тестировании (:
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    +3
    Проснулся вроде целый. Пишу слишком пафосно? У меня такое бывает, а снобом меня называли уже в младшей школе. Так что извините, если что (:
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    +2
    Рад стараться (:
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    +1
    Технически да — в данный момент я уже упёрся в потолок развития для чисто технического специалиста. Поэтому сейчас стал больше заниматься отвлечёнными делами — продуктовыми проектами, геймдевом, деврелом.

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

    В большинстве же случаев сейчас «программист» — не машина для выдачи кода, он занимается такими «кросс-доменными» делами как проектирование, алгоритмизация, оптимизация, поиск новых способов решения задач… То же самое и с тестировщиками. Кликать кнопки — самый базовый уровень, начало карьеры. Хороший тестировщик должен уметь намного больше. Немного автоматизации, немного UX, немного аналитики и оптимизации архитектуры…
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    0
    Думаю, в скором времени появится и такая статья, тут в двух словах не объяснить
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    +1
    Мы однажды писали статью о том, как мы фантастически увеличили скорость сборки кавериджа: https://habrahabr.ru/company/badoo/blog/192538/

    С тех пор всё стало ещё лучше, но все равно полная сборка кавериджа занимает чуть более часа и порядочно нагружает машину. Делать это на каждый тикет (ещё раз повторю — до 40 тикетов релизится в день) несколько затруднительно :)
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    0
    В полностью автоматическом режиме — да, об уменьшении покрытия какого-то конкретного места мы не узнаем. Но мы дважды в день собираем полный каверидж по всему проекту — и по уменьшившемуся покрытию компонента можно будет узнать, что что-то не так. А на плохо покрытые тестами места у нас регулярно заводятся тикеты.
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    +1
    Сами удивились. Изначально сценарии «на коленке» написал для себя один из наших разработчиков, а потом выложил это дело в общий доступ (вообще многие наши qa-инструменты имеют подобный жизненный цикл).

    А сам он выбрал lua потому что он прост как две копейки, наши сценарии на нём выглядят почти человекопонятными фразами, да ещё и в php он встраивается простым расширением.

    Так что ответ на ваш вопрос — «Так получилось»
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    0
    Как бы хорош не был Selenium Manager, он позволяет в автоматическом режиме обнаружить только часть проблем. Если же проблема возникает только в комбинации задач — да, сидим и проверяем различные комбинации руками, либо всё же по текстам ошибок и симптомам пытаемся сразу обнаружить виновников — всё таки редко из 20 задач более двух затрагивают один и тот же компонент. Не представляю, как это можно было бы эффективно и дёшево автоматизировать.

    По поводу отката вам лучше ответит кто-нибудь из наших релиз-инженеров, постараюсь прикастовать кого-нибудь из них в эту ветку (:
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    0
    Да, багфиксы и мелкие исправления логики обычно даже не проходят полноценный этап PRD, а начинают жизнь уже в задаче в JIRA — в таком быстроразвивающемся проекте как наш иначе жить было бы невозможно
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    +1
    Надеюсь, я правильно понял ваш вопрос, если нет — уточните, пожалуйста.

    Ревью задачи/проекта у нас выглядит так:

    1. Когда PRD готово оно проходит ревью команды продукта: разработчик PRD проводит презентацию и все участники продукт-команды обсуждают все кейсы, вопросы за и против и так далее.
    2. После проведения данного ревью, идет почтовая рассылка, в которой каждый заинтересованный может оставить свой фидбэк.
    3. Также есть техническая API-команда, которая тесно содействует с продуктом при написании протокола (то есть также проводит процесс ревью).
    4. Kick off внутри команды разработки. Совещание, которое проводится до начала разработки проекта, где как раз обсуждаются все кейсы, продукты рассказывают про проект, а тех отдел делает свое ревью по данному проекту. До проведения kick-off'a все участники проекта знакомятся с PRD.
    5. По выполнении задачи она отправляется на код-ревью, где коллеги-разработчики могут проверить детали реализации и подходы к решению той или иной проблемы.
    6. После прохождения код-ревью разработчик составляет сообщение для отдела QA, в котором рассказывает, как с технической точки зрения был реализован проект, чтобы мы при изучении задачи могли понять ход его мысли.

    И на каждом из этих этапов в PRD могут вноситься различные поправки и дополнения, чтобы проект ушё на продакшн максимально проработанным и развитым.
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    +1
    Дождёмся автора Selenium Manager'а с больничного и отпишем развёрнутый ответ, может быть даже полноценную статью :)

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



    Насчёт автоматизаторов: разработчики пишут только интеграционные и юнит-тесты. В нашем отделе QA есть три специалиста, занимающиеся поддержкой Selenium и smoke-тестов фулл-тайм, они же занимаются поддержкой инфраструктуры, Selenium-grid фермы и всего такого. Все остальные QA-инженеры занимаются разработкой тестов наравне с непосредственным тестированием задач.
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    +5
    Вам спасибо! Когда я выступаю с докладом или пишу статью и это кажется полезным хотя бы одному человеку (а тем более если это побуждает его к каким-либо созидательным действиям), то я знаю, что работа была сделана не напрасно. Думаю, мои коллеги придерживаются того же мнения.
  • Как мы уже 4 года выживаем в условиях двух релизов в день
    +1
    Рады стараться! (:
  • Worldwide-биллинг Badoo глазами QA
    0
    Доброго времени суток!
    Нет, насколько мне известно, партнёрская программа работает исправно.
    В будние дни обращусь к ответственным лицам, попробую разъяснить ситуацию. Результаты ждите в личке (:
  • Worldwide-биллинг Badoo глазами QA
    0
    Хочу всё же отдельно написать, что это совершенно не значит что «отдел мониторинга биллингу не нужен»!
    Они непрестанно мониторят более низкоуровневые вещи, которые я могу пропустить (или даже могу не иметь доступа к ним): нагрузку на сервера, количество API-запросов к биллингу или от него и многое другое. К тому же их триггеры помогают нам обнаруживать растянутые по времени аномалии, например, быстрее увеличивающийся объём баз данных или необычные тренды на тех или иных графиках.
    Так что мы ни коим образом их не заменяем в нашей работе, просто стараемся изо всех сил сделать её эффективнее (:
  • Worldwide-биллинг Badoo глазами QA
    +1
    Некоторые агрегаторы предоставляют тестовые API или SDK, позволяющие нам полностью проводить весь флоу покупки на девел-окружении, включая полную процедуру общения с платёжной системой — заодно и наши автотесты могут таким способом платить без ограничений.
    При этом абсолютно все платёжные методы мы полностью проверяем и на продакшне с «живыми» API. Некоторые методы оплаты поддерживают рефанды и мы платим со своих собственных карточек или пэйпалов (благо при быстром рефанде деньги возвращаются сразу же и без штрафов), для SMS-методов оплаты в разных странах мы используем сервис онлайн-аренды сим-карт SimTest. Иногда приходится связываться с партнёрами, чтобы они помогли нам провести тесты без затраты реальных денег. Автотесты, конечно же, таким не занимаются. Во избежание.

    По поводу мониторинга, здесь есть несколько вещей:
    • Поиск причины проблемы у мониторщиков займёт сильно больше времени, чем у тестировщика, который прекрасно знает, что изменяется в новом билде;
    • В принципе время реагирования мониторинга может быть ниже (они же тоже не могут бить в бубен при каждом странном поведении графика), а для нас это могут быть потерянные деньги каждую секунду. Потому следить за потенциально рискованными метриками очень важно — и начинать искать возможные причины проблемы даже при малейшем отклонении значения от нормы;
    • Довольно сложно сделать адекватные автоматические триггеры на каждую метрику (приведённые примеры «аномалий» хорошо это демонстрируют), а их у нас сотни;
    • Всего под наблюдением мониторинга находятся ТЫСЯЧИ метрик, так что лишних ложных срабатываний от хитрых биллинговых систем им точно не нужно;
  • Как я сходил на первый в России «Testathon», хакатон для тестировщиков
    0
    К сожалению, не все шли на мероприятие с этой целью — и далеко не все были открыты к общению. Особенно те, кто пришли командой в 5 человек и совершенно растерялись после перемешивания команд)
  • Как я сходил на первый в России «Testathon», хакатон для тестировщиков
    0
    Если мы будем относиться ко всему так, как к объекту нашего профессионального тестирования, то лопнем от перенапряжения — слишком много дефектов на нашей планете)