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

krukovskiy

Регистрация: 13 окт 2013
Offline Активность: 25 дек 2015 11:17
-----

Мои сообщения

В теме: Тестировщик и kpi

26 января 2015 - 16:40

1. Для разработки KPI необходимо прежде всего определить цель сбора метрик.

 

2. Метрики должны быть сбалансированными. Это значит, что если вы, например, измеряете скорость тестирования (кол-во пройденных тест кейсов), то обязательно надо измерять и качество (кол-во претензий от пользователей). Иначе будут большие перекосы. 

 

3. KPI должны отражать разные аспекты деятельности.

Мы, например, используем следующую модель. Разделяем kpi на 3 категории:

1) Надежность ПО

Сюда входят показатели, относящиеся к непосредственно к характеристикам ПО (дефекты разной степени тяжести, успешные/неуспешные тесты, плотность дефектов и т.д.)

 

2) Сложность/Покрытие (кол-во функций, кол-во тестов на функцию и т.д.) 

 

3) Финансы (условная стоимость прогона одного теста, бага, кол-во выполненных тестов в час и т.д.)

 

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

Или, например, время прогона тестов увеличилось на 20%, при этом сложность выросла на 50% - вывод очевиден.

 

По метрикам рекомедную прочитать книгу  Каплана и Нортона "Система сбалансированных показателей" .


В теме: Как грамотно организовать тестирование

11 декабря 2014 - 16:48

Периодичность отчетности говорит об уровне доверия руководства, чем чаще - тем меньше доверия.

 

 "Пропускаю ошибки. на которые потом напарывается начальство / Заказчик - этот пункт наверное причина"

Причина недоверия - пропущенные дефекты. Решение - ? Ежедневные отчеты просто дадут понимание вашей занятости, а дальше надо будет принимать решение. 

Проблема багов, найденных заказчиком, заключается в тестовом покрытии - ваша тестовая активность не совпадает с пользовательскими действиями. Один из вариантов решения - добавлять пользовательские прецеденты в регрессионный тест план и прогонять перед релизом. Далее - выводить закономерности, категоризировать и приоритезировать тесты. Здесь есть и обратная сторона - чересчур раздутый тест план увеличивает время (как следствие, затраты) на тестирование и всё равно не дает 100% гарантии от пользовательских багов. Однако, на данную ситуацию вы всё-таки можете повлиять. 

 

Есть масса других критериев, от которых зависит удовлетворенность пользователя, на которые вы напрямую, увы повлиять не сможете. Начиная от цветовых решений приложения, заканчивая манерой разговора инженера технической поддержки. Опять же, разные пользователи реагируют на дефекты по-разному: одни готовы ждать багфикса, другие хранят несколько версий ПО, третьи будут висеть по 3 часа на телефоне, объясняя, как важно, чтобы кнопочка была на 3 см левее. 


В теме: Performance evaluation или ежегодные разговоры о главном

16 октября 2014 - 16:10

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

 

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

Для начала определите Вашу позицию и меру ответственности в коллективе. Вашего начальника волнует, чтобы все  сотрудники работали, не было текучки и ФОТ умещался в бюджет. Всё. Каким образом Вы обеспечите эти цели - уже Ваша головная боль. Хотите - проводите performance review, хотите - бегайте с плеткой или бубном, хотите - заставьте всех писать метрики - решать Вам и отвечать тоже Вам. Уровень демократичности в команде - вещь настраиваемая, но помните об обратной стороне медали. 

 

У меня встречный вопрос: встречались ли Вам команды с "зажравшимися" сотрудниками? Если да, то каковы Ваши ощущения от работы в данных командах?

 

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

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

 

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


В теме: Тема новичка.

17 июня 2014 - 07:32

Рекомендую совместить теорию с практикой. Читайте Канера до 5 главы, затем читайте и параллельно тестируйте какой-нибудь проект.

Например, сейчас правительство Москвы выпустило Карту Инновационной Москвы, и предлагает всем сочувствующим потестировать:

 

"В текущий момент нам необходима помощь в тестировании Карты, поэтому мы рассчитываем на ваше деятельное участие.

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

Ваши замечания и предложения мы ждем по адресу map@inno.msk.ru с пометкой КАРТА ИННОВАЦИОННОЙ МОСКВЫ."

 

Отличный проект для тренировки. Если затянет, то добро пожаловать в сообщество тестировщиков!


В теме: Office management: общие организационные моменты

05 июня 2014 - 08:57

Мой коллега сказал очень интересную мысль: "Если что-то можно взять деньгами, то лучше взять деньгами."

Т.е. если вместо корпоратива у вас +5000 руб к годовой премии, то лучше взять деньгами.

 

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

 

Ну и из старенького: http://blog.shumoos.com/archives/171

 

 

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

 

Если говорить просто, есть вещи, которые удобнее/выгоднее делать коллективно. Фитнес-центр дает скидку 20% за "опт". Если вы собираетесь купить абонемент, разумеется, вам будет выгоднее, чтобы его оплатила фирма. А если вам спорт неинтересен, тогда кэш лучше. А если вы колеблетесь?

Кроме того, важно от кого произошла инициатива: сверху или снизу? Какая стадия развития коллектива? Каков размер коллектива? 

Это социальные аспекты.

 

 

Кроме социальных, есть и экономические:

 

1) На рынке труда существуют такие же спекуляции, как и на других рынках. Особенно характерно это для растущего ИТ сегмента. Работодатели конкурируют между собой за специалистов. Это порождает поле для спекуляций: "летуны", которые переходят из одной компании в другую за +10% к жалованью, создают спекулятивный рост зарплат. У работодателей есть своеобразный защитный механизм: любая вакансия имеет свой потолок, выше которого работодатель платить кэшем не готов. Здесь включаются доп условия: гибкий график, обеды, молодой дружный коллектив, - кому на что хватит фантазии. 

 

2) Экономика компании. Каждые 5 000 рублей, выплаченных на руки сотруднику, обходятся компании в 7 480 рублей. Экономически выгоднее потратить деньги на плюшки для  сотрудников. К тому же сумма запишется в расходы и снизит налоговую базу (при 15% налоговом режиме экономия составит 1 122 рубля). 

Теперь считаем: номинальная цена абонемента в фитнес-центр стоит 5 000 рублей. С учетом скидки за "опт" будет стоит 4 000 руб. Плюс налоговая выгода - итого абонемент обойдется компании в 3 400 рублей. 

При тех же затратах компании (3 400 руб.) сотрудник получит на руки 2 270 руб. На эти деньги даже половину абонемента не купить. Вот и вся экономика. 

 

*налоговые расчеты взяты отсюда