Home

Автор: Баранцев Алексей

Критерий — это некоторый признак, который имеет три основных назначения: при помощи него производится 1) оценка, 2) определение и 3) классификация. Рассмотрим эти три назначения по очереди применительно к тестированию программного обеспечения. Критерий начала тестирования. Критерии прекращения и завершения тестирования. Еще раз о метриках и оценках.

Введение

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

Лирическое отступление про термины

Термины всегда вызывают много споров. Хочется найти такие определения терминов, которые бы удовлетворяли всех. Увы, такое случается редко. Люди вкладывают в одни и те же слова разный смысл, что иногда приводит к взаимному непониманию.

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

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

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

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

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

Например, упомянутый ранее термин «функция» имеет определенные смысловые оттенки в зависимости от контекста, но если сказать «математическая функция» или «функция на языке С», контекст немедленно проясняется.

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

Что такое «критерий»?

Словарь Ушакова дает следующее определение (http://ushdict.narod.ru/040/w12150.htm):

Итак, критерий — это некоторый признак, который имеет три основных назначения: при помощи него производится 1) оценка, 2) определение и 3) классификация.

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

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

Итак, почему в других предметных областях с этим термином не возникает проблем? Для ответа на этот вопрос достаточно обратить внимание на то, в каких контекстах употребляется это словосочетание, и что при этом подразумевается под тестированием.

Можно выделить два основных контекста, в которых употребляется термин «критерий тестирования».

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

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

Других достаточно распространенных случаев мне неизвестно.

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

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

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

Оценка и определение

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

Использование критериев, как можно видеть из этимологии термина (греч. kriterion — средство для решения), неразрывно связано с принятием тех или иных решений. Критерий помогает определить, какое решение следует принять в той или иной ситуации.

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

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

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

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

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

Критерий начала тестирования

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

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

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

Напомним еще раз, что критерий — это не просто метрика, а пара: метрика плюс некоторое критическое значение.

Таким образом, в качестве критерия начала разработки тестов может выступать, например, следующее условие: «описаны все варианты использования». Здесь метрика — отношение количества описанных вариантов использования к числу всех заявленных, критическое значение — 100%.

Однако это условие не может служить критерием начала выполнения тестов, для этого придётся подождать выполнения некоторого другого условия, например, такого: «реализована половина функциональности приложения, разработчики покрыли unit-тестами 80% написанного кода, и эти тесты не обнаруживают ошибок». Здесь мы видим составную метрику, построенную из трёх зависимых простых метрик. Первая — процент реализованных «фич», или функциональных точек, или вариантов использования, или еще чего-нибудь, в чём можно измерить функциональность, критическое значение — 50%. Вторая — покрытие написанного кода unit-тестами, критическое значение — 80%. Третья — отношение количества успешных unit-тестов к их общему числу, критическое значение — 100%.

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

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

Впрочем, не так сложно начать тестирование, как его закончить.

Критерии прекращения и завершения тестирования

Если начать что-нибудь делать можно лишь одним способом, закончить можно как минимум двумя — успешно и неуспешно.

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

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

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

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

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

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

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

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

• тестирование прекращается, если выявлены нарушения более чем 20% требований к функциональности приложения (метрика — отношение количества невыполненных требований к их общему числу, критическое значение — 20%),
• тестирование завершается, если проверено выполнение всех требований (метрика — отношение количества выполненных требований к их общему числу, критическое значение — 100%),
• тестирование продолжается, если не выполнено ни одно из предыдущих двух условий.

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

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

Еще раз о метриках и оценках

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

Мини-критерии

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

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

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

Классификация

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

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

Использование критерия отбора для формирования тестовых наборов, на мой взгляд, наиболее ярко и наглядно объясняется в следующей цитате из статьи Ольги Беззубовой «Музей как объект философско-антропологического исследования» (http://anthropology.ru/ru/texts/bezzubova/symp12_40.html):

Да, набор тестов — это не библиотека и не архив, это — музей.

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

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

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

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

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

Заключение

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

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

Заранее спасибо всем отказавшимся! :)