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

Доброго времени суток!

Передо мной стоит задача, хотя это скорее моё желание разобраться... помогите!

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

Ныне процесс поставлен так:

• Есть море тест-кейсов которые достаточно прилично покрывают функционал системы
• Определяется область системы для покрытия автотестами
• Автоматизаторы автоматизируют :) тест-кейсы по обозначенной области

Как оценить работу при таком подходе?!

Помогите советами, стоит ли оценивать цифрами или может субъективно оценивать?!

Стоит ли смотреть на кол-во найденных автотестами багов?!

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

Спасибо!

Оценивайте в деньгах.
Простейшая оценка:
{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}

{N} - число итераций;

Оценивайте в деньгах.
Простейшая оценка:
{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}

{N} - число итераций;

Ну и ерунда!

Если уж оценивать в деньгах, то либо премией либо повышением зп. Тогда те хорошо работал поймут, что их работу оценили :).

Оценивайте в деньгах.
Простейшая оценка:
{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}

{N} - число итераций;

Ну и ерунда!

Если уж оценивать в деньгах, то либо премией либо повышением зп. Тогда те хорошо работал поймут, что их работу оценили :).

Не путайте причину и следствие. Речь шла о том как понять, кто хорошо работал, а кто - нет.

Оценивайте в деньгах.
Простейшая оценка:
{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}

{N} - число итераций;

Эм... ну у нас допустим сборки каждый день и соответственно каждый день прогоняются автотесты по функционалу... получится, что N=20(кол-во рабочих дней) и тогда {стоимость на создание автотеста/автотестов} будет астрономическая!

Не путайте причину и следствие. Речь шла о том как понять, кто хорошо работал, а кто - нет.

Только мне бы хотелось эффективность оценивать, а не только на сколько быстрей тесты прогоняются в автоматическом режеми по сравнению с ручным прогоном...

Да, количество выявленных багов - это показатель эффективности автоматизации как процесса.

Правда для оценки работы группы автоматизации слабо подходит :-)
Скорее это оценка того, кто принял решение, что данные тесты требуют автоматизации :-)

Стоит ли смотреть на кол-во найденных автотестами багов?!

Не учитываются расходы на анализ результатов и поддержку автотестов.

А вообще, считать ROI автоматизации тестирования по количеству прогонов - это некая подмена понятий.

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

Оценивайте в деньгах.
Простейшая оценка:
{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}

{N} - число итераций;

Не путайте причину и следствие. Речь шла о том как понять, кто хорошо работал, а кто - нет.

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

{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}
{N} - число итераций

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

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

И это не все претензии к данной формуле. Вы пробовали что-нибудь подсчитать с её помощью?

Да, количество выявленных багов - это показатель эффективности автоматизации как процесса.

Правда для оценки работы группы автоматизации слабо подходит :-)
Скорее это оценка того, кто принял решение, что данные тесты требуют автоматизации :-)

Не правда. Если это так, то моя текущая эффективность (как автоматизатора) или оценка (как принявшего решение) = 0. Я, в данный момент, пишу автотесты для верификации ранее найденых багов. Количество дефектов которое было ими найдено, пока 1 (дефект был не до конца починен - нашелся случай пропущенный при описании бага, при котором проблема всё ещё есть). Новых багов, найденых тестами 0.
Хотя я тут немного лукавлю, т.к. при написании тестов и анализе результатов какие-то дефекты находятся и на них пишутся новые тесты, которые я запущу и добавлю в общий набор при верификации багов, после их починки. Но факт в том, что они не найдены регрессионными автотестами. И мечтать о том, что регрессионный тестовый набор будет находить много багов можно только если у вас не разработчики, а бригада неквалифицированных борзописцев, ходящих по одним и тем же граблям.

{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}
{N} - число итераций

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

смею предположить, что это не минус, а как бы равно :) т.е. {Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - это {стоимость на создание автотеста/автотестов}

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

В таком случае, как понять руководителю кто хорошо работает?! :)

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

Не правда. Если это так, то моя текущая эффективность (как автоматизатора) или оценка (как принявшего решение) = 0. Я, в данный момент, пишу автотесты для верификации ранее найденых багов. Количество дефектов которое было ими найдено, пока 1 (дефект был не до конца починен - нашелся случай пропущенный при описании бага, при котором проблема всё ещё есть). Новых багов, найденых тестами 0.

Не путайте причину и следствие. Речь шла о том как понять, кто хорошо работал, а кто - нет.

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

{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}
{N} - число итераций

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

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

