Жизнеспособность команды разработчиков без * выделенной * роли тестера [закрыто]

9

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

Пока что я определяю стройную команду следующим образом:

  • Маленький;
  • Самоорганизация;
  • Все участники должны иметь в виду QA;
  • Члены должны быть способны выполнять несколько ролей

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

Разработчики делают плохих тестеров.

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

Предполагая, что это правильно, я думал о разных способах решения проблемы dev / tester, и я считаю, что нашел жизнеспособную модель.

Моя модель требует:

  • Небольшой программный дом с 2+ проектами
  • Agile (итеративный) подход к разработке и доставке
  • 1 команда на проект
  • Все члены команды будут разработчиками программного обеспечения
    • Их описание работы будет четко развития , обеспечения качества , тестирования и доставки в качестве обязанностей

Если все эти предварительные условия были выполнены, то проекты могут быть организованы следующим образом (этот пример будет относиться к двум проектам, A и B ):

  • Каждый член команды будет переключаться между ролью разработчика и ролью тестера
  • Если член команды является разработчиком проекта А , он будет тестером проекта Б
    • Пользователи будут работать только один проект в то время, и , следовательно , как ожидается, будут действовать как ни в Dev или тестером.
  • Роль Цикл состоит из 3 -х итераций как Dev и 2 итерации в качестве тестера (опять же , на два разных проектах)
  • У проектных команд всегда будет 3 разработчика и 2 тестера.
  • Циклы роли участника должны быть не в фазе на 1 итерацию.
    • Это сводит к минимуму резкие изменения команды. Для каждой итерации 2 разработчика и 1 тестер останутся такими же, как и предыдущая итерация.

Учитывая вышеизложенное, я вижу следующие плюсы и минусы:

Pros

  • Распространяет знания о проекте по всей компании.
  • Гарантирует, что члены команды не тестируют код, который они помогли написать.
  • Роль циклов вне фазы означает, что ни один проект не имеет 100% -ого переключения участников.
  • Чередование ролей нарушает однообразие скучных проектов.

Cons

  • Итерации обоих проектов тесно связаны между собой. Если бы один проект отменил итерацию на полпути и начал заново, тогда оба проекта были бы не синхронизированы. Это затруднит управление ролевым циклом.
  • Зависит от найма Разработчики также работают в качестве тестеров.

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

Поэтому мой вопрос: может ли такая модель работать на практике? Если нет, то можно ли его подстроить под рабочую модель?

Примечание: ради краткости я сосредоточился только на ролях разработчика и тестера. Я расширю другие роли, если это необходимо.

MetaFight
источник
Несмотря на то, что разработчики могут или должны быть тестерами, они частично совпадают, но я думаю, что суть этого вопроса заключается в роли «вне фазы 2» в модели 2 проекта.
MetaFight
2
FWIW мое личное мнение таково, что вы рискуете довольно много с таким подходом. Я бывший тестер (и не худший), и когда я однажды попал в проект, где я мог «переплетать» 2 роли, я впервые подумал: «Вау, шанс понять, как это сделать правильно». Примерно через пол года я передумал и больше не хочу пытаться это повторить. Обе роли (dev и QA) требуют 100% -ной концентрации, чтобы сделать это правильно, но когда вы чередуетесь, вы отвлекаетесь и теряете ни в качестве, ни в производительности, ни в обоих. Кстати, получение специального тестера в этом проекте обеспечило самый впечатляющий ROI, который я когда-либо наблюдал
gnat
2
@gnat, но вы не объяснили, почему Разработчик не может выполнять роль Тестера. Конечно, этот человек должен воспринимать это всерьез как штатную должность, поэтому я предложил, чтобы они чередовали проекты и работали только над одним проектом одновременно. Я не ожидаю, что любой Разработчик сможет сделать это ... только те, кто станет хорошими Тестерами, если бы они выбрали этот путь.
MetaFight
2
Перефразируя то, что вы хотите сделать: «Я хочу открыть медицинскую операцию, вместо того, чтобы нанять пару анестезиологов, я найму достаточное количество хирургов и поменяю их роль». Ваше предложение показывает (типичное) непонимание того, что профессиональный тестировщик предлагает команде. Вы могли бы сделать это, многие делают, некоторые заставляют это работать. То, что вы никогда не узнаете, это то, что вы упускаете, и что вы могли бы делать лучше. Кстати, тестирование - это не тестирование, а всего лишь один урок, который преподаст вам профессиональный тестер.
Mattnz

Ответы:

8

Я не согласна с

Разработчики делают плохих тестеров

Большинство команд, над которыми я работал в моей карьере, не имели поддержки QA. Это включает в себя несколько крупных глобальных корпораций, использующих такие продукты, как их глобальная система входа и регистрации. В другом случае у меня было 30% дохода компании, проходящего через коробку на моем столе. (Кстати, эти практики не рекомендуются;)) Эти компании полагались на инженеров, чтобы убедиться, что их код работает правильно. А мы, будучи ориентированными на детали, немного навязчивыми и гордыми своей работой, пойдем на многое, чтобы убедиться, что наше программное обеспечение работает правильно.

Кроме того, как разработчик, я делаю гораздо больше тестов, чем тестеров. Я регулярно тестирую мой код до 90% или 100%, если я не работаю с Java.

Мне нравится работать с тестерами, потому что они приходят к этому с другой точки зрения и ловят вещи, о которых я не думал. Но я действительно не рассчитываю на то, что они обеспечат более 30-50% тестового покрытия, в то время как я считаю себя ответственным за 100%. (Кстати, для них это не удар - они обычно разбросаны по проектам.)

Вместо того, чтобы спрашивать инженеров на собеседованиях, хотят ли они проводить QA, спросите: если ошибка обнаруживается в производстве, кто несет ответственность? Если я привожу ошибку, и клиент испытывает ее, я чувствую себя плохо и беру на себя ответственность. Я не виню парней QA. ИМХО Это тот тип инженера, которого вы хотите нанять (и работать с ним)

Мой метод обеспечения качества: а) суперагрессивное модульное тестирование (хотя я не могу заставить себя сделать полный тест-ориентированный Devlopment), б) эффективный процесс проверки кода действительно помогает, и в) интеграция нетерпимости и нетерпения с дефекты в культуре команды.

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

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

обкрадывать
источник
6

Я согласен с ответом @Rob Y и хотел бы добавить несколько моментов:

  • В Agile выделенные тестеры в команде - это не шаблон, потому что они вынуждают команды работать по конвейеру и по своей сути неэффективны. Вы постоянно сталкиваетесь с историями, которые "сделаны", но не проверены. Выделенные тестеры хороши, если они работают вне команды (или отдельной команды).

  • Дев делают плохих тестеров ... а тестеры делают плохих тестеров. QA сложно. На самом деле это очень сложно. Ваша проблема не в людях и ролях. Ваша проблема может быть в том, что ваше программное обеспечение выброшено. Опять же, в Agile ваша команда несет ответственность за тестирование перед производством (независимо от того, имеют ли они выделенный контроль качества или нет).

  • QA является частью разработки, такой как рефакторинг, архитектура и т. Д. Команда разработчиков должна выпускать программное обеспечение по определенному, согласованному, реалистичному стандарту. QAs не улучшит этот стандарт. Лучше разработчики, вероятно, будут.

  • Провокация: Кто сказал, что QA лучше, чем разработчики в QA-ing? Это то, что люди говорят, но ... Необходимый «хакерский» менталитет QA - это менталитет разработчика. Фактически, в основном все хакеры являются или были разработчиками, а не QA ...

  • Провокация 2: 99% работ по обеспечению качества могут быть (и, смею сказать, должны быть ) автоматизированы с помощью сценариев. Хорошая команда сделает это, и чтобы сделать это правильно, вам нужны ... разработчики.

Sklivvz
источник
Комментируем Provocation 2: автоматизация тестирования может выполняться разработчиками, но не обязательно. Тестировщики, которые умеют кодировать (но не на уровне профессионального разработчика), могут писать достаточно хорошие сценарии.
Мате Мрше
4

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

