Я решил открыть новую тему для дискуссий, потому как для меня она является одной из наиболее спорных среди разработчиков и QA. Я не раз участвовал в дискуссиях на тему в каком виде должны предоставляться требования для написания тест кейсов, должны ли быть тест кейсы вообще и когда/кто должен ими заниматься. Agile методологии накладывают некоторые ограничения на работу с требованиями, но в то же время позволяют повысить уровень надежности кода за счет покрытия тестами, парного программирования и других практик. Но все же проверка приложения с точки зрения бизнеса будет присутствовать. Хотелось бы узнать какие подходы/средства кто использовал для этого? Я искал tool для хранения и работы с тесткейсами. Лично мне из open source не понравилось ничего. Из платных я успел посмотреть только на TestLog. Он понравился по функционалу очень, но он не имеет web интерфейса и написан только под винду. Интересно послушать мнения.
P.S. На размышления навела книжка (кто не читал может будет интересно): Wiley - Software Testing
> Я решил открыть новую тему для дискуссий, потому как для меня она > является одной из наиболее спорных среди разработчиков и QA. Я не раз > участвовал в дискуссиях на тему в каком виде должны предоставляться > требования для написания тест кейсов, должны ли быть тест кейсы вообще > и когда/кто должен ими заниматься. Agile методологии накладывают > некоторые ограничения на работу с требованиями, но в то же время > позволяют повысить уровень надежности кода за счет покрытия тестами, > парного программирования и других практик. Но все же проверка > приложения с точки зрения бизнеса будет присутствовать. Хотелось бы > узнать какие подходы/средства кто использовал для этого? Я искал tool > для хранения и работы с тесткейсами. Лично мне из open source не > понравилось ничего. Из платных я успел посмотреть только на TestLog. > Он понравился по функционалу очень, но он не имеет web интерфейса и > написан только под винду. Интересно послушать мнения.
> P.S. На размышления навела книжка (кто не читал может будет > интересно): Wiley - Software Testing
>как на счет wiki для хранения тест-кейсов? acceptance тестов? >тогда каждый член команды может участвовать в наполнении
Проблема wiki в том, что это по сути простой блокнот, который не приспособен под специфические задачи. В данном случае хотелось бы иметь удобство в добавлении тест кейса, набор необходимых полей, выбор типа тестирования (функциональный, структурный, интеграционный и так далее), выбор этапа тестирования (разработка, интеграция, инсталляция и так далее), привязка к реальным тестам и их результатам, получение отчетов по текущему состоянию тестирования, которые могут быть использованы для дальшейшего анализа и предугадывания поведения проектра в реальном использовании (процент багов, найденных пользователями). Взгляни к примеру на тот же TestLog, у них есть демо инсталляк.
если мы говорим про тестирование в agile проектах, то я бы предпочел говорить о тулзах, которые не заменяют общения, предоставляя информацию по "предугадыванию поведения проекта", а лишь помогают команде общаться более эффективно.
On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> >как на счет wiki для хранения тест-кейсов? acceptance тестов? > >тогда каждый член команды может участвовать в наполнении
> Проблема wiki в том, что это по сути простой блокнот, который не > приспособен под специфические задачи. В данном случае хотелось бы > иметь удобство в добавлении тест кейса, набор необходимых полей, выбор > типа тестирования (функциональный, структурный, интеграционный и так > далее), выбор этапа тестирования (разработка, интеграция, инсталляция > и так далее), привязка к реальным тестам и их результатам, получение > отчетов по текущему состоянию тестирования, которые могут быть > использованы для дальшейшего анализа и предугадывания поведения > проектра в реальном использовании (процент багов, найденных > пользователями). Взгляни к примеру на тот же TestLog, у них есть демо > инсталляк.
> Мне эти пожелания кажуться слишком сложными, и возможно возникающими при > работе по классической методологии.
Очень хотелось бы узнать об альтернативных подходах к тестированию (к примеру в Scrum). У QA нету опыта работы в подобных методологиях и хотелось бы осуществить мягкий переход.
> Во первых, предполагается, что все типы тестов(функциональное, > интеграционное, структурный тест) можно реализовать с помощи одного тула.
Никак они не могут быть организованы с помощью одного тула, потому что перформанс и лоад тестирование отделено от остального, так же как и тестирование окружения, тестирование сети и софта, юнит тестирование, статическое тестирование пользовательской документации, тестирование инсталляции продукта (если она есть) и мануальное тестирование функционала.
> Во вторых, если так специфицировать тесты, то не понятно, как вы их будете > привязывать к результатам выполнения.
Вот это как раз интересный вопрос. Это может быть мануальный процесс. К примеру некоторые тулзы дают возможность проставлять логи запусков со статусом. Это очень удобно для репортов.
> Также у меня вопрос - почему не использовать для получения текущего > состояния тестирования баг трекинг систему ?
Баг трекинг система отражает лишь наличие багов и не дает информации какое количество user story или use case реально покрыто тестами, каков их текущий статус и какова тенденция. Необходима интеграция с баг трекинг системой, чтобы иметь информацию о количестве багов на тест кейс (а соответственно на user story или use case) для анализа и принятия решений.
> Кто является реальным заказчиком/пользователем тулзы, о который вы хотели бы > пользоваться ?
Не совсем понял вопрос. Ее хотелось бы использовать в проекте для процесса тестирования.
"Также у меня вопрос - почему не использовать для получения текущего состояния тестирования баг трекинг систему ?" Я тоже подумал именно о таком вопросе/ответе :)
Сейчас мы используем DevTrack, в котором я планирую, вести не только замечания и ошибки (как делается в проектах, доставшихся мне "по наследству"), но и требования и тест-кейсы, привязанные к этим требованиям. Все необходимое для определения и отслеживания состояний в каждой из баз знаний (баги, требования, тест-кейсы) в данном продукте есть. Остается только настроить и прописать регламент использования для команды :)
К слову, не вижу большого смысла в отдельных "специализированных" инструментах для ведения каждой из деятельностей. В любом случае бОльшая часть знаний (читай, текста) будет лежать лишь в одной из баз. На разных этапах зрелости продукта это могут быть разные базы, но "подводя итоги" все равно нужно составлять как общий перечень изменений (или вообще требований), так и краткий обзор того, что не сделано, но хотелось бы. И источники для этого - все три базы знаний. Из этих соображений я и считаю, что один инструмент, пусть и не супер-функциональный, лучше, чем 3 "идеальных". Да и в плане поддержки такая конфигурация среды проще :) 14.09.07, Serhiy Yevtushenko <syevtushe...@gmail.com> написал(а):
"Баг трекинг система отражает лишь наличие багов и не дает информации какое количество" Это какая-то сильно "негибкая" (non-agile, хе-хе :) ) система... Я уже не помню, когда последний раз сталкивался с подобными продуктами. Возможно, вам стоит детальнее изучить один из гибких продуктов, и не отбрасывать его по-умолчанию, а трезво оценить возможности по адаптации? Ведь нам с вами нужно создавать хорошие продукты, а не хорошие среды для разработки этих продуктов ;) Или, как минимум, второе не должно мешать первому.
14.09.07, Alimenkou Nikolay <lumii.subscri...@gmail.com> написал(а):
> > Мне эти пожелания кажуться слишком сложными, и возможно возникающими при > > работе по классической методологии.
> Очень хотелось бы узнать об альтернативных подходах к тестированию (к > примеру > в Scrum). У QA нету опыта работы в подобных методологиях и хотелось > бы осуществить мягкий переход.
> > Во первых, предполагается, что все типы тестов(функциональное, > > интеграционное, структурный тест) можно реализовать с помощи одного > тула.
> Никак они не могут быть организованы с помощью одного тула, потому > что > перформанс и лоад тестирование отделено от остального, так же как и > тестирование > окружения, тестирование сети и софта, юнит тестирование, статическое > тестирование > пользовательской документации, тестирование инсталляции продукта (если > она есть) > и мануальное тестирование функционала.
> > Во вторых, если так специфицировать тесты, то не понятно, как вы их > будете > > привязывать к результатам выполнения.
> Вот это как раз интересный вопрос. Это может быть мануальный процесс. > К примеру > некоторые тулзы дают возможность проставлять логи запусков со > статусом. Это очень > удобно для репортов.
> > Также у меня вопрос - почему не использовать для получения текущего > > состояния тестирования баг трекинг систему ?
> Баг трекинг система отражает лишь наличие багов и не дает информации > какое количество > user story или use case реально покрыто тестами, каков их текущий > статус и какова тенденция. > Необходима интеграция с баг трекинг системой, чтобы иметь информацию о > количестве багов > на тест кейс (а соответственно на user story или use case) для анализа > и принятия решений.
> > Кто является реальным заказчиком/пользователем тулзы, о который вы > хотели бы > > пользоваться ?
> Не совсем понял вопрос. Ее хотелось бы использовать в проекте для > процесса тестирования.
> Я решил открыть новую тему для дискуссий, потому как для меня она > является одной из наиболее спорных среди разработчиков и QA. Я не раз > участвовал в дискуссиях на тему в каком виде должны предоставляться > требования для написания тест кейсов, должны ли быть тест кейсы вообще > и когда/кто должен ими заниматься. Agile методологии накладывают > некоторые ограничения на работу с требованиями, но в то же время > позволяют повысить уровень надежности кода за счет покрытия тестами, > парного программирования и других практик. Но все же проверка > приложения с точки зрения бизнеса будет присутствовать. Хотелось бы > узнать какие подходы/средства кто использовал для этого? Я искал tool > для хранения и работы с тесткейсами. Лично мне из open source не > понравилось ничего. Из платных я успел посмотреть только на TestLog. > Он понравился по функционалу очень, но он не имеет web интерфейса и > написан только под винду. Интересно послушать мнения.
> P.S. На размышления навела книжка (кто не читал может будет > интересно): Wiley - Software Testing
Главный вопрос: дает ли баг трекинг система трейсебилити между требованиями (в каком бы виде они не были), тесткейсами, реальными тестами, багами и исходным кодом. Это самое главное качество, не считая наличия веб интерфейса. ;)
как мне кажется, лучшее отслеживание связей осуществляется за счет 1. частого запуска автоматических тестов разного уровня 2. фиксировании скоупа и длины итерации (так как уменьшается количество задач и связей) 3. прозрачности прогресса внутри итерации (частое живое общение)
On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> Главный вопрос: дает ли баг трекинг система трейсебилити между > требованиями (в каком бы виде они не были), тесткейсами, реальными > тестами, багами и исходным кодом. Это самое главное качество, не > считая наличия веб интерфейса. ;)
"дает ли баг трекинг система трейсебилити" DevTrack дает, если... использовать и понимать эту самую трассируемость :) Есть (в порядке уменьшения "грубости" подхода): а) группирование по какому-либо полю (например, по модулю/функциональной группе), б) связывание отдельных замечаний между собой (в том числе и с поддержкой подчиненности, и между проектами/базами), в) связывание замечаний с документами/файлами (как вложенные документы, так и ссылки), г) связывание (а точнее интеграция) с файлами в VSS (в том числе с определенной версией).
Это из того, что есть у нас, и доступно без лишних телодвижений. Вполне вероятно, есть интеграция и других фич, о которых я не знаю :)
14.09.07, Alimenkou Nikolay <lumii.subscri...@gmail.com> написал(а):
> Главный вопрос: дает ли баг трекинг система трейсебилити между > требованиями (в каком бы виде они не были), тесткейсами, реальными > тестами, багами и исходным кодом. Это самое главное качество, не > считая наличия веб интерфейса. ;)
"дает ли баг трекинг система трейсебилити" DevTrack дает, если... использовать и понимать эту самую трассируемость :) Есть (в порядке уменьшения "грубости" подхода): а) группирование по какому-либо полю (например, по модулю/функциональной группе), б) связывание отдельных замечаний между собой (в том числе и с поддержкой подчиненности, и между проектами/базами), в) связывание замечаний с документами/файлами (как вложенные документы, так и ссылки), г) связывание (а точнее интеграция) с файлами в VSS (в том числе с определенной версией).
Это из того, что есть у нас, и доступно без лишних телодвижений. Вполне вероятно, есть интеграция и других фич, о которых я не знаю :)
14.09.07, Alimenkou Nikolay <lumii.subscri...@gmail.com> написал(а):
> Главный вопрос: дает ли баг трекинг система трейсебилити между > требованиями (в каком бы виде они не были), тесткейсами, реальными > тестами, багами и исходным кодом. Это самое главное качество, не > считая наличия веб интерфейса. ;)
Я посмотрел демо на DevTrack и не увидел многого (может мало уделил времени).
Меня интересуют следующие метрики:
- какое количество фичей/use case/user story покрыто тест кейсами - какое количество тест кейсов уже имеют реальные тесты (позитивные, негативные) - статистика запусков этих тестов и их текущий статус - количество и статус багов на тест кейс - деление метрик по параметрам, таким как фаза проекта, тип тестов и так далее
В дополнение хотелось бы отметить, что идеально было бы иметь open source. ;)
Наши QA недавно начали использовать TestLog. До этого было найдено несколько других, но подобных продуктов, но все они напоминали расфуфыреный редактор базы данных с разным набором встроенных видов отчётности.
Кроме того, я сам пробовал создать подобную систему в рамках нашего проекта, но она оказалась хорошей только для меня самого :(
Вне сомнения, что TestLog один из лучших продуктов для анализа требований и тест кейсов, но мне кажется, что у нас просто не достаточный уровень развития QA для того, что бы они понимали какой продукт им в действитльности нужен. Хотя бы потому, что есть вопросы по организации тестирования как такового. По-моему, расчитывать на то, что наличие тулзы поможет их организовать бесполезно.
Моим любимым произведением по QA стала книга Рекса Блека, "Ключевые процессы тестирования ...". Там есть сюжет где лидер QA парень по имени Джамал организовывает процесс контроля качества. И надо сказать очень правильно, что они кроме MS Excel и notepad он ничем не пользовался.
On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> Я решил открыть новую тему для дискуссий, потому как для меня она > является одной из наиболее спорных среди разработчиков и QA. Я не раз > участвовал в дискуссиях на тему в каком виде должны предоставляться > требования для написания тест кейсов, должны ли быть тест кейсы вообще > и когда/кто должен ими заниматься. Agile методологии накладывают > некоторые ограничения на работу с требованиями, но в то же время > позволяют повысить уровень надежности кода за счет покрытия тестами, > парного программирования и других практик. Но все же проверка > приложения с точки зрения бизнеса будет присутствовать. Хотелось бы > узнать какие подходы/средства кто использовал для этого? Я искал tool > для хранения и работы с тесткейсами. Лично мне из open source не > понравилось ничего. Из платных я успел посмотреть только на TestLog. > Он понравился по функционалу очень, но он не имеет web интерфейса и > написан только под винду. Интересно послушать мнения.
> P.S. На размышления навела книжка (кто не читал может будет > интересно): Wiley - Software Testing
> Наши QA недавно начали использовать TestLog. До этого было найдено > несколько других, но подобных продуктов, но все они напоминали расфуфыреный > редактор базы данных с разным набором встроенных видов отчётности.
> Кроме того, я сам пробовал создать подобную систему в рамках нашего > проекта, но она оказалась хорошей только для меня самого :(
> Вне сомнения, что TestLog один из лучших продуктов для анализа требований > и тест кейсов, но мне кажется, что у нас просто не достаточный уровень > развития QA для того, что бы они понимали какой продукт им в действитльности > нужен. Хотя бы потому, что есть вопросы по организации тестирования как > такового. По-моему, расчитывать на то, что наличие тулзы поможет их > организовать бесполезно.
> Моим любимым произведением по QA стала книга Рекса Блека, "Ключевые > процессы тестирования ...". Там есть сюжет где лидер QA парень по имени > Джамал организовывает процесс контроля качества. И надо сказать очень > правильно, что они кроме MS Excel и notepad он ничем не пользовался.
> On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > Я решил открыть новую тему для дискуссий, потому как для меня она > > является одной из наиболее спорных среди разработчиков и QA. Я не раз > > участвовал в дискуссиях на тему в каком виде должны предоставляться > > требования для написания тест кейсов, должны ли быть тест кейсы вообще > > и когда/кто должен ими заниматься. Agile методологии накладывают > > некоторые ограничения на работу с требованиями, но в то же время > > позволяют повысить уровень надежности кода за счет покрытия тестами, > > парного программирования и других практик. Но все же проверка > > приложения с точки зрения бизнеса будет присутствовать. Хотелось бы > > узнать какие подходы/средства кто использовал для этого? Я искал tool > > для хранения и работы с тесткейсами. Лично мне из open source не > > понравилось ничего. Из платных я успел посмотреть только на TestLog. > > Он понравился по функционалу очень, но он не имеет web интерфейса и > > написан только под винду. Интересно послушать мнения.
> > P.S. На размышления навела книжка (кто не читал может будет > > интересно): Wiley - Software Testing
> On 9/14/07, Borys Lebeda <borys.leb...@gmail.com> wrote:
> > Наши QA недавно начали использовать TestLog. До этого было найдено > > несколько других, но подобных продуктов, но все они напоминали расфуфыреный > > редактор базы данных с разным набором встроенных видов отчётности.
> > Кроме того, я сам пробовал создать подобную систему в рамках нашего > > проекта, но она оказалась хорошей только для меня самого :(
> > Вне сомнения, что TestLog один из лучших продуктов для анализа > > требований и тест кейсов, но мне кажется, что у нас просто не достаточный > > уровень развития QA для того, что бы они понимали какой продукт им в > > действитльности нужен. Хотя бы потому, что есть вопросы по организации > > тестирования как такового. По-моему, расчитывать на то, что наличие тулзы > > поможет их организовать бесполезно.
> > Моим любимым произведением по QA стала книга Рекса Блека, "Ключевые > > процессы тестирования ...". Там есть сюжет где лидер QA парень по имени > > Джамал организовывает процесс контроля качества. И надо сказать очень > > правильно, что они кроме MS Excel и notepad он ничем не пользовался.
> > On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> > > Я решил открыть новую тему для дискуссий, потому как для меня она > > > является одной из наиболее спорных среди разработчиков и QA. Я не раз > > > участвовал в дискуссиях на тему в каком виде должны предоставляться > > > требования для написания тест кейсов, должны ли быть тест кейсы вообще > > > и когда/кто должен ими заниматься. Agile методологии накладывают > > > некоторые ограничения на работу с требованиями, но в то же время > > > позволяют повысить уровень надежности кода за счет покрытия тестами, > > > парного программирования и других практик. Но все же проверка > > > приложения с точки зрения бизнеса будет присутствовать. Хотелось бы > > > узнать какие подходы/средства кто использовал для этого? Я искал tool > > > для хранения и работы с тесткейсами. Лично мне из open source не > > > понравилось ничего. Из платных я успел посмотреть только на TestLog. > > > Он понравился по функционалу очень, но он не имеет web интерфейса и > > > написан только под винду. Интересно послушать мнения.
> > > P.S. На размышления навела книжка (кто не читал может будет > > > интересно): Wiley - Software Testing
Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг трекинговая система, на все эти вопросы он не может дать ответы, разве что если кастомизировать его и заставить каждого девелопера писать процент покрытия в специально отведенное поле, а каждого QA проверять всю эту ахинею. И всё это ради того, что бы один человек смог построить отчёт со светомузыкой ...
Овчинка выделенки не стоит :-\
On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> Я посмотрел демо на DevTrack и не увидел многого (может мало уделил > времени).
> Меня интересуют следующие метрики:
> - какое количество фичей/use case/user story покрыто тест кейсами > - какое количество тест кейсов уже имеют реальные тесты (позитивные, > негативные) > - статистика запусков этих тестов и их текущий статус > - количество и статус багов на тест кейс > - деление метрик по параметрам, таким как фаза проекта, тип тестов и > так далее
> В дополнение хотелось бы отметить, что идеально было бы иметь open > source. ;)
> On 9/14/07, Borys Lebeda <borys.leb...@gmail.com> wrote:
> > Наши QA недавно начали использовать TestLog. До этого было найдено > > несколько других, но подобных продуктов, но все они напоминали расфуфыреный > > редактор базы данных с разным набором встроенных видов отчётности.
> > Кроме того, я сам пробовал создать подобную систему в рамках нашего > > проекта, но она оказалась хорошей только для меня самого :(
> > Вне сомнения, что TestLog один из лучших продуктов для анализа > > требований и тест кейсов, но мне кажется, что у нас просто не достаточный > > уровень развития QA для того, что бы они понимали какой продукт им в > > действитльности нужен. Хотя бы потому, что есть вопросы по организации > > тестирования как такового. По-моему, расчитывать на то, что наличие тулзы > > поможет их организовать бесполезно.
> > Моим любимым произведением по QA стала книга Рекса Блека, "Ключевые > > процессы тестирования ...". Там есть сюжет где лидер QA парень по имени > > Джамал организовывает процесс контроля качества. И надо сказать очень > > правильно, что они кроме MS Excel и notepad он ничем не пользовался.
> > On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> > > Я решил открыть новую тему для дискуссий, потому как для меня она > > > является одной из наиболее спорных среди разработчиков и QA. Я не раз > > > участвовал в дискуссиях на тему в каком виде должны предоставляться > > > требования для написания тест кейсов, должны ли быть тест кейсы вообще > > > и когда/кто должен ими заниматься. Agile методологии накладывают > > > некоторые ограничения на работу с требованиями, но в то же время > > > позволяют повысить уровень надежности кода за счет покрытия тестами, > > > парного программирования и других практик. Но все же проверка > > > приложения с точки зрения бизнеса будет присутствовать. Хотелось бы > > > узнать какие подходы/средства кто использовал для этого? Я искал tool > > > для хранения и работы с тесткейсами. Лично мне из open source не > > > понравилось ничего. Из платных я успел посмотреть только на TestLog. > > > Он понравился по функционалу очень, но он не имеет web интерфейса и > > > написан только под винду. Интересно послушать мнения.
> > > P.S. На размышления навела книжка (кто не читал может будет > > > интересно): Wiley - Software Testing
> Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг > трекинговая система, на все эти вопросы он не может дать ответы, разве что > если кастомизировать его и заставить каждого девелопера писать процент > покрытия в специально отведенное поле, а каждого QA проверять всю эту > ахинею. И всё это ради того, что бы один человек смог построить отчёт со > светомузыкой ...
> Овчинка выделенки не стоит :-\
Вот тут не соглашусь на за что. Пример: на данный момент я имею неплохие метрики, которые мне даются continuous integration server и maven:
- покрытие кода тестами - статистику по запускам тестов и их результатам - project health из различных репортов
Дополнительно от bug tracking системы я имею отчеты по:
- количеству найденных багов - их распределение по компонентам системы и функционалу - привязку багов к user story/use case - количество багов в разных состояниях и общий прогресс
НО, я никак не могу получить общий прогресс тестирования:
- сколько реально тест кейсов покрыто (может все мои тесты - просто для 5 тест кейсов) - сколько функциональности адекватно покрыто тест кейсами, причем возможно без реальных тестов, потому как кода нет и тестов нет - какое количество тестов, которые не запускаются ежедневно (или при каждом коммите) прошло и когда они запускались - насколько стабильной является система (одна из метрик, которая получается по приоритетам тест кейсов с точки зрения бизнеса), это особенно важно чтобы знать прогресс с бизнес стороны и знать его постоянно
и так далее...
Часть из этого покрывает TestLog, но далеко не все. Excel - абсолютно не приспособлен для всех перечисленных задач и затрудняет доступ к информации (проверено на горьком опыте).
On Sep 14, 4:11 pm, "Borys Lebeda" <borys.leb...@gmail.com> wrote:
> Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг > трекинговая система, на все эти вопросы он не может дать ответы, разве что > если кастомизировать его и заставить каждого девелопера писать процент > покрытия в специально отведенное поле, а каждого QA проверять всю эту > ахинею. И всё это ради того, что бы один человек смог построить отчёт со > светомузыкой ...
> Овчинка выделенки не стоит :-\
Написал ответ, но его сожрал инет :(. Предлагаю обсудить это при встрече 9 числа.
> On Sep 14, 4:11 pm, "Borys Lebeda" <borys.leb...@gmail.com> wrote: > > Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг > > трекинговая система, на все эти вопросы он не может дать ответы, разве > что > > если кастомизировать его и заставить каждого девелопера писать процент > > покрытия в специально отведенное поле, а каждого QA проверять всю эту > > ахинею. И всё это ради того, что бы один человек смог построить отчёт со > > светомузыкой ...
> > Овчинка выделенки не стоит :-\
> Написал ответ, но его сожрал инет :(. Предлагаю обсудить это при > встрече 9 числа.
ок. всё это круто, а теперь может быть выкатишь методолгию которая по всем этим параметрам позволит адекватно оценить стабильность системы, её юзабилити и т.д.
On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг > > трекинговая система, на все эти вопросы он не может дать ответы, разве > что > > если кастомизировать его и заставить каждого девелопера писать процент > > покрытия в специально отведенное поле, а каждого QA проверять всю эту > > ахинею. И всё это ради того, что бы один человек смог построить отчёт со > > светомузыкой ...
> > Овчинка выделенки не стоит :-\
> Вот тут не соглашусь на за что. Пример: на данный момент я имею > неплохие метрики, > которые мне даются continuous integration server и maven:
> - покрытие кода тестами > - статистику по запускам тестов и их результатам > - project health из различных репортов
> Дополнительно от bug tracking системы я имею отчеты по:
> - количеству найденных багов > - их распределение по компонентам системы и функционалу > - привязку багов к user story/use case > - количество багов в разных состояниях и общий прогресс
> НО, я никак не могу получить общий прогресс тестирования:
> - сколько реально тест кейсов покрыто (может все мои тесты - просто > для 5 тест кейсов) > - сколько функциональности адекватно покрыто тест кейсами, причем > возможно без > реальных тестов, потому как кода нет и тестов нет > - какое количество тестов, которые не запускаются ежедневно (или при > каждом коммите) > прошло и когда они запускались > - насколько стабильной является система (одна из метрик, которая > получается по приоритетам > тест кейсов с точки зрения бизнеса), это особенно важно чтобы знать > прогресс с бизнес стороны > и знать его постоянно
> и так далее...
> Часть из этого покрывает TestLog, но далеко не все. Excel - абсолютно > не приспособлен для всех > перечисленных задач и затрудняет доступ к информации (проверено на > горьком опыте).
Что такое project health я не знаю Метрики по девелопменту и по дев-трекингу у меня есть для проектов из управляемого кода (Попытка сделать мало-мальски адекватное покрытие для VB закончилось ничем). На вопросы, на которые и не может найти ответы и Николай, я попытался ответить специальными отчётами, данные для которых должен был предоставлять каждый девелопер при закрытии определённой задачи и тестер при открытии. Чаще всего это от них требовало значительного усилия: - Девелопер должен был знать как его коммит влияет на прогресс закрытия требований или use cases - Тестер должен был знать какие модули он протестировал. - Заказчик должен понимать физический смысл всех этих метрик
На самом деле наличие отчёта по покрытиям требований менее важен, чем право девелопера НЕ ЗНАТЬ и НЕ ИНТЕРЕСОВАТЬСЯ над каким требованием он в данный момент работает. Бог придумал разделение труда не для того, что бы каждый член команды знал о всех аспектах проектах. Да и не возможно это для нашего проекта...
Alimenkou Nikolay wrote: > > Мы сейчас пользуемся devTrack. Это не анализ требований - это именно баг > > трекинговая система, на все эти вопросы он не может дать ответы, разве что > > если кастомизировать его и заставить каждого девелопера писать процент > > покрытия в специально отведенное поле, а каждого QA проверять всю эту > > ахинею. И всё это ради того, что бы один человек смог построить отчёт со > > светомузыкой ...
> > Овчинка выделенки не стоит :-\
> Вот тут не соглашусь на за что. Пример: на данный момент я имею > неплохие метрики, > которые мне даются continuous integration server и maven:
> - покрытие кода тестами > - статистику по запускам тестов и их результатам > - project health из различных репортов
> Дополнительно от bug tracking системы я имею отчеты по:
> - количеству найденных багов > - их распределение по компонентам системы и функционалу > - привязку багов к user story/use case > - количество багов в разных состояниях и общий прогресс
> НО, я никак не могу получить общий прогресс тестирования:
> - сколько реально тест кейсов покрыто (может все мои тесты - просто > для 5 тест кейсов) > - сколько функциональности адекватно покрыто тест кейсами, причем > возможно без > реальных тестов, потому как кода нет и тестов нет > - какое количество тестов, которые не запускаются ежедневно (или при > каждом коммите) > прошло и когда они запускались > - насколько стабильной является система (одна из метрик, которая > получается по приоритетам > тест кейсов с точки зрения бизнеса), это особенно важно чтобы знать > прогресс с бизнес стороны > и знать его постоянно
> и так далее...
> Часть из этого покрывает TestLog, но далеко не все. Excel - абсолютно > не приспособлен для всех > перечисленных задач и затрудняет доступ к информации (проверено на > горьком опыте).
Вот-вот, я как раз об этом упоминал в своём предыдущем посте: это хорошо, если Твой заказчик IT компания и там есть люди, хоть краем уха знающие, что такое юнит тесты. А иначе можно влипнуть в ситуацию, когда вроде по отчётам стабильность системы и юзабилити зашкаливает, а заказчик чем-то недоволен ...
On 9/14/07, sun <aleksey.solnt...@gmail.com> wrote:
> ок. всё это круто, а теперь может быть выкатишь методолгию которая по всем > этим параметрам позволит адекватно оценить стабильность системы, её > юзабилити и т.д.
> On 9/14/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > > Мы сейчас пользуемся devTrack. Это не анализ требований - это именно > > баг > > > трекинговая система, на все эти вопросы он не может дать ответы, разве > > что > > > если кастомизировать его и заставить каждого девелопера писать процент
> > > покрытия в специально отведенное поле, а каждого QA проверять всю эту > > > ахинею. И всё это ради того, что бы один человек смог построить отчёт > > со > > > светомузыкой ...
> > > Овчинка выделенки не стоит :-\
> > Вот тут не соглашусь на за что. Пример: на данный момент я имею > > неплохие метрики, > > которые мне даются continuous integration server и maven:
> > - покрытие кода тестами > > - статистику по запускам тестов и их результатам > > - project health из различных репортов
> > Дополнительно от bug tracking системы я имею отчеты по:
> > - количеству найденных багов > > - их распределение по компонентам системы и функционалу > > - привязку багов к user story/use case > > - количество багов в разных состояниях и общий прогресс
> > НО, я никак не могу получить общий прогресс тестирования:
> > - сколько реально тест кейсов покрыто (может все мои тесты - просто > > для 5 тест кейсов) > > - сколько функциональности адекватно покрыто тест кейсами, причем > > возможно без > > реальных тестов, потому как кода нет и тестов нет > > - какое количество тестов, которые не запускаются ежедневно (или при > > каждом коммите) > > прошло и когда они запускались > > - насколько стабильной является система (одна из метрик, которая > > получается по приоритетам > > тест кейсов с точки зрения бизнеса), это особенно важно чтобы знать > > прогресс с бизнес стороны > > и знать его постоянно
> > и так далее...
> > Часть из этого покрывает TestLog, но далеко не все. Excel - абсолютно > > не приспособлен для всех > > перечисленных задач и затрудняет доступ к информации (проверено на > > горьком опыте).
