Какие тесты выделяют по критерию эффективности. Оценка эффективности теста большая пятерка и пример его практического использования

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

Что такое KPI?

Итак, для начала обратимся к самому понятию KPI. KPI (Key Performance Indicator) – это показатель достижения успеха в определенной деятельности или в достижении определенных целей. Можно сказать, что KPI – это количественно измеримый индикатор фактически достигнутых результатов.

В нашем случае KPI на проекте – это показатель эффективности работы всей команды тестирования. Помимо термина KPI в статье будет использоваться термин «метрики», под которым мы будем понимать числовое значение для измерения этой эффективности.

Зачем нам KPI?

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

Кроме того, в KPI можно включить не только общепринятые количественные показатели, но и качественные (например, «уровень удовлетворенности заказчика»). Но давайте обо всем по порядку!

Откуда взять KPI?

Каждый проект – вещь во многом уникальная. Не стоит полагать, что метрики с одного проекта хорошо «приживутся» на другом; их стоит разрабатывать с учетом специфики проекта и ожиданий/опасений вашего заказчика. А вот для превращения ожиданий в метрики потребуются время и терпение.

Как было у нас

Теперь я, как и обещала, расскажу о наших действиях на проекте.

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

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

Приведем примеры формулировок заказчика: «Из одного модуля программы в другой не «прилетают» сущности, а они там нужны, на них многое завязано»; «Не можем из старой программы в новую версию передать информацию»; «Мы полностью планируем переезд из одной системы в другую, поэтому будем настраивать передачу».

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

Теперь нам предстояло провести процесс декомпозиции, то есть разбиения глобальной цели на небольшие решаемые задачи для проектной команды. Кстати, в этом мне помогла сама команда! Давайте посмотрим, как же это происходило, но для начала вновь уточним сам термин «декомпозиция», разложив все по полочкам.

Декомпозиция

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

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

В теории все достаточно просто и ясно: из большой задачи нужно получить ряд маленьких. Казалось бы, ничего сложного, но на практике мы часто сталкиваемся с тем, что просто не понимаем критериев декомпозиции задачи, а потому делаем все наугад. Следствиями такого непонимания становятся неравномерная нагрузка на тестировщиков проекта, неверная оценка трудозатрат, неправильное понимание задач и разное представление о результатах. Для лучшего уяснения данной темы обратимся к принципу SMART.

Принцип SMART

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

• S pecific – конкретный. Ставя задачу, мы должны четко понимать, какого результата хотим достичь. Результат должен быть однозначным и понятным всем участникам процесса – сотрудникам команды тестирования, заказчикам, руководителям разных уровней.
• M easurable – измеримый. Нам нужны задачи, которые могут быть измерены. Иными словами, измеримость предполагает наличие критериев – измерителей, показателей выполнения.
• A ttainable – достижимый. В данном случае определение «достижимый» я бы переименовала в «доступный» (доступный для выполнения сотрудником с определенным уровнем подготовки и квалификации). Грамотный руководитель никогда не даст новичку сверхсложную задачу, так как понимает, что новичок с ней просто не справится, а время, затраченное на попытки решения, уже не вернуть. Учет личностных особенностей и качеств сотрудников команды тестирования на проекте позволит очень четко (а главное – равномерно и посильно) распределить нагрузку, дать новичкам несложные задачи, а «звездочкам» и профи – задачи со сложной логикой в соответствии с их силами и навыками.
• R elevant – актуальный, значимый. Действительно ли выполнение задачи так важно для нас? Является ли данная задача необходимой именно сейчас? Что мы получим, если решим эту задачу? А если не решим?
• T ime-bound – ограниченный во времени. Любая задача должна иметь свой срок, в течение которого ее необходимо решить. Установление временных рамок и границ для выполнения задачи позволяет сделать процесс контролируемым и прозрачным. Руководитель в любой момент времени может увидеть прогресс выполнения задачи.

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

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

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

Помимо этих основных подзадач я выделила еще несколько дополнительных:

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

Теперь давайте вместе пройдемся по каждой подзадаче и рассмотрим измеримые показатели (метрики).

Метрики, из которых складываются KPI

Покрытие функционала тестами. Как мы его можем измерить? Мы остановились на метрике «% покрытия xx числа модулей продукта тестами» (более подробную информацию о том, как это посчитать, вы можете найти в статье Натальи Руколь ).

