Процесс тестирования должен быть эффективен в первую очередь с точки зрения компании, в которой он протекает. Компании могут быть интересны следующие параметры процесса тестирования:
- · Время, необходимое для разработки тестов
- · Время, которое занимает один цикл тестирования
- · Квалификация персонала, необходимая для разработки и проведения тестов
Изменив любой из этих параметров, компания может повлиять на качество тестирования. Однако важно понимать, что любая комбинация этих параметров может быть выражена в денежном эквиваленте, и, как правило, у любого конкретного процесса тестирования есть оптимальная комбинация, при которой достигается достаточный уровень качества тестирования при минимальных денежных затратах.
Автоматизируя процесс тестирования, мы, разумеется, меняем процесс тестирования, а вместе с ним поменяется и оптимальная комбинация перечисленных выше параметров. Например, можно ожидать, что увеличится время, необходимое для разработки тестов и повысятся требования к квалификации персонала, при этом сильно понизится, время, занимаемое одним циклом тестирования. Учитывая, что комбинация параметров стала новой, вероятно поменяется и качество тестирования вместе с его стоимостью. Для того чтобы была возможность дать численный эквивалент эффективности процесса тестирования, предлагается зафиксировать параметр качества на определенном уровне. Тогда численной оценкой эффективности определенного способа тестирования будет являться величина инвестиций, необходимая для того, чтобы он обеспечивал некий определенный уровень качества.
Оценка целесообразности автоматизации тестирования производится с помощью подсчета затрат на ручное и автоматизированное тестирование и их сравнение , . Точно посчитать финансовую целесообразность автоматизации тестов обычно невозможно, поскольку она зависит от параметров, которые в процессе разработки продукта могут быть лишь примерно понятно (например, планируемая длина жизненного цикла системы или точный список тестов, подлежащих автоматизации).
Для расчёта инвестиций, необходимых для внедрения и эксплуатации автоматизированных тестов за выделенный период (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 утверждения. Затем по специальной таблице выполняются подсчет результатов и их анализ.
Если вы сомневаетесь, что члены команды будут честно отвечать на вопросы, постарайтесь обеспечить анонимность тестирования. По большому счету это уже показатель взаимоотношений в команде. Тем не менее провести тестирование все равно полезно, так как его результаты позволяют точнее выявить недостатки в работе команды.
Кроме того, очень полезно сравнить результаты тестов руководителей и их подчиненных. Это позволяет оценить атмосферу в команде и определить степень доверия подчиненных к руководству.
Ключ к тесту
Перенесите выделенные ответы из анкеты в таблицу результата. Посчитайте количество отметок в каждом столбце. Запишите количество в строке «Итого».
Таблица результата
| А | В | С | D | Е | F | G | Н | I | J | К | L | |
| 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 | 70 | 81 | 82 | 83 | 84 | |
| Итого |
Перенесите счет столбцов из строки «Итого» в таблицу.
Ошибки, влекущие за собой снижение эффективности теста, появляются, если:
- Тест неправильно составлен
- Тест неправильно стандартизован
- Тест неправильно использован
Конструирование теста
Прежде всего, необходимо четко представлять себе то психологическое свойство, которое будет измерять будущий тест. Ни один тест не создается "с нуля", обычно за его созданием стоит длительная научная работа по изучению тематического материала.
Перед конструктором психологического теста стоит сложная задача - наиболее полно отразить все стороны измеряемого психологического свойства через минимальное количество заданий. Последнее условие - один из критериев эффективности теста. Это не означает, что личностный опросник Кеттела , содержащий полтысячи вопросов, можно считать неэффективным. При таком большом количестве измеряемых личностных факторов (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 дефектам.
|
Кол-во дефектов |
k |
d |
Предполагаемая допустимая часть дефектов, найденных заказчиком от общего числа найденных дефектов |
Последний столбец в таблице введен для пояснения того, какое число дефектов допустимо найти заказчику на данной выборке. Соответственно, чем меньше выборка, тем больше может быть погрешность, и тем больше дефектов может быть найдено заказчиком. С точки зрения функции это означает предельное минимальное значение отношение числа дефектов, найденных заказчиком и тестировщиком, после которого эффективность становится отрицательной, или точку пересечения графиком оси X. Т.е. чем меньше выборка, тем правее должно быть пересечение с осью. В управленческом же плане это означает, что чем меньше выборка, тем менее точной является такая оценка, поэтому исходим из принципа, что на меньшей выборке нужно менее строго оценивать тестировщиков.
Имеем графики следующего вида:
Черный график отражает критерий для выборки более 60 дефектов, желтый – для 21-60 дефектов, зеленый – для выборки менее 20 дефектов. Видно, что чем больше выборка, тем левее график пересекает ось X. Как уже говорилось, для оценивающего сотрудника это означает, что чем больше выборка, тем больше можно доверять этой цифре.
Метод оценки заключается в вычислении эффективности работы тестировщика по формуле (2) с учетом поправочных коэффициентов и сравнение этой оценки с требуемым значением на графике. Если оценка выше графика – тестировщик соответствует ожиданиям, если ниже – тестировщик работает ниже требуемой «планки». Также хочу отметить, что все эти цифры были подобраны эмпирически, и для каждой организации они могут быть изменены и подобраны со временем более точно. Поэтому любые комментарии (здесь или в моем личном блоге) и доработки я только приветствую.
Такой метод оценки по соотношению количества найденных дефектов командой тестирования и заказчиком/пользователем/клиентом, мне кажется разумным и более-менее объективным. Правда такую оценку можно провести только после завершения проекта или, как минимум, при наличии активных внешних пользователей системы. Но что делать, если продукт еще не используется? Как в этом случае оценивать работу тестировщика?
Кроме того, такая методика оценки эффективности тестировщика порождает несколько дополнительных проблем:
1.Один дефект начинает делиться на несколько более мелких.
· Руководитель тестирования, заметивший такую ситуацию, должен пресекать ее уже неформальными методами.
2.Управление дефектами становится более сложным из-за увеличивающегося количества дублирующихся записей.
· Правила фиксирования дефектов в систему отслеживания ошибок, включающие обязательный просмотр наличия схожих дефектов, могут помочь решить эту проблему.
3.Отсутствие оценки качества находимых дефектов, поскольку единственной целью тестировщика становится количество дефектов, и, как следствие, отсутствие мотивации у тестировщика к поиску “качественных” дефектов. Все-таки нельзя приравнивать критичность и “качество” дефекта, второе является менее формализуемым понятием.
· Здесь решающую роль должен сыграть “настрой” и тестировщика и руководителя. Только общее правильное (!) понимание значения такой количественной оценки может решить данную проблему.
Резюмируя все вышесказанное, мы приходим к выводу, что оценивать работу тестировщика только по количеству находимых дефектов не только сложно, но и не совсем правильно. Поэтому количество находимых дефектов должно быть лишь одним из показателей интегральной оценки работы тестировщика, причем не в чистом виде, а с учетом перечисленных мной факторов.
