Как заставить младших программистов писать тесты?[закрыто]

https://stackoverflow.com/questions/7252

08-06-2019
|

Вопрос

У нас есть младший программист, который просто не пишет достаточного количества тестов.
Мне приходится пилить его каждые два часа: "Ты написал контрольные?"
Мы пытались:

Показывая, что дизайн становится проще
Демонстрация этого предотвращает появление дефектов
Превращая это в эгоизм, говоря, что только плохие программисты этого не делают
В эти выходные 2 члена команды должны были выйти на работу, потому что в его коде была НУЛЕВАЯ ссылка, и он не тестировал ее

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

Знаете ли вы о других мотивах?

Решение

Это один из самые трудные вещи делать.Привлечение ваших людей к получи это.

Иногда один из лучших способов помочь программистам младшего уровня "понять это" и перенять правильные техники у старших - это немного позаниматься парным программированием.

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

Что эти ребята вместе могут создавать код намного быстрее и более высокого качества.
Если ваш младший парень узнает достаточно, чтобы "добиться своего", а старший парень направит его по правильному пути (напр."Хорошо, теперь, прежде чем мы продолжим, давайте напишем at test для этой функции".) Это будет стоить тех ресурсов, которые вы на это выделите.

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

Еще одна вещь , которую вы можете сделать , - это пригласить своего младшего .Разработчики практикуют Игра в боулинг Ката это поможет им освоить разработку, основанную на тестировании.Он написан на java, но может быть легко адаптирован к любому языку.

Другие советы

Проводите проверку кода перед каждой фиксацией (даже если это 1 минута "Я изменил имя этой переменной"), и как часть проверки кода, просматривайте любые модульные тесты.

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

(Кроме того, если его работа не была протестирована, то почему она вообще была в производственной сборке?Если он не протестирован, не впускайте его, тогда вам не придется работать по выходным)

Что касается меня, то я начал настаивать на том, чтобы каждая ошибка, которую я нахожу и исправляю, выражалась в виде теста:

"Хммм, это неправильно..."
Найдите возможную проблему
Напишите тест, покажите, что код завершается с ошибкой
Устраните проблему
Покажите, что новый код проходит
Повторите цикл, если исходная проблема не устранена

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

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

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

Давайте начнем с создателя:

Показывая, что дизайн становится проще.

Как можно написать больше, упростить ситуацию?Теперь мне пришлось бы следить за тем, чтобы получить больше обращений, и так далее.Это все усложняет, если вы спросите меня.Дайте мне подробные сведения.

Демонстрация этого предотвращает появление дефектов.

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

Превращая это в эгоизм, говоря, что только плохие программисты этого не делают.

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

@Джастин Стандарт:При запуске нового проекта соедините младшего сотрудника с самим собой или другим старшим программистом.

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

@Джастин Стандарт:Читать Модульное тестирование 101 презентация Кейт Роудс.

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

Я хотел бы увидеть больше убедительных статей и других инструментов, которые помогли бы мне прийти в соответствие с мнением, что это правильный способ делать что-то.

@Доминик Куни:Потратьте немного времени и поделитесь методами тестирования.

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

@Доминик Куни:Отвечайте на вопросы, примеры и книги.

Наличие ответственного лица (people) для ответа на вопрос полезно, это может повысить вероятность того, что я попытаюсь.Хорошие примеры - это здорово, и это дает мне то, к чему можно стремиться, и то, на что можно ссылаться.Книги, имеющие непосредственное отношение к этому вопросу, являются отличным справочником.

@Адам Хейл:Неожиданный отзыв.

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

@Ритмис:Элементы считаются выполненными только тогда, когда у них есть тестовые примеры.

Ооо, интересно.Я вижу, что мне действительно нужно сделать это сейчас, иначе я ничего не завершу.В этом есть смысл.

@джморрис:Избавиться/ Принести в жертву.

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

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

Аргументация, Подготовка, Обучение, Последующее наблюдение, Поддержка.

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

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

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

Вот что бы я сделал на вашем месте:

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

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

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

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

Конечно, на самом деле я ничего не знаю.Но я надеюсь, что эти слова были полезны.

Редактировать:[Джастин Стандарт]

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

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

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

Я предполагаю, что он тоже довольно новый сотрудник (< 1 год) и, вероятно, недавно вышел из school...in в этом случае он, возможно, не привык к тому, как все работает в корпоративной среде.Подобные вещи большинству из нас могли сойти с рук в колледже.

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

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

Он уже делает это.Действительно.Он просто не записывает это.Не убедили?Наблюдайте, как он проходит стандартный цикл разработки:

Напишите фрагмент кода
Скомпилируйте его
Беги, чтобы посмотреть, что он делает
Напишите следующий фрагмент кода

Шаг №3 - это тест.Он уже проводит тестирование, он просто делает это вручную.Задайте ему этот вопрос:"Как вы узнаете завтра, что сегодняшний код все еще работает?" Он ответит:"Это такой маленький фрагмент кода!"

Спрашивай:- Как насчет следующей недели?

Когда у него не будет ответа, спросите:"Как бы вы хотели, чтобы ваша программа сообщала вам, когда изменение нарушает то, что работало вчера?"

Вот что такое автоматическое модульное тестирование.

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

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

Мне посчастливилось находиться под присмотром доброго и очень терпеливый старший программист.К счастью для меня, он решил сесть со мной за стол и потратить 1-2 недели на изучение моего взломанного кода togethor.Он объяснил бы, где я ошибся, тонкости языка си и указатели (боже, как это меня смутило!).Примерно за неделю нам удалось написать довольно приличный класс / модуль.Все, что я могу сказать, это то, что если бы старший разработчик не потратил время, чтобы помочь мне на правильном пути, я, вероятно, не продержался бы так долго.

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

Забирайте домой очки

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

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

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

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

Я бы заставил младшего программиста пожертвовать своими выходными, чтобы исправить ошибку.Его действия (или их отсутствие) не влияют на него напрямую.Кроме того, дайте понять, что он не увидит продвижения по службе и / или повышения зарплаты, если не улучшит свои навыки в тестировании.

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

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

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

Примечание:ты в самом деле хотите, чтобы цветной аддон thunderbird-diffs если вы планируете это сделать.

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

Вы можете помочь людям привыкнуть к этому, периодически говоря что-то вроде "Эй, Боб, ты видел коммит, который я сделал сегодня утром, я нашел отличный трюк, с помощью которого ты можешь делать все, что угодно, прочитай коммит и посмотри, как это работает!"

Примечание:У нас есть 2 "старших" разработчика и 3 младших.Это может не масштабироваться, или вам, возможно, потребуется немного скорректировать процесс с привлечением большего числа разработчиков.

Сделайте покрытие кода частью обзоров.
Сделайте "написать тест, который выявляет ошибку" обязательным условием для исправления ошибки.
Требуется определенный уровень покрытия, прежде чем код может быть возвращен.
Найдите хорошую книгу по разработке, основанной на тестировании, и используйте ее, чтобы показать, как test-first может ускорить разработку.

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

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

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

Опять же, вы можете делать все это мягко, если считаете, что это необходимо, но многим людям просто нужна крепкая пощечина. Жизнь В Реальном мире, и вы оказали бы им услугу, подарив это им.

Удачи.

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

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

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

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

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

Я бы не стал особенно подчеркивать фактор стыда / вины.Стоит отметить, что тестирование является широко распространенной хорошей практикой и что написание и поддержание хороших тестов - это профессиональная вежливость, поэтому вашим товарищам по команде не нужно проводить выходные на работе, но я бы не стал подробно останавливаться на этих моментах.

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

Учить его / ее - обязанность его Наставника.Насколько хорошо вы учите его / ее тестированию?Вы программируете с ним в паре?Младший, скорее всего, не знает, КАК настроить хороший тест для xyz.

Будучи новичком в школе, он знает много Понятий.Какая-то техника.Некоторый опыт.Но, в конце концов, все Юниоры - это ПОТЕНЦИАЛ.Почти в каждой функции, над которой они работают, будет что-то новое, чего они никогда раньше не делали.Конечно, Младший, возможно, и делал простой шаблон состояния для проекта в классе, открывая и закрывая "двери", но никогда не применял шаблоны в реальном мире.

Он / она будет настолько хорош, насколько хорошо вы будете преподавать.Если бы они могли "Просто получить это", как вы думаете, они бы вообще заняли младшую должность?

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

@ jsmorris

Однажды старший разработчик и "архитектор" отчитал меня и тестировщика (это была моя первая работа после окончания колледжа) по электронной почте за то, что я не задержался допоздна и не выполнил такое "легкое" задание накануне вечером.Мы занимались этим весь день и прекратили работу в 7 вечера, в тот день я метался с 11 утра до обеда и по меньшей мере дважды обращался за помощью к каждому члену нашей команды.

Я ответил и обратился к команде с:- Вот уже месяц, как я разочарован в тебе.Я никогда не получаю помощи от команды.Я буду в кафе через дорогу, если я тебе понадоблюсь.Мне жаль, что я не смог отладить метод с 12 параметрами и 800 строками, от которого зависит практически все ".

Посидев часок в кафе, я вернулся в офис, собрал свои вещи и ушел.Через несколько дней они позвонили мне и спросили, приду ли я, я сказал, что приду, но у меня собеседование, возможно, завтра.

- Значит, ты увольняешься?

В вашем исходном репозитории :используйте хукеры перед каждой фиксацией (например, хук предварительной фиксации для SVN).

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

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

Только автоматические проверки могут хорошо масштабироваться в проекте.Вы не можете проверить все вручную.

У разработчика должно быть средство проверить, покрывают ли его тестовые примеры 100% кода.Таким образом, если он не передает код, проверенный на 100%, это его собственная вина, а не ошибка типа "ой, извините, я забыл".

Вспомни :Люди никогда не делают того, чего вы ожидаете, они всегда делают то, что вы проверяете.

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

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

Большинство организаций допускают фатальную ошибку, назначая роли тестировщиков новичкам, людям с НАИМЕНЬШИМ опытом работы с вашим кодом - в идеале, старшие разработчики должны быть переведены на роль QA, поскольку у них есть опыт работы с кодом и (надеюсь) развито шестое чувство к запахам кода и местам сбоев, которые могут возникнуть.

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

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

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

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

Если в вашей организации меньше 6 человек или вам не удается создать новую команду, я рекомендую парное программирование (PP).Я не сторонник всех методов экстремального программирования, но я определенно верю в парное программирование.Однако оба члена парной команды программистов должны быть преданы делу, иначе это просто не сработает.Они должны следовать двум правилам:инспектор должен полностью понимать, что кодируется на экране, или он должен попросить программиста объяснить это;программист может закодировать только то, что он может объяснить - никаких "ты увидишь", или "доверься мне", или маханий руками не допускается.

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

Если PP не для вас, то TDD - ваш лучший выбор, но только в том случае, если понимать его буквально.Разработка, основанная на тестировании, означает, что вы сначала пишете тесты, запускаете их, чтобы доказать, что они действительно терпят неудачу, затем пишете простейший код, чтобы заставить его работать.Компромисс заключается в том, что теперь у вас (должна) быть коллекция из тысяч тестов, которая также является кодом и с такой же вероятностью, как и производственный код, содержит ошибки.Честно говоря, я не большой поклонник TDD, в основном по этой причине, но он работает для многих разработчиков, которые предпочитают писать тестовые сценарии, а не документы с тестовыми примерами - немного тестирования лучше, чем ничего.Соедините TDD с PP для повышения вероятности охвата тестированием и уменьшения количества ошибок в скрипте.

Если все остальное не помогает, попросите программистов использовать эквивалент банки с ругательствами - каждый раз, когда программист прерывает сборку, он должен положить 20, 50, 100 долларов (все, что в меру болезненно для ваших сотрудников) в банку, которая переходит к вашему любимому (зарегистрированному!) благотворительность.Пока они не заплатят, избегайте их :)

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

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

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

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

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

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

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

Не у всех одинаковый уровень таланта и / или мотивации.Команды разработчиков, даже гибкие, состоят из людей из "A-Team" и людей из "B-Team".Члены команды А - это те, кто разрабатывает решение, пишет весь нетривиальный производственный код и общается с владельцами бизнеса - вся работа, требующая нестандартного мышления.Команда B занимается такими вещами, как управление конфигурацией, написание сценариев, исправление неубедительных ошибок и выполнение работ по техническому обслуживанию - всей работой, которая требует строгих процедур, которые влекут за собой небольшие последствия в случае сбоя.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow