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

+1

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

EM>От этой беды есть 2 пути. Порочный — наращивать количество тестеров чтобы превратить 2 недели в пару дней (в приделе это приведет к дебилизму из серии 1 тестер — 1 дев). И непорочный — писать acceptance и по-модульные функциональные тесты. При правильном подходе после этого в системе останутся только интеграционные ошибки. И количество необходимых тестеров снизится до соотношения 1-10.

Свежо предание...

Самый главный источник багов при наличии более или менее адекватного тестирования — интеропы и редко возникающие хитро пограничные случаи (т.е. условия воспроизведения бага — 5 фраз, соединенных оператором AND).

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

К счастью, именно эти баги имеют обычно низкий приоритет из-за небольших значений метрик reproduceability и affected users.

EM>Вопрос терминологии. Я под "тестером" имел в виду ручного тестера.

Написание тест-сьютов, не требующих знания кода продукта и тестирующих продукт как более или менее целое — тоже работа тестера, а не девелопера.

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

K>а капитан футбольной команды должен хоть когда-нибудь играть в футбол

Совершенно верно. Тимлид — играющий тренер.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Самый главный источник багов при наличии более или менее адекватного тестирования — интеропы и редко возникающие хитро пограничные случаи (т.е. условия воспроизведения бага — 5 фраз, соединенных оператором AND).

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

Согласен. Наш единственный ручной тестер в команде из ~10 пишущих человек примерно этим и занимается. И его вполне хватает. Потому что решена проблема того, что состояние системы определено только во время между окончанием тестирования и внесением первого фикса в билд. Состояние зафиксировано тестами. ОК, пусть на 80-90 % а не на 100, "все равно хорошо" (С).

К слову, если тут кто есть из МС и Гугла, просветите : Много ли у вас тестируют руками ? Я вот думаю что нет.

MSS>К счастью, именно эти баги имеют обычно низкий приоритет из-за небольших значений метрик reproduceability и affected users.
+1

C>Эти две векти работают в параллель. Так, программерская ветка может строчить 1.0, а аналитика уже фигачит требования к 3.0 версии, а архитектор корпеет над 2.0

Плохо.

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

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

В девелопменте при этом да, может быть и 1.0.

Здравствуйте, craft-brother, Вы писали:

CB>(с) RUP, Wikipedia и другие источники.

CB>Вольный пересказ.

В общем, спасибо.
Действительно, мне надо было сначала в WiKi заглянуть.

EM>Согласен. Наш единственный ручной тестер в команде из ~10 пишущих человек примерно этим и занимается. И его вполне хватает. Потому что решена проблема того, что состояние системы определено только во время между окончанием тестирования и внесением первого фикса в билд. Состояние зафиксировано тестами. ОК, пусть на 80-90 % а не на 100, "все равно хорошо" (С).

Я думаю, что 100% охват тестами каждого публичного билда — утопия. Тестировать там ИМХО надо только то, на что могло повлиять последнее изменение, и что изменение правильно работает, и что не сломано ранее работавшее.

Собственно, микрософт именно так тестирует _хотфиксы_ на WU. Вот сервис-паки и релизы ОС тестируются уже намного более тщательно, с фазами binary freeze.

Типичное распределение трудозатрат по процессам в коммерчекой разработке ПО:

– 10% Управление
– 10% Конфигурирование
– 10% Управление требованиями
– 15% Проектирование
– 25% Разработка
– 25% Тестирование
– 5% Документирование

Итого: 100%

Где-то, так.

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

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

График выхода версий тебе тоже не сверху спускается, а создается по ходу тех же процессов. Людям на самом деле нужны не версии, а фичи . Сравнительные приоритеты разных фич при этом могут меняться динамически по воле заказчика, значит — меняется объем понятия "версия 2.0" (какие-то фичи вынесли в 3.0), а значит — и графики.

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

CB>Типичное распределение трудозатрат по процессам в коммерчекой разработке ПО:

CB>– 10% Управление
CB>– 10% Конфигурирование
CB>– 10% Управление требованиями
CB>– 15% Проектирование
CB>– 25% Разработка
CB>– 25% Тестирование
CB>– 5% Документирование

CB>Итого: 100%

CB>Где-то, так.

Ага, только вот не ясно, что такое конфигурирование, а еще нет в этой схеме _саппорта_, что делает ее всю детсадовской игрушкой. Саппорт состоявшегося продукта — процентов 60 усилий, саппорт-инженеров и девелоперов в сумме.

Собственно, процентов 50 объема работ к следующему майлстону — это support issues, и баги, и мелкие доработки по просьбам клиентов, которые не пришли в голову на этапе анализа требований.

