Критерии эффективности процесса тестирования. Тесты в процессе разработки программного обеспечения Метрики, из которых складываются 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 с.

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

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

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

Количество найденных дефектов - крайне скользкий показатель. Об этом же твердят и все ресурсы в сети, обсуждающие данную проблему (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.Отсутствие оценки качества находимых дефектов, поскольку единственной целью тестировщика становится количество дефектов, и, как следствие, отсутствие мотивации у тестировщика к поиску “качественных” дефектов. Все-таки нельзя приравнивать критичность и “качество” дефекта, второе является менее формализуемым понятием.

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

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

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

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

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

Наиболее распространенный способ оценки эффективности (прежде всего экономической) является расчет возврата инвестиций (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 также похожа на спиральную модель, в том смысле, что вся процедура тестирования разбивается на несколько циклов. Каждый цикл состоит из четырех этапов - создание, разработка, строительство, и переход. В конце каждого цикла продукт/выход пересматривается, и далее цикл (состоящий из тех же четырех фаз) следует при необходимости.

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

Перевод : Ольга Алифанова

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

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

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

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

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

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

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

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

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

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

Изящество можно рассматривать в том числе как минимизацию сложности. В мире разработки люди часто делят сложность решений на обязательную и случайную. Следовательно, для того, чтобы решения в тестировании были изящными, они должны состоять только из "обязательной сложности" и практически не содержать случайной. Звучит, наверное, загадочно? Да, возможно, так как сколько людей – столько мнений о том, где начинается "сложность". Для меня сложность решений в тестировании возникает, когда в системе нет выборов и в наличии высокая неопределенность.

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

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

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

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

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

Теперь давайте применим эти концепции к тест-сьюту:

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

И, наконец, давайте приложим эти определения к тестированию как виду деятельности:

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

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

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

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

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

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

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