И это не все претензии к данной формуле. Вы пробовали что-нибудь подсчитать с её помощью?

Я привел простейшую формулу для рассчета экономической выгоды авт. тестирования. Если ее можно применить ко всему отделу/группе тестирования, то можно привезти ее к отдельно взятому автоматизатору.
Стоимость создания автотестов это время * стоимость часа авт. тестировщика.(если N >1 то + поддержка автотестов). Всегда можно взять среднюю стоимость стоимости часа специалиста. На результат оценки эффективности работы это практически не влияет.
Я считаю, что оценка руководителя тоже вполне нормальный вариант. Но бывают случаю, когда необходимо привезти более весомые доводы чем эта субъективная оценка(объяснить автоматизатору почему у него именно такой "весовой коофициент", для вышестоящего начальства).
Если вы автоматизируете ради автоматизации это ваше дело. Если вы же что-то считаете приведите свою формулу.
Наверняка она у вас "большая", со множеством парметров, учитывает разные факторы и внешние воздействия ;)

{Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - {стоимость на создание автотеста/автотестов}
{N} - число итераций

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

смею предположить, что это не минус, а как бы равно :) т.е. {Время прогона ручных теста/тестов в часах} * {стоимость часа работы ручного тестера}* {N} - это {стоимость на создание автотеста/автотестов}

Именно минус. Просто в большинстве случаев у вас легко может получится отрицательная величина. Но это уже говорит о том, что автоматизация убыточна. Даже в этом случае вы наверняка умеете сравнивать отрицательные числа;)
Например я совмещаю как ручное так и автоматическое тестирование и для меня быстрее или сравнимо по времени написать закодировать автотест (это относится только к функциональным и нагрузочным видам тестов).
Стоимость часа специалиста ручного и автотестера я принимаю одинаковой (грубо говоря моя часовая зарплата).
Согласно формуле для 1 прогона ( N =1) моя эффективность около 0. Для с возрастанием N (если тесты не приходится изменять/поддерживтаь) эффективность растет.

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

А вывод какой? Не писать автотесты?
У меня продукт командлайновый и в нём мало места для ручного тестирования. Чтобы проверить, надо написать скрипт (+данные +разные вариации проверить). Я так или иначе это делаю, но если меня посчитать получается, что работаю впустую... но я-то знаю, что не впустую :) Парадокс.

Если вы автоматизируете ради автоматизации это ваше дело. Если вы же что-то считаете приведите свою формулу.
Наверняка она у вас "большая", со множеством парметров, учитывает разные факторы и внешние воздействия ;)

Нет, автоматизирую, т.к. иначе не проверить (утилита командной строки).
Считать что-то по формуле мне, к счастью, ничего не надо. (Плюю во все стороны и стучу по дереву).

Стоимость создания автотестов это время * стоимость часа авт. тестировщика.(если N >1 то + поддержка автотестов). Всегда можно взять среднюю стоимость стоимости часа специалиста. На результат оценки эффективности работы это практически не влияет.

Солдат спит служба идёт? Количество тестов никак не должно учитываться? Если должно, то что лучше один большой сценарный тест, несколько средних или куча-мала маленьких?

Стоимость создания автотестов это время * стоимость часа авт. тестировщика.(если N >1 то + поддержка автотестов). Всегда можно взять среднюю стоимость стоимости часа специалиста. На результат оценки эффективности работы это практически не влияет.

Солдат спит служба идёт? Количество тестов никак не должно учитываться? Если должно, то что лучше один большой сценарный тест, несколько средних или куча-мала маленьких?

Параметр {кол-во тестов} в формуле в явном виде не фигирирует. Однако время на разработку автотестов/поддержку/выполнения ручных вариантов тестов можно указать для 1 теста так и просуммировать для нескольких тестов. Я бы анализировал работу каждого автотестировщика за период (к примеру месяц). В этом случае не важно напишешь 100 маленьких или 1 большой, зависит от ваших потребностей. Если тест-кейсы "независимые" (предполагается выполнять запуск не всех, а только 1,2...10, то лигичнее будет разбить), если же тест-кейсы "единые" - достаточно 1 большого.

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

Писать автотесты по тест-дизайну, а не по багам :-)

Авто-тесты гоняют часто не потому, что это реально нужно, а потому, что это относительно дешево.
Допустим, авто-тесты все разом сломались, а сборку нужно отдать срочно. Какой объем тестов нужно будет прогнать вручную, чтобы выпустить сборку?

А вывод какой? Не писать автотесты?