у нас есть один молодой программист, который суперски программит, нообсалютно не хочет подчинятся процессу разработки ПО :)
Ставит версии багов на абум, статусы захочет поставит fixed, захочет won't fix, причём комменты тоже никак не относятся к тому что он сделал и к статусу. Его баги тестить это как крассворды разгадывать.
Начинаеш ему что то втирать он весь краснеет и начинает арать что это не его fault, как будто вообще его кто то обвиняет, просто просят делать как все в будущем. Я боюсь на него наежать так как ещё сматается в другую компанию а менеджер меня потом прибьёт. Но уже задрало. Что с ним делать?

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

Ты должна не ему "втирать", а менеджеру. Это ж не программист, а хакер.

и как показывает практика, такие программисты как правило производят ужасный код, несмотря на свою крутость

Что с ним делать?
------
А ничего с ним не делать.
Есть изменение статуса бага - надо тестить. Т.е. нормальным образом получать квоту времени на выполнение работы по тестированию (перетестированию) и эту работу делать.
Репорт об состоянии - обратно.
Остальным будет заниматься менеджер.
Начинаеш ему что то втирать ...
начинает арать что это не его fault
-----
Ну и не втирай. Результаты теста в репорт и забыть. Для втирания есть менеджер.
Его баги тестить это как крассворды разгадывать.
------
А причем здесь "его баги"? Тестируется то что и как должно работать. Т.е. - на соответствие тех.заданию. Кто и как писал код - знать при этом вредно, об коментах в баг-репорте - подавно.
Но уже задрало.
-----
Бракуй код по-чаще. По любому несоответствию заданию.

Интересно, в чем крутость заключается ;)

забыл кавычки поставить :-)
иногда бывает, что человек быстро выдает на гора работающий код, но если туда заглянуть, то очень часто это какие-то неподдерживаемые спагетти, слепленные кое-как, чтобы работало. такой код очень тяжело сопровождать, и часто бывает быстрее выкинуть и написать в модульном стиле...
P.S. 2Kislosladkaya: у этого "программиста" поди еще и unit-тестов нету?

Да, мне это знакомо.
зы У нас тестов тоже почти нет, потому что легаси. Черт бы его побрал.

иногда бывает
------
Не иногда - часто или даже - обычно. Тяжко принуждать творить в рамках...
Самое печальное, что после этого находится время на то, чтобы пофиксить всплывающие баги, но нет времени переписать код... При этом суммарные затраты на фиксинг этого спагетти раз пять выше затрат на нормальное написание...
у этого "программиста" поди еще и unit-тестов нету?
------
А разве они у него должны быть? Как Я понимаю - чем отдельнее - т.е. в идеале только ТЗ - трудится тестер, тем все лучше получается... УТ как раз задача тестера...

не путай юнит тесты, с другими видами тестирования. юнит-тесты - задача программиста, задача тестера - smoke tests, integration tests и т.д.

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

юнит-тесты - задача программиста
-----
Спорно.
Базовое тестирование - типа выявить неправильно написанную переменную в копи-пащенном коде проперти - это, да чисто программерское.
А вот выяснить, что есть какой-нибудь хитрый сбой, зависимый от данных или контекста - уже не его. Мало того - тут их желательно полностью разделить.
Хотя оба теста могут базироваться на УТ - только писать их должны разные люди.

никак не спорно. читай http://en.wikipedia.org/wiki/Software_testing#Testing_Levels и http://en.wikipedia.org/wiki/Unit_testing
тестировщики обычно не имеют доступа к исходному коду, да и в первую очередь юнит-тесты предназначены для контроля базовой функциональности, базовых функций и т.д. Вот Integration testing - это уже смешанная работа

тестировщики обычно не имеют доступа к исходному коду
-----
Я и говорю - желательно разделять.
да и в первую очередь юнит-тесты предназначены для контроля базовой функциональности, базовых функций и т.д.
------
Или у меня задачи более-мение нестандартные, или организация работ хромает - этого уровень тестирования лежит на мне, но без разработки специальных тестов. Знаю, что есть NUnit, но необходимость писать тесты съедает время, которое с большей результативностью тратится на отладку следующего уровня.
Не факт, что это правильно, но для меня - так. Вероятно сказывается работа на чистом Си с разнесением переменных по модулям - опыт достаточного внимания к деталям.
Вот Integration testing - это уже смешанная работа
-----
С этого и начинается. Только, опять таки, программист этим заниматься не должен. Спецификация и вперед тестер - готовься к приему черного ящика. Оттестить, внятным языком разъяснить что не работает и на следующий круг...

Видимо, в их с(т)ране этому не учили ;)

Если писать хеловорлды то да.
Или ты пишешь безбажный код ?

Или ты пишешь безбажный код ?
------
Разумеется нет. НО! Если я для того кода, над которым Я работаю, я буду писать тесты количество работы над тестами превысит количество работы над багами в нормальной отладке. Есть, разумеется, сопровождение, но опять таки - затраты на сопровождение кода и актуализацию тестов будут больше, чем модификация и отладка имеющегося кода.

