Должен ли я сообщить разработчику программного обеспечения, что ему нужно повысить производительность тестирования?

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

Вот проблема: для определенной задачи по разработке функции, которая потребовала бы у другого среднего/старшего разработчика 2 месяца, плюс встречи и помощь от меня и некоторых других старших инженеров, которые написали кодовую базу, и 3 дня для тестирования. Ему требуется 1 месяц, чтобы самостоятельно написать абсолютно красивый и производительный кодпочти без дефектов и 1-2 недели на тестирование. И он с нами всего несколько месяцев! Руководство начало отслеживать время его простоя (из-за того, сколько времени ему требуется на тестирование), и мы заметили, что он бездействует 50% времени во время циклов тестирования, с чем у руководства большие проблемы, потому что они считают, что он должен работать усерднее и тестировать его функции быстрее... несмотря на то, что он самый результативный член нашей команды... на юниорском уровне... мы также значительно недоплачиваем, учитывая ценность, которую он приносит нашей команде.

Я действительно не хочу терять этого человека, потому что тогда я буду ответственным за его замену... и в настоящее время я считаю его лучшим сотрудником в моей команде. Я также не хочу ничего говорить ему, потому что мы не так много ему платим, и я чувствую, что он, вероятно, уволится на месте (я нахожу его немного вспыльчивым) и найдет новую работу, если я донесите это до него. Замена его кем-то с равными навыками обошлась бы нам в 2-3 раза дороже, чем мы платим ему сейчас. И если мы наймем кого-то еще, мы рискуем тем, что они не смогут выполнять эту работу, и в конечном итоге нам придется их уволить.

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

Что мне здесь делать?

Помимо того, что менеджмент был задницей, можете ли вы объяснить мне, почему проблема в том, что разработчик выполнил задачу, которая, по вашим оценкам, заняла 2 месяца за 6 недель?
@PhilipKendall проблема управления заключается в том, что вместо 2-3 дней на тестирование (или лучше) им требуется 2 недели, и во время тестирования их компьютер простаивает 50% дня.
Я подозреваю, что это потому, что он простаивает часть времени в течение длительного цикла тестирования, и они думают, что он должен выполнять те же самые задачи за 1 месяц — он мог бы быть в два раза быстрее, если бы его тестирование было быстрее.
@thursdaysgeek Правильно
We recently let our QA team go and have started to expect developers to do their own in-depth testing- Здорово! Это само по себе красный флаг. Разработчики не тестировщики, это другая дисциплина. Они также никогда не должны нести ответственность за контроль качества кода, который они написали сами. Они пропустят те же самые ошибки, которые пропустили, когда писали это.
@SethR абсолютно. На моем рабочем месте мы полностью полагаемся на наших специалистов по обеспечению качества, даже при полном автоматизированном тестировании. Существует совершенно другой метод ума от «мне это нужно, чтобы сделать это» до «хорошо, как мне это сломать»
«Мы заметили, что он бездействует 50% времени во время циклов тестирования». Поздравляю, вы нашли более безумный корпоративный показатель производительности, чем количество написанных строк кода. Разработчики — это не рабочие конвейера, мышление — это тоже работа… Не собирайте эту метрику, не ранжируйте сотрудников по этой метрике и уж точно не обучайте сотрудников по этой метрике. ИМХО.
«Он мой лучший сотрудник. Он превосходит всех остальных в команде. Мы не платим ему почти столько, сколько он стоит. должны его уволить». - У меня нет слов.
У вас есть какая-нибудь теория, почему он бездействует 50% времени во время тестирования? Время на обдумывание, усталость или неприязнь к определенному виду задач, даже, может быть, просто накладные расходы из-за неопытности и организации своих мыслей — все это может быть законным объяснением. Кажется совершенно кафкианским спорить с ним об этом, когда вы уже признаете, что качество его кода очень высокое и в целом он работает быстро. Было бы лучшей стратегией начать разговор о том, что делает его таким продуктивным, чтобы, возможно, можно было бы обобщить его передовой опыт!
Есть ли хоть какой-то шанс, учитывая, насколько он хорош и продуктивен, что он просто делает работу по тестированию намного лучше, чем другие разработчики? Если вы посмотрите на ошибки, обнаруженные после того, как код был протестирован, его код выходит вперед?
Отпустить нашу команду QA — вот самая большая проблема: разработчики подсознательно не хотят находить проблемы в своем коде. Каждая ошибка, которую они находят, создает работу для них самих. У наших QA нет проблем с этим. Если они заставляют меня работать дополнительно, значит, они хорошо поработали.
Let go of our QA team, tracking his idle times, we considerably underpay him, hope I don't have to fire him [the highest performer]. Это должно быть вопрос тролля. Я не понимаю, что человек или компания могут быть настолько плохи в управлении и настолько бессознательны.
Что здесь означает «холостой ход»?
Если вы думаете, что функция, на разработку которой уходит 1-2 месяца, может быть протестирована за 2-3 дня, вы серьезно ошибаетесь, и, вероятно, прямо сейчас у вас есть серьезные дефекты и другие проблемы с качеством в вашем продукте. Вы думали, что ваша предыдущая команда QA ничего не делала? Я думаю, что 1-2 недели, которые разработчик тратит на тестирование, вероятно, являются недостатком.
Пожалуйста, поделитесь названием компании, чтобы никому не пришлось иметь несчастье работать в этой потогонной мастерской в ​​течение следующих 2 лет, которые потребуются для того, чтобы компания прекратила свою деятельность.
«Что мне здесь делать?» -- дайте ему хорошее рекомендательное письмо, предложите GTFO как можно быстрее (для его же блага), а затем сделайте то же самое сами.
«Замена его кем-то с равными навыками обошлась бы нам в 2-3 раза дороже, чем мы платим ему сейчас». -- Вы поднимали этот конкретный денежный вопрос в этих терминах в обсуждениях с руководством? Я думаю, что если это не заставит их изменить курс, то ничего не изменится.

Ответы (5)

У вас проблемы с управлением. И, правда это или нет, вы должны объяснить им, что время, которое он тратит на тестирование, является причиной того, что код так хорош , и поскольку он все еще быстрее других людей, у них есть два варианта:

  1. Оставьте его в покое и надейтесь продержать его несколько лет, прежде чем он осознает свою ценность и пойдет туда, где ему будут платить прилично.
  2. Беспокоите его о времени, которое он тратит на тестирование, что приведет либо к тому, что он предоставит не такой хороший код, либо, что более вероятно, вообще уйдет.

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

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

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

Я думаю, что самая большая проблема, с которой они сталкиваются, это то, что он простаивает 50% времени вместо тестирования. Я лично не возражаю против этого из-за его производительности, но руководство / высшие чины ожидают, что работник будет простаивать, может быть, менее 5% дня, если что. Человек также много бездействует во время разработки, но это легко оправдать (вы должны подумать), а тестирование - нет. Тем более, что многое из этого связано с регрессионным тестированием/проверкой контрольных списков.
@Джефф - я не единорог, как этот парень, но если бы мне пришлось работать без простоя или даже с простоем 5%, я бы скорее сломался. Вот почему я сейчас здесь: чтобы освежить свои мысли перед тем, как перейти к следующему вопросу.
@Джефф - я бы также указал руководству, что то, что его пальцы не двигаются во время тестирования, не означает, что он бездействует. Думать (и отдыхать) — это не видимая работа, но все же это активная и продуктивная работа.
@ Джефф, может ли это быть оправдано тем, что он более тщательен, чем другие, что он на самом деле применяет к задаче больше когнитивной работы? Или даже то, что процесс тестирования рутинный и обыденный, или, наоборот, что он включает в себя большое разнообразие, и в любом случае он находит его психологически более утомительным, чем норма, и ему приходится работать в более медленном темпе?
@Jeff Вот в чем разница между специалистом по обеспечению качества и разработчиком: специалист по обеспечению качества находит ошибку, и, если они хороши, записывает точные шаги, как они могут ее воспроизвести. Разработчик, тестирующий собственный код, делает то же самое, но затем начинает думать о том, в чем на самом деле проблема в коде, и, возможно, исправляет ее. На самом деле это более эффективно, но, похоже, они прекратили тестирование. На самом деле, они прекратили тестирование и устранили проблему. Этот парень 20 часов тестирует, 20 часов чинит, а идиоты наверху думают, что он ленивый.

Здесь довольно много всего происходит, и не так уж много хорошего.

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

Даже без доступа к опытным тестировщикам и тестировщикам по обеспечению качества ваш младший разработчик пишет код с небольшим количеством дефектов. Вдобавок ко всему, они завершают общий пакет работ по проектированию, разработке и тестированию решения за 5-6 недель, когда вы оцениваете, что другому среднему или старшему разработчику потребуется 8 недель, чтобы выполнить эту работу. Они доставляют на 2-3 недели быстрее и, по-видимому, более высокого качества, чем вы ожидаете от более высокопоставленного человека.

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

Это приводит к «простою». Измерение «времени простоя» мало что значит в умственной работе. Что значит, что они простаивают 50% времени? Как определяется это число? Возможно, вы захотите еще раз подумать, означает ли это что-нибудь, тем более что работа выполняется быстрее, чем предполагалось.

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

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

Итак, резюмируя:

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

Это очень просто. В фактической производительности этого молодого разработчика нет ничего плохого. Проблема в том, что его производительность измеряется какой-то довольно глупой метрикой производительности. Поэтому вы просто объясняете ему, что ему нужно сделать, чтобы обойти эти показатели производительности.

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

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

Вы неправильно аргументировали.

Если руководство хочет, чтобы разработчики занимались контролем качества, и вы не можете изменить их мнение, на этом все. Вам нужно работать с тем, что у вас есть.

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

Стоит отметить, что здесь действуют два фактора. Конечно, они немного медленнее при тестировании, но это усугубляется тем, что они работают быстрее во время разработки.

Но вы можете обратить это в плюс:

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

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

Большая часть кода не может быть разумно протестирована, и по-прежнему требует большого количества ручного тестирования и большого количества регрессионного тестирования. Иногда большая часть системы изменяется из-за функции, поэтому все нужно тестировать повторно, что-то вроде контрольного списка.
Ах, это позор. В таком случае, можно ли прямо спросить его, есть ли какие-то блокираторы, с которыми он сталкивается? Я чувствую, что формулировка вопроса вокруг «что-то мешает вам», а не «почему ваша машина так долго простаивает», может ограничить шансы на то, что он защитится.
@Jeff Если у вас нет способов автоматизировать тестирование, то лучше всего будет назначить это как проблему этому тестеру. Существует множество способов тестирования и множество инструментов. Если ни один инструмент не соответствует тому, что вам нужно, то работа этого человека над созданием такого инструмента принесет компании большую пользу. Много лет назад у меня было устройство, которое надевалось на клавиатуру, и я мог нажимать клавиши. Существует множество способов автоматизации тестирования.
Должен ли я сообщить разработчику программного обеспечения, что ему нужно повысить производительность тестирования?
СпросиСетьПолитика конфиденциальности1y, 0v