но в моем случае файл один

Возможно прошлый прогон теста записался в этот же файл?

думал об этом, поэтому стал вычищать папку с результатами вручную

думал об этом, поэтому стал вычищать папку с результатами вручную

../results/_${testStartDateTime}/stats.csv так намного удобнее делать)

../results/_${testStartDateTime}/stats.csv так намного удобнее делать)

спасибо)

Коллеги, привет! Поделитесь, у кого практикуется KPI для тестирования. Имеет ли место вообще вводить KPI для тестировщиков? Какие метрики использовать? Метрику "количество багов" не предлагать :)

Начальство загорелось идеей и теперь требует нововведенний от лидов. Цель ввода KPI - пока что не понимает даже само начальство, но требует предложить метрики. >____<

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

я б валил

У нас в одном проекте считали кол-ва пропущенных багов по приоритетам

Есть абстрактная цель - "увеличить лояльность клиента"

Но как ее достигать при нынешних условий - непонятно

Типа ни больше двух критикал в одной фиче

Ну, значит мерить соотношение user reported bug с найденным и вот это всё.

У нас в одном проекте считали кол-ва пропущенных багов по приоритетам

Плохая метрика.

Ну, это одна из)

Типа ни больше двух критикал в одной фиче

Не больше N не работает, можно только смотреть на соотношение найдено до продакшена \ найдено после.

Тестирование ничего не производит. В этом вся проблема

А еще считали кол-во фичей, отданных в продакшен в определенном качестве

Тестирование производит то же самое, что и разработка.

И полноту документации тестовой.

И еще чего-то, не помню уже.

Но в таком духе

Просто ненадо разделять эти процессы и будет хорошо. :)

Тестирование ничего не производит. В этом вся проблема

как же так? а кто же производит качество?

метрика "Уровень текучки кадров до и после введения KPI"

как же так? а кто же производит качество?

Разработка, очевидно. Тестирование лишь дает свой фидбек

нет

тестирование такой же вклад в код вносит

просто не прямым образом, как правило

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

просто у каждого своя часть

Не согласна. Если тестировщик заведет 10500 багов и улучшений, но разработчик и пальцем не пошевелит - качество лучше не станет.

ну да

Поэтому и метрики это условности

если разработчик не напишет код, качества тоже не будет

или если его код не задеплоят

тогда получится, что ничего не произведено

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

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

в общем, мы говорим про процессы здоровых людей, а не курильщиков

KPI тестирования - это вообще что-то странное

про разработку не скажу

KPI тестирования - это вообще что-то странное

++

В этом полностью согласна

у меня один вид KPI: количество проблем, связанных с сотрудником, о которых я знаю

Но если ничего не придумаем, то начальство введет метрику "количество багов"

поэтому такой KPI может быть только отрицательным

KPI нормально работает, если он нормально построен и все понимают что и зачем.

а расскажи

как строить кпи тестерам

Банальный production bug rate отлично показывает, что где-то что-то пошло не так.

Но если ничего не придумаем, то начальство введет метрику "количество багов"

Уж лучше на проде/к найденным

Тестером

Банальный production bug rate отлично показывает, что где-то что-то пошло не так.

это слишком общая метрика

Зависит от того, как вы её используете.

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

ну, давайте тогда на берегу разграничимся: говорим о неких персонализированных кпи, либо о показателях компании и ее отделов в целом?

Метрики не должны решать проблем, это как мониторинг. Скакнул какой-то показатель -> начал смотреть почему так.

Это скорее показатели о качестве продукта в целом.

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

Так оно и работает.

Если зарплату количеством багов мерить, то да, KPI не работает. :)

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

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

А зачем?

Если человек выполняет свои задачи хорошо - пусть ленится дальше. Если человек выполняет свои задачи плохо - это повод обсудить, что он их выполняет плохо.

:)

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

Это недоверие

ERROR: S client not available

Если человек выполняет свои задачи хорошо - пусть ленится дальше. Если человек выполняет свои задачи плохо - это повод обсудить, что он их выполняет плохо.

Вот хотят больше доказательств, чтобы было на основе чего говорить

Вот хотят больше доказательств, чтобы было на основе чего говорить

Так единственное доказательство - плохой результат.

"Если видно, что админ ничего не делает, значит он прекрасно справляется со своими обязанностями")

Это недоверие

Ага, к людям со всей душой, а они вруть и фигнёй страдають

Все ленятся иногда

Т.е. ты даешь человек задач, он их выполняет плохо - всё плохо.

Вопрос в количестве

Все ленятся иногда

Иногда – ключевое слово.

Ты даешь человеку задач, он выполняет их хорошо, а дальше смотрит котиков - это норм.

Вопрос в количестве

Для этого есть эстимейты. Оценил задачу в день - делаешь день.

Если ты думаешь что сотрудники не делают то что ты от них хочешь, то либо меняй сотрудников, либо себя

А поводу метрик...Для qa. Бывает что разрабы не мотивированы либо слишком слабые. Тогда ошибок будет гора постоянно и qa ничем не помогут

А поводу метрик...Для qa. Бывает что разрабы не мотивированы либо слишком слабые. Тогда ошибок будет гора постоянно и qa ничем не помогут

Помогут находить их до релиза.

Ну это да

Ну, т.е. не пускать задачи в продакшен до тех пор, пока критикалов там не будет. :)

Просто будет срыв сроков

А так то да

По вине qa)

И этот срыв будет постоянно

Ну, а дальше уже быстро - дешево - хорошо.

Не...По вине багов

Вот хотят больше доказательств, чтобы было на основе чего говорить

разве то что весь день у человека будет отрыт тестируемый продукт и прочие инструменты говорит о том что он не ленится?

разве то что весь день у человека будет отрыт тестируемый продукт и прочие инструменты говорит о том что он не ленится?

Нет, конечно :) Но если они открыты 4 часа на одной и той же странице…

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

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

Есть люди, которые все ещё думают "а вот он там новости читал, а мог бы ещё 30 багов найти!".

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

для продуктовой неатсорсной компании в всё верно говорите.

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

разве качество работы не снижается, если работать без перерывов?

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

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

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

А есть люди, которые нанимают команду разработки типа "Вы будете месяц писать мне код, а потом расходимся"?

О каких перерывах идёт речь? По медицине надо давать глазам отдыхать каждые 30 минут. Каждый час надо делать гимнастику. По помодоро 25-5 или 40-10. Что из этого люди делают?