Багтрекинг

Тема в разделе "Lotus - Программирование", создана пользователем anna, 13 апр 2015.

  1. anna

    anna Lotus team
    Lotus team

    Регистрация:
    3 июн 2014
    Сообщения:
    304
    Симпатии:
    8
    Коллеги разработчики, я уже видела где-то тему про это, но еще раз можно - как у вас реализован багтрекинг под Lotus? Можно заодно про систему контроля версий
     
  2. anna

    anna Lotus team
    Lotus team

    Регистрация:
    3 июн 2014
    Сообщения:
    304
    Симпатии:
    8
    и тишина.... :)
     
  3. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    люди прикручиваю jira
    для vsc - git или TS (TeamStudio - для классики)
     
  4. anna

    anna Lotus team
    Lotus team

    Регистрация:
    3 июн 2014
    Сообщения:
    304
    Симпатии:
    8
    А TeamStudio чем может помочь? А с гитом идея мне вообще не нравится - хранить совершенно внутреннюю информацию где-то вдали.... не айс, да и за платные аккаунты никто платить не будет.
    Про JIRA у меня тягостные воспоминания. Стоит ли, помимо эклипса, еще одного монстра держать?
     
  5. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    не понял - причем здесь гитхаб? git - программа, кот. никак не связана с хостингом
    http://hashabc.com/blogs/testing/120981/
    можете и весь список проверить https://ru.wikipedia.org/wiki/Система_отслеживания_ошибок
    все зависит от требований, может оказаться что проще свою написать
     
  6. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    #6 lmike, 13 апр 2015
    Последнее редактирование модератором: 13 апр 2015
  7. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    #7 lmike, 13 апр 2015
    Последнее редактирование модератором: 13 апр 2015
  8. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    #8 lmike, 13 апр 2015
    Последнее редактирование модератором: 13 апр 2015
  9. anna

    anna Lotus team
    Lotus team

    Регистрация:
    3 июн 2014
    Сообщения:
    304
    Симпатии:
    8
    да, точно, именно этот пост и искала. однако, три года прошло, ничего нового не изобрели?
    1. VladSh обрисовывает отличную модель, однако, там, как мне кажется, проприетарное ПО пишется на лотусе и никто не станет делиться импортерами-экспортерами, и уж, тем более, вряд ли поможет адаптировать их по себе. Для команд типа "человек-оркестр" тоже не подойдет, а у нас примерно так - полтора землекопа.
    2. Легко ли "выкусить" из dxl все лишнее, чтобы подпихивать svn? легко?
    3. Не пытался ли кто-нибудь строить багтрекинг на самом лотусе - в принципе, все средства командной разработки есть, источник тасков и багов в нем уже есть..
    4. И у меня крамольная мысль (я так шепотом скажу) - а никто не пытался на лотусе строить систему управления требованиями? а то понапишут разных ТЗ, сиди анализируй, что с чем стыкуется и откуда взялася воооон та кнопочка?
     
    #9 anna, 14 апр 2015
    Последнее редактирование модератором: 14 апр 2015
  10. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    легко, только надо знать - что хчется на выходе ;)
    то что видел мне не нравилось
    сотрудничал с 2-мя компаниями ведущими разработку под ЛДН - ни в одной не встречал ТЗ адаптированное под ЛДН :)
    причина понятна - те кто ч-л хочет - не знает нотусни, а те кто знает - не обладает достаточным временем переписывать "этот бред"
    выше указал полный стэк (правда платный) для все-и-сра, причем используется людьми в гетерогенных средах/платформах - чем не устраивает?
     
  11. hosm

    hosm * so what *

    Регистрация:
    18 май 2009
    Сообщения:
    2.450
    Симпатии:
    7
    У нас нормальной не было, когда-то для облегчения разработки была бд с общими элементами и тимстудия (CIAO) на 6-7й версиях домино, потом был "самопал": бд с выгруженным dxl для общих элементов с поддержкой версионности (в основном либы и агенты)+ плагин для дизайнера коллеги делали, при сборке автоматическая раздача на рабочие бд и вручную компиляция, затем автоматизированное получение шаблонов - лучше, чем вообще ничего... мож, еще полгода-годик и дорастут до нормальных систем. ;)
    В компании, в которой Влад работал, насколько интересовалась, сейчас лотус-направление особо не развивается, там вроде свой какой-то конвертер или что-то подобное. Вот еще описание среды разработки от другого экс-коллеги: http://dpastov.blogspot.com/2013/08/github-jira-jenkins-domio.html
    Это к вопросу о велосипедах))) Чем так не устраивает jira, вроде ж она вполне расширяема? Писали такой в одной из компаний несколько лет назад, не сложно, в принципе, вполне можно использовать для небольших локальных и распределенных команд. Нашу систему использовали на протяжении нескольких лет, в целом неплохо - для меня интересный опыт, но лично я не вижу особых перспектив развития при таком разнообразии багтрекинговых систем (с учетом возможности "допиливания" большинства из них).
    Если отдаете на аутсорс, могу взяться :) если нет - ниже вот кусочек из опыта.
    Если бы сейчас писала подобное, то это были бы либо икспейджи+домино, либо джаваскрипт, джава(шарп) + реляционка.
    Написали, так как надо было на заре развития компании при ограниченном кол-ве денежных ресурсов максимально быстро организовать работу небольшой команды (2-3 разработчика, 2 тестировщика, аналитик, ПМ+техпис, саппорт) и преемственность разработки продукта.
    Из задач, требований и проблем, с которыми сталкивались в начале работы (6-10 пользователей):
    - понять бизнес-процесс - первичный анализ текущего и желаемого процесса работы с проектами, ошибками и требованиями (была предоставлена схема+пояснения, проблем почти не было, одна из самых хорошо представленных задач для разработки),
    - импорт текущих ошибок в систему на начальном этапе разработки (экспорт из предыдущего багтрекера ClearQuest),
    - уникальная последовательная нумерация в распределенной среде, нотификация,
    контроль версий, поддержка одновременной работы над несколькими проектами,
    отчетность и экспорт, поиск и отбор.
    - недостаточность существующей отчетности для специалистов техподдержки и менеджеров (доделывали отчетность, поиск, новые вьюхи).
    В дальнейшем с масштабированием на десятки пользователей в распределенной среде (распределенная команда, 2-3 часовых пояса) проблемы вызывало отсутствие необходимых нотификаций и веб-интерфейса (писалось под 7й лотус, тогда не стали заморачиваться с вебом, нотификация изначально была, но потом то убирали, то добавляли), необходимость обучения пользователей (не было нормальной документации и сценариев (стандартов) работы с системой - например, в связи с увеличением кол-ва багов в системе из-за небрежного их оформления и лени тестировщиков началось массовое дублирование дефектов), иногда не хватало полной истории редактирования описаний ошибок. По необходимости в дальнейшем доделывалось связывание, настройки, поиск, отчетность (в т.ч. по трудозатратам), аналитика, меняли немного бизнес-процесс. Прикручивала позже ради обучения веб на икспейджах - пожалела, что в свое время описание вместо текстового поля по просьбе тест-аналитика сделали простым рт-полем (надо было хоть рт-лайт) - туда ушлые тестеры скриншоты тыкали, очень неудобно было отображать.
    На текущий момент одна компания, использовавшая систему, вроде приостановила работу, другая, я думаю, рано или поздно окончательно перейдет на jira.

    А мне повезло больше - встречала вполне нормальные тз. Правда, такие задачи обычно ставили либо менеджеры, вышедшие из тех. спецов и знающие платформу, либо "специально обученные девочки-аналитики" после консультации опять же тех.специалистов-конструкторов - но это специфика разработки в довольно крупной софтверной компании. В общем, либо самому приходится что-то придумывать (создавать прототипы, изучать аналитику, напрямую общаться с заказчиком и уточнять требования), либо поднимать перед ответственными за проект данную проблему в том ракурсе, что некачественное тз создает проблемы и приводит к избыточным затратам (иногда помогает выделить одного ответственного за качество проектной документации, иногда вводить стандарты и образовывать "специально обученных" - самые вменяемые достигают хороших результатов через несколько месяцев, остальные максимум через год-два либо уходят, либо тоже уже вполне адекватные тз готовят).
     
    #11 hosm, 15 апр 2015
    Последнее редактирование модератором: 15 апр 2015
    2 пользователям это понравилось.
  12. anna

    anna Lotus team
    Lotus team

    Регистрация:
    3 июн 2014
    Сообщения:
    304
    Симпатии:
    8
    В JIRA баги из лотуса доставлять и как связывать?
     
  13. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299

Поделиться этой страницей