Это еще хороший анализ требований. При плохом будут не мелкие доработки, а крупные переделки.

И даже без саппорта схема неверна. Если брать просто по часам и людям (чтобы оценить сроки и потребности в персонале), то разработка раз в 20-50 больше проектирования. Проектирует 1 архитектор 1 месяц, разрабатывают потом 10 девелоперов 2-5 месяцев. Это нормально.

Здравствуйте, Maxim S. Shatskih, Вы писали:


MSS>Ага, только вот не ясно, что такое конфигурирование, а еще нет в этой схеме _саппорта_, что делает ее всю детсадовской игрушкой. Саппорт состоявшегося продукта — процентов 60 усилий, саппорт-инженеров и девелоперов в сумме.

MSS>Собственно, процентов 50 объема работ к следующему майлстону — это support issues, и баги, и мелкие доработки по просьбам клиентов, которые не пришли в голову на этапе анализа требований.

MSS>Это еще хороший анализ требований. При плохом будут не мелкие доработки, а крупные переделки.

Максим, а почему ты решил, что сапорт предыдущего релиза или продукта входит в новый проект? Сапорт, имхо, устранение багов в работающем у клиентов релизе в соответствие с SLA. Это операционная деятельность, которую не следует относить к проекту. Если участники проекта в этой деятельности задействованы, то надо соответствующим образом раскладывать их рабочие часы, например, 60% — на проект, 30% — на сапорт, 10% — на проч. административную деятельность. Если речь идет о реализации в новом релизе фич, которые затребовали заказчики, то это не сапорт а R&D.


MSS>И даже без саппорта схема неверна. Если брать просто по часам и людям (чтобы оценить сроки и потребности в персонале), то разработка раз в 20-50 больше проектирования. Проектирует 1 архитектор 1 месяц, разрабатывают потом 10 девелоперов 2-5 месяцев. Это нормально.

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

В принципе, видел проекты без архитектуры: порезали продукт на фичи и давай параллельно кодировать, — результат большой (в 2-5 раз больше, чем возможно при правильном проектировании) и проблемный код, поддержка которого действительно может съесть все время команды, а не только 60%.

MV5>Ну с девелоперами вроде более менее понятно (хотя как человек узнает что он уже не Developer а Senior Developer? В трудовой разряд другой напишут? )

В трудовой напишут "старший прграммист"/"программист"/"ведущий программист"/"руководитель проекта"
Да и должности в трудовой коррелируют более со штатным расписанием, нежели с проектной ролью.
Тимлидер/архитектор/ПМ — это все же проектная роль (на одном проекте ты ТЛ, на другом ПМ, на третьем — просто дев, вполне нормально), а в трудовой книжке записывается твоя должность, которая, скорее всего, будет что-т вроде "Инженер по разработке ПО". Для перевода на другую должность нужен соответствующий приказ, доп. соглашение к трудовому договору . Поэтому если человека просто назначили на проект тимлидом или архитектором, это вовсе не значит, что произойдут какие-то изменения в трудовой книжке.

MV5>Так все-таки чего ожидать когда в вакансиях пишут "тимлид" и "архитектор"? И что будут ожидать от меня когда я напишу в резюме "тимлид" или "архитектор"?

Спрашивать будут больше и жестче. А берут всех изначально все равно на девелоперов, а там уж — как вырастешь.

Здравствуйте, MV5, Вы писали:

Всем спасибо за ответы.

PS
Может что-нибудь (я имею ввиду книги) посоветуете почитать по организации разработки ПО, RUP?
Я конечно сам могу поискать, но совет все равно будет лучше.

Здравствуйте, MV5, Вы писали:

MV5>Может что-нибудь (я имею ввиду книги) посоветуете почитать по организации разработки ПО, RUP?

Rational Unified Process – это легко, Пер Кролл, Филипп Крачтен

Здравствуйте, Maxim S. Shatskih, Вы писали:

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

MSS>+1

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

Позволю себе не согласиться: в идеале юнит-тесты нужны везде. А не в идеале — нужно 40%-80% покрытие юнит-тестами, иначе проект довольно быстро (по моим наблюдением — через 100 разработчико-дней) перевалит за ту черту, где каждый fix или change request потенциально уменьшает стабильность проекта.

MSS>Я думаю, что 100% охват тестами каждого публичного билда — утопия. Тестировать там ИМХО надо только то, на что могло повлиять последнее изменение, и что изменение правильно работает, и что не сломано ранее работавшее.

Ыыы... Проблема в том, что очень уж трудно локализовать ВСЕ то, на что могло повлиять изменение. Особенно если взаимозависимость патча и других кусков кода какая-нить западлистая и неочевидная.