По клику на картинку откроется полная версия.

Разработка тест-кейсов и тестовых сущностей. Здесь мы решили работать с метрикой «количество модулей / функциональных блоков продукта, для которых разработано 100% сущностей».

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

«Заведение дефектов». Мы решили воспользоваться несколькими метриками, которые бы давали нам информацию о состоянии версии: «количество дефектов, заведенных командой», «количество дефектов приоритета Blocker на версии».

«Тестировать релизы и хот-фиксы» мы решили метриками «% протестированных задач, входящих в релиз и/или хот-фикс» (отношение проверенных задач к общему числу задач версии), «% тест-кейсов, пройденных на версии» и «% успешности прохождения кейсов на версии».
Последнюю метрику мы считаем по формуле:



где P1 – passed-шаги по первому блоку,
P2 – passed-шаги по второму блоку,
Pn – passed-шаги по n-ному блоку,
A1 – число шагов по первому блоку,
А2 – число шагов по второму блоку,
An – число шагов n-ного блока,
N – общее число всех блоков продукта.

Для измерения задачи, связанной с работоспособностью приоритетных продуктов, мы специально разработали матрицу (в ней отмечалось, работает или не работает то или иное значение для продукта) а далее подсчитали «% значений, работающих для продукта 1 и продукта 2 на версии». Считаем по формуле:



где Pп1 – это число работающих значений для продукта один,
Aп1 – все значения для продукта один.

По клику на картинку откроется полная версия.

Разобравшись с основными задачами, мы перешли к дополнительным.

Напомню, что мы не хотели тратить дорогое нам время на объяснения багов и комментирование отчетов, но в то же время нам было важно, чтобы заказчик был доволен нашей работой. Таким образом для первой подзадачи, мы решили использовать количественные показатели «% отклоненных дефектов на версии с резолюцией Can’t reproduce», а для второй – «количество обращений заказчика с просьбой прокомментировать промежуточный отчет» и качественный показатель «удовлетворенность заказчика нашей работой».
Для оценки «удовлетворенности заказчика» мы ввели три уровня – «все отлично», «есть небольшие замечания / вопросы к работе» и «все плохо, заказчик недоволен». Этот показатель, кстати, вообще очень помогает с оперативным принятием решений внутри проектной команды. Если заказчик чем-то недоволен или огорчен, мы по «горячим следам» проводим обсуждение: стараемся минимизировать риски, понять причины недовольства, в максимально короткие сроки проработать решение и представить его заказчику.

По клику на картинку откроется полная версия.

Что в итоге нам дают KPI

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

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

После внедрения метрик на моем проекте стало легче готовить промежуточную отчетность для заказчика, вся проектная команда (а у ребят есть доступ к KPI проекта) прикладывала максимум усилий для роста наших по
казателей, все стали более внимательными и сосредоточенными!

Вместо заключения

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

Не бойтесь потратить время на подготовку и внедрение KPI на проекте: эти затраты полностью окупятся! Ваш заказчик будет удовлетворен проведенными работами и отличным качеством продукта. Он вновь и вновь обратится к вам за помощью!

Ошибки, влекущие за собой снижение эффективности теста, появляются, если:

• Тест неправильно составлен
• Тест неправильно стандартизован
• Тест неправильно использован

Конструирование теста

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

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

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

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

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

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

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

Правильно составленный тест еще нельзя назвать разработанным. Для этого он должен быть стандартизован.

Стандартизация

Стандартизация теста обеспечивает возможность сравнения полученных с его помощью данных от разных людей. Для этого необходимо, чтобы все эти люди находились в равных условиях. На психологическом языке это называется "контроль всех зависимых переменных". В идеале единственной независимой переменной в тесте будет личность испытуемого. Для обеспечения равных условий разработчик теста дает специальные указания по его проведению. Они включают:

• Специфику стимульного материала
• Временные ограничения (time limits)
• Инструкцию испытуемым
• Пробные образцы заданий
• Допустимые ответы на вопросы (если таковые ограничения необходимы)

Кроме этих указаний, в приложение к тесту включаются специально установленные нормы ответов (в "сырых баллах") и их интерпретации.

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

Надежность

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

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

Валидность

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

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

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

Оценка валидности теста включает следующие этапы:

• определение очевидной валидности (face validity). Такую валидность видно, что говорится, "невооруженным глазом" - оценивается общее соответствие теста его назначению.
• определение концептуальной валидности (construct validity). Степень соответствия теста, измеряющего какое-либо свойство, общепринятым теоретическим представлениям об этом свойстве. Как правило, эта валидность оценивается экспертами.
• определение эмпирической валидности (empirical validity). Выбирается критерий (независимая переменная), с которой связываются результаты теста. К примеру, критерием для теста готовности к школе может стать общая оценка успеваемости первоклассника.
• определение содержательной валидности (content validity). Разработанный тест должен включать вопросы для оценки максимально возможного числа параметров того свойства, которое этот тест измеряет (выше упоминалось первое правило составления теста - максимальное количество параметров свойства через минимальное количество заданий). Эта валидность также оценивается с помощью экспертных оценок.

Кстати, не только новые тесты проходят такой экзамен. В настоящее время многие исследователи заняты анализом эффективности уже известных тестов. Недавняя полемика на страницах психологического журнала "Psychological Science in the Public Interest" поставила под сомнение эффективность таких "мэтров" психодиагностических инструментов, как тест чернильных пятен Роршаха, ТАТ (тест тематической апперцепции) и проективный тест-рисунок фигуры человека. Оказалось, что эти психодиагностические методики имеет низкую эмпирическую валидность, низкую тест-ретестовую надежность и некорректно составленные нормативные показатели.

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

Психологический комплекс Effecton Studio

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

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

Ольга Данилова.

Эксклюзивный материал сайта "www.. Заимствование текста и/или связанных материалов возможно только при наличии прямой и хорошо различимой ссылки на оригинал. Все права защищены.

Демо-версия комплекса

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

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

Первое, что приходит на ум, – по количеству найденных дефектов. И именно этот показатель я сходу пытался ввести в «Инрэко ЛАН». Однако сразу же возникла бурная дискуссия, которая и подтолкнула меня к анализу данного критерия. На эту тему я и хочу порассуждать в этой статье.

Количество найденных дефектов - крайне скользкий показатель. Об этом же твердят и все ресурсы в сети, обсуждающие данную проблему (http://www.software-testing.ru/ , blogs.msdn.com/imtesty , it4business.ru , sqadotby.blogspot.com , blogs.msdn.com/larryosterman , sql.ru , http://www.testingperspective.com/ и много-много других). Проанализировав собственный опыт и эти ресурсы, я пришел к следующему дереву проблем:

Во-первых, дефект дефекту – рознь. Один тестировщик может искать дефекты в расположении кнопочек в приложении, другой – копаться в логике и придумывать сложные тестовые ситуации. В большинстве случаев первый тестировщик найдет больше дефектов, потому что даже на подготовку теста у него будет уходить гораздо меньше времени, но ценность таких дефектов значительно ниже. Эта проблема легко решается введением критичности дефекта. Можно оценивать по количеству найденных дефектов в каждой из категорий. У нас, например, их 4: критичный, значительный, средний и малозначительный. Но поскольку граница определения критичности не совсем четкая, хотя у нас и есть формальные признаки критичности, то можно пойти двумя более надежными путями. Первый - определенная часть найденных дефектов за выделенный период должна быть не малокритичными дефектами. Второй – не учитывать при оценке малозначительные дефекты. Таким образом, мы боремся с желанием тестировщика набрать как можно большее количество дефектов за счет описания мелочных изъянов, заставляя его (или чаще её) копать глубже и находить серьезные дефекты. А они всегда есть, поверьте моему опыту. Я выбрал второй вариант – отбрасывать малозначительные дефекты.

Вторая причина “скользкости” такого критерия – присутствие в системе достаточного количества дефектов, чтобы тестировщик мог их найти. Тут есть три фактора. Первый – сложность логики и технологии системы. Второй - качество кодирования. И третий – стадия проекта. Разберем по порядку эти три фактора. Сложность логики и технологии, на которой написана система, влияет на потенциальные недочеты, которые могут быть допущены. Причем зависимость здесь далеко не прямая. Если реализовывать простую логику на сложной или незнакомой платформе, то ошибки будут в основном связаны с некорректным использованием технологии реализации. Если реализовывать сложную логику на примитивной платформе, то, скорее всего, ошибки будут связаны как с самой логикой, так и со сложностью реализации такой логики на примитивном языке. То есть нужен баланс при выборе технологии реализации системы. Но часто технологию диктует заказчик или рынок, поэтому повлиять мы вряд ли можем. Значит, остается лишь учитывать этот фактор как некий коэффициент потенциального количества дефектов. Причем значение этого коэффициента, скорее всего, нужно определять экспертным путем.

Качество кодирования. Здесь мы уже точно никак повлиять не можем на разработчика. Зато мы можем: а) опять же экспертно оценить уровень разработчика и включить его как еще один коэффициент и б) постараться предотвратить появление ошибок в коде за счет модульных тестов, сделав обязательным требованием 100% покрытие кода модульными тестами.

Стадия проекта. Давно известно, что найти все дефекты невозможно, разве что для тривиальной программы или случайно, поскольку совершенству нет предела, а любое несовпадение с совершенством можно считать дефектом. Но одно дело, когда проект находится в активной стадии разработки, и совсем другое – когда в фазе поддержки. А если еще учесть факторы сложности системы и технологии и качества кодирования, то понятно, что все это коренным образом влияет на количество дефектов, которые тестировщик способен найти. С приближением проекта к завершению или к фазе поддержки (называем это все условно и определяем сейчас интуитивно) количество дефектов в системе уменьшается, а значит и количество находимых дефектов тоже. И тут нужно определить момент, когда требовать с тестировщика нахождения определенного количества дефектов становится неразумно. Для определения такого момента было бы неплохо знать, какую часть дефектов от общего их числа мы способны найти и сколько дефектов еще осталось в системе. Это тема для отдельной дискуссии, но можно применить достаточно простой и эффективный статистический метод.

На основании статистики предыдущих проектов можно понять с определенной погрешностью, сколько дефектов было в системе и сколько было найдено командой тестирования в различные периоды проекта. Таким образом, можно получить некий среднестатистический показатель эффективности команды тестирования. Его можно декомпозировать по каждому отдельному тестировщику и получить персональную оценку. Чем больше опыта и статистики, тем меньше будет погрешность. Также можно использовать метод «подсева ошибок», когда мы точно знаем, сколько ошибок в системе. Естественно, что нужно учитывать дополнительные факторы, такие как тип системы, сложность логики, платформу и т.п. Так, мы получаем зависимость между фазой проекта и процентом находимых дефектов. Теперь можно применить данную зависимость в обратную сторону: зная число найденных дефектов и текущую фазу проекта, мы можем определить общее число дефектов в нашей системе (с некоторой погрешностью, конечно же). И дальше на основании показателей персональной или общей оценки можно определить, сколько дефектов тестировщик или команда способны найти за оставшийся период времени. Отталкиваясь от этой оценки, уже можно определять критерий эффективности работы тестировщика.

Функция показателя эффективности работы тестировщика может выглядеть следующим образом:

Defects – количество находимых дефектов,

Severity – критичность находимых дефектов,

Complexity – сложность логики системы,

Platform – платформа реализации системы,

Phase – фаза проекта,

Period – рассматриваемый период времени.

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

Учесть все факторы на данный момент пока не удается, однако совместно с нашим ведущим разработчиком Иваном Астафьевым и руководителем проектов Ириной Лагерь, мы пришли к следующей формуле, учитывающей число дефектов и их критичность:

, где

E – эффективность, определяемая по числу найденных дефектов,

D Заказчик – число дефектов, найденных заказчиком, но которые должен был найти оцениваемый тестировщик,

D Тестировщик – число дефектов, найденных тестировщиком,

k и d – поправочные коэффициенты на общее количество дефектов.

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

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

Здесь есть нюанс, связанный с общим количеством анализируемых дефектов. Естественно, чем больше статистики, тем лучше, но иногда нужно проанализировать различные этапы проекта, иногда просто требуется оценка по каждому периоду времени. И одно дело, когда за период найдено 4 дефекта и 2 из них – заказчиком, и совсем другое, когда найдено 100 дефектов, и 50 из них - заказчиком. В обоих случаях отношение числа дефектов, найденных заказчиком и тестировщиком, окажется равным 0.5, но мы-то понимаем, что в первом случае не все так плохо, а во втором пора бить в набат.

Без особого успеха попытавшись сделать строгую математическую привязку к общему количеству дефектов, мы приделали, по выражению той же Ирины Лагерь, «костыли» к этой формуле в виде интервалов, для каждого из которых определили свои коэффициенты. Интервала получилось три: для статистики от 1 до 20 дефектов, от 21 до 60 дефектов и для статистики по более чем 60 дефектам.

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

Имеем графики следующего вида:

Черный график отражает критерий для выборки более 60 дефектов, желтый – для 21-60 дефектов, зеленый – для выборки менее 20 дефектов. Видно, что чем больше выборка, тем левее график пересекает ось X. Как уже говорилось, для оценивающего сотрудника это означает, что чем больше выборка, тем больше можно доверять этой цифре.

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

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

Кроме того, такая методика оценки эффективности тестировщика порождает несколько дополнительных проблем:

1.Один дефект начинает делиться на несколько более мелких.

· Руководитель тестирования, заметивший такую ситуацию, должен пресекать ее уже неформальными методами.

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

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

3.Отсутствие оценки качества находимых дефектов, поскольку единственной целью тестировщика становится количество дефектов, и, как следствие, отсутствие мотивации у тестировщика к поиску “качественных” дефектов. Все-таки нельзя приравнивать критичность и “качество” дефекта, второе является менее формализуемым понятием.

· Здесь решающую роль должен сыграть “настрой” и тестировщика и руководителя. Только общее правильное (!) понимание значения такой количественной оценки может решить данную проблему.

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

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

• · Время, необходимое для разработки тестов
• · Время, которое занимает один цикл тестирования
• · Квалификация персонала, необходимая для разработки и проведения тестов

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

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

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

Для расчёта инвестиций, необходимых для внедрения и эксплуатации автоматизированных тестов за выделенный период (Ip), используется следующая формула:

I0 - Оценка стартовых инвестиции, которые состоят из затрат на лицензии необходимого программного обеспечения для разработки автотестов, стоимости дополнительных аппаратных средств и.т.п.

C0 - Оценка стоимости разработки и отладки библиотеки автоматических тестов, которая рассчитывается как произведение среднего времени, нужного для написания одного автоматизированного теста одним разработчиком тестов (в часах), умноженное на цену его рабочего часа и на общее количество тестов, которые предстоит автоматизировать.

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

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

Cm - Оценка стоимости поддержания автоматизированных тестов в рабочем и актуальном состоянии. Рассчитывается как вероятность появления необходимости изменения одного теста между циклами тестирования, умноженная на количество тестов, на среднее время, необходимое для актуализации одного теста и на цену одного рабочего часа тестировщика.

Оценка стоимости ручного тестирования (Gp) представлена в следующей формуле:

G0 - Оценка стоимости разработки базы тест-кейсов для ручного тестирования.

k - Это количество планируемых прогонов тестов (циклов тестирования) за всё оставшееся время жизненного цикла продукта.

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

Ga - Оценка стоимости анализа результатов для одного прогона цикла ручного тестирования. Вычисляется как оценка средней доли отрицательных тестов в прогоне, умноженная на количество тестов, на среднее время, необходимое для анализа причин отрицательной оценки одного теста одним тестировщиком, и на цену одного рабочего часа тестировщика;

Gm - Оценка стоимости поддержания ручных тестов в актуальном состоянии. Рассчитывается как вероятность появления необходимости изменения одного теста между циклами тестирования, умноженная на количество тестов, на среднее время, необходимое для актуализации одного теста и на цену одного рабочего часа тестировщика .

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

Тест Вудкока

Инструкция

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

Не тратьте много времени, обдумывая каждое утверждение: достаточно нескольких секунд.

Помните, что результаты будут иметь смысл, только если Вы искренни.

Тестовое задание

1. Наша команда испытывает достаток в лидерстве.

2. Кажется, что решения являются принудительными по отношению к нам.

3. Людей не поощряют высказываться откровенно.

4. В трудной ситуации каждый берется за свои интересы.

5. Общение нуждается в улучшении.

6. Решения принимаются на неадекватном уровне иерархии.

7. Некоторые менеджеры неискренни сами с собой.

8. Мы редко подвергаем сомнению основное содержание или пользу наших совещаний.

9. Созданы недостаточные возможности для развития.

10. Мы часто ссоримся с другими подразделениями.

11. Члены команды не общаются друг с другом в достаточной мере.

12. Ясно, что организация ожидает от нашей команды.

13. Принятый порядок редко подвергается сомнению.

14. В действительности никому не ясно, куда мы движемся.

15. Люди не говорят, что они в действительности думают.

16. Люди имеют позицию «моя хата с краю».

17. В команде конфликт носит деструктивный характер.

18. Решения основываются на неадекватной информации.

19. Некоторым менеджерам не доверяют.

20. Мы не учимся на своих ошибках.

21. Менеджеры не помогают своим подчиненным учиться.

22. Отношения с другими группами являются прохладными.

23. Мы не обдумываем хорошо наше положение внутри организации.

24. Наша команда «политически» восприимчива.

25. Мы часто обнаруживаем, что нам недостает нужной квалификации.

26. Мы все очень заняты, но, кажется, везде не успеваем.

27. Спорные вопросы прячутся под ковер.

28. Помогло бы, если бы люди имели больше желания признавать свои ошибки.

29. Имеют место недоверие и враждебность.

30. Люди не допускаются к решениям.

31. Мало лояльности к команде.

32. Мнения извне не приветствуются.

33. Следовало бы иметь большую ротацию работ.

34. Мы редко работаем эффективно вместе с другими командами.

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

36. Способность работать в команде является критерием отбора при поступлении в эту организацию.

37. Никто не налаживает необходимых связей с другими группами.

38. Мы не тратим требуемого времени на планирование будущего.

39. Деликатных вопросов избегают.

40. Бывает, что кому-то «всадили нож в спину».

41. В действительности мы не работаем вместе.

42. Неподходящие люди принимают решения.

43. Менеджеры являются слабыми и не готовы бороться и требовать внимания к своей точке зрения.

44. Я не получаю достаточной обратной связи.

45. Развиваются несоответствующие виды умений.

46. Помощь не придет из других частей организации.

47. Существует сильное непонимание между нашей командой и профсоюзами, которые оказывают давление на нас.

48. В этой организации вознаграждается слаженность работы в команде.

49. Мы не уделяем достаточно внимания взаимоотношениям.

50. Мы не имеем ясного представления о том, чего от нас ожидают.

51. Честность не является характерной чертой нашей команды.

52. Я не чувствую поддержки со стороны моих коллег.

53. Квалификация и информация распределены недостаточно хорошо.

54. Имеются сильные личности, которые идут своим собственным путем.

55. Чувство собственного достоинства не одобряется.

56. Нам следует уделять больше времени обсуждению методов работы.

57. Менеджеры не принимают всерьез личное развитие.

58. Другие части организации нас не понимают.

59. Нам не удается донести наше сообщение к внешнему миру.

60. Люди в команде имеют хорошие связи с другими членами организации.

61. Часто мы достигаем решений слишком быстро.

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

63. Слишком много секретов.

64. Конфликтов избегают.

65. Разногласия разлагают.

66. Приверженность к решениям низка.

67. Наши менеджеры полагают, что более строгий надзор улучшает результат.

68. Слишком много запретов в нашей команде.

69. Очевидно, что в другом подразделении имеются лучшие возможности.

70. Мы тратим много энергии на защиту наших границ.

71. Члены команды не понимают, чего от них ожидают.

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

73. Мы не уделяем достаточно внимания новым идеям.

74. Приоритеты не ясны.

75. Люди не вовлекаются в достаточной мере в принятие решений.

76. Слишком много взаимных обвинений и упреков.

77. Не всегда выслушивают.

78. Мы не используем в полном объеме навыки, которыми обладаем.

79. Менеджеры полагают, что люди по своему существу ленивы.

80. Мы тратим много времени на то, чтобы делать, и не уделяем достаточно времени тому, чтобы думать.

81. Не поощряется стремление личности к росту.

82. Мы не стараемся понять точку зрения других команд.

83. Нам не удается выслушать наших клиентов.

84. Команда работает в соответствии с целями организации.

Спасибо за ответы!

Ключ к тесту Вудкока для оценки эффективности команды

Описание

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

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

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

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

Ключ к тесту

Перенесите выделенные ответы из анкеты в таблицу результата. Посчитайте количество отметок в каждом столбце. Запишите количество в строке «Итого».

Таблица результата

Перенесите счет столбцов из строки «Итого» в таблицу.