Як змусити молодших програмістів писати тести? [зачинено]

У нас є молодший програміст, який просто не пише достатньо тестів.
Я мушу його кожні дві години, "ти писав тести?"
Ми спробували:

• Показано, що конструкція стає простішою
• Показ цього запобігає виникненню дефектів
• Зробити це предметом его, говорячи, що тільки погані програмісти цього не роблять
• У ці вихідні 2 учасники команди повинні були прийти на роботу, оскільки його код мав NULL-посилання, і він не перевіряв його

Моя робота потребує стабільного коду вищої якості, і зазвичай кожен "отримує це", і немає необхідності просувати тести. Ми знаємо, що можемо змусити його писати тести, але всі ми знаємо, що корисні тести - це ті, які написані, коли ти в ній.

Чи знаєте ви більше мотивацій?

Це одна з найважчих справ . Змусити своїх людей це отримати .

Іноді один з найкращих способів допомогти програмістам молодшого рівня «дістати» та навчитися правильних прийомів у старших - це зробити трохи програмування пар.

Спробуйте так: у майбутньому проекті з’єднайте молодшого хлопця з собою або іншим старшим програмістом. Вони повинні працювати разом, по черзі «керуючи» (будучи тим, хто набирає клавіатуру) та «тренуватися» (дивлячись через плече водія та вказуючи пропозиції, помилки тощо). Це може здатися марною тратою ресурсів, але ви знайдете:

1. Що ці хлопці разом можуть створити код досить швидко і більш високої якості.
2. Якщо ваш молодший хлопець навчиться достатньо "здобути його" разом зі старшим хлопцем, який направляє його на правильний шлях (наприклад, "Добре, тепер, перш ніж ми продовжимо, давайте написати тест на цю функцію".) Це буде добре варто ресурсів, які ви взяти на себе зобов’язання.

Можливо, також хтось із вашої групи дасть презентацію Unit Testing 101 від Кейт Родос, я вважаю, що це прекрасний спосіб викликати захоплення людей від тестування.

Інша річ, яку ви можете зробити, це зробити, щоб ваш молодший розробник практикував катання на боулінгу Ката, яка допоможе їм навчитися розробці тестових програм. Він знаходиться в java, але його легко можна адаптувати до будь-якої мови.

Проводьте перевірку коду перед кожним фіксацією (навіть якщо це 1 хвилина "Я змінив ім'я цієї змінної"), і в рамках огляду коду перегляньте будь-які одиничні тести.

Не виходьте на комісію, поки не пройдуть тести.

(Крім того, - якщо його робота не була перевірена - чому це було в першу чергу на виробництві? Якщо це не перевірено, не впускайте його, тоді вам не доведеться працювати вихідними)

Для себе я почав наполягати, щоб кожна помилка, яку я знайшов і виправила, була виражена як тест:

1. "Гммм, це не так ..."
2. Знайти можливу проблему
3. Напишіть тест, покажіть, що код виходить з ладу
4. Вирішіть проблему
5. Покажіть, що новий код проходить
6. Цикл, якщо початкова проблема не зберігається

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

(Я не живу в комерційному середовищі програмування, і часто є єдиним кодером, який працює над певним проектом.)

Уявіть, що я - глузуючий програміст, званий ... Марко. Уявіть, я не так давно закінчив школу, і ніколи насправді не доводилося писати тести. Уявіть, я працюю в компанії, яка насправді цього не вимагає і не вимагає. ГАРАЗД? добре! А тепер уявіть, що компанія переходить на використання тестів, і вони намагаються мене з цим зрозуміти. Я дам дещо бурхливу реакцію на згадані досі предмети, як ніби я не робив жодного дослідження з цього приводу.

Почнемо це з творця:

Показано, що конструкція стає простішою.

Як можна писати більше, робити речі простішими. Зараз мені доведеться вести вкладки щодо отримання більшої кількості справ тощо. Це ускладнює, якщо ви запитаєте мене. Дайте мені ґрунтовні деталі.

Показ цього запобігає виникненню дефектів.

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

Зробити це предметом его, говорячи, що тільки погані програмісти не роблять.

О, так ти вважаєш, що я поганий програміст лише тому, що я не так часто використовую тестування. Я ображений і позитивно роздратований на вас. Я б швидше мав допомогу та підтримку, ніж приказки.

@ Джастін Стандарт : На початку нової перспективної пари молодший хлопець з собою або іншим старшим програмістом.

О, це так важливо, що ресурси будуть витрачені на те, щоб я бачив, як це робиться, і мені допоможуть, як це робити. Це корисно, і я можу просто почати робити це більше.

@ Джастін Стандарт : Прочитайте презентацію блоку Тестування 101 від Кейт Родос.

Ах, це була цікава презентація, і це змусило мене задуматися про тестування. Це зафіксувало деякі моменти в тому, що я повинен був би розглянути, і це, можливо, трохи похитнуло мої погляди.

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

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

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

@ Домінік Куні : Дайте відповіді на запитання, приклади та книги.

Якщо людині, яка бажає відповісти на запитання, корисно, це може змусити мене спробувати. Хороші приклади чудові, і це дає мені щось, на що я прагну, і щось шукати для посилання. Книги, які безпосередньо стосуються цього, є чудовим посиланням.

@ Адам Хейл : Огляд сюрпризу.

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

@ Rytmis : Предмети вважаються зробленими лише тоді, коли у них є тестові справи.

О, цікаво. Я бачу, що мені справді доводиться це робити зараз, інакше я нічого не завершую. Це має сенс.

@ jmorris : Позбавляйся / жертвуючи.

відблиски, відблиски, відблиски - Є шанс, що я можу навчитися, і за підтримки та допомоги я можу стати дуже важливою та функціональною частиною команд. Це один з моїх негараздів зараз, але це буде недовго. Однак якщо я просто цього не отримаю, я розумію, що піду. Я думаю, я це отримаю.

Зрештою, підтримка моєї команди зіграла велику роль у всьому цьому. Запропонувати людині витратити свій час на допомогу, і навести мене на добрі звички завжди вітається. Тоді, згодом мати добру мережу підтримки буде чудово. Завжди було б вдячно, щоб хтось прийшов кілька разів після цього і переглянув якийсь код, щоб побачити, як все протікає, не в огляді як такому, а більше як дружньому візиті.

Розум, підготовка, викладання, подальша підтримка.

Я помітив, що багато програмістів бачать цінність тестування на раціональному рівні. Якщо ви чули речі на кшталт "так, я знаю, що я повинен це перевірити, але мені справді потрібно швидко зробити це", тоді ви знаєте, що я маю на увазі. Однак на емоційному рівні вони відчувають, що щось роблять лише тоді, коли пишуть справжній код.

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

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

Ось що я б робив:

• Перший час ... "ми будемо робити цей проект спільно. Я буду писати тести, а ви збираєтеся написати код. Зверніть увагу на те, як я пишу тести, тому що ми робимо справи тут, і саме цього я очікую від вас ".

• Після цього ... "Ви закінчили? Чудово! Спочатку давайте подивимось на тести, які сприяють вашій розробці. О, ніяких тестів? Повідомте мене, коли це буде зроблено, і ми перекладемо перегляд вашого коду. Якщо ви" Вам потрібна допомога у формулюванні тестів, дайте мені знати, і я допоможу вам ".

Він це вже робить. Дійсно. Він просто не записує це. Не переконані? Спостерігайте за тим, як він проходить стандартний цикл розробки:

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

Крок №3 - тест. Він уже робить тестування, він просто робить це вручну. Задайте йому це запитання: "Як ви знаєте завтра, що код від сьогодні ще працює?" Він відповість: "Це така невелика кількість коду!"

Запитайте: "Як щодо наступного тижня?"

Коли у нього немає відповіді, запитайте: "Як би ви хотіли, щоб ваша програма повідомила вам, коли зміна порушує щось, що працювало вчора?"

Саме про це і полягає автоматичне тестування блоку.

Як молодший програміст, я все ще намагаюся ввійти в звичку писати тести. Очевидно, що здобути нові звички непросто, але, думаючи про те, що могло б зробити цю роботу для мене, я повинен поставити +1 коментарям щодо перегляду коду та програмування коучінга / пари.

Можливо, варто також підкреслити довготермінову мету тестування: забезпечити те, що те, що було зроблено вчора, працює і сьогодні, і на наступному тижні, і в наступному місяці. Я говорю це лише тому, що, проглядаючи відповіді, я не бачив цього.

Роблячи огляди коду (якщо ви вирішили це зробити), переконайтеся, що ваш молодий розробник знає, що справа не в тому, щоб його знищити, а в тому, щоб зробити код кращим. Оскільки таким чином його впевненість менше пошкоджується. І це важливо. З іншого боку, так знаєш, як мало ти знаєш.

Звичайно, я насправді нічого не знаю. Але я сподіваюся, що слова були корисними.

Редагувати: [ Джастін Стандарт ]

Не пригнічуйте себе, те, що ви маєте сказати, дуже добре.

Щодо вашого огляду на коди: ви знайдете, що не лише молодший розробник дізнається в цьому процесі, але і рецензенти. Усі в огляді коду дізнаються, якщо зробити це спільним процесом.

Чесно кажучи, якщо ви того , щоб покласти , що багато зусиль змусити його зробити що - то , то ви , можливо , доведеться змиритися з думкою , що він може просто не бути добре підходить для команди, і , можливо , доведеться піти. Тепер це не обов'язково означає звільнення його ... це може означати, що знайти десь інше в компанії, його навички більше підходять. Але якщо більше немає місця ... ти знаєш, що робити.

Я припускаю, що він також є досить новим наймом (<1 рік) і, мабуть, нещодавно поза школою ... в такому випадку він може не звикнути, як все працює в корпоративних умовах. Такі речі, як більшість із нас могли б уникнути в коледжі.

Якщо це так, я знайшов одну з речей, щоб провести щось на зразок "несподіваного нового огляду на прокат". Не має значення, якщо ви ніколи цього не робили раніше, він цього не знатиме. Просто сідайте його і скажіть йому, що збираєтеся перейти його виступ і покажіть йому справжні цифри ... візьміть звичайний аркуш огляду (у вас офіційний процес огляду?) Та змініть заголовок, якщо хочете, щоб він виглядав офіційний і покажіть йому, де він стоїть. Якщо ви покажете йому в дуже офіційній обстановці, що не робити тестів негативно впливає на його рейтинг, а не просто «натягувати» на це, він, сподіваємось, отримає бал. Ви повинні показати йому, що його дії насправді вплинуть на нього, будь то мудро чи платно.

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

Як молодший програміст, я думав, що я виявляю, як це було, коли опинився в подібній ситуації з вашим молодшим розробником.

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

Мені пощастило бути під наглядом доброго і дуже терплячого старшого програміста. На щастя для мене, він вирішив сісти зі мною і провести 1-2 тижні, переглядаючи мій дуже зламаний кодовий код. Він пояснив би, куди я пішов не так, тонкіші пункти с і покажчики (хлопець це мене бентежить!). Нам вдалося написати досить пристойний клас / модуль приблизно за тиждень. Все, що я можу сказати, це те, що якби старший розробник не вклав би час, щоб допомогти мені на правильному шляху, я, мабуть, не тривав би дуже довго.

На щастя, я сподіваюся, що два роки я сподіваюся, що хтось із моїх колег навіть може вважати мене середнім програмістом.

Візьміть домашні очки

1. Більшість університетів дуже погано готують студентів до реального світу
2. Парове програмування мені дуже допомогло. Це не сказати, що це допоможе всім, але це працювало на мене.

Призначте їх проектам, які не потребують "стабільного коду вищої якості", якщо це стосується вас, і нехай jr. невдача розробника. Нехай вони будуть "прийти на вихідні", щоб виправити свої помилки. Пообідайте багато і поговоріть про практику розробки програмного забезпечення (не лекції, а дискусії). З часом вони набудуть і виробитимуть найкращі практики для виконання покладених на них завдань.

Хто знає, вони можуть навіть придумати щось краще, ніж методи, якими зараз користується ваша команда.

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

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

Зрештою, навіть при всій вашій допомозі, заохоченні та наставництві він може не бути придатним для вашої команди, тому відпустіть його та шукайте когось, хто це отримає.

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

Я не знаю, чи потрібно вам блокувати такі коміти. На моєму робочому місці кожен має безкоштовне зобов’язання з усім, і всі повідомлення SVN (з різними ознаками) надсилаються команді.

Примітка: ви дійсно хочете, щоб громовідвід відрізнявся кольором, якщо ви плануєте це робити.

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

Ви можете допомогти спонукати людей вникати в це, періодично вимовляючи такі речі, як "Ей, Боб, ти бачив, що я вчинив сьогодні вранці, я знайшов цей акуратний трюк, де ти можеш робити бла-ха, що завгодно, прочитати фіксацію та побачити" як це працює!"

NB: У нас є 2 «старших» і 3 молодших. Це може не масштабуватись, або, можливо, вам доведеться трохи відрегулювати процес з іншими розробниками.

1. Зробіть покриття кодом частиною оглядів.
2. Зробіть «написання тесту, який викриває помилку» необхідною умовою для виправлення помилки.
3. Потрібен певний рівень покриття, перш ніж код можна буде перевірити.
4. Знайдіть хорошу книгу про тестові розробки та використовуйте її, щоб показати, як тест-перший може пришвидшити розвиток.

Багато психології та корисних методик «наставництва», але, чесно кажучи, це просто зводиться до «написання тестів, якщо ти хочеш все-таки завтра працювати».

Ви можете куштувати його в будь-які умови, які ви вважаєте підходящими, суворими або м'якими, це не має значення. Але факт полягає в тому, що програмісти не платять, аби просто зібрати код і перевірити його - їм платять, щоб обережно скласти код, потім скласти тести, потім протестувати свій код, А потім перевірити все це. ось як це звучить, з вашого опису.)

Отже, якщо хтось збирається відмовитись виконувати свою роботу, поясніть їм, що завтра вони можуть залишитися вдома, і ви наймете того, хто БУДЕ виконувати цю роботу.

Знову ж таки, ви можете робити все це обережно, якщо вважаєте, що це необхідно, але багатьом людям просто потрібен великий жорсткий ляпас Life In The Real World , і ви зробите їм послугу, віддавши їх їм.

Удачі.

На деякий час змініть його посадову інструкцію, щоб виключно писати тести та підтримувати тести. Я чув, що багато компаній роблять це для нових нових недосвідчених людей деякий час, коли вони починають.

Крім того, створіть виклик, поки він перебуває в цій ролі: Напишіть тести, які: а) не спрацюють з поточним кодом: а) виконують вимоги програмного забезпечення. Сподіваємось, це змусить його створити ґрунтовні та ретельні тести (вдосконалюючи проект) та покращить його в написанні тестів, коли він знову інтегрується в основну розробку.

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

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

• Приділіть трохи часу та поділіться методами тестування, наприклад, введенням залежності, пошуком кращих випадків тощо з вашим колегою.
• Пропонуйте відповісти на запитання про тестування.
• Продовжуйте кодові огляди тестів. Попросіть колегу переглянути ваші зміни, які є зразком хорошого тестування. Погляньте на їх коментарі, щоб побачити, чи справді вони читають і розуміють ваш тестовий код.
• Якщо є книги, які особливо добре відповідають філософії тестування вашої команди, дайте йому копію. Це може допомогти, якщо відгуки чи дискусії про ваш код переглянуть посилання на книгу, щоб він чи вона мала нитку взяти та слідкувати.

Я б особливо не підкреслював фактор сорому / провини. Варто зазначити, що тестування є загальноприйнятою, доброю практикою та написання та підтримка хороших тестів є професійною ввічливістю, тому товаришам по команді не потрібно проводити свої вихідні на роботі, але я не ставлюся до цього.

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

Його Наставник зобов'язаний навчити його / її. Наскільки добре ви вчите його / її ЯК тестувати. Ви паруєте програмування з ним? Молодший, швидше за все, не знає, ЯК створити хороший тест на xyz.

Будучи молодшою ​​школою, він знає багато понять. Якась техніка. Певний досвід. Але врешті-решт, всі юніори - ПОТЕНЦІАЛЬНІ. Практично в кожній функції, над якою вони працюють, з’явиться щось нове, чого вони ще ніколи не робили. Впевнений, що Молодший, можливо, зробив просту державну схему для проекту в класі, відкриваючи та зачиняючи «двері», але ніколи не застосовуючи ці шаблони в реальному світі.

Він / вона буде лише настільки ж хорошим, наскільки добре ви навчаєте. Якби вони змогли "Просто дістати", ти вважаєш, що вони зайняли б в першу чергу посаду Юніора?

З мого досвіду, юніори приймають на роботу і несуть майже таку ж відповідальність, як старші, але їм платять менше, а потім ігнорують, коли вони починають плакати. Пробач, якщо мені здається гіркотою, це тому, що я є.

@ jsmorris

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

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

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

"Тож ваша відмова тоді?"

У вашому вихідному сховищі: використовуйте гачки перед кожним вчиненням (наприклад, попередньо здійснити гак для SVN)

У цьому гачку перевірте наявність принаймні одного випадку використання для кожного методу. Скористайтеся умовою для організації тестових підрозділів, яку ви можете легко застосувати за допомогою гачка попереднього введення.

На сервері інтеграції компілюйте все і регулярно перевіряйте покриття тесту за допомогою інструменту тестового покриття. Якщо покриття тесту не становить 100% для коду, блокуйте будь-які коміти розробника. Він повинен надіслати вам тестовий випадок, який охоплює 100% коду.

Тільки автоматичні перевірки можуть добре масштабувати проект. Ви не можете перевірити все вручну.

Розробник повинен мати можливість перевірити, чи охоплює його тестовий випадок 100% коду. Таким чином, якщо він не робить 100% перевірений код, це його власна вина, а не помилка "ой, вибачте, що забув".

Пам’ятайте: люди ніколи не роблять того, чого ви очікуєте, вони завжди роблять те, що ви перевіряєте.

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

Якщо ваша організація досить велика, щоб мати понад 6 розробників, я настійно рекомендую створити відділ забезпечення якості (навіть якщо це лише одна людина для початку). В ідеалі ви повинні мати співвідношення 1 тестер до 3-5 розробників. Річ у програмістах - це вони програмісти, а не тестери. Я ще не мав інтерв'ю з програмістом, якого формально навчали правильним методикам якості.

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

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

У вашому випадку, якщо ви можете дозволити собі перенаправлені робочі зусилля, зробіть цього нового хлопця першим членом вашої команди QA. Запропонуйте йому прочитати "Тестування програмного забезпечення в реальному світі: вдосконалення процесу", оскільки він, очевидно, потребуватиме певної підготовки у своїй новій ролі. Якщо йому це не сподобається, він відмовиться, і ваша проблема все одно вирішена.

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

Побічна примітка: Врешті-решт, вам потрібно, щоб команда з контролю якості звітувала з керівником із контролю якості, або, принаймні, не менеджером з розробників програмного забезпечення, тому що мати звітність команди QA перед менеджером, головна мета якого - зробити продукт - це конфлікт відсотки.

Якщо ваша організація менше 6, або ви не можете піти зі створення нової команди, рекомендую парне програмування (PP). Я не є тотальним перетворенням всіх екстремальних методів програмування, але я безумовно вірую в парне програмування. Однак обидва члени команди програмованого програмування повинні бути відданими, або це просто не працює. Вони повинні дотримуватися двох правил: інспектор повинен повністю зрозуміти, що кодується на екрані, або він повинен попросити кодер пояснити це; кодер може кодувати лише те, що він може пояснити - жодне "ви побачите" чи "повірте мені", або махання рукою не буде допущено.

Я рекомендую ПП лише в тому випадку, якщо ваша команда на це здатна, тому що, як і тестування, жодна радість чи загроза не переконує пару наповнених егою інтровертів працювати разом, якщо їм це не комфортно робити. Однак я вважаю, що між вибором написання детальних функціональних характеристик та переглядом коду проти парного програмування ПП зазвичай виграє.

Якщо ПП не для вас, то TDD - це найкраща ставка, але тільки якщо вона сприймається буквально. Тестова розробка означає, що ви пишете тести ПЕРШИЙ, запускаєте тести, щоб довести, що вони насправді не спрацьовують, а потім пишете найпростіший код, щоб він працював. Зараз у вас є (ви) маєте колекцію тисяч тестів, що також є кодом, і це так само ймовірно, як і виробничий код, що містить помилки. Чесно кажу, я не є великим прихильником TDD, головним чином, саме з цієї причини, але це працює для багатьох розробників, які скоріше писатимуть тестові сценарії, ніж документи тестових справ - деякі тестування краще, ніж жодні. З'єднайте TDD з PP для кращої ймовірності тестового покриття та меншої кількості помилок у сценарії.

Якщо все інше не вдасться, попросіть програмістів еквівалентності банальної лайки - кожен раз, коли програміст порушує збірку, вони повинні класти $ 20, 50, 100 доларів (що б то не було помітно болісно для вашого персоналу) у банку, яка йде до вашої улюбленої ( зареєстровано!) благодійність. Поки вони не заплатять, уникайте їх :)

Усі жарти вбік, найкращий спосіб змусити програміста писати тести - не дозволяйте йому програмувати. Якщо ви хочете програміста, найміть програміста - Якщо ви хочете тестів, найміть тестера. Я починав як молодший програміст 12 років тому, роблячи тестування, і це перетворилося на мою кар’єрну дорогу, і я ні на що не торгував. Міцний відділ якості, який належним чином підтримує та надає повноваження та мандат на вдосконалення програмного забезпечення, настільки ж цінний, як розробники, які пишуть програмне забезпечення в першу чергу.

Це може бути трохи бездушним, але те, як ви описуєте ситуацію, звучить так, що вам потрібно звільнити цього хлопця. Або, принаймні, уточнити: відмова від дотримання правил забудови будинку (включаючи написання тестів) та перевірка баггі-коду, який повинні прибирати інші люди, з часом вас звільнять.

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

На мій досвід, найкращий спосіб звикнути молодших професіоналів - це зробити це явно частиною процесу. Тобто, під час оцінки часу, який повинна тривати ітерація, час цієї конструкції, запису та / або виконання справ повинен бути включений до цієї оцінки часу.

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

Виходячи з вашого коментаря, "Показавши, що дизайн стає простішим", я припускаю, що ви, хлопці, практикуєте TDD. Робити перевірку коду після факту не вийде. Вся справа в TDD полягає в тому, що це дизайн, а не філософія тестування. Якщо він не написав тести як частину дизайну, ви не отримаєте великої користі від написання тестів після факту, особливо від молодшого розробника. Він пропустить безліч кутових справ, і його код все одно буде шаленим.

Ваша найкраща ставка - мати дуже терплячого старшого розробника, щоб сидіти з ним і робити якесь парне програмування. І просто тримайтеся на цьому, поки він не дізнається. Або не вчиться, і в цьому випадку вам потрібно перекласти його на завдання, яке йому краще підходить, тому що ви просто розчаруєте справжніх розробників.

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