Ну почему же расходятся? Я тоже считаю что обстановка очень важна. Но как ее формализовать? Хорошо если вы прийдя в компанию и поработав там, поймете хорошо там с этой самой обстановкой или нет. А если плохо? Уходить в другую компанию?
В статье я намеренно упоминаю инженерную культуру, в это широкое понятие входит и обстановка тоже. Когда работаешь в окружении крутых ребят, чувствуешь себя мотивированным делать крутые вещи.
И частью своей работы и работы других менеджеров считаю как раз воспитание инженерной культуры и взращивание той самой обстановки, в которой людям драйвово работать. Процессы — один из механизмов, позволяющих эту самую культуру развивать.
Если вы обратили внимание, я даже сделал оговорку о том, что я намеренно утрирую и «сгущаю краски» при приведении примеров. Reductio ad absurdum — это специальный полемический прием, позволяющий наиболее красочно показать те или иные аспекты обсуждаемой проблемы.
Разумеется у разных людей цели разные. И я очень рад, что есть ребята, которых просто драйвит делать крутые вещи. Это прикольно и здорово мотивирует. Моя же цель в том, чтобы сделать процесс, работающий в большинстве случаев. Даже тогда, когда у людей внутренней мотивации не вполне достаточно.
Привет, Александр!
Пойдем по пунктам.
1) Как быть, если «Фича нужна бизнесу в продакшне раньше чем due date?». Due date это в первую очередь бизнесовый показатель. Если фича нужна раньше, чем Due date, это значит что Due date = раньше :). Понятно что бывает так, что бизнес требует почти невозможного. Но если задуматься, то все что мы делаем, нужно в первую очередь именно бизнесу. И если получилось так, что мы должны к определенному сроку дать какой-то продукт, то надо выложиться по полной, но сделать. Мы нередко делаем MVP-продукт. Это когда мы компромиссным путем в кратчайшие сроки даем на выход результат, который позволяет прощупать концепт. И если он «летит», то полируем фичу дальше.
2) Во-первых, надо регулярно с менеджером проверять результат на промежуточных этапах, а во-вторых, если мы делаем прагматично и полезно бизнесу, то это не всегда означает что мы делаем плохо, верно? Может быть оно с архитектурной точки зрения не всегда оптимально, но нашим пользователям зачастую наплевать как оно сделано изнутри. Если фича сделана так, что ее можно «продать» пользователю, значит она сделана «на отлично». При этом мы сразу делаем оговорку, что возможно в будущем надо будет делать рефакторинг, или даже полную переделку — это все технический долг.
3) По поводу коллективной ответственности, и «устаревшего правила» — я даже рад что бывают альтернативные мнения. С другой стороны, есть зарекомендовавший себя подход и правила, а есть мода. И если автомат Калашникова работает, несмотря на то что он «устарел», может это значит что он не так уж и плохо сделан?
1) Я подробно описывал процесс на примере одной из команд вот в этой статье. Если кратко, то после того как задача от продактов пришла в разработку, задачу берет разработчик-микропроджектменеджер. Он дальше несет ответственность за сроки задачи и все что касается ее реализации на всех стадиях проекта. Он готовит план разработки, внедрения, продумывает зависимости.
За декомпозицию задачи отвечает тоже он. Как именно он декомпозирует — сам, либо с техническим лидом, либо с помощью других членов команды с архитекторской экспертизой разных компонентов — его дело. Он заинтересован в том, чтобы декомпозиция прошла правильно, так как она колоссально влияет на срок доставки, который он называет и за который отвечает.
Отдельной роли «декомпозитор» у нас нет.
2) Глубина декомпозиции сильно зависит от PRD — задания, которое приходит от продактов. Оно не детальное. Многие аспекты реализации уточняются/дополняются в процессе декомпозиции, а некоторые даже в процессе разработки. Я бы сказал так: мы не стараемся все детализировать и документировать, а пытаемся быть гибкими. Описание достаточно чтобы начать работу? Значит можно начинать. Декомпозиции частей достаточно чтобы начать работу над этими частями? Значит вперед.
3) Поскольку отдельной роли декомпозиторов нет, думаю вопрос не актуален?
4) Тайного смысла нет. Просто так получилось что в Баду QA занимает немаловажную роль, особенно в построении процессов и организации практик и методологий. По правде сказать, я считаю что так должно быть в любой компании и не должно зависеть от роли. Если у вас есть что предложить для улучшения работы — надо предлагать, объяснять, убеждать. Это залог роста для всех, в том числе и для всей компании в целом.
5) Тот же микропроджектменеджер-разработчик, который задачу везет. Либо сам, либо с помощью коллег. Но инициирует, контролирует и отвечает за процесс именно он.
Давать советы «по фотографии» сложно, как мне кажется. Очень многое зависит от самих конфликтов, языка разработки и подходов и правил командной разработки.
Единственное, что я хотел бы отметить (и часто рекомендую друзьям и знакомым) — забыть про tortoise hg/git/svn/whatever. Равно как и про любые другие UI-инструменты для работы с системами контроля версий. Консоль — вот ключ к пониманию того, как оно устроено изнутри, как работает и что делает в каждом конкретном случае.
Собрать приложение с головы любого коммита — не проблема. Ни для нас, ни для любого другого человека, хоть немного понимающего матчасть.
Суть в том, что когда вас больше 200 инженеров, формулировки «сделай, ты же умный и сам знаешь как» не работают. Тут нужны четкие правила. А если учесть что часть людей вообще может не знать git, модели ветвления и принципы работы в команде, являясь при этом крутыми специалистами в других областях, то совсем тяжело.
Когда я делал проект по переходу на git с svn в Баду, я написал пошаговую инструкцию. Прям с примерами консольных команд и четкими правилами «делай так, получишь то-то». Шаги в инструкции были неправильными, если смотреть с точки зрения опытного пользователя git (git — крайне гибкая и мощная система). Но они были такими, чтобы избежать ошибок по-максимуму.
В результате, люди, поработав по инструкции несколько раз, начинали «рубить фишку» и понимать всю гибкость инструмента.
По поводу багфиксов — да, флоу у нас подразумевает одинаковую работу с любыми типами задач. Новая фича, багфикс, эксперимент, рефакторинг — все идет по одному накатанному пути.
Другое дело что иногда баги (а бывает что и фичи) надо делать по-максимуму быстро. Минуя все дополнительные стадии, внося риски. Когда такие ситуации риск оправдывают, мы делаем прагматично — резрабатываем и релизим вне флоу, у нас есть инструменты и соглашения, которые позволяют так делать.
Я думаю, мы напишем статью или сделаем доклад про систему патчей в ближайшее время.
Спасибо за отзыв!
Приятно что то, что я пишу, оказывается полезным.
Мне вдвойне приятно что многие ребята из нашей компании, когда мы делали вычитку, говорили про то что тема «капитанская» и очевидная. Ребята, вы — крутые! С вами работать очень здорово!
В то же время, даже у нас регулярно приходится объяснять и рассказывать подобные элементарные вещи. В том числе и поэтому я и решил написать цикл статей об основах, стараясь максимально подробно описать «почему» и что стоит за решениями и подходами, которые у нас работают.
У нас есть вот такая статья и видео выступления там же о том, как мы тестируем iOS в параллель. Правда, есть недостаток — материал на английском языке.
К слову, у нас для автоматизации используется calabash и тесты мы пишем кросс-платформенные. Вот тут и тут можно прочитать еще немного про автотестирование в мобайле у нас в компании.
Как я уже писал выше, отвечая на вопрос про то, должны ли тестировщики уметь программировать — однозначного ответа у меня нет.
С точки зрения эффективности удобнее, когда человек, тестируя ветку задачи, так же покроет ее автотестом. Чтобы на последующих стадиях проверки все той же задачи, все ручные проверки не повторять еще раз. Ведь это лишнее время и мы стремимся к оптимизации параметра β. И каждый раз повторять одни и те же проверки в Exploratory testing, для одной и той же задачи — это утомительно. Человек устает, глаз замыливается, начинают влиять масса факторов чисто человеческой природы.
С другой стороны, автоматизация во время первого сеанса тестирования не всегда достижима и в моей практике в том числе встречаются ребята, которым вообще не интересно заниматься автоматизацией и они только демотивируются и начинают делать работу хуже. Обратные примеры так же имеются — есть ребята, которые замечательно тестируют руками, но считают автоматизацию единственно возможным путем дальнейшего развития.
Более того, в нашем жизненном цикле задач, даже выкладка на продакшен не всегда означает завершение работы над фичей. Ведь мы ее после этого обкатываем, дорабатываем, улучшаем, делаем А/Б тесты и даже поведение фичи может поменяться впоследствии. Часто это происходит так быстро, что автоматизировать тест для каждого чиха становится непомерно дорогим удовольствием. Поэтому мы автоматизацию некоторых фич откладываем до завершения периода ее стабилизации. Тестируем руками и ставим отдельный тикет на автоматизацию, приступаем к которому через некоторое время после завершения работы над фичей.
Я бы сказал так: мы даем возможность и дальше смотрим. Я описывал пример desktop web команды, где тестировщики делают и то и то. Так вот в ней тоже есть исключения, есть люди, которые не проявляют интереса к автоматизации.
Соответственно, мы стимулируем чтобы имеющиеся тесты 1) использовали 2) фиксили 3) улучшали все в команде. А написание новых тестов для новых фич и уж тем более, развитие фреймворков, окружения, подходов и практик автоматизации — дело добровольное.
Спасибо за отзыв. Отвечаю по пунктам:
1) Правила нет. Более того, мы пропагандируем полный шаринг знаний и взаимозаменяемость. Это позволяет избежать бас-фактора. В то же время, часто для оптимальной работы зачастую на повторных этапах назначается тот же самый человек, что был вначале. Так попросту быстрее. Мы оставляем этот вопрос за каждым лидом конкретной команды тестирования и прямо запрещаем разработчикам назначать задачу на того же тестировщика после доработки.
2) Это зависит от команды. В desktop web, где мы в этом плане продвинулись максимально далеко (ибо начали раньше остальных), тестировщики делают как ручное тестирование, так и пишут автотесты высокого уровня. В других командах мы идем к тому же, для сравнения — в iOS команде мы недавно обязали ручных тестировщиков проверять результаты автоматизации и разбираться с падениями тестов. Затем планируем стимулировать самостоятельное исправление падений, а потом доберемся и до написания новых.
3) Есть. Несмотря на то, что тесты так или иначе пишут (или скоро будут) все, у нас есть выделенные люди, которые занимаются фреймворком, окружением, вырабатывают правила и методологии для остальных. Количество таких людей и их соотношение к ручным тестировщикам разное в разных командах.
4) Нагрузочного тестирования у нас нет. Вместо этого мы занимаемся планированием нагрузки, базируясь на текущих показателях перформанса на серверах, полученных от мониторинга. Плюс — плавная раскладка. В то же время для некоторых критичных демонов мы несколько раз нагрузку проверяли. Особой пользы от этого процесса не получили.
5) Команды тестирования разделены так же как и команды разработки. Есть разработчики, которые пишут серверную часть, биллинг, мобильные клиенты для iOS и Android и т.д. Каждая такая команда имеет свой выделенный пул тестировщиков. Между командами иногда происходит ротация для обмена знаниями, либо помощи коллегам в случае авралов.
1) Нет, задачи висеть в промежуточных статусах не будут. Задачи должны быть декомпозированы так, чтобы иметь возможность пройти по всем стадиям независимо. В том числе, быть выложенными на продакшен.
2) Не предусмотрено и не может быть предусмотрено, потому что задачи разные. Разные размеры и функционал новых фич стимулируют индивидуальный подход. Общая канва исходит из самого принципа разделения задач на кусочки — кусочки должны быть логически законченными и уметь выкладываться независимо. И вот эти кусочки уже идут по конвейеру дальше, подчиняясь общим правилам, не зависящим от типа изменений.
3) Работа с багами и другими задачами (например тех-долг), не отличается от новых фич в той части, когда они идут по конвейеру. Заказчик в этом случае для них внутренний — либо сами девелоперы, либо тестировщики, либо технический руководитель. В остальном принцип такой же — либо разбили на кусочки, если задача большая, либо одна задача — самостоятельный кусочек, который идет все по тому же флоу. Разумеется, Visual QA в этом случае может не быть, но так же очевидно что если бага касается изменения функционала или предполагает неочевидное, неучтенное ранее поведение фичи, то может потребоваться разговор с продакт-менеджером, который владеет фичей.
Спасибо за вопросы.
1) Вы правы, обычно рефакторинг заказчика не интересует. Это нормально, он мыслит только бизнес-категориями, проблемы технического долга в его мире не существуют и не должны существовать. Как быть в каждом конкретном случае — это задача непосредственного технического лида разработки в команде.
В каких-то случаях стоит делать по-максимуму быстро, с костылями и велосипедами, в ущерб «красоте» кода и архитектуры, имея в виду что в будущем возникающий технический долг придется исправлять. В других случаях следует сначала избавиться от тех долга, лишь затем приступить непосредственно к написанию нового функционала. Еще ряд случаев может предполагать параллельную работу над рефакторингом и новыми фичами несколькими разработчиками сразу. Все индивидуально и сильно зависит от конкретных условий. Главный принцип тут — прагматизм. Как сделать максимально выгодно и пользователям и с точки зрения технологий.
Я бы сказал, что помимо людей и их проблем, эта задача — одна из основных для лида разработки.
Как именно разделять задачи правильно — это нетривиальная проблема, с которой справляется не каждый. Я сейчас готовлю отдельную статью про это.
2) Опять же, прежде всего — прагматизм. Гладко бывает только на бумаге и в сказках, в жизни регулярно возникающие неожиданности — это норма. Не подумали, не учли, не заметили, пропустили: так случается. Как быть в этом случае зависит от того, что именно явилось проблемой. Иногда чтобы их решить, приходится жертвовать личным временем; искать компромисс с заказчиком и выпускать задачу как есть, если она позволяет «прощупать» концепт итак; иногда бывает так что приходится начинать все сначала.
Главное помнить принцип — столкнулись с проблемой, значит надо решить как такую проблему (а идеально — и тип подобных проблем) избежать в будущем. Не искать виноватого, а конструктивно, надежно попытаться закрыть вопрос раз и навсегда. Тогда (не сразу) мы будем улучшать и улучшать инженерную культуру и будем воспитывать себя и своих коллег, обеспечивая развитие свое и своей компании.
Это зависит от стадии. Если для разработки и QA в нашей джире есть отдельные статусы и надо менять состояние задачи, то для Visual QA такого статуса нет.
Я бы сказал так: мы руководствуемся здравым смыслом и пытаемся избежать лишней бюрократии по-максимуму. Если мы видим, что какой-то шаг в процессе требует более пристального внимания/напоминания, то в этом случае мы можем применить более формальный подход. Так появился чек-лист для разработчика перед резолвом задачи, например. И сейчас это прям отдельный экран в трекере, куда надо руками проставить чекбоксы, чтобы кнопка «Готово» стала доступной.
Отвечаю на вопросы по пунктам:
1) Договоренности и формального срока нет. Очень многое зависит от функционала конкретных фич. В каких-то случаях он интуитивно понятен и без напоминалок, в каких-то случаях, чувствуя необходимость, люди начинают создавать чек-листы. Кроме того, учитывая огромное количество экспериментов, в некоторых ситуациях легче подождать «стабилизации» фичи. Для автоматизации — уж точно.
В этом и прелесть Exploratory testing — полный фристайл, минимум формализма.
2) Тут все очевидно — сначала нового человека необходимо познакомить с заведенными правилами команд, с системой, которую ему придется тестировать, с технологиями, инструментами и т.д. Для этого у нас во многих командах есть специальные странички в wiki, в которых описано как у нас происходит тот или иной процесс, из чего состоят те или иные компоненты системы. Информации очень много и мы не ожидаем того что человек сразу все это запомнит. Основная цель тут — показать где искать в случае чего. Обычно первый день нового сотрудника занят чтением этой информации и подготовкой рабочей среды.
Кроме того обычно либо сам менеджер, либо кто-то из команды, берет такого новичка «на поруки». Он выступает первой точкой контакта в случае возникновения вопросов, объясняет и показывает, ставит задачи. Это очень важный процесс, призванный установить доверительные отношения с новым сотрудником. На этом базируется все дальнейшее сотрудничество и карьерный путь новичка в компании.
Задачи для новичка сначала ставятся простые, для знакомства с системой, затем все сложнее и сложнее.
В то же время мы ожидаем максимальной самостоятельности от присоединившегося к нам человека. Долго нянчится и «водить за ручку» его никто не будет — своей работы полно. И в большинстве случаев готовность человека самостоятельно выполнять задачи является важным критерием прохождения испытательного срока.
Прежде всего, справедливости ради, я бы хотел отметить что крутые ребята у нас работают не только в A-team (платформа). Badoo — это команда очень хороших профессионалов в разных сферах, с высокой инженерной культурой.
А отвечая на ваш вопрос, я бы рекомендовал заглянуть вот в эту нашу статью. В ней Константин Карпов рассказывает как раз про процесс разработки и тестирования в платформе при производстве демонов.
Еще много различной информации про работу наших замечательных ребят из A-team можно найти вот в этой статье.
Я думаю, что вопрос однозначного ответа не имеет. Все зависит от.
С одной стороны я рассматриваю опыт и умение программировать как большой плюс. Лично мне, к примеру (а я в прошлом — программист), очень сильно помогает чтение изменений в коде перед тестированием. Таким образом мне легче определить уязвимые места и варианты проверок.
С другой стороны, у меня есть ребята, которые программировать не хотят/не умеют и при этом отлично справляются с поиском багов. Во многих случаях даже лучше меня (что скрывать, я не самый идеальный тестировщик).
По поводу курсов — мы даем возможность нашим сотрудникам посещать любые курсы в пределах определенного бюджета, с определенной периодичностью. Какие именно это курсы должен определить сам сотрудник, а его менеджер должен подтвердить необходимость. И да, некоторые сотрудники из QA посещали курсы по программированию в том числе.
В статье я намеренно упоминаю инженерную культуру, в это широкое понятие входит и обстановка тоже. Когда работаешь в окружении крутых ребят, чувствуешь себя мотивированным делать крутые вещи.
И частью своей работы и работы других менеджеров считаю как раз воспитание инженерной культуры и взращивание той самой обстановки, в которой людям драйвово работать. Процессы — один из механизмов, позволяющих эту самую культуру развивать.
Спасибо за ваш комментарий.
В нашей компании разработчики очень толковые. А в вашей?
Если вы обратили внимание, я даже сделал оговорку о том, что я намеренно утрирую и «сгущаю краски» при приведении примеров. Reductio ad absurdum — это специальный полемический прием, позволяющий наиболее красочно показать те или иные аспекты обсуждаемой проблемы.
Разумеется у разных людей цели разные. И я очень рад, что есть ребята, которых просто драйвит делать крутые вещи. Это прикольно и здорово мотивирует. Моя же цель в том, чтобы сделать процесс, работающий в большинстве случаев. Даже тогда, когда у людей внутренней мотивации не вполне достаточно.
Удачи!
Пойдем по пунктам.
1) Как быть, если «Фича нужна бизнесу в продакшне раньше чем due date?». Due date это в первую очередь бизнесовый показатель. Если фича нужна раньше, чем Due date, это значит что Due date = раньше :). Понятно что бывает так, что бизнес требует почти невозможного. Но если задуматься, то все что мы делаем, нужно в первую очередь именно бизнесу. И если получилось так, что мы должны к определенному сроку дать какой-то продукт, то надо выложиться по полной, но сделать. Мы нередко делаем MVP-продукт. Это когда мы компромиссным путем в кратчайшие сроки даем на выход результат, который позволяет прощупать концепт. И если он «летит», то полируем фичу дальше.
2) Во-первых, надо регулярно с менеджером проверять результат на промежуточных этапах, а во-вторых, если мы делаем прагматично и полезно бизнесу, то это не всегда означает что мы делаем плохо, верно? Может быть оно с архитектурной точки зрения не всегда оптимально, но нашим пользователям зачастую наплевать как оно сделано изнутри. Если фича сделана так, что ее можно «продать» пользователю, значит она сделана «на отлично». При этом мы сразу делаем оговорку, что возможно в будущем надо будет делать рефакторинг, или даже полную переделку — это все технический долг.
3) По поводу коллективной ответственности, и «устаревшего правила» — я даже рад что бывают альтернативные мнения. С другой стороны, есть зарекомендовавший себя подход и правила, а есть мода. И если автомат Калашникова работает, несмотря на то что он «устарел», может это значит что он не так уж и плохо сделан?
Спасибо за ваше мнение!
За декомпозицию задачи отвечает тоже он. Как именно он декомпозирует — сам, либо с техническим лидом, либо с помощью других членов команды с архитекторской экспертизой разных компонентов — его дело. Он заинтересован в том, чтобы декомпозиция прошла правильно, так как она колоссально влияет на срок доставки, который он называет и за который отвечает.
Отдельной роли «декомпозитор» у нас нет.
2) Глубина декомпозиции сильно зависит от PRD — задания, которое приходит от продактов. Оно не детальное. Многие аспекты реализации уточняются/дополняются в процессе декомпозиции, а некоторые даже в процессе разработки. Я бы сказал так: мы не стараемся все детализировать и документировать, а пытаемся быть гибкими. Описание достаточно чтобы начать работу? Значит можно начинать. Декомпозиции частей достаточно чтобы начать работу над этими частями? Значит вперед.
3) Поскольку отдельной роли декомпозиторов нет, думаю вопрос не актуален?
4) Тайного смысла нет. Просто так получилось что в Баду QA занимает немаловажную роль, особенно в построении процессов и организации практик и методологий. По правде сказать, я считаю что так должно быть в любой компании и не должно зависеть от роли. Если у вас есть что предложить для улучшения работы — надо предлагать, объяснять, убеждать. Это залог роста для всех, в том числе и для всей компании в целом.
5) Тот же микропроджектменеджер-разработчик, который задачу везет. Либо сам, либо с помощью коллег. Но инициирует, контролирует и отвечает за процесс именно он.
Единственное, что я хотел бы отметить (и часто рекомендую друзьям и знакомым) — забыть про tortoise hg/git/svn/whatever. Равно как и про любые другие UI-инструменты для работы с системами контроля версий. Консоль — вот ключ к пониманию того, как оно устроено изнутри, как работает и что делает в каждом конкретном случае.
Удачи!
Суть в том, что когда вас больше 200 инженеров, формулировки «сделай, ты же умный и сам знаешь как» не работают. Тут нужны четкие правила. А если учесть что часть людей вообще может не знать git, модели ветвления и принципы работы в команде, являясь при этом крутыми специалистами в других областях, то совсем тяжело.
Когда я делал проект по переходу на git с svn в Баду, я написал пошаговую инструкцию. Прям с примерами консольных команд и четкими правилами «делай так, получишь то-то». Шаги в инструкции были неправильными, если смотреть с точки зрения опытного пользователя git (git — крайне гибкая и мощная система). Но они были такими, чтобы избежать ошибок по-максимуму.
В результате, люди, поработав по инструкции несколько раз, начинали «рубить фишку» и понимать всю гибкость инструмента.
По поводу багфиксов — да, флоу у нас подразумевает одинаковую работу с любыми типами задач. Новая фича, багфикс, эксперимент, рефакторинг — все идет по одному накатанному пути.
Другое дело что иногда баги (а бывает что и фичи) надо делать по-максимуму быстро. Минуя все дополнительные стадии, внося риски. Когда такие ситуации риск оправдывают, мы делаем прагматично — резрабатываем и релизим вне флоу, у нас есть инструменты и соглашения, которые позволяют так делать.
Я думаю, мы напишем статью или сделаем доклад про систему патчей в ближайшее время.
Приятно что то, что я пишу, оказывается полезным.
Мне вдвойне приятно что многие ребята из нашей компании, когда мы делали вычитку, говорили про то что тема «капитанская» и очевидная. Ребята, вы — крутые! С вами работать очень здорово!
В то же время, даже у нас регулярно приходится объяснять и рассказывать подобные элементарные вещи. В том числе и поэтому я и решил написать цикл статей об основах, стараясь максимально подробно описать «почему» и что стоит за решениями и подходами, которые у нас работают.
К слову, у нас для автоматизации используется calabash и тесты мы пишем кросс-платформенные. Вот тут и тут можно прочитать еще немного про автотестирование в мобайле у нас в компании.
С точки зрения эффективности удобнее, когда человек, тестируя ветку задачи, так же покроет ее автотестом. Чтобы на последующих стадиях проверки все той же задачи, все ручные проверки не повторять еще раз. Ведь это лишнее время и мы стремимся к оптимизации параметра β. И каждый раз повторять одни и те же проверки в Exploratory testing, для одной и той же задачи — это утомительно. Человек устает, глаз замыливается, начинают влиять масса факторов чисто человеческой природы.
С другой стороны, автоматизация во время первого сеанса тестирования не всегда достижима и в моей практике в том числе встречаются ребята, которым вообще не интересно заниматься автоматизацией и они только демотивируются и начинают делать работу хуже. Обратные примеры так же имеются — есть ребята, которые замечательно тестируют руками, но считают автоматизацию единственно возможным путем дальнейшего развития.
Более того, в нашем жизненном цикле задач, даже выкладка на продакшен не всегда означает завершение работы над фичей. Ведь мы ее после этого обкатываем, дорабатываем, улучшаем, делаем А/Б тесты и даже поведение фичи может поменяться впоследствии. Часто это происходит так быстро, что автоматизировать тест для каждого чиха становится непомерно дорогим удовольствием. Поэтому мы автоматизацию некоторых фич откладываем до завершения периода ее стабилизации. Тестируем руками и ставим отдельный тикет на автоматизацию, приступаем к которому через некоторое время после завершения работы над фичей.
Я бы сказал так: мы даем возможность и дальше смотрим. Я описывал пример desktop web команды, где тестировщики делают и то и то. Так вот в ней тоже есть исключения, есть люди, которые не проявляют интереса к автоматизации.
Соответственно, мы стимулируем чтобы имеющиеся тесты 1) использовали 2) фиксили 3) улучшали все в команде. А написание новых тестов для новых фич и уж тем более, развитие фреймворков, окружения, подходов и практик автоматизации — дело добровольное.
1) Правила нет. Более того, мы пропагандируем полный шаринг знаний и взаимозаменяемость. Это позволяет избежать бас-фактора. В то же время, часто для оптимальной работы зачастую на повторных этапах назначается тот же самый человек, что был вначале. Так попросту быстрее. Мы оставляем этот вопрос за каждым лидом конкретной команды тестирования и прямо запрещаем разработчикам назначать задачу на того же тестировщика после доработки.
2) Это зависит от команды. В desktop web, где мы в этом плане продвинулись максимально далеко (ибо начали раньше остальных), тестировщики делают как ручное тестирование, так и пишут автотесты высокого уровня. В других командах мы идем к тому же, для сравнения — в iOS команде мы недавно обязали ручных тестировщиков проверять результаты автоматизации и разбираться с падениями тестов. Затем планируем стимулировать самостоятельное исправление падений, а потом доберемся и до написания новых.
3) Есть. Несмотря на то, что тесты так или иначе пишут (или скоро будут) все, у нас есть выделенные люди, которые занимаются фреймворком, окружением, вырабатывают правила и методологии для остальных. Количество таких людей и их соотношение к ручным тестировщикам разное в разных командах.
4) Нагрузочного тестирования у нас нет. Вместо этого мы занимаемся планированием нагрузки, базируясь на текущих показателях перформанса на серверах, полученных от мониторинга. Плюс — плавная раскладка. В то же время для некоторых критичных демонов мы несколько раз нагрузку проверяли. Особой пользы от этого процесса не получили.
5) Команды тестирования разделены так же как и команды разработки. Есть разработчики, которые пишут серверную часть, биллинг, мобильные клиенты для iOS и Android и т.д. Каждая такая команда имеет свой выделенный пул тестировщиков. Между командами иногда происходит ротация для обмена знаниями, либо помощи коллегам в случае авралов.
Надеюсь, понял вопросы правильно.
2) Не предусмотрено и не может быть предусмотрено, потому что задачи разные. Разные размеры и функционал новых фич стимулируют индивидуальный подход. Общая канва исходит из самого принципа разделения задач на кусочки — кусочки должны быть логически законченными и уметь выкладываться независимо. И вот эти кусочки уже идут по конвейеру дальше, подчиняясь общим правилам, не зависящим от типа изменений.
3) Работа с багами и другими задачами (например тех-долг), не отличается от новых фич в той части, когда они идут по конвейеру. Заказчик в этом случае для них внутренний — либо сами девелоперы, либо тестировщики, либо технический руководитель. В остальном принцип такой же — либо разбили на кусочки, если задача большая, либо одна задача — самостоятельный кусочек, который идет все по тому же флоу. Разумеется, Visual QA в этом случае может не быть, но так же очевидно что если бага касается изменения функционала или предполагает неочевидное, неучтенное ранее поведение фичи, то может потребоваться разговор с продакт-менеджером, который владеет фичей.
1) Вы правы, обычно рефакторинг заказчика не интересует. Это нормально, он мыслит только бизнес-категориями, проблемы технического долга в его мире не существуют и не должны существовать. Как быть в каждом конкретном случае — это задача непосредственного технического лида разработки в команде.
В каких-то случаях стоит делать по-максимуму быстро, с костылями и велосипедами, в ущерб «красоте» кода и архитектуры, имея в виду что в будущем возникающий технический долг придется исправлять. В других случаях следует сначала избавиться от тех долга, лишь затем приступить непосредственно к написанию нового функционала. Еще ряд случаев может предполагать параллельную работу над рефакторингом и новыми фичами несколькими разработчиками сразу. Все индивидуально и сильно зависит от конкретных условий. Главный принцип тут — прагматизм. Как сделать максимально выгодно и пользователям и с точки зрения технологий.
Я бы сказал, что помимо людей и их проблем, эта задача — одна из основных для лида разработки.
Как именно разделять задачи правильно — это нетривиальная проблема, с которой справляется не каждый. Я сейчас готовлю отдельную статью про это.
2) Опять же, прежде всего — прагматизм. Гладко бывает только на бумаге и в сказках, в жизни регулярно возникающие неожиданности — это норма. Не подумали, не учли, не заметили, пропустили: так случается. Как быть в этом случае зависит от того, что именно явилось проблемой. Иногда чтобы их решить, приходится жертвовать личным временем; искать компромисс с заказчиком и выпускать задачу как есть, если она позволяет «прощупать» концепт итак; иногда бывает так что приходится начинать все сначала.
Главное помнить принцип — столкнулись с проблемой, значит надо решить как такую проблему (а идеально — и тип подобных проблем) избежать в будущем. Не искать виноватого, а конструктивно, надежно попытаться закрыть вопрос раз и навсегда. Тогда (не сразу) мы будем улучшать и улучшать инженерную культуру и будем воспитывать себя и своих коллег, обеспечивая развитие свое и своей компании.
Я бы сказал так: мы руководствуемся здравым смыслом и пытаемся избежать лишней бюрократии по-максимуму. Если мы видим, что какой-то шаг в процессе требует более пристального внимания/напоминания, то в этом случае мы можем применить более формальный подход. Так появился чек-лист для разработчика перед резолвом задачи, например. И сейчас это прям отдельный экран в трекере, куда надо руками проставить чекбоксы, чтобы кнопка «Готово» стала доступной.
Отвечаю на вопросы по пунктам:
1) Договоренности и формального срока нет. Очень многое зависит от функционала конкретных фич. В каких-то случаях он интуитивно понятен и без напоминалок, в каких-то случаях, чувствуя необходимость, люди начинают создавать чек-листы. Кроме того, учитывая огромное количество экспериментов, в некоторых ситуациях легче подождать «стабилизации» фичи. Для автоматизации — уж точно.
В этом и прелесть Exploratory testing — полный фристайл, минимум формализма.
2) Тут все очевидно — сначала нового человека необходимо познакомить с заведенными правилами команд, с системой, которую ему придется тестировать, с технологиями, инструментами и т.д. Для этого у нас во многих командах есть специальные странички в wiki, в которых описано как у нас происходит тот или иной процесс, из чего состоят те или иные компоненты системы. Информации очень много и мы не ожидаем того что человек сразу все это запомнит. Основная цель тут — показать где искать в случае чего. Обычно первый день нового сотрудника занят чтением этой информации и подготовкой рабочей среды.
Кроме того обычно либо сам менеджер, либо кто-то из команды, берет такого новичка «на поруки». Он выступает первой точкой контакта в случае возникновения вопросов, объясняет и показывает, ставит задачи. Это очень важный процесс, призванный установить доверительные отношения с новым сотрудником. На этом базируется все дальнейшее сотрудничество и карьерный путь новичка в компании.
Задачи для новичка сначала ставятся простые, для знакомства с системой, затем все сложнее и сложнее.
В то же время мы ожидаем максимальной самостоятельности от присоединившегося к нам человека. Долго нянчится и «водить за ручку» его никто не будет — своей работы полно. И в большинстве случаев готовность человека самостоятельно выполнять задачи является важным критерием прохождения испытательного срока.
Прежде всего, справедливости ради, я бы хотел отметить что крутые ребята у нас работают не только в A-team (платформа). Badoo — это команда очень хороших профессионалов в разных сферах, с высокой инженерной культурой.
А отвечая на ваш вопрос, я бы рекомендовал заглянуть вот в эту нашу статью. В ней Константин Карпов рассказывает как раз про процесс разработки и тестирования в платформе при производстве демонов.
Еще много различной информации про работу наших замечательных ребят из A-team можно найти вот в этой статье.
Удачи!
С одной стороны я рассматриваю опыт и умение программировать как большой плюс. Лично мне, к примеру (а я в прошлом — программист), очень сильно помогает чтение изменений в коде перед тестированием. Таким образом мне легче определить уязвимые места и варианты проверок.
С другой стороны, у меня есть ребята, которые программировать не хотят/не умеют и при этом отлично справляются с поиском багов. Во многих случаях даже лучше меня (что скрывать, я не самый идеальный тестировщик).
По поводу курсов — мы даем возможность нашим сотрудникам посещать любые курсы в пределах определенного бюджета, с определенной периодичностью. Какие именно это курсы должен определить сам сотрудник, а его менеджер должен подтвердить необходимость. И да, некоторые сотрудники из QA посещали курсы по программированию в том числе.