Перейти к содержимому

Программирование на Python для тестировщиков
онлайн, начало 18 октября
Логи как инструмент тестировщика
онлайн, начало 21 октября
Тестирование REST API
онлайн, начало 21 октября
Организация автоматизированного тестирования
онлайн, начало 18 октября
Фотография

Как измерить эффективность тестировщика


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 31

#1 baranceva

baranceva

    Гуру

  • Admin
  • PipPipPipPipPipPip
  • 3 156 сообщений
  • ФИО:Баранцева Наталья


Отправлено 17 Август 2016 - 08:02

Автор: Роб Ламберт (Rob Lambert)

Оригинал статьи: http://thesocialtest...ation-you-need/

Перевод: Ольга Алифанова

 

Меня регулярно спрашивают, как измеряется эффективность тестировщика. Обычно я отвечаю "Зачем это вам? Чтобы что?" Мой ответ вызван желанием понять мотивы менеджмента: почему измерение эффективности конкретного человека так важно для них? Обычно этот вопрос задают именно менеджеры.

 

Конечно, важно знать, насколько хорошо человек справляется со своей работой и достигает поставленных целей. Но не менее важно понимать, что движет теми, кто пытается это измерять. Это делается, чтобы развивать и улучшать сотрудника, предоставить ему возможности для обучения и поддержку? Или исходя из чисто коммерческих соображений?

 

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

 

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

 

Как правило, они пытаются измерять две вещи. Во-первых, одинаково ли ценны тестировщик А и тестировщик Б? Можем ли мы поменять их местами и продолжать достигать своих целей? Может, один из них лучше другого?

 

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

 

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

Звучит бредово, но встречается достаточно часто! Менеджеры любят простые метрики для принятия информированных решений.

 

Читать статью полностью...


  • 0
Наталья Баранцева
Тренинги по тестированию ПО

#2 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 611 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 17 Август 2016 - 08:18

Хорошая статья. Она, по крайней мере, говорит, что не надо делать. Но не говорит, как делать правильно:)

Обосновать повышение зп для подчиненного на основе  выстроенных отношений не всегда просто. А тем более делать это с какой-то периодичностью. Но не невозможно:)


  • 0

#3 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 250 сообщений
  • Город:Москва


Отправлено 17 Август 2016 - 09:44

 

Обосновать повышение зп для подчиненного на основе  выстроенных отношений не всегда просто. А тем более делать это с какой-то периодичностью. Но не невозможно:)

"В 2014 зарплата наиболее массового инженера у нас была 70 000 руб, а иностранные компании предлагали им $2000. И все было нормально. Сейчас же получать  $2000 несколько интереснее. К счастью, мы вовремя спохватились и успели потерять всего 20% персонала."

Вот и все обоснование.

 

Другой вариант из другой фирмы:

"- Сейчас у вас зарплата 100 у.е., а если выполните вот это задание, то через три месяца будете получать 150 у.е.

- Э.э.э... Нам прямо сейчас с завтрашнего дня предложили 275 у.е. Прощайте."


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней

 


#4 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 611 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 17 Август 2016 - 09:49

Нет, Сергей.

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

А я делаю повышения, чтобы человек не искал оффер)


  • 0

#5 Little_CJIOH

Little_CJIOH

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 421 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 17 Август 2016 - 09:52

Вспоминаются анекдот про собеседование секретарши и наши индийские тестировщики, у которых, похоже, эти метрики были.
анекдот:
- какая у вас скорость набора текста?
- 2000 знаков в минуту, но такая ерунда получается.
Индусы:
1. Уронить систему и завести 50 багов на неработающий функционал
2. Логи прикладывали всегда, но никогда на момент возникновения проблемы. То есть, просто кусок лога, иногда даже не от того устройства.
  • 0

#6 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 074 сообщений
  • Город:Москва

Отправлено 17 Август 2016 - 10:01

Когда у человека офер на руках, ему поздно уже предлагать повышение.


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#7 Garm

Garm

    Активный участник

  • Members
  • PipPip
  • 116 сообщений

Отправлено 17 Август 2016 - 10:06

Я вообще не представляю как правильно составлять такие метрики. Поэтому я за это даже не берусь. И не должны браться те, кто не имеет представления. Но это утопия какая-то. :)

 

Тут, кстати, про ЗП зашла речь... Я вот сейчас пытаюсь организовать автоматизацию, а какие-либо результаты надо успеть показать до ноября (время повышений). При этом я считаю что моих текущих знаний недостаточно, но вместо того чтобы читать теорию и навык программирования поднимать, я как слепой котёнок тыкаюсь в углы. Конечно я постепенно выхожу на решение, узнаю новое и применяю это, но каждый день уходя домой в 9 вечера я думаю что мог это время провести полезнее. А ведь ЗП больше тоже хочется. =/


  • 0

#8 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 611 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 17 Август 2016 - 10:06

Когда у человека офер на руках, ему поздно уже предлагать повышение.

 

Ошибаетесь:)

Хорошее отношение и коллектив позволяют перебить даже высокую планку зп. При повышении я даже не дошел до уровня оффера.


  • 0

#9 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 074 сообщений
  • Город:Москва

Отправлено 17 Август 2016 - 10:09

Я и хотел сказать это, что у человека офер появляется неспроста. И если он появился, то перебить одной з\пл уже тяжело будет. Да и смысла уже нет.


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#10 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 611 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 17 Август 2016 - 10:10

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


  • 0

#11 QuadBit

QuadBit

    Новый участник

  • Members
  • Pip
  • 48 сообщений

Отправлено 17 Август 2016 - 10:31

Я вообще не представляю как правильно составлять такие метрики. Поэтому я за это даже не берусь. И не должны браться те, кто не имеет представления. Но это утопия какая-то. :)

 

Тут, кстати, про ЗП зашла речь... Я вот сейчас пытаюсь организовать автоматизацию, а какие-либо результаты надо успеть показать до ноября (время повышений). При этом я считаю что моих текущих знаний недостаточно, но вместо того чтобы читать теорию и навык программирования поднимать, я как слепой котёнок тыкаюсь в углы. Конечно я постепенно выхожу на решение, узнаю новое и применяю это, но каждый день уходя домой в 9 вечера я думаю что мог это время провести полезнее. А ведь ЗП больше тоже хочется. =/

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


  • 0

#12 QuadBit

QuadBit

    Новый участник

  • Members
  • Pip
  • 48 сообщений

Отправлено 17 Август 2016 - 10:35

 

Когда у человека офер на руках, ему поздно уже предлагать повышение.

 

Ошибаетесь:)

Хорошее отношение и коллектив позволяют перебить даже высокую планку зп. При повышении я даже не дошел до уровня оффера.

 

ИМХО какой-то единичный случай, если разница между оффером и вашим повышением была столь незначительна, из разряда с 60 на 80, а вы дали 70. Обычно я искал работу с минимум 1.5 ставкой к текущей, и это уже совсем другой вопрос и только хорошим коллективом меня ничто не удерживало на работах,  где я начинал с 15к. Да и как правильно сказали выше оффер ищут далеко не только из-за зарплаты, можете мне хоть в 10 раз больше дать, но на 1 работе я и за миллион не остался бы из-за абсолютно унылой деятельности фирмы, не смотря на великолепный коллектив тогда ещё студентов.


  • 1

#13 leftCh

leftCh

    Постоянный участник

  • Members
  • PipPipPip
  • 179 сообщений

Отправлено 17 Август 2016 - 10:35

Давайте рассмотрим такой кейс.

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

А ответственный и любит свою работу. Б имитирует деятельность, в ожидании оффера, а может вообще даже не хочет работать в тестировании, но никуда больше не берут.

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

 

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

 

А какие есть альтернативы сбору метрик для предотвращения таких ситуаций? Ждать от Б что он сам расскажет, что работа ему не интересна? Наивно на это надеяться. Требовать отчеты о проделанной работе? Накладно, да и А может потерять интерес ввиду увеличения бюрократии. Плюнуть, и пусть он будет в команде? Это уменьшение эффективности команды, да и А может со временем начать брать с него пример.

 

 

Другое дело когда тестировщики занимаются разной работой. Тогда мерить эффективность одинаковыми метриками в любом случае некорректно


  • 0

#14 QuadBit

QuadBit

    Новый участник

  • Members
  • Pip
  • 48 сообщений

Отправлено 17 Август 2016 - 10:41

Давайте рассмотрим такой кейс.

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

А ответственный и любит свою работу. Б имитирует деятельность, в ожидании оффера, а может вообще даже не хочет работать в тестировании, но никуда больше не берут.

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

 

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

 

А какие есть альтернативы сбору метрик для предотвращения таких ситуаций? Ждать от Б что он сам расскажет, что работа ему не интересна? Наивно на это надеяться. Требовать отчеты о проделанной работе? Накладно, да и А может потерять интерес ввиду увеличения бюрократии. Плюнуть, и пусть он будет в команде? Это уменьшение эффективности команды, да и А может со временем начать брать с него пример.

 

 

 

Другое дело когда тестировщики занимаются разной работой. Тогда мерить эффективность одинаковыми метриками в любом случае некорректно

Крайне маловероятен кейс, когда люди будут заниматься продолжительное время идентичной работой внутри одного проекта, а собирать метрику за краткий период - дело наивное, почему думаю объяснять не нужно. Ну и даже допустим, идёт регресс, Б находит 5 ерундовых багов из-за поверхностного подхода, но просто ему попал кусок регресса, где новая тяп-ляп фича, критикалов не пропускает просто потому что до этого задачи тестилсь А и С. А находит 2 бага посерьёзнее, но не принципиально. Выйдет что Б чуть ли не лучше чем А. Я не могу представить кейс, в котором на длительный период по некоторому "количеству найденных багов" можно будет хоть сколько-то что-то оценить. Да и не бывает таких черно-белых случаев с А-молодцом, Б-холодцом. Обычно их эффективность будет разиться ну процентов на 30% в худшем случае благодаря куче побочных факторов и на основе их делать какие-то выводы глупо. Если Б такой уж нерадивый - это будет заметно сразу и без всяких метрик. А 10% погрешность, так ли уж она нужна?


  • 0

#15 Garm

Garm

    Активный участник

  • Members
  • PipPip
  • 116 сообщений

Отправлено 17 Август 2016 - 10:53

 

Я вообще не представляю как правильно составлять такие метрики. Поэтому я за это даже не берусь. И не должны браться те, кто не имеет представления. Но это утопия какая-то. :)

 

Тут, кстати, про ЗП зашла речь... Я вот сейчас пытаюсь организовать автоматизацию, а какие-либо результаты надо успеть показать до ноября (время повышений). При этом я считаю что моих текущих знаний недостаточно, но вместо того чтобы читать теорию и навык программирования поднимать, я как слепой котёнок тыкаюсь в углы. Конечно я постепенно выхожу на решение, узнаю новое и применяю это, но каждый день уходя домой в 9 вечера я думаю что мог это время провести полезнее. А ведь ЗП больше тоже хочется. =/

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

 

Я этим в свободное время занимаюсь, поэтому особо просесть не должен. :)

Компания известная, точнее я в дочерней компании этой известной. Поэтому тут им особо репутация не важна. Но вообще да, я считаю что то что я делаю так или иначе мне пользу приносит. 

 

 

Про сотрудников А и Б. Как выше написали, лично мне сложно представить метрику, которая эффективно покажет насколько "А" эффективнее "Б", если они не работают в абсолютно одинаковых условиях и при этом сами не являются клонами. 


  • 0

#16 leftCh

leftCh

    Постоянный участник

  • Members
  • PipPipPip
  • 179 сообщений

Отправлено 17 Август 2016 - 11:12

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

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

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

Текущая "любимая" метрика:

- критичность пропущенных багов
- очевидность пропущенных багов
- отношений найденных к пропущенным с учетом критичности и очевидности
- количество сделанных задач с учетом их размера (что-то типа стори поинтов в скраме)

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

Критикуйте )


  • 0

#17 QuadBit

QuadBit

    Новый участник

  • Members
  • Pip
  • 48 сообщений

Отправлено 17 Август 2016 - 11:17

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

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

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

Текущая "любимая" метрика:

- критичность пропущенных багов
- очевидность пропущенных багов
- отношений найденных к пропущенным с учетом критичности и очевидности
- количество сделанных задач с учетом их размера (что-то типа стори поинтов в скраме)

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

Критикуйте )

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

 

Да, насчет метрики количества выполненных кейсов - вообще ни о чем. В идеале кейсы должны быть примерно одинаковой сложности, если соблюдается приемлимый тест дизайн( спорное утверждение, конечно). На деле всегда будут побочные настройки окружения и т.п. которые приведут к выполнению у А 3 кейсов за день, а у Б - 40.


  • 0

#18 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 074 сообщений
  • Город:Москва

Отправлено 17 Август 2016 - 11:20

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

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

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

Текущая "любимая" метрика:

- критичность пропущенных багов
- очевидность пропущенных багов
- отношений найденных к пропущенным с учетом критичности и очевидности
- количество сделанных задач с учетом их размера (что-то типа стори поинтов в скраме)

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

Критикуйте )

 

А что тут критиковать. Лучше ответьте на 1 один вопрос - что конкретно дают вам эти цифры, не на бумаге, а в реальности. Вы кого то уволили, пожурили, при этом улучшили процесс, продукт качественнее стал  и т.д. и т.п.?


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#19 Little_CJIOH

Little_CJIOH

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 421 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 17 Август 2016 - 11:24

Когда у человека офер на руках, ему поздно уже предлагать повышение.

Почему?
Если человека устраивало все, кроме того, что ЗП не индексировали и рынок уже на 20% выше.
Я бы на прошлой работе остался, если бы мне повысили ЗП до того уровня о котором мы с руководством уже пол года беседовали. Даже при том, что на новом месте соцпакет в разы толще был.
  • 0

#20 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 611 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 17 Август 2016 - 11:39

 

 

 

ИМХО какой-то единичный случай, если разница между оффером и вашим повышением была столь незначительна, из разряда с 60 на 80, а вы дали 70. Обычно я искал работу с минимум 1.5 ставкой к текущей, и это уже совсем другой вопрос и только хорошим коллективом меня ничто не удерживало на работах,  где я начинал с 15к. Да и как правильно сказали выше оффер ищут далеко не только из-за зарплаты, можете мне хоть в 10 раз больше дать, но на 1 работе я и за миллион не остался бы из-за абсолютно унылой деятельности фирмы, не смотря на великолепный коллектив тогда ещё студентов.

У меня таких случая было два)

Да, согласен, что одного коллектива мало - тут играли роль все факторы.

 

Еще был случай, когда человек сильно переживал, что хочет уйти и пришлось ему объяснять, что все хорошо и иди спокойно на новую работу - там тебе будет интереснее) У меня не было загрузки по уровню сотрудника на тот момент. А развиваться было необходимо.


  • 0


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале