вторник, 31 августа 2010 г. - www.msmirnov.ru

Кто ошибку создает - тот ее и проверяет?

Вчера я произвел некоторые изменения в workflow ошибок в нашем Team Project. Как я уже упоминал ранее здесь шаблон проекта, был создан на основе Agile-шаблона, входящего в стандартную поставку TFS.

В workflow ошибок при закрытии ошибки она автоматически назначалась на ее создателя. Видимо это была реализация правила "Кто ошибку создает - тот ее и проверяет". Этот постулат я помню кто-то настоятельно популяризировал на ЛАФ-2010.

Еще тогда он у меня вызвал сомнения, а сейчас я в полной мере осознал его неудобство.

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

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

P.S. Продолжение темы здесь и здесь.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)
Мой сайт - www.msmirnov.ru

среда, 25 августа 2010 г. - www.msmirnov.ru

Заметки о Яндекс API

У нас, в России, как всегда свой путь.

Все ведущие мировые поисковые системы (Google, MSN, Yahoo, а с недавнего времени даже и Baidu) давно перешли на почти одинаковую структуру PPC Account'ов:



Такая структура очень гибкая, она разрывает непосредственную связь между ключевыми словами и объявлениями, позволяет осуществлять ротацию объявлений и пр.


Яндекс до сих пор сохраняет структуру, напоминающую Overture 2003 года:



Эта структура не обеспечивает какой-либо ротации объявлений и является сильно устаревшей.

В свое время Baidu потребовалось около года, чтобы полностью переработать API и перейти на более развитую структуру.

Странно, почему Яндекс до сих пор не делает этого. Видимо, лидирующее положение на российском рынке позволяет почивать на лаврах :)

P.S. Совершенно убийственной является способ авторизации в Яндекс API. Все нормальные поисковые системы используют логин и пароль и иногда токен. Яндекс же требует для авторизации получать у них сертификат и обновлять его каждый месяц.

P.P.S. Ключевые слова на Яндекс не обладают собственным URL, что делает невозможным связать трафик (регистрации, продажи и вообще любую активность посетителей) с ключевыми словами. У всех есть, а у Яндекса нет.

За державу обидно...
Мой сайт - www.msmirnov.ru

вторник, 24 августа 2010 г. - www.msmirnov.ru

Пояснение к посту "Количество багов в единицу времени"

Некоторое время назад в посте "Количество багов в единицу времени" я опубликовал график количества имеющихся багов за последние 6 лет.



На графике видно, что количество багов никогда не снижается до нуля никогда.

Хотел бы пояснить (как говорится, меня часто спрашивают), это обусловлено тем, что версии продукта идут с наложением по времени.

Т.е. на предыдущем графике не показана принадлежность багов к версии продукта.

Если попытаться ее отобразить, то получиться нечто следующее -

Т.е. видно, что работа над версиями продукта идет с наложением и количество багов, если их рассматривать в привязке в версиям, снижается до нуля.
Мой сайт - www.msmirnov.ru

понедельник, 23 августа 2010 г. - www.msmirnov.ru

Фотографии...

На днях мой фотик Sony Cybershot DSC-R1 сбросил счетчик фотографий, достигнув значения 10 000. Получается что за прошедшие 4 года я делал примерно 7 фотографий в день...
Мой сайт - www.msmirnov.ru

вторник, 3 августа 2010 г. - www.msmirnov.ru

Миграция в TFS (Team Foundation Server)

Итак, вчера я провел миграцию к TFS (Microsoft Team Foundation Server).
Раньше мы использовали SVN для контроля исходного кода, TestTrack Pro для управления багами и тасками, Groove для управления документами, календарями и т.п.

Теперь TFS используется для контроля исходного кода, он же используется для управления задачами и багами. Программисты и тестеры используют Visual Studio для работы с ним, все остальные работают через SharePoint-портал, который был создан для проекта. Особой разницы в функцинале портала и Team Explorer я не заметил.
Задачи и баги из TestTrack Pro в TFS переносить не стали - все таки база накоплена довольно большая - более 10-ти тысяч багов и тасков. Решили что они пока поживут одновременно. Т.е. фиксим баги в TestTrack Pro, новые пишем уже в TFS.

Перед миграцией в Process Editor я создал шаблон проекта (на основе Agile-шаблона) который мы использовали для создания проекта.

Для удобства сотрудников я создал в шаблоне готовый набор запросов, необходимый в повседневной работе - My current tasks, My current bugs, All tasks, All bugs и т.п. Кроме того, отдельные запросы созданы для каждой версии нашей системы. Поскольку каждая следующая версия системы не создает в TFS новый проект, все задачи и баги у нас будут храниться в одном Team Project.
Поэтому, для облегчения разделения багов и тасков по версиям, я сгруппировал их в соответствующие каталоги.
Выглядит это вот так:



Таким образом каждый сотрудник может использовать эти фильтры для работы с work items по версиям.
Тестировщикам еще нужны дополнительные запросы (например, Need to verify - список багов и тасков, нуждающихся в проверке), но они сделают их сами.
Еще из полезных запросов - Fixed today и Fixed in the last 2 days - я сделаю на днях.
Списки My current tasks, My current bugs вынесены на главную страницу SharePoint-портала.

Кроме запросов, в шаблоне проекта были внесены также изменения в набор полей для тасков и багов.
Были добавлены следующие поля:
1. Required architecture review - установка этого свойства означает, что разработчик должен согласовать способ устранения бага с архитектором.
2. Update text on site - установка этого свойства означает, что после завершения бага или таска, программист должен переназначить баг на тех. писателя, который внесет дополнения в подсказки на сайте.
3. Need to deploy - требуется ли выгрузка систему для проверки данного бага. Полезно для тестировщиков на случай, если какой-то баг решается без выгрузки и может быть проверен достаточно быстро.



Все документы из Groove были перенесены в Shared documents SharePoint-портала. Теперь все документы одновременно доступны в Groove, SharePoint или Visual Studio. Groove и SharePoint синхронизируются автоматически каждый час. Работа с файлами в Groove реализована значительно удобнее, чем в SharePoint, поэтому используем его.
К сожалению календари, встречи и т.п. у Groove и SharePoint интегрировать не удалось. Все это по прежнему остается в Groove. Баги тоже не удалось интегрировать в Groove.

С какими сложностями пришлось столкнуться в процессе миграции:
1. Как оказалось TFS может создавать бранчи только на основе каталогов файловой системы. Посколько у нас не все проекты Solution'а хранились в одном каталоге, при миграции от этого пришлось отказаться - т.е. пришлось переместить все проекты в один каталог. Несколько нелогично со стороны Microsoft - давать такую возможность в Visual Studio, но не предусмотреть ее в TFS.

2. Как оказалось, TFS не может складывать последние версии бранчей в один и тот же каталог - вместо этого он складывает их в разные каталоги. Это приводит в тому, что нельзя так же просто, как и раньше, когда мы работали с SVN, использовать IIS для отладки сайтов - в IIS для приложений пути прописаны в явном виде. Видимо, для того, чтобы использовать уже сконфигурированное приложение, после взятия последней версии нового бранча, нам придется вручную исправлять пути приложений в IIS. Это несколько неудобно. Странно, что в Microsoft не предусмотрели решения такой, в общем-то довольно очевидной проблемы.

3. Как оказалось в студии по умолчанию нет поиска багов или тасков по номеру или подстроке - только запросы. Очень неудобно, особенно тестировщикам. К счастью для решения проблемы уже есть plug-in - http://visualstudiogallery.msdn.microsoft.com/en-us/3f31bfff-5ecb-4e05-8356-04815851b8e7


Из положительных результатов миграции хотелось бы отметить следующие:
1. Отсутствие зоопарка инструментов. Раньше был TestTrack, Groove, SVN. Теперь осталась только студия и немного Groove.

2. Возможность явной связи изменений в коде с багом или таском. Раньше такого не было и для выгрузки патча программистам приходилось писать в комментариях к багу список измененных файлов. Теперь стало очень удобно - при чекине в TFS можно легко ассоциировать чекин с багом или таском и потом по истории обновления бага или таска посмотреть историю изменений кода. Очень удобно.

3. Удобная возможность мержа кода от основной ветки разработки к стабильным бранчам для подготовки патчей (что было очень неудобно в SVN).

4. Высокий потенциал на будущее - возможность автоматизированных сборок на сервере, запуска unit-тестов, деплоймента и пр.


Из недостатков:
1. Как оказалось в TFS нельзя назначить баг или таск сразу нескольким сотрудникам. В общем-то это небольшая проблема и требуется довольно редко. Можно сказать, что можно вполне обойтись и без этого.

2. В TFS нет как такового общего списка багов или тасков - вместо этого есть только запросы. В принципе ничего страшного, но потенциально существует опасность потерять какой-нибудь work item, составим неверный запрос.

3. При назначении человеку бага или таска у него не выскакивает сообщение, как это было в TestTrack Pro. Иногда полезно.

4. Списки багов и тасков не обновляются автоматически - приходится жать Refresh.

5. Нет возможности изменить историю работы с work item. Т.е. если в комментарии забыли что-то написать и хотим добавить - надо взять весь комментарий, скопировать его, вставить и уже потом исправлять.

А в остальном все не плохо.

Теперь в планах - наладить автоматизированный запуск unit-тестов (сейчас тестировщики запускают их вручную) и автоматический деплоймент на тестовые сервера.
Но это уже осенью.


P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)
Мой сайт - www.msmirnov.ru