Главное - сделать это частью культуры команды и частью каждого проекта. Мы составили планы тестирования (просто краткие списки тестов, которые мы намеревались написать для проекта), и другие разработчики рассмотрели бы и предложили случаи и сценарии, которые мы пропустили.

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

Рори Хантер
источник
этот пост довольно трудно читать (стена текста). Не могли бы вы изменить его в лучшую форму?
комнат
2
Извините, утренняя помойка. Я сломал это сейчас.
Рори Хантер
2

Сначала предостережение - я работал профессионально как инженер QA и инженер-программист.

Может ли такая модель работать на практике?

Все возможно.

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

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

И, по моему опыту, каждый проект требует хотя бы небольшого количества такого тестирования (даже если не каждый проект проводил такого рода тестирование). Проблема в том, что вы не получаете такого рода тестирование от людей, незнакомых с лучшими практиками QA. Черт, вы даже не получаете его от людей, которые знают лучшие практики, но "доверяют" разработчикам.

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

Даже если вы сможете найти разработчиков, которые могут терпеть не делать то, что они любят делать 2 недели из 5, вы также столкнетесь с этим основным противоречием. Хуже того, вы тратите время и силы на то, чтобы научить людей хорошо выполнять две работы, а не одну. Компаниям трудно найти и обучить людей, хорошо работающих на одной работе, не говоря уже о двух.

Может быть, вы в какой-то степени удивительны, с чем я еще не сталкивался, но я сомневаюсь в этом.

Telastyn
источник
Возможно, моя модель нуждается в роли Sr QA, чтобы рассмотреть предложенные подходы моих разработчиков и рекомендовать подходы наилучшей практики. О, и большинство людей не находят меня классным, но моя мама знает :), и этого достаточно для меня!
MetaFight
Я перевожу некоторые из наших ролей QA на владельцев продуктов. Похоже, у вас нет одобрения владельцем продукта пользовательских историй или обзоров спринтов. Обе они уловят много проблем, которые команда разработчиков могла пропустить. Однако до этого, если вы не можете доверить разработчикам качество продукции, вам нужно найти других разработчиков. Это мой вывод - по моему опыту - вы не можете тренировать плохое качество у плохого разработчика. Я работал со многими разработчиками «сделай свою работу», и это результат, который ты получаешь от них. Хорошая команда разработчиков требует хороших разработчиков.
Дэвид Андерсон
0

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

  1. Будьте очень откровенны в отношении двойных ролей для кандидатов. Это не для всех по многим причинам. Если у вас слишком много людей, которым это не нравится, у вас будут неудачи и текучесть кадров.
  2. Составьте план, в котором вы сможете оценить лучший способ объединить это с командой. Хотя мне нравится концентрироваться на одной задаче / проекте за раз, я не уверен, что хотел бы не программировать в течение очень длительного периода времени. Может быть, тестирование это хороший отпуск вдали от программирования. Не то, чтобы это было проще, просто используя разные клетки мозга для разнообразия. Будьте готовы попробовать это по-разному, прежде чем решить, что лучше.

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

Этот план не позволяет командам самоорганизоваться достаточно. Одна стратегия, вероятно, не подходит для всех команд и всех проектов.

JeffO
источник
Роль тестера в этом случае может включать ручное и автоматическое тестирование. Я ожидал бы, что разработчики напишут модульные и интеграционные тесты, но тестеры также сделали бы то же самое. Надо надеяться, что точное разделение написания тестового кода будет естественным равновесием, достигнутым после нескольких итераций.
MetaFight
Это действительно не должно быть даже в случае, если кандидаты хотят играть двойные роли или нет. Если вы хотите управлять успешной компанией, вы должны поставить людей там, где они превосходны. Зачем ставить парня на тестирование, который может самостоятельно разрабатывать и кодировать 2 надежные системы, если команде из 4 или 5 человек приходится создавать одну систему одновременно? Аналогично, у тестирования есть свои навыки, чтобы уметь это делать хорошо. Самые большие достижения в человеческой цивилизации произошли, когда люди начали специализироваться. Почему управление компанией-разработчиком программного обеспечения отличается от того, что материнская природа уже доказала свою эффективность?
Данк