Tester's KPI

Product Manager (РМ) команды разработки в ConquestSS многие годы опирался на количество задач при оценке уровня специалиста. Поэтому, когда команда разрослась, поручил мне еженедельно публиковать в чате отчёт об обработанных задачах в разрезе продуктов (от трёх до шести приложений) и о переписке тех.поддержки (сколько получено писем, сколько отправлено ответов, сколько застряло в обработке). В те недели, когда у меня были отпуска, количество обработанных задач резко падало, и это первым заметил PM. Сделав выборку значений и подставив периоды моего отсутствия, у меня получился нижеследующий график.

Схождение отпусков и провалов задач

Скачки снижения количества задач (голубая и рыжая кривые) в точности совпали помесячно с периодами моих отпусков (коричневая кривая, где 100 - наличие отпуска, 0 - рабочий период). Что в точности подтвердило гипотезу РМ.
Но мне стали интересны и другие мои идеи.
1. Как часто стоит менять курируемый продукт? Ежедневно, как это делал РМ на стендапах, или закрепить один продукт за каждым тестировщиком на весь период спринта?
2. Зависит ли производительность тестировщика от его гендерности?
3. Кто эффективнее обучает новичка?
Для этого была собрана нижеследующая таблица.

Данные о сроках и количестве задач в разрезе тестировщиков

Имя (пол)		Tester_1 (F)	Tester_2 (F)	Tester_3 (F)	Tester_4 (F)	Tester_5 (M)	Tester_6 (F)	Tester_7 (M)
Через N дней оформлен "свой" баг		1	13	4	15	11	9	23
Через N дней оформлена первая задача из техподдержки		16	46	3	15	11	9	23
Срок в команде (месяцы)		165	26	16	26	6	5	2
Обработано всего задач за весь период		32457	4510	2181	1632	548	427	157
Скорость (обработано задач в месяц)		196,7	173,5	136,3	62,8	91,3	85,4	78,5
Количество оформленных задач (найденные баги самостоятельно и предложения из техподдержки)	всего	17204	1697	814	1362	188	148	51
	в т.ч. своих	12187	994	497	707	91	65	35
	%	71	59	61	52	48	44	69
Курируемый продукт		All	P_1, P_2, P_3	P_1, P_4	All	P_1, P_3, P_4	P_2	P_1, P_4
Количество обработанных задач по Product_1	всего	4981	3042	1116	926	288	16	147
	в т.ч. новые	3779	1136	260	798	101	10	44
	закрытые	1202	1906	856	128	187	6	103
Количество обработанных задач по Product_2	всего	5920	923	86	324	16	400	0
	в т.ч. новые	3701	328	16	292	12	128	0
	закрытые	2219	595	70	32	4	272	0
Количество обработанных задач по Product_3	всего	21016	336	31	163	164	11	0
	в т.ч. новые	11388	174	6	152	42	10	0
	закрытые	9628	162	25	11	122	1	0
Количество обработанных задач по Product_4	всего	540	209	948	219	80	0	10
	в т.ч. новые	444	59	532	120	33	0	7
	закрытые	96	150	416	99	47	0	3
Кто обучал внутренним правилам		самостоятельно	Tester_1	Tester_1	PM	Tester_3	PM	Tester_5

Если рассмотреть цифры в строке "Скорость (обработано задач в месяц)" в зависимости от строки "Курируемый продукт", то можно предположить, что тестировщик - универсальный солдат, легко перескакивающий с одной темы на другую. Но если учесть "Срок в команде (месяцы)", то гипотеза становится сомнительной. Особенно после отчёта на одном из стендапов, когда Tester_6 отчиталась об оформлении одного бага, а от Tester_1 за этот же день было добавлено в BTS более 20-ти задач.
На второй мой вопрос о половой принадлежности цифры мало что могут ответить. Поскольку не было возможности разбить задачи по их тематичности, которая в большей степени влияет на эффективность распределения работ. Более подробно об этом читайте в моей статье "Гендерность на страже качества или Вам Девочку или Мальчика?".
А вот на третий вопрос об обучении цифры вполне подтвердили мою гипотезу, что передавать знания должен единый лидер. Скорость учеников прямопропорциональна скорости учителя. Взгляните на строки "Скорость (обработано задач в месяц)" и "Кто обучал внутренним правилам" в купе со значениями "Курируемый продукт".
По таблице может у вас возникнуть вопрос о наличии данных в продуктовых деталях у тестировщиков, занимавшихся не всеми продуктами. Это последствия частой смены кураторов, которую так усердно лоббировал РМ, желая превратить нас в универсальных солдатов. Как следствие, одна из тестировщиц на указания шефа стала отвечать смайликом "Yes, Sir!", но он воспринял это лишь шуткой, не придав значения хлипкости командного духа подчинённых.
Количеством закрытых в спринте задач любил бахвалиться РМ и перед вышестоящим руководством, не вдаваясь в подробности того, что половина из них были элементарным откатом к функционалу прошлых версий. На каждое изменение в продукте "деды" тестирования всегда оформят, как минимум, две задачи. А если тестировщик более внимательно слышит пользователя, нежели сборщик бэклога РМ, то процесс его пополнения будет бесконечным: РМ навязывает свой взгляд на решение, а тестировщик инвертирует к пожеланиям пользователей.

UI appearance

Компания ConquestSS производит интерфейсные продукты для разработчиков БД Oracle, а ClearSQL (далее - CS) полезен тестировщикам PL/SQL кода. Поскольку продукт в большинстве своём - визуализатор, то посмотрим на его производительность в области интерфейса. Примечания: приложение десктопное, все установки были на Windows 64bit, замеры (кадрирование через VideoPad) интерфейсной производительности проводились по видеозаписям.
Для теста были взяты версии CS 7.0, 7.1, 8.0, 8.1, 9.0 для Windows 32bit и 64bit, а последний релиз в "светлом" и "тёмном" исполнениях. Каждая инсталляция запускалась по три раза, в каждом из которых анализировался демо-проект. Первые два идентичны по установке на "чистую" машину и полному анализу демо-проекта со всеми диаграммами. Третий запуск отличается от второго тем, что приложению нет необходимости доустанавливать продукт (создавать папки, выставлять опции по-умолчанию и прочее), а анализ проекта проводился без генерации диаграмм. Количество скриптов в демо-проекте уменьшилось на один ("Wrapped function.fnc") с версии CS 9, то есть примем везде по 60 скриптов. Настройки анализатора во всех тестах идентичны, так как взяты дефолтные.
Но сначала поглядим на запуск приложения. До версии CS 9 процесс открытия приложения проходил в так называемом "невидимом" режиме, когда пользователь не понимал, что происходит в системе: на панели задач не было кнопки приложения, на рабочем столе никаких новых окон. Спасибо, в CS 9 через 5 секунд молчания добавили "пропеллер" загрузки, а в предыдущих версиях какой-либо реакции по запуску приложения приходилось ждать иногда и более двух минут. Окно выбора лицензии мелькнуло на 5-10 секунде, а далее - пустое молчание.

Зависание старта

Казалось бы, первый и второй запуск должны быть идентичны, но график показывает реальные цифры. Напомню, все тесты проводились на одной машине, сначала первый, потом после очистки - второй и третий подряд (без очистки машины от инсталляции). Как видим из графика, пользователи 7-мых версий дольше всех ожидали в неведении отклика интерфейса. Но не стоит столь позитивно воспринимать значения 8-мых версии, так как по значениям следующего графика вам станет понятно, что фактически начать работу быстрее в 7-мых версиях, потом или почти в равной степени в 9-тых.

Ожидание полно-рабочего интерфейса

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

Затраты на выбор проекта

Накручивание каких-то скрытых обработок от версии к версии неблагоприятно сказывается на работоспособности интерфейсного приложения. Когда ваш маркетолог или аналитик просит вставить сбор статистики, то хорошенько  оцените конкретное место для этого действия: при каждом запуске приложения или перед конкретными кликами. Любое ожидание пользователя - это его нервы, особенно, если экран никак не отображает процесс.
Например, программисты ConquestSS, как говорится в Release Notes, от версии к версии что-то ускоряют. Но мои замеры показывают, что это какие-то пустые хлопоты. Взгляните на значения для CS 7.1 64bit и сравните их с другими. Только в этой версии по-умолчанию открывалась панель Script Editor (редактор, дерево кода и первая из панелей с результатами анализа скрипта - Errors), тогда как во всех других (в том числе и в CS 7.1 32bit) отрисовывалась более красочная закладка Summary с множеством графиков.

Прорисовка главного окна при запуске приложения с открытием демо-проекта

Раздражительность пользователя растёт от непонимания происходящего и, как факт, обновление главного окна юзеру приходится ожидать более 10 секунд при открытии проекта и по 5 секунд после каждого анализа.

Прорисовка главного окна после анализа проекта

Для понимания этого графика стоит учесть, что процесс прорисовки юзер видит собственными глазами. Но в некоторых версиях были отличия: 1) как уже было сказано, CS 7.1 64bit активировал Script Editor (текст и пара таблиц) закладку, а все остальные - Summary (несколько чартов); 2) в 7-мых версиях после анализа курсор в дереве проекта перескакивал на первый скрипт и, следовательно, значения в панели с результатами анализа просчитывались только для одного скрипта; 3) в 8-мых и 9-тых версиях выбранные для анализа ноды в дереве проекта не теряли своих чекеров и, следовательно, значения в панели с результатами анализа просчитывались для всех выбранных скриптов и папок; 4) CS 7.1 64bit  отличилась и в числе подсвеченных нод после анализа тем, что курсор в дереве раздваивался - на верхней ноде оставалась подсветка и на первом скрипте прорисовывался курсор-подсветка. Как видите из графика, снижение ожидания было за счёт закладки Script Editor в CS 7.1 64bit  и, вероятно, за счёт каких-то снижений затрат на обработку интерфейса в 8-мых и 9-тых версиях.

CS 9 black - Summary tab

CS 7.1 64bit - Script Editor tab

Cs 7.1 64bit - Project Tree node highlighting

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

Время общего анализа и генерации Call Tree 

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

серая линия - весь анализ, коричневая - call  tree

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

Время выборки данных анализатора и форматирования кода

Для того, чтобы легче вам было разглядеть графики, они сгруппированы только по временным величинам (первая группа - полное время анализа и генерация call tree, второй - только форматирование или обработка данных для проверки правил кодирования, третья - генерация матриц crud и диаграмм flowchart).

Время генерации матриц crud и диаграмм flowchart

Очень странно, что полный анализ (серая линия на первом графике и второй график) проходит за разное время во впервые открытом приложении и при повторном запуске проги. Весьма заметно, что в 9-й версии что-то "накрутили" (светло-зелёная линия) при генерации flowchart, и с версии 8.1 что-то намудрили (синяя линия резко взлетела) для CRUD1.
В демо-проекте 60 скриптов, по полсотни flowchart и call tree диаграмм, десяток crud матриц. Все запуски имели равные условия (одна машина и рабочий день, без лишних  параллельных процессов), а линия обработки проекта показывает, что время не различается при генерации с диаграммами или только с анализом, без диаграмм. Соглашусь, что количество проведённых тестов для таких выводов маловато. Но тенденции по "совершенствованию" продукта вполне можно обнаружить.
Красота, конечно, требует жертв, но это совершенно нельзя применять к интерфейсным продуктам, которые хоть и помогают юзеру общаться с данными в упрощённом режиме, но пользователь в первую очередь желает не терять скорость обращения к данным и получать отчёты. Так, например, HTML Project Report с каждой версией замедляется.

Время генерации отчётов проекта

График показывает время формирования отчёта по демо-проекту: впервые открытого в чистом триале, после полного анализа, после анализа без диаграмм и ещё раз после полного переанализа. Наименьшие значения по версиям соответствует проекту без диаграмм. Но среднее время по версиям отчего-то растёт, хотя ни в каких RNs не упоминалось ни о каких изменениях в алгоритме генерации отчёта. Значит общие интерфейсные изменения в продукте отрицательно сказывались на генерации отчёта.

Из вышеизложенного могу порекомендовать тестировщикам и программистам интерфейсных десктопных приложений следующее.
1. Все внутренние процессы должны иметь визуализацию: конечную в виде "градусника" с процентами или таймерную анимацию в виде "пропеллера". Даже движущийся "пропеллер" не всегда даёт уверенность, что процесс когда-то закончится. А наличие сменяемого счётчика (хотя бы с 5-ти секундным интервалом) обнадёживает юзера благополучным исходом.
2. Десктопное приложение с первых секунд запуска должно быть обозначено на рабочем столе, на панели задач или трее. Юзер не должен рыскать по Диспетчеру Задач в поисках причин визуальной тишины. Причём подписи должны быть адекватными: обязательно актуальное название продукта (не как в CS 9 - пустая кнопка), информация о текущем состоянии продукта (инсталлируется, настраивается, запускается, закрывается, сохраняет или восстаналивает данные и тому подобное).
3. Сбор статистики для аналитиков или маркетологов не должен отягощать обычную работу пользователя. Если же это временно или срочно необходимо производителям, то перед выпуском проведите замеры и в Release Notes перечислите все процессы, которые станут замедляться.
4. Прежде чем кардинально менять интерфейс на новомодные элементы, замерьте прорисовку часто используемых окон по времени и объёму памяти.
5. Перерисовку основного окна не стоит выполнять бэкграундом. Закрывайте текущее окно, а затем ОДИН раз обновляйте главное. Иначе, ваше основное окно будет затрачивать ресурсы дважды: под текущим и при активации (например, в CS по завершении анализа моргают панели в основном окне, а после закрытия диалога опять прорисовывают тоже самое).

Перед началом тестов у меня была мизерная надежда, что разработчики в ConquestSS услышали своих пользователей и вместе с "бантиками" в виде новых иконок и тем подложки ускорили работу в приложении. Но, как всегда, вся вера в лучшее рухнула при виде результатов тестов. Помимо того, новый интерфейс только усугубил неудобства в виде плохо просматриваемых элементов, а местами и отсутствие привычных полезностей. Среди последнего: кнопка приложения в режиме загрузки приложения не имеет подписи; в тёмной теме очень трудно разглядеть выбранные ноды в дереве, процесс не отображается на кнопке приложения в панеле задач; сочетание новых иконок и тёмной темы не продумано - чёрные или голубые тонкие линии не видны на сером фоне. Так что в моей копилке высказываний завелось ещё одно: "Декорирование - хитрая наука, но тестировщик знает, что чем ярче банты, тем круче баги".

Рухлядь

Спектакль "Самая большая маленькая драма" начинается словами: "Рухнет потолок в театре, а сами скажут, что в городе Н. рухнула культура!", которые можно было взять лейтмотивом полвекового юбилея ТЮЗа, если бы не изворотливость организатора АКТ. В шестом кабинете (малая сцена ДК г. Кольчугино) истёрся до дыр линолеум, а под ним развалился паркет. Этим фактом грозил Рыжов пропесочить всех ответственных за ремонт на капустнике. Но тут подвернулся грант и режиссёр решил за его счёт укрепить пол так, чтобы не провалится однажды в бухгалтерию. К сожалению, распространение и укрепление культуры не подразумевает ремонт окружающего пространства. Подобное отношение к делу мне напоминает стартап, который не заглядывает в будущее, а лишь надеется на единоразовый успех. Обеспечение качества в быстрых проектах не предусмотрено, поскольку это удлинит процесс и себестоимость продукта увеличится.
Отказ в ремонте, ради которого и устраивался конкурс сельских театров, не сильно подкосил упрямство выигравшего грант руководителя АКТ и средства на обновление стен и пола выкроил из своего бюджета ДК. Вот что написала об этом местная пресса: "... как нам стало известно, средства полученного гранта в сумме 500 тысяч рублей нельзя было направить на ремонт малой сцены ДК, а так не хотелось новое оборудование, закупленное в рамках гранта, размещать в неотремонтированном зале. И Дворец культуры из собственных средств выделил порядка 200 тысяч рублей на ремонт малой сцены. Браво! Это настоящая поддержка театрального искусства."
Ремонт закипел с первых дней лета, а уже через месяц меценат городской культуры завод "Электрокабель" в честь собственного 80-летия расщедрился на 30 миллионов рублей для ремонта ДК. Знаменательным при этом был факт того, что среди столичных артистов в праздничном концерте участвовал лишь один местный коллектив, порождённый из театралов. Образцовая студия эстрадного танца "Dell`Arte" сформировалась в нулевых из актёров ТЮЗа, а неизменная руководительница О.Н. Никанорова (Архипова) ставит и репетирует шедевры хореографии не только у себя в коллективе, но и тесно до сих пор сотрудничает с АКТ. Поэтому считаю, что средства, поступившие в городской бюджет, должны в первую очередь покрывать потребности "Dell`Arte" и АКТ, соорудивших своими силами мизерные гримёрки-костюмерные для текущих представлений. Стоит заметить, что уровень постановки и исполнения номеров девочками из "Dell`Arte" превышал на пару голов столичные, уж поверьте моему хореографическому стажу с 1974 года, в числе которого 20 лет отдано полупрофессиональным коллективам. Застенчивость Ольги Николаевны не позволяет ей истребовать от директора ДК заработанные средства на организацию раздевалки для танцоров, ну что ж, пусть и дальше СЭС прикрывает глаза на то, что верхняя одежда и обувь использует столы и стулья буфета не по назначению. И чтоб этот баг вам не вышел боком, прошу за скромную и работящую принять во внимание наличие проблемы и уже начать её исправлять, благо достаточные средства пришли к вам не без помощи Никаноровой. За пронырливого Рыжова просить ничего не буду, так как он сам обладает достаточной фантазией и связями для осуществления любых своих хотелок.