Agile testing
Alimenkou Nikolay
является одной из наиболее спорных среди разработчиков и QA. Я не раз
участвовал в дискуссиях на тему в каком виде должны предоставляться
требования для написания тест кейсов, должны ли быть тест кейсы вообще
и когда/кто должен ими заниматься. Agile методологии накладывают
некоторые ограничения на работу с требованиями, но в то же время
позволяют повысить уровень надежности кода за счет покрытия тестами,
парного программирования и других практик. Но все же проверка
приложения с точки зрения бизнеса будет присутствовать. Хотелось бы
узнать какие подходы/средства кто использовал для этого? Я искал tool
для хранения и работы с тесткейсами. Лично мне из open source не
понравилось ничего. Из платных я успел посмотреть только на TestLog.
Он понравился по функционалу очень, но он не имеет web интерфейса и
написан только под винду. Интересно послушать мнения.
P.S. На размышления навела книжка (кто не читал может будет
интересно): Wiley - Software Testing
Alexey Krivitsky
тогда каждый член команды может участвовать в наполнении
Alimenkou Nikolay
>тогда каждый член команды может участвовать в наполнении
Проблема wiki в том, что это по сути простой блокнот, который не
приспособен под специфические задачи. В данном случае хотелось бы
иметь удобство в добавлении тест кейса, набор необходимых полей, выбор
типа тестирования (функциональный, структурный, интеграционный и так
далее), выбор этапа тестирования (разработка, интеграция, инсталляция
и так далее), привязка к реальным тестам и их результатам, получение
отчетов по текущему состоянию тестирования, которые могут быть
использованы для дальшейшего анализа и предугадывания поведения
проектра в реальном использовании (процент багов, найденных
пользователями). Взгляни к примеру на тот же TestLog, у них есть демо
инсталляк.
Alexey Krivitsky
то я бы предпочел говорить о тулзах, которые не заменяют общения, предоставляя информацию по "предугадыванию поведения проекта",
а лишь помогают команде общаться более эффективно.
Serhiy Yevtushenko
Во первых, предполагается, что все типы тестов(функциональное, интеграционное, структурный тест) можно реализовать с помощи одного тула.
Во вторых, если так специфицировать тесты, то не понятно, как вы их будете привязывать к результатам выполнения.
Также у меня вопрос - почему не использовать для получения текущего состояния тестирования баг трекинг систему ?
Кто является реальным заказчиком/пользователем тулзы, о который вы хотели бы пользоваться ?
Alimenkou Nikolay
> работе по классической методологии.
Очень хотелось бы узнать об альтернативных подходах к тестированию (к
примеру
в Scrum). У QA нету опыта работы в подобных методологиях и хотелось
бы осуществить мягкий переход.
> Во первых, предполагается, что все типы тестов(функциональное,
> интеграционное, структурный тест) можно реализовать с помощи одного тула.
Никак они не могут быть организованы с помощью одного тула, потому
что
перформанс и лоад тестирование отделено от остального, так же как и
тестирование
окружения, тестирование сети и софта, юнит тестирование, статическое
тестирование
пользовательской документации, тестирование инсталляции продукта (если
она есть)
и мануальное тестирование функционала.
> Во вторых, если так специфицировать тесты, то не понятно, как вы их будете
> привязывать к результатам выполнения.
Вот это как раз интересный вопрос. Это может быть мануальный процесс.
К примеру
некоторые тулзы дают возможность проставлять логи запусков со
статусом. Это очень
удобно для репортов.
> Также у меня вопрос - почему не использовать для получения текущего
> состояния тестирования баг трекинг систему ?
Баг трекинг система отражает лишь наличие багов и не дает информации
какое количество
user story или use case реально покрыто тестами, каков их текущий
статус и какова тенденция.
Необходима интеграция с баг трекинг системой, чтобы иметь информацию о
количестве багов
на тест кейс (а соответственно на user story или use case) для анализа
и принятия решений.
> Кто является реальным заказчиком/пользователем тулзы, о который вы хотели бы
> пользоваться ?
Не совсем понял вопрос. Ее хотелось бы использовать в проекте для
процесса тестирования.
Артур Ракицкий
"Также у меня вопрос - почему не использовать для
получения текущего состояния тестирования баг трекинг систему ?"
Я тоже подумал именно о таком вопросе/ответе :)
Сейчас мы используем DevTrack, в котором я планирую, вести не только замечания
и ошибки (как делается в проектах, доставшихся мне "по наследству"),
но и требования и тест-кейсы, привязанные к этим требованиям.
Все необходимое для определения и отслеживания состояний в каждой из баз знаний
(баги, требования, тест-кейсы) в данном продукте есть. Остается только
настроить и прописать регламент использования для команды :)
К слову, не вижу большого смысла в отдельных "специализированных"
инструментах для ведения каждой из деятельностей. В любом случае бОльшая часть
знаний (читай, текста) будет лежать лишь в одной из баз. На разных этапах
зрелости продукта это могут быть разные базы, но "подводя итоги" все
равно нужно составлять как общий перечень изменений (или вообще требований),
так и краткий обзор того, что не сделано, но хотелось бы. И источники для этого
- все три базы знаний. Из этих соображений я и считаю, что один инструмент,
пусть и не супер-функциональный, лучше, чем 3 "идеальных". Да и в
плане поддержки такая конфигурация среды проще :)
С уважением,
Артур Ракицкий
------------------
ICQ: 21062147
Артур Ракицкий
какое количество"
ICQ: 21062147
sun
Alimenkou Nikolay
требованиями (в каком бы виде они не были), тесткейсами, реальными
тестами, багами и исходным кодом. Это самое главное качество, не
считая наличия веб интерфейса. ;)
Alexey Krivitsky
1. частого запуска автоматических тестов разного уровня
2. фиксировании скоупа и длины итерации (так как уменьшается количество задач и связей)
3. прозрачности прогресса внутри итерации (частое живое общение)
Артур Ракицкий
Есть (в порядке уменьшения "грубости" подхода):
а) группирование по какому-либо полю (например, по модулю/функциональной группе),
б) связывание отдельных замечаний между собой (в том числе и с поддержкой подчиненности, и между проектами/базами),
в) связывание замечаний с документами/файлами (как вложенные документы, так и ссылки),
г) связывание (а точнее интеграция) с файлами в VSS (в том числе с определенной версией).
Это из того, что есть у нас, и доступно без лишних телодвижений. Вполне вероятно, есть интеграция и других фич, о которых я не знаю :)
Главный вопрос: дает ли баг трекинг система трейсебилити между
Артур Ракицкий
Есть (в порядке уменьшения "грубости" подхода):
а) группирование по какому-либо полю (например, по модулю/функциональной группе),
б) связывание отдельных замечаний между собой (в том числе и с поддержкой подчиненности, и между проектами/базами),
в) связывание замечаний с документами/файлами (как вложенные документы, так и ссылки),
г) связывание (а точнее интеграция) с файлами в VSS (в том числе с определенной версией).
Это из того, что есть у нас, и доступно без лишних телодвижений. Вполне вероятно, есть интеграция и других фич, о которых я не знаю :)
Главный вопрос: дает ли баг трекинг система трейсебилити между
Alimenkou Nikolay
времени).
Меня интересуют следующие метрики:
- какое количество фичей/use case/user story покрыто тест кейсами
- какое количество тест кейсов уже имеют реальные тесты (позитивные,
негативные)
- статистика запусков этих тестов и их текущий статус
- количество и статус багов на тест кейс
- деление метрик по параметрам, таким как фаза проекта, тип тестов и
так далее
В дополнение хотелось бы отметить, что идеально было бы иметь open
source. ;)
Borys Lebeda
sun
sun
Borys Lebeda
Borys Lebeda
Alexey Krivitsky
8 октября.
я ещё дам анонс.
Alimenkou Nikolay
> трекинговая система, на все эти вопросы он не может дать ответы, разве что
> если кастомизировать его и заставить каждого девелопера писать процент
> покрытия в специально отведенное поле, а каждого QA проверять всю эту
> ахинею. И всё это ради того, что бы один человек смог построить отчёт со
> светомузыкой ...
>
> Овчинка выделенки не стоит :-\
Вот тут не соглашусь на за что. Пример: на данный момент я имею
неплохие метрики,
которые мне даются continuous integration server и maven:
- покрытие кода тестами
- статистику по запускам тестов и их результатам
- project health из различных репортов
Дополнительно от bug tracking системы я имею отчеты по:
- количеству найденных багов
- их распределение по компонентам системы и функционалу
- привязку багов к user story/use case
- количество багов в разных состояниях и общий прогресс
НО, я никак не могу получить общий прогресс тестирования:
- сколько реально тест кейсов покрыто (может все мои тесты - просто
для 5 тест кейсов)
- сколько функциональности адекватно покрыто тест кейсами, причем
возможно без
реальных тестов, потому как кода нет и тестов нет
- какое количество тестов, которые не запускаются ежедневно (или при
каждом коммите)
прошло и когда они запускались
- насколько стабильной является система (одна из метрик, которая
получается по приоритетам
тест кейсов с точки зрения бизнеса), это особенно важно чтобы знать
прогресс с бизнес стороны
и знать его постоянно
и так далее...
Часть из этого покрывает TestLog, но далеко не все. Excel - абсолютно
не приспособлен для всех
перечисленных задач и затрудняет доступ к информации (проверено на
горьком опыте).
Alimenkou Nikolay
On Sep 14, 4:11 pm, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг
> трекинговая система, на все эти вопросы он не может дать ответы, разве что
> если кастомизировать его и заставить каждого девелопера писать процент
> покрытия в специально отведенное поле, а каждого QA проверять всю эту
> ахинею. И всё это ради того, что бы один человек смог построить отчёт со
> светомузыкой ...
>
> Овчинка выделенки не стоит :-\
Написал ответ, но его сожрал инет :(. Предлагаю обсудить это при
встрече 9 числа.
Alexey Krivitsky
http://groups.google.com/group/agile-ukraine/msg/84488b8faa7faca9
sun
borys....@gmail.com
Метрики по девелопменту и по дев-трекингу у меня есть для проектов из
управляемого кода (Попытка сделать мало-мальски адекватное покрытие
для VB закончилось ничем). На вопросы, на которые и не может найти
ответы и Николай, я попытался ответить специальными отчётами, данные
для которых должен был предоставлять каждый девелопер при закрытии
определённой задачи и тестер при открытии. Чаще всего это от них
требовало значительного усилия:
- Девелопер должен был знать как его коммит влияет на прогресс
закрытия требований или use cases
- Тестер должен был знать какие модули он протестировал.
- Заказчик должен понимать физический смысл всех этих метрик
На самом деле наличие отчёта по покрытиям требований менее важен, чем
право девелопера НЕ ЗНАТЬ и НЕ ИНТЕРЕСОВАТЬСЯ над каким требованием он
в данный момент работает. Бог придумал разделение труда не для того,
что бы каждый член команды знал о всех аспектах проектах. Да и не
возможно это для нашего проекта...
Borys Lebeda
Alimenkou Nikolay
что то что мне требуется в действительности мне не нужно. Я не хотел
бы углубляться в специфику проекта, но поверьте на слово - нужно.
Вопрос этого топика был "Поделитесь опытом и расскажите о ваших
подходах", а не "Критикуйте вопрос и требования, которые в нем
перечислены". Если нечего рассказать на тему топика, так попросту не
пишите.
Артур Ракицкий
Артур Ракицкий
Похоже, проблема не в инструменте, а в организации работ. Когда продукт разбит на "удобные" части (функции, например) и эту разбивку поддерживает вся команда и заказчик, подобных вопросов не появляется.
> Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг
Ілля Романенко
Agile Software Development Quality Assurance
http://www.amazon.com/dp/1599042169?tag=itbookscatalo-20&link_code=as3&creativeASIN=1599042169&creative=373489&camp=211189
Якщо цікаво - можу дістати в електронному вигляді
Alexey Krivitsky
Ілля Романенко
Borys Lebeda
Borys Lebeda
Alimenkou Nikolay
> "сколько реально тест кейсов покрыто" и т.д.
> Похоже, проблема не в инструменте, а в организации работ. Когда продукт
> разбит на "удобные" части (функции, например) и эту разбивку поддерживает
> вся команда и заказчик, подобных вопросов не появляется.
Приведите мне пример как можно получить ответы на мои вопросы не имея
приведенных
метрик. К примеру: можно ли с точки зрения бизнеса сделать демо для
потенциальных
заказчиков. А такой заказчик может появиться в любой момент и
хотелось бы знать в каком состоянии находятся самые приоритетные
бизнес фичи.
Насколько они протестированы и какие аспекты остались незатронутыми (к
примеру
не было перформанс тестирования). Я рад послушать реальные
предложения. Причем это
всего лишь один из волнующих вопросов.
Alimenkou Nikolay
On Sep 15, 10:44 am, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> Ничего я не пытаюсь доказать, просто мой опыт пошёл в разрез с Вашими
> требованиями. А другим поделится не могу, потому как на моей памяти не было,
> что бы какие-то метрические показатели (даже из тех, что перечисленны
> в Вашем посте) позволяли отследить степень удовлетворения требований
> заказчика. Путём долгих переговоров с заказчиком нам удалось создать роль
> аналитика - специального человека, который работает с требованиями и тест
> сьютами, при этом не смотрит в код и не смотрит в отчёты по тестированию. Я
> могу сколько угодно критиковать работу этого человека и самого института
> анализа требований, но это работает лучше, чем попытка автоматизировать этот
> процесс метриками. Если привести аналогию в спорте, то анализ требований
> скорее похож на фигурное катание, чем на пауэр лифтинг...
>
> На меня, а также на Артура или Алексея, обижаться совершенно напрасно...
> Представьте себе, что будет в тот злополучный день, когда и Ваш опыт
> перестанет согласовываться с вопросом в этом посте :)
>
Тогда я сделаю новый пост и забуду про этот. Не хочу заглядывать на
будущее. ;)
А на счет аналитиков мне есть что рассказать. Очень хотелось бы
поделиться при встрече.
Было достаточно опыта работы с аналитиками в контрактных проектах.
Артур Ракицкий
потенциальных
заказчиков. А такой заказчик может появиться в любой момент и
Я же говорю, у Вас проблема не в метриках :)
Вы как позиционируете свой продукт?
а) Как коробочное решение? Ну так продавайте в магазинах, и кто захочет - тот и купит. Фокус-группу для вашего продукта и позицию относительно альтернатив и конкурентов в случае коробки вы должны были выяснить еще ДО того, как что-то разработали :) Этого нет? Значит начинайте прямо сейчас, пока не поздно. А там и по результатам исследований рынка вы сможете оценивать полноту покрытия чего бы то ни было.
б) Позиционируете как систему "под ключ"? Вы будуте ее дорабатывать под специфику бизнеса заказчика? Ну так начинать нужно (увы и ах!) не с продукта. Вероятно, ваш продукт (в сегодняшнем состоянии) реальному (а не потенциальному) заказчику даром не нужен. Прежде всего выясните его бизнес-процессы, определите те места, где нужна реальная автоматизация (а не хотелки с бубенчиками). И делать эту реальную, а не "потенциальную", работу должны люди от бизнеса. В идеале - по бизнес-аналитику с кажой стороны. И вот они должны определить требования и выяснить меру их покрытия продуктом. Причем, не на основании каких-либо авто-тестов, или отчетов о закрытии кесов/багов. А на основании живого использования продукта в тестовом цикле бизнес-процесса.
Думаю, вы занимаетесь вариантом б), на нем и остановимся.
Вы не с того места думать начинаете. Вы считаете, что продукт (система, комплекс, даже с полноценной документацией по ее использованию в определенной области) может что-то "покрывать". Это не так. Бизнес делают люди, деньги и схемы с их участием (в том чесле бизнес-процессы). Для каждого конкретного заказчика это свои "особые" люди, свои деньги и свои схемы. Начинать нужно с них, а не с "потенциальных" понятий :).
Отступим немного от моих советов :) И вернемся к Вашей просьбе.
"Приведите мне пример как можно получить ответы на мои вопросы не имея приведенных метрик."
С моей точки зрения, Вы ставите собеседника в заведомо проигрышную позицию. Это как минимум некрасиво :) Так можно поступать только заведомо зная, что собеседник глуп, и желая его "ненавязчиво" подвести к вашему собственному решению. Я понимаю, в нашем бизнесе это распространенная практика, но не в группе agile-ukraine же ее применять :)
Ну и собственно про метрики. Боюсь, что Вы подумаете о том, что я (или кто-то другой из этой темы) не видит в них пользы. Это не так. Метрики полезны, но в меру :) Например, для отслеживания хода выполнения работ они незаменимы. И SCRUM (в частности) использует несколько метрик (например, сколько осталось незакрытых задач до конца спринта). Динамика их изменений служит наглядной демонстрацией эффективности работы команды. Но не демонстрацией "покрытия бизнес-потребностей".
Borys Lebeda
Alimenkou Nikolay
так
давно появилась тут. Судя по вашим комментариям вы живете в некотором
иллюзорном
мире, к котором методология как вирус заняла основное место и стала
БЕЗальтернативным
решением. В вышеуказанной статье приводится неплохая цитата о том, что
нечто не признающее
альтернатив - есть глепость по существу своему. Речь идет не о
коробочных продуктах, а о
полноценном заказе со стороны представителей бизнеса на разработку
вполне конкретного
продукта. Но специфика любого бизнеса такова, что он постоянно
находится в движении и
изменяется. Так вот, для разработки данного продукта используется
итеративный процесс, в
котором сочетаются элементы XP и Scrum (по некоторым обстоятельствам с
некоторыми
уступками). Так вот заказчик постоянно приоритизирует задачи в backlog
и участвует в
планировании каждой итерации. При этом специфика проекта такова, что у
него есть
более или менее подробное описание проекта и его фичей (а также оценки
рисков с точки
зрения бизнеса) на некоторое время вперед (неважно кто это делает,
аналитик ли или еще
кто-то). Но когда некоторая фича была имплементирована в итерации (при
этом код покрыт
тестами) далеко не факт что она прошла интеграционное тестирование.
Пример тому
тестирование бизнесс процесса с помощью веб интерфейса. Само
тестирование было
описано, спланировано и связано с данной фичей (тесткейсы и прочее,
устал перечислять).
Но оно не могло начаться до завершения веб функционала. Теперь для
тех, кто в бронепоезде
описываю ситуацию. Приходит после первой половины итерации заказчик и
рассказывает о
потенциальном клиенте. Просит сделать демо, но которое обязательно
должно содержать
некоторые фичи. При этом очень нежелательно иметь проблемы
(непротестированные
части фичей) при показе. Можно в целом заказчику отказать и заставить
ждать его до того как
тестирование фичи будет закончено полностью. А если иметь метрику из
моего примера,
то можно выяснить, что на данный момент наиболее приоритетные моменты
выбранных фичей
прошли полное тестирование (а заказчик готов сделать демо с
незначительными недоработками
наподобие отчетов и статистики). Если же окажется что покрыты не все
наиболее
приоритетные моменты, то можно провести перепланирование в итерации
для QA для того чтобы
дать заказчику то, что он хочет.
>Вы изначально ограничиваете метод оценки (кстати, оценки
>чего? выше я объяснил, что оценивать нечего :) )
Вы даже не поняли вопроса, а тем более не знаете деталей проекта, но
уже готовы сделать
вывод о том, что в принципе мне эти метрики и не нужны. Это вы ставите
меня в заведомо
дурацкое положение, при этом аппелируя к пунктам а) и б). К сожалению
вы промахнулись
с обоими пунктами. И как аналитик или еще кто-то сможет оценить в
любой момент времени
работоспособность и завершенность продукта. Закройте глаза и
представьте, что вам этот
продукт принесли из другой компании, которая закрылась на прошлой
неделе, и задали тот
же вопрос, что и я по поводу демо. Никто не утверждает что данные
метрики решат все
проблемы, но согласитесь, что имея их под рукой вы существенно
уменьшите бизнес-риски
ваших заказчиков.
И еще раз повторяю: я задавал вопрос изначальный по поводу приемов и
тулзей, которые
кто-то из вас использовал в Agile проектах. Но стоящего ответа так и
не получил. Зато получил
кучу постов с критикой. Представьте вы спросили бы на сайте Sun как
вам запустить ваш Java
класс, а вам бы написали кучу постов о том что в вашем проекте вообще
не нужна Java, да и
глобально С++ лучше (не в обиду никому). Зачем? Только тратим мое и
ваше время попусту.
Если вы хотите за счет этого самоутвердиться, то тоже глупо, да и
возраст не тот мне кажется.
> 15.09.07, Alimenkou Nikolay <lumii.subscri...@gmail.com> написал(а):
>
>
>
> > On Sep 14, 9:00 pm, "Артур Ракицкий" <arty...@gmail.com> wrote:
> > > "сколько реально тест кейсов покрыто" и т.д.
> > > Похоже, проблема не в инструменте, а в организации работ. Когда продукт
> > > разбит на "удобные" части (функции, например) и эту разбивку
> > поддерживает
> > > вся команда и заказчик, подобных вопросов не появляется.
>
> > Приведите мне пример как можно получить ответы на мои вопросы не имея
> > приведенных
> > метрик. К примеру: можно ли с точки зрения бизнеса сделать демо для
> > потенциальных
> > заказчиков. А такой заказчик может появиться в любой момент и
> > хотелось бы знать в каком состоянии находятся самые приоритетные
> > бизнес фичи.
> > Насколько они протестированы и какие аспекты остались незатронутыми (к
> > примеру
> > не было перформанс тестирования). Я рад послушать реальные
> > предложения. Причем это
> > всего лишь один из волнующих вопросов.
>
Артур Ракицкий
Либо Вы описались, и хотели сказать "тестирование веб интерфейса в рамках выполнения сценариев бизнес-процесса", либо Вы ничего не смыслите в понятии бизнес-процесс...
Прочитайте, пожалуйста, еще раз мой предыдущие ответ ПОЛНОСТЬЮ, и постарайтесь понять, что я хотел Вам объяснить. Я не привязывался ни к одной методологии в своих объяснениях. И Вы зря пытаетесь меня обвинить в каких-либо пристрастиях по этому поводу. Вчитайтесь, и поймите, что у Вас сложилось ложное впечатление. :)
"Приходит после первой половины итерации заказчик и
рассказывает о потенциальном клиенте. Просит сделать демо, но которое обязательно
должно содержать некоторые фичи."
а) управление рисками (если вы хотите показывать сырые фичи, будьте готовы устранить последствия ошибок).
б) прототипирование (как уже написал Борис, продавать можно и презентацию в Power Point).
А поспешно оценивать статус фичи - зачем? Кому Вы этим сделаете приятно? Самому себе разве что. Но при этом Вы забудете о рисках, тем самым подпилив сук, который успешно выращивали с момента начала проекта, строя эффективную систему управления проектом.
"И как аналитик или еще кто-то сможет оценить в любой момент времени работоспособность и завершенность продукта."
а) функциональные требования, которіе сформированы ДО разработки, и которые покрывают бизнес-требования.
б) полноту покрытия именно БИЗНЕС-требований ПОСЛЕ передачи продукта в тестовую эксплуатацию. При этом он может использовать какие угодно знания и инструменты, но обязаен в них профессионально разбираться. Именно бизнес-аналитик, а не менеджер и тем более не тестировщик (подтверждающий тест-кейсы), принимает РЕШЕНИЕ о готовности продукта. И принимать решение "на переправе меняя коней" - вот глупость, которую я Вам пытаюсь показать.
Подумайте обо всем этом без эмоций, и поймите, что никто здесь не хочет что-либо Вам доказать, или в чем-либо ущемить. Лишь помочь. А про тулзы Вам все же ответили, и описали их возможности. Не нужно становиться в позу - это ни на кого здесь не произведет впечатления :)
Alimenkou Nikolay
можете. Можете
обвинять меня, считать дураком, но реально то, что вы пишете - вода.
Вам бы и быть
аналитиком или работать в отделе продаж (хорошо получается замутить
воду). Устал
повторять тему топика (хотя для некоторых возможно это и бесполезно):
КАКИЕ МЕТОДИКИ, ПРАКТИКИ И ИНСТРУМЕНТЫ ИСПОЛЬЗОВАЛИСЬ ДЛЯ
ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ В AGILE ПРОЕКТАХ?
Были перечислены несколько тулзовин: DevTrack, TestLog, Jira. Ни одну
из них не назовешь
чисто Agile тулзой. А пробовал кто-то AgileTrack? Я когда-то давно
смотрел на нее, когда она
была еще бесплатной. Довольно интересная вещь для тех, кто хочет вести
Agile проекты с
помощью заведомо приспособленных вещей. Там есть понятие story, task
(bug, feature and etc.),
довольно неплохие графики для оценки velocity команды. Может у кого
есть опыт (позитивный
или негативный) работы с ней?
On Sep 16, 1:46 pm, "Артур Ракицкий" <arty...@gmail.com> wrote:
> "Пример тому тестирование бизнесс процесса с помощью веб интерфейса."
> 16.09.07, Alimenkou Nikolay <lumii.subscri...@gmail.com> написал(а):