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

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

пункты 1, 3, 5 очень субъективны :)

а все эти данные для чего собирались?

а все эти данные для чего собирались?

Чтоб выявить молчунов, которые весь спринт копят инфу и не делятся ей. Если такие найдены, то провести с ними беседу/тренинг. Суть в том, что тестер должен знать все о проекте и быть связующим звеном между клиентом и разработчиками. Именно у тестера спрашивали насколько готов релиз, какие проблемы имеем и тд и тп. Соответственно если тестер фейлит этот момент, то заказчик находится в заблуждении, команда разрабов дизориентированна, доверие херится, скорость разработки падает.

Чтоб выявить молчунов, которые весь спринт копят инфу и не делятся ей. Если такие найдены, то провести с ними беседу/тренинг. Суть в том, что тестер должен знать все о проекте и быть связующим звеном между клиентом и разработчиками. Именно у тестера спрашивали насколько готов релиз, какие проблемы имеем и тд и тп. Соответственно если тестер фейлит этот момент, то заказчик находится в заблуждении, команда разрабов дизориентированна, доверие херится, скорость разработки падает.

а это аутсорс ? а те у кого показатели высокие по kpi получали бонусы?

пункты 1, 3, 5 очень субъективны :)

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

а это аутсорс ? а те у кого показатели высокие по kpi получали бонусы?

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

а так везде на аутсорсе?

а так везде на аутсорсе?

Нет. Мне повезло с компанией :)

получается что тестировщик еще и немного пм? или нет?

получается что тестировщик еще и немного пм? или нет?

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

В некотором роде тестировщик всегда пм

В некотором роде тестировщик всегда пм

это да, но тут получается в большей степени

Раставление приоритетов это задачи пма)

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

Ну а вдруг кто что подскажет. Здравствуйте, возникла необходимость в инструменте для чек листов и тест кейсов в jira, немного поискав наткнулся только на одну Structure.Testy. по описанию вроде подходит, но вдруг кто посоветует что-нибудь еще

testrail

https://zephyrdocs.atlassian.net/wiki/display/ZTD/Zephyr+for+JIRA+Documentation+Home

Structure.Testy. - мне нравится. но цена конечно пугает

Ну а вдруг кто что подскажет. Здравствуйте, возникла необходимость в инструменте для чек листов и тест кейсов в jira, немного поискав наткнулся только на одну Structure.Testy. по описанию вроде подходит, но вдруг кто посоветует что-нибудь еще

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

Structure.Testy. - мне нравится. но цена конечно пугает

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

https://zephyrdocs.atlassian.net/wiki/display/ZTD/Zephyr+for+JIRA+Documentation+Home

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

а где вы сейчас кейсы храните ? 0_о

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

Относительное количество критических багов пропущенных на продакшен - вполне ощутимый показатель работы отдела тестирования. Что тестировщики могут делать, что бы их не было? Не пускать в релизную ветку пулл реквесты без код ревью, фризить мержи в ветку после начала тестирования, блочить релиз пока тестирование не будет закончено. В общем много чего могут. Но это отдельный холивар, зачем он тут - непонятно. P.S. Я, если что, не сторонник KPI, просто я понимаю, что их можно готовить правильно.

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

Зефир дно. ;(

Зефир дно. ;(

весьма аргументированная точка зрения... железобетонно

весьма аргументированная точка зрения... железобетонно

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

Сравните с тестрейлом и почувствуйте разницу.

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

а где вы сейчас кейсы храните ? 0_о

exel, + confluence для чек листов

Версионность есть!

тот же вопрос. сижу смотрю на QaSpace (в аддонах к джире, бесплатный), есть у кого опыт? из неджировских понравился тестпад

Хотя стоп, вы про отдельностоящий зефир или тот, который jir'ный? В джирном версионности из коробки нет нормальной.

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

Ох, лол. Ну в таком виде да.

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

Джира сама по себе категорически неудобно, и всё что позиционируется как Looks and feels like JIRA не может быть удобным. Это громоздкое, медленное и перегруженное интерпрайзное нечто.

Это холивар

Джира сама по себе категорически неудобно, и всё что позиционируется как Looks and feels like JIRA не может быть удобным. Это громоздкое, медленное и перегруженное интерпрайзное нечто.

+

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

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

именно так сейчас и происходит- весь процесс разработки идет в jira. Спасибо за совет, посмотрю

Давайте по делу - мое мнение что зефир надо использовать если вся команда в JIRA. Но делать это надо с умом.

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

Их миллион.

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

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

Нормальное форматирование в степе - критично.

Офигенно прям критично.

В степе должно быть описание а не изображение.

это холивар я не буду с тобой спорить

В степе должно быть всё, что я посчитаю нужным добавить в стэп.

Я уже сказал куда в зефире это кладется

Хоть файлы аттачить.

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

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

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

но это другой уровень

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

Если Вам не удобно держать документацию в JIRA поговорите с менеджментом наверняка есть какие-то другие решения но я вряд ли что-то подскажу)

http://www.gurock.com/testrail/tour/testing-integration/ http://www.testlodge.com/tour https://www.practitest.com/integrations/ Миллион их. :)

Открыл условные топ5 тест менеджмент систем - каждая умеет интеграции с джирой. :)

@azshoo как ты видишь себе идеальное версионирование?

ERROR: S client not available

@azshoo как ты видишь себе идеальное версионирование?

Если коротко, то как атрибут любой составляющей части тест-кейса. Если более развернуто: 1) Возможность простого и удобного создания версий, переноса, клонирования и замены тесткейсов между версиями (в т.ч. балковых). 2) Простая навигация и общая связанность тесткейсов по разным версиям. Банальный пример - comparison по версиям. 3) Удобная работы с версиями по апи (в первую очередь для интеграций, но и автотестиков тоже). 4) (Самое очевидное, но тоже не везде сделанное) Возможность нормально апдейтить устаревшие версии. 5) Возможность кросс-версионных репортов (примрно попадает под пункт 2, но отдельно вынес, т.к. этого вообще почти нигде нет) На техническом уровне она, в том или ином виде, много где сделана, но при этом многое упирается в интерфейсы и юзабилити, тут уже так просто не объяснить.

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

кто что добавит на тему версионности?

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

Да. :)

Привет, Иван)

Ivan о, Иван!!!

Относительное количество критических багов пропущенных на продакшен - вполне ощутимый показатель работы отдела тестирования. Что тестировщики могут делать, что бы их не было? Не пускать в релизную ветку пулл реквесты без код ревью, фризить мержи в ветку после начала тестирования, блочить релиз пока тестирование не будет закончено. В общем много чего могут. Но это отдельный холивар, зачем он тут - непонятно. P.S. Я, если что, не сторонник KPI, просто я понимаю, что их можно готовить правильно.

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

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

Там, где они их не принимают, они предоставляют информацию по этим историям, и падение KPI объясняется фразой "В отчете о тестировании написано, что всё было хреново, но вы запушили"

И всем добра.

все верно, но смысл то какой в этом?)

ведь он должен быть везде. а тут метрики ради метрик?

Как и в любом мониторинге - выявление проблем и их причин.

Всем привет)

И, соотвественно, возможность по этим метрикам отслеживать динамику состояния этих проблем.

Условно - дали куа кнопку "Stop Release", посмотрели, количество багов в продакшене не упало относительно багов в тестировании. Следовательно проблема не в том, что лили недотестировав.

ведь он должен быть везде. а тут метрики ради метрик?

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

И дальше.

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

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

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

смотря как представить)

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

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

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

не согласен.

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

Просто не работайте с мудаками, и всё будет хорошо. :)

Просто не работайте с мудаками, и всё будет хорошо. :)

абсолютно согласен :)

согласен.

не согласен.

обоснуйте)

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

мы сейчас с разных позиций просто говорим. и хорошую презентацию результатов работы мало кто проводит. Она действительно мало где нужна.

Во первых, графики и метрики - всего лишь инструмент. То, как им кто-то пользуется не делает его (инструмент) плохим или хорошим.

мы сейчас с разных позиций просто говорим. и хорошую презентацию результатов работы мало кто проводит. Она действительно мало где нужна.

а вы с чьей позиции сейчас говорите?