|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
Поскольку Управление процессом разработки имеет не только технические аспекты, то хотелось-бы в этом форуме обсудить и организационные моменты. Разберем на конкретных примерах из жизни: Пример 1 Структура отдела - есть: - начальник (и программист и админ и все другие вопросы в одном лице...), - я (программист) Задача - разработать модуль, взаимодействующий с банковской АБС, выполняющий некоторые задачи... Для меня это первый проект такого рода. Проходит время, модуль готов. Спрашиваю - а кто будет тестировать и проверять корректность работы? Ответ можно вкратце сформулировать "тестируй сам". Ок, запускаем в работу... на старте в первую неделею есть мелкие недочеты - исправляю все "на ходу"... Проходит несколько месяцев. модуль работает... и вдруг - бах! Клиент звонит и спрашивает, почему у него со счета ушли неск. миллионов? Оказывается он сформировал платеж, а на следующий день решил его отозвать, и система выдала сообщение, что платеж успешно отозван (все как всегда, тысячи раз это так и работало) Но в главной банковской базе он не отозван !!! Проводим "разбор полетов" и находим что в коде одного из моих триггеров есть условия, которые могут привести к неправильной работе, но найти эту ошибку было очень трудно. Такое стечение обстоятельств, (условий отбора данных) которое приводит к сбою является не очевидным и в жизни мало вероятным , но нашему клиенту "повезло", на нем "сошлись все звезды".. А теперь вопрос. Кто попадал в подобные ситуации ? Как же нужно было выстроить работу, чтобы уменьшить вероятность таких сбоев... Как Вы решаете проблему гипер-отвественного кода, который не имеет права на ошибку, и который неизвестно как можно гарантированно протестировать? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2008, 03:19 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
1. акт здачи-приемки (Acceptance Test Procedure) и правильно составленный договор должен более-менее обезопасить разработчиков 2. многоуровневая процедура тестирования от юнит и функциональных тестов к интегрированному, нагрузочному, и секурити тестированию. В основе успешного процесса тестирования лежит корректный тест дизайн с проработанными кейсами, одобренными заказчиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2008, 04:09 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
Акты, тестирование... все это в теории понятно, но вопрос - как это на практике реализовать ? Кто должен все это продвигать ? Если начальник выстраивает работу минуя все это. В выше приведенном примере все обошлось - клиенту вернули его деньги + небольшой штраф, меня не наказали, но через неск. месяцев я всеравно ушел, т.к. 1 - в принципе не согласен с методами организации процесса работы 2 - нашел ЗП в неск. раз выше. :) Но на новом месте работы по некоторым проектам ситуация очень похожа - супер ответственные модули при практически полном отсутствии тестирования....(то, что было нормальным тестированием не назовешь) вобщем снова ждем, когда грабли опять ударят в лоб... Как мне обьяснить начальсву все это ? Или самому всех построить , но опять-же как ? Снова переходить на другое место не очень хочеся (кризис однако) но и ставить как есть - тоже не правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2008, 16:51 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
Если коротко, то все отвечают, потому что все - в одной лодке. Если длинно, то отвечают: - материально ответственные - материально; если подписались за то, что материально ответственны - Вы в их числе - материально безответственные - репутацией, премией, иногда - работой. Конечно, начальник отвечает за то, что не организовал процесса тестирования, адекватного многомиллионными потерям клиентов, которые происходят вследствие ошибок. Конечно, не ошибается тот, кто ничего не делает. Но в ответе и Вы - за то, что допустили ошибку: что-то не продумали, что-то не сделали. Были бы тестировщики, пропустившие ошибку - отвечали бы и они тоже. У команды разработчиков - т.н. коллективная (бригадная) ответственность. Если бы был налажен процесс тестирования - это могло бы в большей или меньшей степени снизить вероятность ошибки, но никаких гарантий не дало бы. Более того, зачастую при наличии сильных, хорошо организованных тестировщиков, качество кода и скорость разработки падают. Причина этого - в том, что разработчики расслабляются и начинают отдавать в тестирование сборки с ошибками, которые увидели бы, если бы хоть раз попытались их установить и запустить ("... ну нам же некогда, нам нужно новое писать"). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2008, 21:56 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
ART-CODE, 1. то что я написал не теория, а практика применяемая на серьезных проектах 2. вам надо менять не место работы. а функцию. Если хотите все изменить, докажите начальнику, что ему это нужно и что именно вы сможете это сделать ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2008, 23:32 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
В амсердамамх и антверпенах, напрочь засертифицированных по CMMI L5, все конечно же так - и документация и acceptance тесты и т.п. :-). Но в России ситуация не всегда такая, т.к. а) собственно многие бизнес-заказчики "не зрелые" б) разработка часто ведется "на коленках". Заказчик зачастую не осознает, насколько критично для его бизнеса то или иное ПО и какова цена ошибки. Часто у заказчика не хватает квалификации это оценить, а иногда им движет элементарное желание "сделать подешевле". Ведь не секрет, что качество стоит денег. Бывает, что заказчик просто РАССЧИТЫВАЕТ, что разработчик сделает все на совесть (они же программисты -- умные ...), а иногда даже не подозревает, что в ПО могут быть дефекты :-). В маленьких разработческих конторах не всегда встретишь выделенные роли аналитиков и специалистов по качеству. В основном разработчикам приходится быть "единым в N лицах". Руководитель такой конторы сам бывший (или действующий) талантливый разработчик, который делает код "на совесть", без формальных юнит-тестов и тест-кейзов ... просто в уме прикидывая где могут быть косяки). Такой начальник искреннее ищет таких же разработчиков себе в коллектив, и бывает искренне удивлен, когда люди работают, по-его мнению, не очень качественно -- т.е. НЕ ТАК КАК ОН. Отсюда вывод -- "лечить" начальника внедрением практик юнит-тестирования и т.п. достаточно сложно и редко когда успешно. Другой вопрос -- когда вы приходите из более зрелой команды и на ура начинаете наиболее успешный опыт использовать, причем лично ... и это дает реальный положительный эффект (комментарий -- такой эффект продемонстрировать сложно, ведь никто не мерял, скажем, плотность дефектов до внедрения практик и после :-)). Но в любом случае -- коль скоро есть желание "поднять уровень зрелости" вашей команды "с низу" -- придется самому внедрять эти практики, помня при этом, что текущие задачи НИКТО НЕ ОТМЕНЯЛ. А тут уж следует просто прикинуть -- стоит ли овчинка выделки :-), и какие бенефиты в сравнении с костами это принесет, как компании, так и лично вам. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2008, 15:25 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
[quote]В амсердамамх и антверпенах, напрочь засертифицированных по CMMI L5, все конечно же так - и документация и acceptance тесты и т.п. :-). Но в России ситуация не всегда такая, т.к. а) собственно многие бизнес-заказчики "не зрелые" б) разработка часто ведется "на коленках". [/quote] Вообще то обычно наличие выделенного тестировщика очень положительно сказывается на качестве. Почему? Твоя работа написать код без ошибок. Качество работы программиста определяют во многом по этому параметру. Кто проверяет - "а есть ли ошибки"? сам программист. Если есть человек, работа которого "найти как можно больше ошибок", то он их будет находить. Потому что ему тоже нужно показать свою важность и объём своей работы. Если нет выделенного тестировщика, то его роль может выступать сам начальник. Это в любом случае должен быть другой человек, а не писатель. В идеале у него должен быть доступ и к исходному коду системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2008, 10:09 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
Денис Ильин,Кто проверяет - "а есть ли ошибки"? сам программист. Если есть человек, работа которого "найти как можно больше ошибок", то он их будет находить. уточните пожалуйста, а разве задача как раз не найти как можно больше ошибок? А кто их должен находить? Заказчик? А потом открывать дефекты? А контора попадать на бабке и репутацию? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2008, 11:17 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
а программист попадает таки на бабки? ну, если он владелец бизнеса, то да. а регистрация ошибки в базе рекламации приводит к автоматической генерации приказа о лишении премии? если да, то всё в порядке, программисты будут рыть копытом землю, если нет - то тезис не работает, и вам нужен тестировщик :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2008, 15:11 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
Денис Ильин<...>а регистрация ошибки в базе рекламации приводит к автоматической генерации приказа о лишении премии? если да, то всё в порядке, программисты будут рыть копытом землю<...> Мой опыт показывает, что наоборот. Все будут сидеть и бояться тронуть кривой, косой, но хоть как-то работающий код. Искать отговорки, придираться к каждой запятой в требованиях, впадать в скепсис по поводу архитектуры, заламывать нереальные сроки, требовать от других перфекционизма, лишь бы этого не делать. IMHO ошибок не надо бояться. Не ошибается тот, кто бездельничает. Нужно просто быть честным с самим собой, уметь признаваться самому себе в своих недочётах и стараться их не допускать. Нужно считать тестировщиков последней преградой для ошибок. Их, а НЕ клиентов, потому что последствия любой, даже самой пустяковой ошибки, дошедшей до клиентов, просто непредсказуемы. Её могут не заметить, могут обнаружить и обозвать про себя или вслух разработчиков нехорошим словом, но иногда она может стать последней каплей в чаше терпения заказчика, или точкой опоры для персоны, заинтересованной применении продукции конкурентов. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2008, 13:46 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
[quote] Оказывается он сформировал платеж, а на следующий день решил его отозвать, и система выдала сообщение, что платеж успешно отозван (все как всегда, тысячи раз это так и работало) Но в главной банковской базе он не отозван !!![/quote] А такая ситуация допускается вообще исходя из технического задания? То, что ваша программа показала правильное состояние счета, т.е. то что деньги не отозваны, это верно, так и должно быть. Представьте, что клиент отозвал платежь, ему в системе показало, что все ОК а деньги из банка реально ушли - вот это действительно попадание. Так что вас зря наказали, неверно это в описанном вами случае. Why CORBA is DEAD? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2009, 10:19 |
|
А кто отвечает за ошибки ?
|
|||
---|---|---|---|
#18+
Первое, что нужно твердо понять - никакие методологии, никакие приемы тестирования, никакие акты приемки-сдачи не могут застраховать от ошибок. И понять это должны как программисты, так и их начальники и тем более заказчики (здесь обычно несколько сложнее). Но правильно выстроенная методология - как организационная, так и технологическая - поможет уменьшить количество этих ошибок и заранее снизить ущерб от них. Второе - то, что над тестированием нужно задумываться уже на моменте написания ТЗ. Технологических методологий описаны кучи. С организационной точки зрения - тот самый акт приемки или подобный документ заставляет заказчика принять на себя риски использования ПО. Т.е., если ошибка - то не только разработчик виноват, но и заказчик сам проморгал. Nobody faults but mine... (LZ) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2009, 16:46 |
|
|
start [/forum/topic.php?fid=37&msg=35713271&tid=1555593]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 271ms |
total: | 407ms |
0 / 0 |