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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Экономика

Тестирование эффективности системы внутреннего контроля

Рахманкулов И.Ш.

доктор экономических наук, профессор кафедры организации производства Казанского государственного финансовоэкономического института

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

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

1. Определение контролей, подлежащих тестированию.

2. Определение сотрудников, которые будут проводить тестирование.

3. Разработка и выполнение планов тестирования.

4. Оценка результатов тестирования.

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

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

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

‘Вестникэкономики, права и социологии”, №1, 2007 г.

Экономика

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

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

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

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

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

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

‘Вестникэкономики, права и социологии”, №1, 2007 г.

Экономика

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

В таблице 2 представлены предложения для отбора необходимого минимума бизнесединиц из категории 2, в которых должны быть протестированы контроли корпоративного уровня.

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

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

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

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

Методы тестирования - существует четыре метода проведения тестирования: подтверждение, наблюдение, ревизия документов или повторное выполнение.

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

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

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

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

Документация - в планах должна описываться требуемая документация.

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

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

‘Вестникэкономики, права и социологии”, №1, 2007 г.

Экономика

Предложения по объему работ

Таблица 1

Катего- рия Минимальное покрытие балансовых счетов Бизнес-единицы Планируемые процедуры

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

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

3 < 5% Объекты, не являющиеся ключевыми ни по отдельности, ни в совокупности Тестирование не требуется.

Таблица 2

Предложения по отбору бизнес-единиц

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

Менее 20 2 - 4

100 и более 10 - 20 и более

ния. Характер контроля также влияет на выбор метода тестирования.

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

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

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

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

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

‘Вестникэкономики, права и социологии”, №1, 2007 г.

Экономика

что общие компьютерные контроли, применяемые в ИТ-системе, были протестированы и признаны эффективными.

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

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

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

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

Основные выводы:

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

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

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

‘Вестникэкономики, права и социологии”, №1, 2007 г.

Экономика

заказов на поставку и счетов-фактур от поставщиков. Система автоматически генерирует отчет о несоответствиях по всем несовпадающим позициям. Затем эти несоответствия анализируются и устраняются отделом по учету кредиторской задолженности. Этот механизм контроля состоит из двух элементов (1) автоматизированного трехстороннего сопоставления и (2) неавтоматизированного анализа

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

Литература:

1. Практическое руководство для менеджмента. Закон Сарбейнса-Оксли (Раздел 404). Издательство: п ю х. 2005. - 138 с.