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

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

Тест Вудкока

Инструкция

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

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

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

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

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 утверждения. Затем по специальной таблице выполняются подсчет результатов и их анализ.

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

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

Ключ к тесту

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

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

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

Является актуальной уже много лет, этому вопросу посвящено немало исследований. В данной статье мы на примере реального проекта рассмотрим процесс внедрения 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 на проекте: эти затраты полностью окупятся! Ваш заказчик будет удовлетворен проведенными работами и отличным качеством продукта. Он вновь и вновь обратится к вам за помощью!

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

Как можно при помощи достаточно простого инструмента оценить возможную эффективность использования автотестов на проекте?

Что определяется как «эффективность» автоматизации тестирования?

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

В случае автоматизации под прибылью понимается экономия на ручном тестировании . Кроме того, что прибыль в данном случае может быть и не явной – например, результаты нахождения дефектов в процессе ad-hoc тестирования инженерами, время которых высвободилось за счет автоматизации. Такую прибыль достаточно сложно рассчитать, поэтому можно либо делать допущение (например +10%) либо опускать.

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

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

Зачем измерять эффективность?

Измерение эффективности помогает ответить на вопросы: «стоит ли внедрять автоматизацию на проекте?», «когда внедрение принесет нам значимый результат?», «сколько часов ручного тестирования мы заместим?», «можно ли заменить 3 инженеров ручного тестирования на 1 инженера автоматизированного тестирования?» и др.

Данные расчеты могут помочь сформулировать цели (или метрики) для команды автоматизированного тестирования. Например, экономия X часов в месяц ручного тестирования, сокращение расходов на команду тестирования на Y условных единиц.

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

Тестирование программного обеспечения является неотъемлемой частью цикла разработки программного обеспечения.

Что такое тестирование программного обеспечения?

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

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

Методика тестирования

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

3) Системное тестирование

4) Приемочные испытания

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

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

Системное тестирование

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

Приемочные испытания

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

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

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

Тестирование методом черного ящика

Тестирование методом черного ящика осуществляется без каких-либо знаний внутренней работы системы. Тестер будет стимулировать программное обеспечение для пользовательской среды, предоставляя различные входы и тестируя сгенерированные выходы. Этот тест также известен как Black-box, closed-box тестирование или функциональное тестирование.

Тестирование методом белого ящика

Тестирование методом "Белого ящика", в отличие от "черного ящика", учитывает внутреннее функционирование и логику работы кода. Для выполнения этого теста, тестер должен иметь знания кода, чтобы узнать точную часть кода, имеющую ошибки. Этот тест также известен как White-box, Open-Box или Glass box тестирование.

Тестирование методом серого ящика

Тестирование методом серого ящика или Gray box тестирование, это что-то среднее между White Box и Black Box тестированием, где тестер обладает лишь общими знаниями данного продукта, необходимыми для выполнения теста. Эта проверка осуществляется посредством документации и схемы информационных потоков. Тестирование проводится конечным пользователем, или пользователям, которые представляются как конечные.

Нефункциональные тесты

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

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

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

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

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

Тесты в процессе разработки программного обеспечения

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

Основными шагами, участвующими в данной методике тестирования программного обеспечения, являются:

• Анализ потребностей
• Тест дизайна
• Тест реализации
• Тестирование, отладка и проверка кода или продукта
• Внедрение и обслуживание

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

Agile Model

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

Rapid Application Development (RAD). Методология быстрой разработки приложений

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

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

Спиральная модель

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

Rational Unified Process (RUP). Рациональный унифицированный процесс

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

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

Отказ от тестирования часто связан с критическим отношением к нему со стороны рекламных (особенно творческих) работников, а также с экономией денежных средств и времени. Тестирование может затормозить запуск рекламной кампании, а значит – и самого продукта. Вместе с тем очевидно, что при больших бюджетах тестирование помогает избежать многомиллионных ошибок. Оно также может быть полезным и для некрупных рекламодателей, для которых несложно подобрать простые, недорогие тесты. Как говорят классики рекламы, «тестирование может быть ограни­ченным или даже неудачным, но оно все равно даст что-то, от чего можно отталкиваться, чем можно руководствоваться».

Исследователи насчитывают несколько тысяч видов тестов. Не меньше существует и мнений о полезности и правильности проведения тех или иных тестов.

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

Действительно, выявить решающий фактор зависимости между самим рекламным обращением и его воздействием (или отсутствием этого воздействия) на отдельного человек весьма затруднительно. Например, в ходе одного из исследований группу, состоящую из управляющих по товару и управляющих службой рекламы фирм, руководителей рабочих групп рекламных агентств, творческих работников, спе­циалистов по средствам рекламы и специалистов исследователь­ских служб, «попросили отобрать лучшие объявления из числа тех, что были уже тщательно проверены на рынке. Результат? Хотя экспертам, в общем-то, удалось установить, какие объявления должны были привлечь наибольшее число читателей, они не сумели определить, какие объявления помогли продать больше товара». Как уже говорилось ранее, кроме рекламы, слишком много других различных факторов влияет на продажи. А по утверждению авторитетнейших специалистов, «методов быстрого и несложного контроля многочисленных факторов, оказывающих влияние на сбыт, не существует».

Согласно мнению Ч. Сэндиджа, В. Фрайбургера и К.Ротцолла, «на реакцию влияет множество всевоз­можных “причин”, а каждая переменная раздражителя порождает множество “эффектов”. Одно и то же объявление может, к примеру, раздражать, информировать, забавлять, подкреплять уверенность, побуждать к действию, может оказаться полностью проигнорированным в момент контакта, а позднее его могут быстро забыть или частично припомнить, оно же может стать причиной перемены в отношении или осведомленности. Поэтому совершенно ясно, что, решая, какими параметрами ответной реакции воспользоваться, исследователь должен во многом руко­водствоваться здравым смыслом».

В связи с вышесказанным представляется очевидным, что объявление (прежде чем на него отреагируют) должно быть увидено. После контакта с рекламой человек также должен знать торговую марку или название компании, разбираться в свойствах, преимуществах и выгодах товара. У человека может появиться рациональная или эмоциональная предрасположенность к покупке определенного товара. К этому можно добавить мнение руководства одного из крупнейших мировых рекламодателей General Motors : «Эффективность будет прежде всего измеряться достоверностью, способностью использовать эмо­ции и убедительностью рекламы».

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

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

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

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

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

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

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

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

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

Видеоверсия лекции " Тестирование эффективности современной рекламы "

(готовится к публикации)

Более подробную информацию на эту тему можно найти в книге А. Назайкина