Visual Studio Team System
#1
Отправлено 03 марта 2006 - 21:44
Кто-нибудь уже использвует этот продукт?
#2
Отправлено 06 марта 2006 - 07:37
Поддерживает ли данный инструмент камстомизацию WorkFlow?
Как у него работает назначение ответственных исполнителей?
Какие группы пользователей он поддерживает, в частности owner и submitter?
Ести ли связи между задачами на уровне parent/child?
Есть ли тригера для автоматического изменения значений, поддерживается скриптование?
Существует ли возможности для использования собственных справочников?
Есть ли связь между требованиями и задачами? ...в разрезе выпускаемых версий?
и т.д. еще есть много вопросов
#3
Отправлено 06 марта 2006 - 15:54
#4
Отправлено 09 марта 2006 - 19:23
Сразу скажу ,что сам Team Studio я еще не трогал ,тока сегодня докачаю с осла дистриб (3.57 ГБ).
Зато я уже неделю использую Team Fondumentation Server(TFS) .Сам он пока не входит в теам сьют.
Сервер представляет собой базу данных различных артефактов. База данных распологаеться на MS SQL 2005 ,так что вам потребуеться поставить еще и его.
Теперь поговорим о том,что вы получаете "в комплекте" с серваком.
Прямо в сервере есть два шаблона :
Microsoft Solutions Framework (MSF) for Agile Software Development
Этот шаблон рекомендуеться для проектов ,которые уже были созданы до установки TFS и вовсю реализовываються ,подробное описания с ролями ,диаграмами и структурой взаимодейтсвия можно скачать с
http://www.microsoft...&displaylang=en
Второй шаблон:
MSF for CMMI® Process Improvement
Этот шаблон рекомендуеться применять для проектов ,которые еще тока планируються или для проектов ,в которых применяеться Agile шаблон
Ссылка на подробное описание:
http://www.microsoft...&displaylang=en
В самом сервере есть оба документа ,так что если вы установите TFS ,то ничего докачивать не нужно. Microsoft предлагает налаживать процесс создания ПО по привиденным выше двум шаблонам.
1) Да ,поддерживает ,все шаблоны имеют XML формат и сайта MS можно бесплатно скачать специальный набор для полной кастаматизации workflow.Поддерживает ли данный инструмент камстомизацию WorkFlow?
Как у него работает назначение ответственных исполнителей?
Какие группы пользователей он поддерживает, в частности owner и submitter?
Ести ли связи между задачами на уровне parent/child?
Есть ли тригера для автоматического изменения значений, поддерживается скриптование?
Существует ли возможности для использования собственных справочников?
Есть ли связь между требованиями и задачами? ...в разрезе выпускаемых версий?
2) Долго расскаывать ,если в двух словах на уровне прав в самом TFS , MS SQL 2005 (!) и SharepointServices(!). На первый взгляд с правами они сильно перемудрили.
3) В TFS нету групп пользователей , вместо них есть роли ,в шаблоне для CMM их более 20
4) Существует возможности отслеживания различных Workitems(это могут быть задачи,баги,требавния,юз кейсы и тп)
5) Еще не касался этой области.
6) Есть возможность добавления любых документов Word,Excel,Project
7) Да есть,см. выше ссылки
Приятные мелочи:
Импортирование базы дефектов из ClearQuest , все работа прямо из IDE, куча интересных и полезных репортов, грамотный(по крайне мере на перый взгляд) workflow стандартных шаблонов,очень хорошая документация.
Продукт оставляют приятное впечатление.
#5
Отправлено 15 марта 2006 - 09:12
Я за прошедшую неделю пришел к выводу ,что TFS продукт не самый плохой ,но багов в Release Candidat`е дофига,стоит хотябы почитать форумы msdn.
Недоработки в интеграции с Ms Project, баги Reporting Services(в один прекрасный момент случаеться одно из двух либо перестают работать все отчеты либо они выдают данные недельной давности ,решение для этого бага описано на форуме самим разработчиками ,но лично у меня ,как и у многих на двух копиях TFS оно не помогло)
Самые прикольные баги ожидают девелоперов при использовнии Source Code Explorer. При некоторых обстоятельсвах система вместо того,чтобы закачать в репозиторий более новую локальную версию файла ,без запроса удаляет её и записывает на её место старую из репозитория. Некоторые девелоперы пишут что "I just hate this product!".
RC вышел 2 февраля ,а релиз обещают в марте. Очень сомневаюсь ,что они доведут продукт до юзабельного состояния,хотя кто знает...
Вообщем тут работает старый добрый принцип ,что не стоит внедрять продукты M$ до выхода первого ,а лучше второго SP.
#6
Отправлено 17 марта 2006 - 13:17
У нас на большинстве проектов ручное тестирование. Управление тестами вообще не сделано как надо! На форумах предлагают решать это фильтрами - при этом фильтров на то, что надо нет!
Такие элементарные вещи, как приассайнить сразу несколько человек на work item не сделаны - может быть приассайнен только один.
Test manager слаб.
Ссылаться в work item на набор тестов невозможно.
Интерфейс учит терпению и развивает силу воли.
Test results в нечитабельном виде - надо много времени потратить что бы разобраться что же там с тестами проделали.
Написание work items нетривиально - пока там все заполнишь.
Да, можно погружатьс в xml и начинать что-то переделывать, но пока что ощущение, что проще искать что-то другое, чем копаться в TFSe
#7
Отправлено 19 марта 2006 - 19:12
Лично я ,когда первый раз увидел принцип работы с Manual Test Cases , то понял ,что с этим там очень плохо. Они сделали лишь бы как-то работало,при этом юзабилити - 0. А что делать когда тест кейсов несколько сотен. А что делать ,когда начинают меняться Requirements и надо найти именно те кейсы ,которые нужно изменить с учетом измененых требований. Нету там возможности создать репорт ,который бы наглядно проказывал как кейсы соответсвуют требованиям. Эту фичу обещают тока в v2. Когда выйдет эта v2 неизвестно.
Да это тоже обсуждалось на msdn`овских форумах. Девелоперы TFS предложили использовать какой-то Summary task ,затем бить его на подзаадачи и на каждому ассйнить. Если я не ошибаюсь этого девелопера вежливо послали доделывать TFS:)Такие элементарные вещи, как приассайнить сразу несколько человек на work item не сделаны - может быть приассайнен только один.
Лично я пришел к выводу,что заполнять встроенные шаблоны неудобно.Написание work items нетривиально - пока там все заполнишь.
#8
Отправлено 19 марта 2006 - 20:09
#9
Отправлено 20 марта 2006 - 12:51
В VSTS есть следующие типы тестов:
Unit test это для девелоперов
Manual test и так понятно ,но реализованно довольно неудобно.
Generic test - это такой тест ,который вызывает внешнюю тестовую программу,написанную ВАМИ. После выполнения эту программа возращает код ,либо тест пройден ,либо провален. В данном случае VSTS берет на себе тяжелую роль.. она должна запустить программу и обработать результат выполнения. Все.
Web test - это можно назвать функциональным тестированием. Однако можно тестировать тока Веб сайты. Работа ведеться тока по HTTP протоколу.
Performance test аналогично предыдущему ,тока тестирование производительности
Все,кажеться ничего не забыл,будут вопросы - задавайте.
#10
Отправлено 21 марта 2006 - 20:30
#11
Отправлено 22 марта 2006 - 11:09
Мы делаем игры. Их куча мелких-мелких, они похожи друг на друга, тестовые наборы по большей части одинаковы. Требования, как правило, распространяются на все существующие игры.
И надо решать: то ли каждую игру делать отдельным team project'ом и + один общий team project собирающий все общие тестовые наборы, документацию и прочее.
То ли делать каждую игру отдельным project в рамках отдного team project.
То ли сделать один проект, а все игры запихать в поле area.
Расскажите, как вы используете поле area и iteration?
#12
Отправлено 24 марта 2006 - 09:21
Я сменил место работы и мы уже как неделю перевели целый проект на TFS.
Впечатления "пока" иссключительно положительные.
Мы написали 11 требований для первой итерации и уже почти всех их реализовали. С помощью Product Requirements querry можно легко посмотреть требования и отследить то ,какие из них уже реализованы ,а какие разрабатываються. Так же очень полезным оказываються репорты. Например , Remaining work.
Скоро начнеться тестирование и появяться первые реальные баги. Я буду следить за тем ,наскока удобно с ними будет работать.
2_IT_
Вам конечно не просто будет с TFS.
По идее можно все запихать в один проект и разные игры это будут разные Area. Приемущество в том,что можно отдельным людям давать свои пермишины на каждый модуль в Area. Таким образом одни разработчики одной игры будут иметь доступ тока в свою Area. При таком подходе есть один недостаток - поле Iteration теряет свою актуальность ,т.к. становиться общим для всех продуктов. Зато игры разрабатываються как правило быстро и в принципе можно забить на разные итерации и работать всегда в одной и той же.
А с требованиями вам лучше всего поступить следующим образом. Написать для одной игры (один модуль в Area) трубования. Затем воспользоваться стандартной функцией и откопировать подходящие требования в другую игру(другой модуль в Area) ,разумееться изменив их с учетом другой игры.
Когда разработчики реализиуют требования ,то они переводят их в состояние Resolved (аналог Ready for Testing). Тестеры тестируют игру в соответствии с требованиями и написанными под каждое требование тестами. Если все тесты для одного требования проходят успешно ,то оно считаеться реализованным и протестированным и переводиться тестером в состояние Closed. Если какой-либо из тестов не проходит ,то оно возвращаеться обратно в состояние Active и на него линкуються созданный\ые баг\и.
#13
Отправлено 28 марта 2006 - 16:47
Кстати-кстати. Требования!Мы написали 11 требований для первой итерации и уже почти всех их реализовали. С помощью Product Requirements querry можно легко посмотреть требования и отследить то ,какие из них уже реализованы ,а какие разрабатываються. Так же очень полезным оказываються репорты. Например , Remaining work.
Хочется узнать как вы их пишете.
1. Одно требование в моем понимании - это конкретное тз: сделать это, вот это и вот это, должно выглядеть так и так, работать так и так. В случае чего - такая-то ошибка. Но как я почитала, что в CMMI-проектах, что в Agile-проектах, предлагается какая-то супер-система, где сначала пишутся scenarios (где по-видимому должно писать то что я называю требованием), потом пишется требование (похоже, одно на весь набор сценариев), потом уже пишутся issues на конкретных людей по каждому сценарию. Я вижу это полным дурдомом, т.к. у нас все требования по определенной функциональности будет делать один человек (т.е не нужно кучи issues) и надо кому-то (project manager'у, похоже) потом эти issues отслеживать и ставить resolved на требовании. Как делаете вы?
2. Есть набор требований - как вы их группируете? В TFSе, как я понимаю, советуют создавать xls файлы, в которые эти требования вводятся и потом published в TFS. Т.е. требования все видны как непосредственно из студии, так и просто в одном файлике. Пользуетесь ли вы екселем при работе с требованиями?
спасибо, попробую поковыряться :-)2_IT_
Вам конечно не просто будет с TFS.
По идее можно все запихать в один проект и разные игры это будут разные Area...
#14
Отправлено 23 мая 2006 - 07:09
Можно ли каким-то образом изменять под себя формы для ввода багов, реквестов и т.п. в TFS? В Rational для СlearQuest есть так называемый СlearQuest Designer, в котором все это можно было делать, а тут ничего не нашла, ни исходный проект формы, ни в MSDN какого-либо упоминания про подобную возможность, а очень хочется ...
#15
Отправлено 23 мая 2006 - 14:51
#16
Отправлено 11 июля 2006 - 09:15
Написание work items нетривиально - пока там все заполнишь.
Да, можно погружатьс в xml и начинать что-то переделывать, но пока что ощущение, что проще искать что-то другое, чем копаться в TFSe
Можно воспользоваться тулом
http://www.imaginets....aspx?tabid=133
#17
Отправлено 22 марта 2008 - 14:05
Я пробовала занести в Visual Studio тест кейсы, чтобы потом вытащить результаты - кто проводил, когда, сколько раз, успешно или нет. Для этого я использовала мануал тесты, но возникла проблема - откуда и как потом вытаскивать эти результаты. Может, кто-нибудь посоветует, каким образом можно использовать Visual Studio для управления тест кейсами?
#18
Отправлено 24 марта 2008 - 09:13
Редактор портала www.it4business.ru
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных