Agile testing

21 views
Skip to first unread message

Alimenkou Nikolay

unread,
Sep 14, 2007, 4:25:55 AM9/14/07
to Agile Software Development Group, Ukraine
Я решил открыть новую тему для дискуссий, потому как для меня она
является одной из наиболее спорных среди разработчиков и QA. Я не раз
участвовал в дискуссиях на тему в каком виде должны предоставляться
требования для написания тест кейсов, должны ли быть тест кейсы вообще
и когда/кто должен ими заниматься. Agile методологии накладывают
некоторые ограничения на работу с требованиями, но в то же время
позволяют повысить уровень надежности кода за счет покрытия тестами,
парного программирования и других практик. Но все же проверка
приложения с точки зрения бизнеса будет присутствовать. Хотелось бы
узнать какие подходы/средства кто использовал для этого? Я искал tool
для хранения и работы с тесткейсами. Лично мне из open source не
понравилось ничего. Из платных я успел посмотреть только на TestLog.
Он понравился по функционалу очень, но он не имеет web интерфейса и
написан только под винду. Интересно послушать мнения.

P.S. На размышления навела книжка (кто не читал может будет
интересно): Wiley - Software Testing

Alexey Krivitsky

unread,
Sep 14, 2007, 4:32:45 AM9/14/07
to agile-...@googlegroups.com
как на счет wiki для хранения тест-кейсов? acceptance тестов?
тогда каждый член команды может участвовать в наполнении

Alimenkou Nikolay

unread,
Sep 14, 2007, 4:54:59 AM9/14/07
to Agile Software Development Group, Ukraine
>как на счет wiki для хранения тест-кейсов? acceptance тестов?
>тогда каждый член команды может участвовать в наполнении

Проблема wiki в том, что это по сути простой блокнот, который не
приспособен под специфические задачи. В данном случае хотелось бы
иметь удобство в добавлении тест кейса, набор необходимых полей, выбор
типа тестирования (функциональный, структурный, интеграционный и так
далее), выбор этапа тестирования (разработка, интеграция, инсталляция
и так далее), привязка к реальным тестам и их результатам, получение
отчетов по текущему состоянию тестирования, которые могут быть
использованы для дальшейшего анализа и предугадывания поведения
проектра в реальном использовании (процент багов, найденных
пользователями). Взгляни к примеру на тот же TestLog, у них есть демо
инсталляк.

Alexey Krivitsky

unread,
Sep 14, 2007, 5:04:53 AM9/14/07
to agile-...@googlegroups.com
если мы говорим про тестирование в agile проектах,
то я бы предпочел говорить о тулзах, которые не заменяют общения, предоставляя информацию по "предугадыванию поведения проекта",
а лишь помогают команде общаться более эффективно.

On 9/14/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

Serhiy Yevtushenko

unread,
Sep 14, 2007, 5:07:30 AM9/14/07
to agile-...@googlegroups.com
Мне эти пожелания кажуться слишком сложными, и возможно возникающими при работе по классической методологии.

Во первых, предполагается, что все типы тестов(функциональное, интеграционное, структурный тест) можно реализовать с помощи одного тула.

Во вторых, если так специфицировать тесты, то не понятно, как вы их будете привязывать к результатам выполнения.

Также у меня вопрос - почему не использовать для получения текущего состояния тестирования баг трекинг систему ?

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



Alimenkou Nikolay

unread,
Sep 14, 2007, 5:24:35 AM9/14/07
to Agile Software Development Group, Ukraine
> Мне эти пожелания кажуться слишком сложными, и возможно возникающими при
> работе по классической методологии.

Очень хотелось бы узнать об альтернативных подходах к тестированию (к
примеру
в Scrum). У QA нету опыта работы в подобных методологиях и хотелось
бы осуществить мягкий переход.

> Во первых, предполагается, что все типы тестов(функциональное,
> интеграционное, структурный тест) можно реализовать с помощи одного тула.

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

> Во вторых, если так специфицировать тесты, то не понятно, как вы их будете
> привязывать к результатам выполнения.

Вот это как раз интересный вопрос. Это может быть мануальный процесс.
К примеру
некоторые тулзы дают возможность проставлять логи запусков со
статусом. Это очень
удобно для репортов.

> Также у меня вопрос - почему не использовать для получения текущего
> состояния тестирования баг трекинг систему ?

Баг трекинг система отражает лишь наличие багов и не дает информации
какое количество
user story или use case реально покрыто тестами, каков их текущий
статус и какова тенденция.
Необходима интеграция с баг трекинг системой, чтобы иметь информацию о
количестве багов
на тест кейс (а соответственно на user story или use case) для анализа
и принятия решений.

> Кто является реальным заказчиком/пользователем тулзы, о который вы хотели бы
> пользоваться ?

Не совсем понял вопрос. Ее хотелось бы использовать в проекте для
процесса тестирования.

Артур Ракицкий

unread,
Sep 14, 2007, 5:32:55 AM9/14/07
to agile-...@googlegroups.com

"Также у меня вопрос - почему не использовать для получения текущего состояния тестирования баг трекинг систему ?"

Я тоже подумал именно о таком вопросе/ответе :)

Сейчас мы используем DevTrack, в котором я планирую, вести не только замечания и ошибки (как делается в проектах, доставшихся мне "по наследству"), но и требования и тест-кейсы, привязанные к этим требованиям.
Все необходимое для определения и отслеживания состояний в каждой из баз знаний (баги, требования, тест-кейсы) в данном продукте есть. Остается только настроить и прописать регламент использования для команды :)

К слову, не вижу большого смысла в отдельных "специализированных" инструментах для ведения каждой из деятельностей. В любом случае бОльшая часть знаний (читай, текста) будет лежать лишь в одной из баз. На разных этапах зрелости продукта это могут быть разные базы, но "подводя итоги" все равно нужно составлять как общий перечень изменений (или вообще требований), так и краткий обзор того, что не сделано, но хотелось бы. И источники для этого - все три базы знаний. Из этих соображений я и считаю, что один инструмент, пусть и не супер-функциональный, лучше, чем 3 "идеальных". Да и в плане поддержки такая конфигурация среды проще :)

14.09.07, Serhiy Yevtushenko <syevtu...@gmail.com> написал(а):
--
С уважением,
Артур Ракицкий

------------------
ICQ: 21062147

Артур Ракицкий

unread,
Sep 14, 2007, 5:37:37 AM9/14/07
to agile-...@googlegroups.com
"Баг трекинг система отражает лишь наличие багов и не дает информации
какое количество"
Это какая-то сильно "негибкая" (non-agile, хе-хе :) ) система... Я уже не помню, когда последний раз сталкивался с подобными продуктами. Возможно, вам стоит детальнее изучить один из гибких продуктов, и не отбрасывать его по-умолчанию, а трезво оценить возможности по адаптации? Ведь нам с вами нужно создавать хорошие продукты, а не хорошие среды для разработки этих продуктов ;) Или, как минимум, второе не должно мешать первому.

14.09.07, Alimenkou Nikolay <lumii.su...@gmail.com> написал(а):
ICQ: 21062147

sun

unread,
Sep 14, 2007, 5:55:15 AM9/14/07
to agile-...@googlegroups.com
Мы для этого используем Jira. у нас вообще всё храниться в jira: юзерстори, баги, юзкейсы.

On 9/14/07, Alimenkou Nikolay < lumii.su...@gmail.com> wrote:

Alimenkou Nikolay

unread,
Sep 14, 2007, 6:02:19 AM9/14/07
to Agile Software Development Group, Ukraine
Главный вопрос: дает ли баг трекинг система трейсебилити между
требованиями (в каком бы виде они не были), тесткейсами, реальными
тестами, багами и исходным кодом. Это самое главное качество, не
считая наличия веб интерфейса. ;)

Alexey Krivitsky

unread,
Sep 14, 2007, 6:20:36 AM9/14/07
to agile-...@googlegroups.com
как мне кажется, лучшее отслеживание связей осуществляется за счет
1. частого запуска автоматических тестов разного уровня
2. фиксировании скоупа и длины итерации (так как уменьшается количество задач и связей)
3. прозрачности прогресса внутри итерации (частое живое общение)

On 9/14/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

Артур Ракицкий

unread,
Sep 14, 2007, 6:29:53 AM9/14/07
to agile-...@googlegroups.com
"дает ли баг трекинг система трейсебилити"
DevTrack дает, если... использовать и понимать эту самую трассируемость :)
Есть (в порядке уменьшения "грубости" подхода):
а) группирование по какому-либо полю (например, по модулю/функциональной группе),
б) связывание отдельных замечаний между собой (в том числе и с поддержкой подчиненности, и между проектами/базами),
в) связывание замечаний с документами/файлами (как вложенные документы, так и ссылки),
г) связывание (а точнее интеграция) с файлами в VSS (в том числе с определенной версией).

Это из того, что есть у нас, и доступно без лишних телодвижений. Вполне вероятно, есть интеграция и других фич, о которых я не знаю :)

14.09.07, Alimenkou Nikolay <lumii.su...@gmail.com> написал(а):
Главный вопрос: дает ли баг трекинг система трейсебилити между

Артур Ракицкий

unread,
Sep 14, 2007, 6:29:53 AM9/14/07
to agile-...@googlegroups.com
"дает ли баг трекинг система трейсебилити"
DevTrack дает, если... использовать и понимать эту самую трассируемость :)
Есть (в порядке уменьшения "грубости" подхода):
а) группирование по какому-либо полю (например, по модулю/функциональной группе),
б) связывание отдельных замечаний между собой (в том числе и с поддержкой подчиненности, и между проектами/базами),
в) связывание замечаний с документами/файлами (как вложенные документы, так и ссылки),
г) связывание (а точнее интеграция) с файлами в VSS (в том числе с определенной версией).

Это из того, что есть у нас, и доступно без лишних телодвижений. Вполне вероятно, есть интеграция и других фич, о которых я не знаю :)

14.09.07, Alimenkou Nikolay <lumii.su...@gmail.com> написал(а):
Главный вопрос: дает ли баг трекинг система трейсебилити между

Alimenkou Nikolay

unread,
Sep 14, 2007, 6:49:09 AM9/14/07
to Agile Software Development Group, Ukraine
Я посмотрел демо на DevTrack и не увидел многого (может мало уделил
времени).

Меня интересуют следующие метрики:

- какое количество фичей/use case/user story покрыто тест кейсами
- какое количество тест кейсов уже имеют реальные тесты (позитивные,
негативные)
- статистика запусков этих тестов и их текущий статус
- количество и статус багов на тест кейс
- деление метрик по параметрам, таким как фаза проекта, тип тестов и
так далее

В дополнение хотелось бы отметить, что идеально было бы иметь open
source. ;)

Borys Lebeda

unread,
Sep 14, 2007, 8:53:17 AM9/14/07
to agile-...@googlegroups.com
Наши QA недавно начали использовать TestLog. До этого было найдено несколько других, но подобных продуктов, но все они напоминали расфуфыреный редактор базы данных с разным набором встроенных видов отчётности.
 
Кроме того, я сам пробовал создать подобную систему в рамках нашего проекта, но она оказалась хорошей только для меня самого :(
 
Вне сомнения, что TestLog один из лучших продуктов для анализа требований и тест кейсов, но мне кажется, что у нас просто не достаточный уровень развития QA для того, что бы они понимали какой продукт им в действитльности нужен. Хотя бы потому, что есть вопросы по организации тестирования как такового. По-моему, расчитывать на то, что наличие тулзы поможет их организовать бесполезно.
 
Моим любимым произведением по QA стала книга Рекса Блека, "Ключевые процессы тестирования ...". Там есть сюжет где лидер QA парень по имени Джамал организовывает процесс контроля качества. И надо сказать очень правильно, что они кроме MS Excel и notepad он ничем не пользовался.
 
On 9/14/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

sun

unread,
Sep 14, 2007, 8:58:28 AM9/14/07
to agile-...@googlegroups.com
ничего себе - кроме Excel ))
--
sun

Borys Lebeda

unread,
Sep 14, 2007, 9:08:33 AM9/14/07
to agile-...@googlegroups.com
На самом деле подойдёт любой более менее надёжный табличный процессор, хоть лотус один два три ... :)

Borys Lebeda

unread,
Sep 14, 2007, 9:11:54 AM9/14/07
to agile-...@googlegroups.com
Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг трекинговая система, на все эти вопросы он не может дать ответы, разве что если кастомизировать его и заставить каждого девелопера писать процент покрытия в специально отведенное поле, а каждого QA проверять всю эту ахинею. И всё это ради того, что бы один человек смог построить отчёт со светомузыкой ...
 
Овчинка выделенки не стоит :-\

 
On 9/14/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

Alexey Krivitsky

unread,
Sep 14, 2007, 9:17:03 AM9/14/07
to agile-...@googlegroups.com
в рамках http://www.globallogic.com.ua/stic/ Naresh Jain будет рассказывать про QA в Agile
8 октября.

я ещё дам анонс.

On 9/14/07, sun <aleksey....@gmail.com> wrote:

Alimenkou Nikolay

unread,
Sep 14, 2007, 9:43:18 AM9/14/07
to Agile Software Development Group, Ukraine
> Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг
> трекинговая система, на все эти вопросы он не может дать ответы, разве что
> если кастомизировать его и заставить каждого девелопера писать процент
> покрытия в специально отведенное поле, а каждого QA проверять всю эту
> ахинею. И всё это ради того, что бы один человек смог построить отчёт со
> светомузыкой ...
>
> Овчинка выделенки не стоит :-\

Вот тут не соглашусь на за что. Пример: на данный момент я имею
неплохие метрики,
которые мне даются continuous integration server и maven:

- покрытие кода тестами
- статистику по запускам тестов и их результатам
- project health из различных репортов

Дополнительно от bug tracking системы я имею отчеты по:

- количеству найденных багов
- их распределение по компонентам системы и функционалу
- привязку багов к user story/use case
- количество багов в разных состояниях и общий прогресс

НО, я никак не могу получить общий прогресс тестирования:

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

и так далее...

Часть из этого покрывает TestLog, но далеко не все. Excel - абсолютно
не приспособлен для всех
перечисленных задач и затрудняет доступ к информации (проверено на
горьком опыте).

Alimenkou Nikolay

unread,
Sep 14, 2007, 9:48:03 AM9/14/07
to Agile Software Development Group, Ukraine

On Sep 14, 4:11 pm, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг
> трекинговая система, на все эти вопросы он не может дать ответы, разве что
> если кастомизировать его и заставить каждого девелопера писать процент
> покрытия в специально отведенное поле, а каждого QA проверять всю эту
> ахинею. И всё это ради того, что бы один человек смог построить отчёт со
> светомузыкой ...
>
> Овчинка выделенки не стоит :-\


Написал ответ, но его сожрал инет :(. Предлагаю обсудить это при
встрече 9 числа.

Alexey Krivitsky

unread,
Sep 14, 2007, 9:50:08 AM9/14/07
to agile-...@googlegroups.com
на вебе ответ вижу
http://groups.google.com/group/agile-ukraine/msg/84488b8faa7faca9

On 9/14/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

sun

unread,
Sep 14, 2007, 11:01:09 AM9/14/07
to agile-...@googlegroups.com
ок. всё это круто, а теперь может быть выкатишь методолгию которая по всем этим параметрам позволит адекватно оценить стабильность системы, её юзабилити и т.д.


On 9/14/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

borys....@gmail.com

unread,
Sep 14, 2007, 11:27:19 AM9/14/07
to Agile Software Development Group, Ukraine
Что такое project health я не знаю
Метрики по девелопменту и по дев-трекингу у меня есть для проектов из
управляемого кода (Попытка сделать мало-мальски адекватное покрытие
для VB закончилось ничем). На вопросы, на которые и не может найти
ответы и Николай, я попытался ответить специальными отчётами, данные
для которых должен был предоставлять каждый девелопер при закрытии
определённой задачи и тестер при открытии. Чаще всего это от них
требовало значительного усилия:
- Девелопер должен был знать как его коммит влияет на прогресс
закрытия требований или use cases
- Тестер должен был знать какие модули он протестировал.
- Заказчик должен понимать физический смысл всех этих метрик

На самом деле наличие отчёта по покрытиям требований менее важен, чем
право девелопера НЕ ЗНАТЬ и НЕ ИНТЕРЕСОВАТЬСЯ над каким требованием он
в данный момент работает. Бог придумал разделение труда не для того,
что бы каждый член команды знал о всех аспектах проектах. Да и не
возможно это для нашего проекта...

Borys Lebeda

unread,
Sep 14, 2007, 11:31:22 AM9/14/07
to agile-...@googlegroups.com
Вот-вот, я как раз об этом упоминал в своём предыдущем посте: это хорошо, если Твой заказчик IT компания и там есть люди, хоть краем уха знающие, что такое юнит тесты. А иначе можно влипнуть в ситуацию, когда вроде по отчётам стабильность системы и юзабилити зашкаливает, а заказчик чем-то недоволен ...

On 9/14/07, sun <aleksey....@gmail.com> wrote:

Alimenkou Nikolay

unread,
Sep 14, 2007, 1:05:40 PM9/14/07
to Agile Software Development Group, Ukraine
Вся наша дискуссия заключается в том, что вы мне пытаетесь доказать,
что то что мне требуется в действительности мне не нужно. Я не хотел
бы углубляться в специфику проекта, но поверьте на слово - нужно.
Вопрос этого топика был "Поделитесь опытом и расскажите о ваших
подходах", а не "Критикуйте вопрос и требования, которые в нем
перечислены". Если нечего рассказать на тему топика, так попросту не
пишите.

Артур Ракицкий

unread,
Sep 14, 2007, 1:57:10 PM9/14/07
to agile-...@googlegroups.com
"И всё это ради того, что бы один человек смог построить отчёт со светомузыкой ..."

Во-во! Для меня тест-кейсы не представляют ничего бОльшего, чем описания отдельных сложных алгоритмов, которые покрывают определенную часть бизнес-процесса (в идеале - бизнес-сценарий или бизнес-функцию). Все что сложнее и дольше по внедрению - от лукавого :)