по моему опыту, наличие юнит-тестов на основные вещи, резко снижает необходимость в дальнейшей отладке - ты определяешь баги раньше, чем они будут воздействовать на другие подсистемы. И это не только мое наблюдение - почитай книги по управлению процессами разработки, во всех написано, что обнаружение бага должно происходить как можно ближе к процессу когда баг был внесен, иначе затраты возрастают многократно. Юнит-тесты - идеальный инструмент для этого
P.S. у нас в багзилле есть отдельные поля - где баг был внесен, и где он был обнаружен. на основании этой информации затем делаются выводы о необходимости улучшения процесса разработки
P.P.S. про себя могу сказать, что у меня покрытие кода тестами на уровне 80% (не покрыты в основном участки типа Bla-Bla *a = new bla-bla; if (!a) {report error}. И это играет мне на руку - в предверии релиза на мне не висит ни одной баги, в отличии от разработчиков, которые тесты не используют - у них по 30-40 багов на человека

На уровне code review это у вас не прописано?

ты определяешь баги раньше, чем
-----
Ты не покажешь образец своего кода и соответствующие тесты? Желательно,
не самые тривиальные.
Вот моя ситуация с багами на последнем месте работы.
Происходит миграция с версии на версию. В результате миграции система
должна производить тот выход, что и в первой версии.
Одна из новинок - динамическое отслеживание навигации по объектам.
В первой версии (база) - отсутствовала, (таблица) - константа, (поле) - поле.
Т.е. пишем:
1) база.таблица1.поле
2) база.таблица2.поле
и имеем в свойствах поля именно то, что определено для конкретного
поля. Наборы свойств для 1) и 2) разные и частично определяют выход.
Система в целом - работает - т.е. нет необработанных прерываний
и процесс доходит до завершения.
Выход - тоже генерируется. По большей части - правильно. Но время
от времени - неправильно. Когда происходит сбой - непонятно - одни
и те же исходные данные приводят к обоим - правильному и неправильному
результатам.
Если брать тер. базис, то выход определяется перемножением двух языков
(читай - двух бесконечостей). Собственно, миграция на новую версию и
была процессом введения второго языка. Грамматики обоих языков определены
не полностью. Доопределить - не удается принципиально - система "открытая"
для языков.
Багов в системе было несколько - от архитектурных - не различались идентификаторы
объектов - в первой версии с этой проблемы не было вообще и задача различения
не ставилась, до неправильно определения контекста... но как-то с этим справился.
Написать полные тесты для подобной системы элементарно невозможно - пара
бесконечностей мешает.
Частичные - не выявляют всех проблем.
По-элементные или юнит тесты - не дают никаких ошибок - все элементы
отрабатывают как планировалось.
Я не говорю, что тесты - лишнее. Просто не всегда и не везде затраты на написание
тестов будут релевантны.
во всех написано, что обнаружение бага должно происходить как можно ближе
к процессу когда баг был внесен, иначе затраты возрастают многократно.
-----
Так это все понятно. Чем быстрее быстрее обнаружишь где спорол фигню, тем
меньше править. Мелкомягкие, правда, привыкли объявлять баги фичами, но это
не мое...

Это что, аффтар топика в IT работает? Какой ужас! :))

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

кстати, у мелгомягких очень хорошие книги по тестированию софта - посмотри на серию best practices

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

посмотри на серию best practices
-----
Если руки дойдут.
Для меня сейчас критичнее освоить .Net 4.0 и кучу его новых фич.
Плюс SharePoint...
Плюс SISC...
Плюс...
А не послать ли мне все это нафиг и не уехать ли к теплому морю?

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

большинство языков программирования имеют тесты
-----
И что они тестируют? Не написал ли прогер глупости? Это - да, это тесты...
Только Я говорил не об этом, а об определении языка и подготовке к его
обработке. Разница в том, что там нужно доказывать что язык определен
корректно - тесты не дадут результата по определению...
значит не только
------
Это тебя немного не туда занесло. Бо, если язык рекурсивный, то все
возможные сентенции определить и протестировать невозможно.
Это базис. ТФЛ.
Ну а не рекурсивные и есть весьма ограниченные. Т.е. какой-нибудь
пасивный ини-файл можно парсить без проблем, но для ХМЛного с
перекрестными ссылками уже придется думать. Запихни в тот же ХМЛ
еще какую-нибудь логику, дающую инфинитивность вариаций, и все
станет на места.

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

все покрыто тестами на 95 процентов
-----
Ну не знаю. При такой задаче Я бы больше занимался поиском обоснований
работоспособности, чем тестами. Бо, затраты на них отличаются более чем
два порядка... и нет гарантий что все тип-топ.
...и все работает как надо в промышленной эксплуатации. Если конечно...
-----
Примерно так же было при разработке Алгола. Группа разработчиков допустила
неоднозначность в определении языка... а так - все работало... пока не случалось
споткнуться об эту неоднозначность.
Работает - хорошо. Юзер знает ограничения - хорошо. Но на этом уровне стоит
доказывать, что там действительно все хорошо. Тесты этого не дают.

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

А что такого? Не она же кодит ;)

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

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

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

сложный код к сожалению весь под NDA

- как всегда. А простой - не покажет преимуществ.

Синтетический пример на основе, нельзя изобрзить?

где время взять для синтетических примеров? да и их полно в книжках по тестированию...

Только не говори, что ты никогда не писал юнит-тестов.