Оценка работы группы автоматизации

Вот именно поэтому нужно пойти и пометить эту ветвь специальным образом, чтобы она не учитывалась при подсчёте покрытия. Потому что иначе, если мы видим при очередном запуске, что покрыто 99%, мы не можем сказать, что же осталось непокрытым -- может быть эта ветвь, а может быть в этот раз она случайно покрылась, но зато непокрытой осталась другая ветвь, которая раньше покрывалась.

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

В бесплатных я тоже не встречал. А вот Clover умеет это делать, причём несколькими разными способами:
http://confluence.at...verage Contexts
http://confluence.at...urce Directives

Мне кажется, подход изначально неправильный.
"Давайте создадим группу автоматизации и померяем её эффективность"...
А зачем Вы её создавали? Какова цель этой группы? Чего Вы хотели достичь таким образом?
Если Вы знаете, зачем Вам автоматизация - то сможете определить, добилась ли она поставленных целей. Если не знаете, зачем, то считайте эффективность в Мб/сек - показатель хороший, измеримый :)

А кто спорит? Разве я где-то сказал, что тесты, обеспечивающие полное покрытие по строкам, гарантируют обнаружение хотя бы каких-нибудь ошибок?

Я видимо не правильно понял вашу фразу:

И тогда мы сможем с уверенностью сказать, глядя на замечательное число 100%, что покрыты все существенные элементы.

А кто спорит? Разве я где-то сказал, что тесты, обеспечивающие полное покрытие по строкам, гарантируют обнаружение хотя бы каких-нибудь ошибок?

Я видимо не правильно понял вашу фразу:

И тогда мы сможем с уверенностью сказать, глядя на замечательное число 100%, что покрыты все существенные элементы.

покрыты != протестированы

В бесплатных я тоже не встречал. А вот Clover умеет это делать, причём несколькими разными способами:
http://confluence.at...verage Contexts
http://confluence.at...urce Directives

Никогда не пользовался продуктами атлазиан, но у меня к ним некое предвзятое отношение с недавних пор (если интересно могу рассказать[показать] почему, но надо с JavaOne 2009 мои фотки выложить наконец-то).
Итак.
Первый подход - регэкспы - насколько понял, это есть возможность отфильтровать кусочек кода (block content). Интересный подход, но опасный. Можно по регэкспу отфильтровать другой блок, который хочется посчитать. И еще, я могу ошибаться, но блоки в бинарном коде class-файла и блоки в языке джава (типа тех, которые в {} ) могут не совпадать. Если интересно могу дополнительно разузнать.
Второй подход не понятен. В бинарном коде (который инструментируется) нет знания о комментах. Что закловерится если я напишу так:

///CLOVER:OFF
if (a > 0){
 println(a);
///CLOVER:ON
 println(" a is positive");
}
else{
 print(" a is not positive")
}

Да и вообще, получается кловеру нужен исходник, чтобы интсрументировать байт-код?

Да и вообще, получается кловеру нужен исходник, чтобы интсрументировать байт-код?

Клевер инструментирует исходники: http://confluence.at...pageId=79986998

Про регэкспы согласен. Да и вообще -- с чего началось обсуждение -- не надо злоупотреблять этими конструкциями :)

По сути в системе ооочень много функционала который практически не меняется + большой объём уже пройденных руками тест-кейсов, хотелось бы автоматизировать пройденные тест-кейсы, а также покрыть автотестами весь редкоменяющийся функционал - это для начала, потом в идеале, я просто пока не знают возможно ли это, хотелось бы, чтобы автотесты были готовы к выпуску первой сборки в тестирование.

Это Вы рассказали план -- что вы собираетесь сделать. Но всё равно не сформулировали цель -- зачем?

затем, чтобы

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

Хотелось бы может услышать пример построения автоматизации, оценки и контроля работы...

Менеджер -- не статистик, он должен уметь работать с людьми, а не с числами.

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

Мне кажется, подход изначально неправильный.
"Давайте создадим группу автоматизации и померяем её эффективность"...
А зачем Вы её создавали? Какова цель этой группы? Чего Вы хотели достичь таким образом?
Если Вы знаете, зачем Вам автоматизация - то сможете определить, добилась ли она поставленных целей. Если не знаете, зачем, то считайте эффективность в Мб/сек - показатель хороший, измеримый :)

Согласен, спасибо!
Но отдел создавался довольно давно и без ЧЁТКИХ целей, как бы странно это не звучало...

Хотелось бы может услышать пример построения автоматизации, оценки и контроля работы...

Менеджер -- не статистик, он должен уметь работать с людьми, а не с числами.

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

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

Или с этим всё хорошо, и теперь осталось только придумать, как про всё это доложить руководству, которому "важны числа"?
То есть надо придумать способ (желательно объективный, а как же!), чтобы руководство тоже увидело, что группа работает хорошо?

Хотелось бы может услышать пример построения автоматизации, оценки и контроля работы...

Менеджер -- не статистик, он должен уметь работать с людьми, а не с числами.

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

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

Или с этим всё хорошо, и теперь осталось только придумать, как про всё это доложить руководству, которому "важны числа"?
То есть надо придумать способ (желательно объективный, а как же!), чтобы руководство тоже увидело, что группа работает хорошо?

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

Хотя, Вы меня правильно натолкнули своей дисскусией на мысль, казалось бы логичную, что нужно чётче сформулировать задачи, цели, т.е. Зачем? и тогда возможно станет яснее :)

зачем?

затем, чтобы

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

Отлично, цели поставлены. Точнее, первое и второе -- это цели, а третье -- это желание :)
Оставим в стороне вопрос о том, насколько удачно поставлены сами цели, будем считать, что удачно.

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

Цель номер один: сократить количество рутинной работы по ручному тестированию "редкоменяющегося" функционала.

Вопросы для оценки эффективности достижения этой цели:

Уменьшается ли количество рутинной ручной работы? На сколько оно сократилось за последние полгода?
Действительно ли причиной сокращения является автоматизация тестов?
Не приводит ли автоматизация к увеличению пропущенных ошибок, которые человек замечал при ручном тестировании, а инструмент не замечает?
Не эффективнее ли было просто сократить количество ручной работы, не заменяя её автоматизированными тестами?
Правильно ли применяется автоматизация? Достаточно ли хорошо выбраны инструменты, подходы, архитектура тестов?
Уменьшается ли время между внесением бага и его обнаружением, а также между внесением бага и его устранением? Важно ли кому-нибудь вообще это сокращение?
Повышается ли моральный дух тестировщиков от всей этой деятельности по автоматизации? Приводит ли это к общему увеличению производительности труда?
Не снижается ли, наоборот, моральный дух людей, занятых ручным тестированием, оттого, что их не взяли в автоматизаторы и они теперь вроде как "второсортные" тестировщики?
Не лучше ли направить усилия команды автоматизации на тестирование новой функциональности, может быть там от них было бы больше пользы?

Про вторую придумайте сами :)

зачем?

затем, чтобы

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

Отлично, цели поставлены. Точнее, первое и второе -- это цели, а третье -- это желание :)
Оставим в стороне вопрос о том, насколько удачно поставлены сами цели, будем считать, что удачно.

ну направление мыслей понятно, спасибо...
будем думать!