Сообщений в теме: 25

[APC]

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

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

[Case]

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

Если говорить согласно принятой практике в РУП-е например то Билд выглядит примерно так:

Artifact: Build
A build is an operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product. A build comprises one or more implementation elements (often executable), each constructed from other elements, usually by a process of compilation and linking of source code.

Role:  Integrator (<-- самое интересное это к какому процессу относится эта роль)

Если идти по иерархии процессов SD которую предлагает РУП, то получится примерно так:

Implementation > Integrate the System > Build

То есть активность в результате которой порождается Билд относится к процессу Имплеменатции, то есть Разработки, а не Тестирования.

[culver]

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

[Case]

То есть если вы тестируете систему сборки :)

[APC]

Case,
не понял... Тестируем не систему сборки... Тестируется вполне конкретный бизнес-софт... Версии которого и собираются...

хотя! Чуть позже я понял твою тонкую шутку, Case! :P
Полностью поддерживаю! Учитывая, что работа идет на продуктах Майкрософт ;)

[ElenaF]

А мне кажется, что разработчики не должны заниматься сборкой. Нет у меня доверия к тому, что они соберут. Вот...
Отвечать за сборку, на мой взгляд, должен либо выделенный человек, либо человек из QA, ну либо из тестировщиков.
И обязательно этот процесс должен быть автоматизирован. Хотя бы на cmd-файлах.
Лично мне понравился продукт VisualBuild.

[culver]

А мне кажется, что разработчики не должны заниматься сборкой. Нет у меня доверия к тому, что они соберут. Вот...
Отвечать за сборку, на мой взгляд, должен либо выделенный человек, либо человек из QA, ну либо из тестировщиков.

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

[Mad Cat]

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

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

[Dimon]

Artifact: Build
Role:  Integrator (<-- самое интересное это к какому процессу относится эта роль)

Этот самый Интегратор и относится к Developers, а не Testers.

[APC]

Сборка в нашем случае - не только компиляция, это компиляция+сборка служебных файлов (XML+XSLT и прочие) и всего этого в единый файл дифференциального обновления ПО.
Проще говоря возможностей автоматизации этого в обозримом будущем не видно. В любом случае человек, делающий сборку, должен ориентироваться, какие служебные и скомпилированные файлы должны обновиться.
Так что вопрос остается тем же - кто же должен такое чудо собирать?
Я понимаю, что я могу и в компиляции в новой для себя среде разобраться, и даже начать там программить... Но вопрос - насколько это будет корректно? И как уже называть мою должность?
Компилятор-сборщикотестировщик?

Вообще как я понимаю по тому же MSF это вообще в конфликт интересов превращается...

[Clauster]

Можно ещё и опрос устроить...

[Clauster]

Собственно, вот http://forums.softwa...66&st=0&p=22772

[samurai_]

Добрый день всем

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

Когда это может быть, например, в случае если поставкой является не готовый продукт, а его исходный код, и конечный пользователь будет сам строить продукт, такая ситуация не очень редка в нашем мире, когда все больше и боьше появляется продуктов с открытым кодом. В этом случае тест состоит в том, чтобы убедится, что билд может быть построен согдасно описанной процедуре (например readme.txt). Тест следует считать прошедшим если билд построился без ошибок и прошло sanity тестирование этого билда.

[Case]

Сборка в нашем случае - не только компиляция, это компиляция+сборка служебных файлов (XML+XSLT и прочие) и всего этого в единый файл дифференциального обновления ПО.

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

Проще говоря возможностей автоматизации этого в обозримом будущем не видно.

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

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

То есть? Вы "руками/глазами" смотрите что обновилось?

[Case]

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

А к тому что соберут тестировщики почему доверия больше? :)

[Case]

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

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

[ElenaF]

На мой взгляд за сборку должен быть назначен отдельный ответственный. Он отвечает за:
1. написание сборочных скриптов,
2. сохранность конфигурации для сборки и ее документированность,
3. за соблюдение единой технологии при сборке разных проектов (например, положение каталогов Temp, Out, Lib в структуре дерева с исходными текстами),
4. за поддержку сборочных скриптов (в случае добавления новых собираемых модулей),
5. за выполнение сборки и инициализацию разбора, в случае, если билд не собрался.

[APC]

Поколупал MSF - в нем построение билдов однозначно повешено на ролевой кластер тестирования. Ну в случае одной версии исходников я еще понимаю...

Case, все выводы из взгляда на реалии, окружающие меня. Такое мнение складывается. Действительно люди смотрят глазами и делают руками там, где давно пора автоматизировать... Но тратить время никто не согласится пока. Я уже закидывал такие удочки, говорят "Да, это было бы неплохо! Но потом... Щас не до этого."
Вот отсюда мой скепсис. До долгосрочных вложений еще не доросли.

[Case]

Поколупал MSF - в нем построение билдов однозначно повешено на ролевой кластер тестирования.

Или у нас MSF разный или одно из двух

Role Cluster: Development

Goal: Build to specification (это цель процесса девелопмента)

Functional Areas:
- Technology Consulting
- Implementation Architecture and
- Design
- Application Development
- Infrastructure Development

Responsibilities:
- Specifies the features of physical design
- Estimates time and effort to complete each feature
- Builds or supervises building of features (!1)
- Prepares product for deployment (!2)
- Provides technology subject matter expertise to the team

Для сравнения, про тестирование и ответственности.
Role Cluster: Test
Responsibilities:
- Ensures all issues are known
- Develops testing strategy and plans
- Conducts testing

Ну в случае одной версии исходников я еще понимаю...

Бр... что значит одна версия исходников? Последняя версия?

PS
Я использовал вот эту версию:
MSF Team Model v. 3.1 - а вы?

[APC]

Я смотрел вот тут, тоже вроде 3.1 версия: http://www.microsoft...m_model_rus.doc
Стр. 29, Ролевой кластер “Тестирование”

Я удивлен такой разницей! Интересно, в чем фишка...

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