14.09.07, Borys Lebeda <borys....@gmail.com> написал(а):

Артур Ракицкий

unread,
Sep 14, 2007, 2:00:41 PM9/14/07
to agile-...@googlegroups.com
"сколько реально тест кейсов покрыто" и т.д.
Похоже, проблема не в инструменте, а в организации работ. Когда продукт разбит на "удобные" части (функции, например) и эту разбивку поддерживает вся команда и заказчик, подобных вопросов не появляется.

14.09.07, Alimenkou Nikolay <lumii.su...@gmail.com> написал(а):
> Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг

Ілля Романенко

unread,
Sep 14, 2007, 2:08:22 PM9/14/07
to agile-...@googlegroups.com
Можливо комусь буде цікаво почитати цю книжку:
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

unread,
Sep 14, 2007, 7:39:08 PM9/14/07
to agile-...@googlegroups.com
а чё она такая дорогая??

Ілля Романенко

unread,
Sep 15, 2007, 3:37:02 AM9/15/07
to agile-...@googlegroups.com
мабуть тому що 2007 року

2007/9/15, Alexey Krivitsky <alexeyk...@gmail.com>:

Borys Lebeda

unread,
Sep 15, 2007, 3:44:36 AM9/15/07
to agile-...@googlegroups.com
Ничего я не пытаюсь доказать, просто мой опыт пошёл в разрез с Вашими требованиями. А другим поделится не могу, потому как на моей памяти не было, что бы какие-то метрические показатели (даже из тех, что перечисленны в Вашем посте) позволяли отследить степень удовлетворения требований заказчика. Путём долгих переговоров с заказчиком нам удалось создать роль аналитика - специального человека, который работает с требованиями и тест сьютами, при этом не смотрит в код и не смотрит в отчёты по тестированию. Я могу сколько угодно критиковать работу этого человека и самого института анализа требований, но это работает лучше, чем попытка автоматизировать этот процесс метриками. Если привести аналогию в спорте, то анализ требований скорее похож на фигурное катание, чем на пауэр лифтинг...
 
На меня, а также на Артура или Алексея, обижаться совершенно напрасно... Представьте себе, что будет в тот злополучный день, когда и Ваш опыт перестанет согласовываться с вопросом в этом посте :)

 
On 9/14/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

Borys Lebeda

unread,
Sep 15, 2007, 3:48:32 AM9/15/07
to agile-...@googlegroups.com
Мені було б цікаво. Хоча я ще не цікавився спеціалізованою літературою з QA із застосуванням підходу Agile. Може є ще які небудь книжки, хай не такі влучні?

Alimenkou Nikolay

unread,
Sep 15, 2007, 7:39:22 AM9/15/07
to Agile Software Development Group, Ukraine
On Sep 14, 9:00 pm, "Артур Ракицкий" <arty...@gmail.com> wrote:
> "сколько реально тест кейсов покрыто" и т.д.
> Похоже, проблема не в инструменте, а в организации работ. Когда продукт
> разбит на "удобные" части (функции, например) и эту разбивку поддерживает
> вся команда и заказчик, подобных вопросов не появляется.

Приведите мне пример как можно получить ответы на мои вопросы не имея
приведенных
метрик. К примеру: можно ли с точки зрения бизнеса сделать демо для
потенциальных
заказчиков. А такой заказчик может появиться в любой момент и
хотелось бы знать в каком состоянии находятся самые приоритетные
бизнес фичи.
Насколько они протестированы и какие аспекты остались незатронутыми (к
примеру
не было перформанс тестирования). Я рад послушать реальные
предложения. Причем это
всего лишь один из волнующих вопросов.

Alimenkou Nikolay

unread,
Sep 15, 2007, 7:41:02 AM9/15/07
to Agile Software Development Group, Ukraine

On Sep 15, 10:44 am, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> Ничего я не пытаюсь доказать, просто мой опыт пошёл в разрез с Вашими
> требованиями. А другим поделится не могу, потому как на моей памяти не было,
> что бы какие-то метрические показатели (даже из тех, что перечисленны
> в Вашем посте) позволяли отследить степень удовлетворения требований
> заказчика. Путём долгих переговоров с заказчиком нам удалось создать роль
> аналитика - специального человека, который работает с требованиями и тест
> сьютами, при этом не смотрит в код и не смотрит в отчёты по тестированию. Я
> могу сколько угодно критиковать работу этого человека и самого института
> анализа требований, но это работает лучше, чем попытка автоматизировать этот
> процесс метриками. Если привести аналогию в спорте, то анализ требований
> скорее похож на фигурное катание, чем на пауэр лифтинг...
>
> На меня, а также на Артура или Алексея, обижаться совершенно напрасно...
> Представьте себе, что будет в тот злополучный день, когда и Ваш опыт
> перестанет согласовываться с вопросом в этом посте :)
>


Тогда я сделаю новый пост и забуду про этот. Не хочу заглядывать на
будущее. ;)
А на счет аналитиков мне есть что рассказать. Очень хотелось бы
поделиться при встрече.
Было достаточно опыта работы с аналитиками в контрактных проектах.

Артур Ракицкий

unread,
Sep 15, 2007, 2:21:12 PM9/15/07
to agile-...@googlegroups.com
"сделать демо для
потенциальных
заказчиков. А такой заказчик может появиться в любой момент и
хотелось бы знать..."

Я же говорю, у Вас проблема не в метриках :)

Вы как позиционируете свой продукт?

а) Как коробочное решение? Ну так продавайте в магазинах, и кто захочет - тот и купит. Фокус-группу для вашего продукта и позицию относительно альтернатив и конкурентов в случае коробки вы должны были выяснить еще ДО того, как что-то разработали :) Этого нет? Значит начинайте прямо сейчас, пока не поздно. А там и по результатам исследований рынка вы сможете оценивать полноту покрытия чего бы то ни было.

б) Позиционируете как систему "под ключ"? Вы будуте ее дорабатывать под специфику бизнеса заказчика? Ну так начинать нужно (увы и ах!) не с продукта. Вероятно, ваш продукт (в сегодняшнем состоянии) реальному (а не потенциальному) заказчику даром не нужен. Прежде всего выясните его бизнес-процессы, определите те места, где нужна реальная автоматизация (а не хотелки с бубенчиками). И делать эту реальную, а не "потенциальную", работу должны люди от бизнеса. В идеале - по бизнес-аналитику с кажой стороны. И вот они должны определить требования и выяснить меру их покрытия продуктом. Причем, не на основании каких-либо авто-тестов, или отчетов о закрытии кесов/багов. А на основании живого использования продукта в тестовом цикле бизнес-процесса.

Думаю, вы занимаетесь вариантом б), на нем и остановимся.

Вы не с того места думать начинаете. Вы считаете, что продукт (система, комплекс, даже с полноценной документацией по ее использованию в определенной области) может что-то "покрывать". Это не так. Бизнес делают люди, деньги и схемы с их участием (в том чесле бизнес-процессы). Для каждого конкретного заказчика это свои "особые" люди, свои деньги и свои схемы. Начинать нужно с них, а не с "потенциальных" понятий :).

Отступим немного от моих советов :) И вернемся к Вашей просьбе.

"Приведите мне пример как можно получить ответы на мои вопросы не имея приведенных метрик."
Эта просьба содержит ссылку на ваши метрики. А значит пример, который вы просите меня привести, должен учитывать существование этих метрик, но не использовать их. Вы изначально ограничиваете метод оценки (кстати, оценки чего? выше я объяснил, что оценивать нечего :) ) метриками, которые нужно выбрать ДО разработки или в ходе, а использовать ПОСЛЕ, при демонстрации заказчику. Это ограницение делает невозможным другую организацию процесса, и в любом случае сводится к генеральному долгосрочному планированию. Не кажется ли Вам, Николай, что это ограничение вступает в некоторый конфликт с контекстом нашей беседы, а именно с Agile, который как раз и задумывался в качестве альтернативы подходу Grand Design :)
С моей точки зрения, Вы ставите собеседника в заведомо проигрышную позицию. Это как минимум некрасиво :) Так можно поступать только заведомо зная, что собеседник глуп, и желая его "ненавязчиво" подвести к вашему собственному решению. Я понимаю, в нашем бизнесе это распространенная практика, но не в группе agile-ukraine же ее применять :)

Ну и собственно про метрики. Боюсь, что Вы подумаете о том, что я (или кто-то другой из этой темы) не видит в них пользы. Это не так. Метрики полезны, но в меру :) Например, для отслеживания хода выполнения работ они незаменимы. И SCRUM (в частности) использует несколько метрик (например, сколько осталось незакрытых задач до конца спринта). Динамика их изменений служит наглядной демонстрацией эффективности работы команды. Но не демонстрацией "покрытия бизнес-потребностей".


15.09.07, Alimenkou Nikolay <lumii.su...@gmail.com> написал(а):

Borys Lebeda

unread,
Sep 15, 2007, 5:29:19 PM9/15/07
to agile-...@googlegroups.com
Верно!
 
     Я хотел написать тоже самое, но короче и лаконичнее. Мне вспомнился очень интересный случай из разговора с заказчиком.
    Я: нужно ли нам продолжать внедрять C.H. в Веб-клиент W.U.?
    Он: нет, зачем, мы ещё никому не продали Веб-клиент W.U.
    Я: но как вы его продадите если у вас не будет такой важной функциональности в вебе? Тем более что мы уже его выполнили на 50% и мы можем гарантировать его завершение через 2 недели
    Он: Запомни, Боря, сейлсы продают продукт БЕЗ ФУНКЦИОНАЛЬНОСТИ, БЕЗ ГАРАНТИЙ, а иногда и БЕЗ САМОГО ПРОДУКТА! Наше приложение O.M. было продано по презентации в Power Point.
 
Да, действительно, метрики нужны только для самого процесса разработки. У нас есть доступные средства для определения степени завершенности ТЕХНИЧЕСКИХ задач. Средства для определения степени завершенности БИЗНЕСС задач хватает у сейлсов, маркетологов и финансистов. А вот как эффективно связать БИЗНЕСС задачи с ТЕХНИЧЕСКИМи, это пожалуй наибольшая проблема IT индустрии.
 

Alimenkou Nikolay

unread,
Sep 15, 2007, 6:47:01 PM9/15/07
to Agile Software Development Group, Ukraine
Именно вам советую прочитать статью про Google, ссылка на которую не
так
давно появилась тут. Судя по вашим комментариям вы живете в некотором
иллюзорном
мире, к котором методология как вирус заняла основное место и стала
БЕЗальтернативным
решением. В вышеуказанной статье приводится неплохая цитата о том, что
нечто не признающее
альтернатив - есть глепость по существу своему. Речь идет не о
коробочных продуктах, а о
полноценном заказе со стороны представителей бизнеса на разработку
вполне конкретного
продукта. Но специфика любого бизнеса такова, что он постоянно
находится в движении и
изменяется. Так вот, для разработки данного продукта используется
итеративный процесс, в
котором сочетаются элементы 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:
> > > "сколько реально тест кейсов покрыто" и т.д.
> > > Похоже, проблема не в инструменте, а в организации работ. Когда продукт
> > > разбит на "удобные" части (функции, например) и эту разбивку
> > поддерживает
> > > вся команда и заказчик, подобных вопросов не появляется.
>
> > Приведите мне пример как можно получить ответы на мои вопросы не имея
> > приведенных
> > метрик. К примеру: можно ли с точки зрения бизнеса сделать демо для
> > потенциальных
> > заказчиков. А такой заказчик может появиться в любой момент и
> > хотелось бы знать в каком состоянии находятся самые приоритетные
> > бизнес фичи.
> > Насколько они протестированы и какие аспекты остались незатронутыми (к
> > примеру
> > не было перформанс тестирования). Я рад послушать реальные
> > предложения. Причем это
> > всего лишь один из волнующих вопросов.
>

Артур Ракицкий

unread,
Sep 16, 2007, 6:46:45 AM9/16/07
to agile-...@googlegroups.com
"Пример тому тестирование бизнесс процесса с помощью веб интерфейса. "
Либо Вы описались, и хотели сказать "тестирование веб интерфейса в рамках выполнения сценариев бизнес-процесса", либо Вы ничего не смыслите в понятии бизнес-процесс...
Прочитайте, пожалуйста, еще раз мой предыдущие ответ ПОЛНОСТЬЮ, и постарайтесь понять, что я хотел Вам объяснить. Я не привязывался ни к одной методологии в своих объяснениях. И Вы зря пытаетесь меня обвинить в каких-либо пристрастиях по этому поводу. Вчитайтесь, и поймите, что у Вас сложилось ложное впечатление. :)

"Приходит после первой половины итерации заказчик и
рассказывает о потенциальном клиенте. Просит сделать демо, но которое обязательно
должно содержать некоторые фичи."

Для таких случаев и существют:
а) управление рисками (если вы хотите показывать сырые фичи, будьте готовы устранить последствия ошибок).
б) прототипирование (как уже написал Борис, продавать можно и презентацию в Power Point).

А поспешно оценивать статус фичи - зачем? Кому Вы этим сделаете приятно? Самому себе разве что. Но при этом Вы забудете о рисках, тем самым подпилив сук, который успешно выращивали с момента начала проекта, строя эффективную систему управления проектом.

"И как аналитик или еще кто-то сможет оценить в любой момент времени работоспособность и завершенность продукта."
Неправильный вопрос (еще раз). В любой момент времени - никак. Знаете такое выражение - "дураку полработы не показывают"? Так вот, фичи в разработке - єто именно тот случай. Аналитик оценивает:
а) функциональные требования, которіе сформированы ДО разработки, и которые покрывают бизнес-требования.
б) полноту покрытия именно БИЗНЕС-требований ПОСЛЕ передачи продукта в тестовую эксплуатацию. При этом он может использовать какие угодно знания и инструменты, но обязаен в них профессионально разбираться. Именно бизнес-аналитик, а не менеджер и тем более не тестировщик (подтверждающий тест-кейсы), принимает РЕШЕНИЕ о готовности продукта. И принимать решение "на переправе меняя коней" - вот глупость, которую я Вам пытаюсь показать.

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

16.09.07, Alimenkou Nikolay <lumii.su...@gmail.com> написал(а):

Alimenkou Nikolay

unread,
Sep 17, 2007, 3:21:39 AM9/17/07
to Agile Software Development Group, Ukraine
Я там понял что лично Вы ничего полезного по теме топика сказать не
можете. Можете
обвинять меня, считать дураком, но реально то, что вы пишете - вода.
Вам бы и быть
аналитиком или работать в отделе продаж (хорошо получается замутить
воду). Устал
повторять тему топика (хотя для некоторых возможно это и бесполезно):

КАКИЕ МЕТОДИКИ, ПРАКТИКИ И ИНСТРУМЕНТЫ ИСПОЛЬЗОВАЛИСЬ ДЛЯ
ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ В 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> написал(а):

Alexey Krivitsky

unread,
Sep 17, 2007, 3:24:00 AM9/17/07
to agile-...@googlegroups.com
Господа, давайте без перехода на личности.
Reply all
Reply to author
Forward
0 new messages