Какие бывают характеристики
Для начала определим два простых понятия, необходимых для понимания дальнейшего изложения.
Количественной характеристикой программной системы называется ее свойство, которое можно измерить и выразить числом. С ним тесно связано понятие метрики — меры, позволяющей получить численное значение этого свойства. При разработке тестов для метрики определяют единицу измерения, метод измерения и числовой критерий приемлемости значения метрики.
Количественные характеристики программных систем — это, например, количество элементов пользовательского интерфейса, объем занимаемой оперативной памяти, скорость передачи данных. Результаты тестов количественной характеристики можно объективно оценить, поскольку она сводится к численному сравнению полученного фактического результата с ожидаемым (критерием успешности).
Замечу, что характеристики, которые можно свести к логическому значению, например наступление какого-либо события, также относятся к количественным: их легко выразить числом по правилу «ложь = 0, истина = 1».
Качественной характеристикой программной системы называется свойство, которое непосредственно измерить нельзя. Например, удобство использования, безопасность, надежность.
На практике используются два подхода к объективной оценке качественных характеристик:
- статистическая обработка субъективных оценок;
- косвенная оценка по количественным характеристикам.
Первый подход даёт статистически достоверные результаты только в случае достаточно большого количества субъективных оценок от тестовых инженеров, участников фокус-групп или реальных пользователей приложения. Зачастую сбор нужного количества данных оказывается дорогим и долгим, а сами оценки всё равно могут оказаться смещенными и недостоверными, например, из-за «человеческого фактора» или ошибок в методике тестирования.
Второй подход также имеет свои «слабые места»: неправильный или неполный выбор количественных характеристик приводит к неверной оценке качественной характеристики. Однако обычно этот подход более достоверный, дешевый и доступный, поэтому мы возьмем его за основу и рассмотрим один из методов оценки качественных характеристик с его помощью.
Помимо классификации тестируемых характеристик как количественных и качественных, существует также разделение на простые и сложные/составные. Совмещение этих двух классификаций разделяет тестируемые характеристики на условные группы.
Сразу оговорюсь, что разделение характеристик на простые (элементарные) и сложные (составные) в значительной степени зависит от особенностей конкретного тестирования, в частности, от цели, вида и уровня тестирования. Границы между классами довольно условны, а их обозначение не является общепринятым, то есть каждый инженер, исходя из решаемой задачи, может разбивать тестируемые характеристики и обозначать их так, как ему это удобно. Я же на основе классификации выше рассмотрю общий подход к тестированию качественных характеристик.
Протестируем качественные характеристики
Качественные характеристики сложно проверять в основном из-за их неопределенности и субъективности оценки результата. В свою очередь, это связано с самой природой таких характеристик, что часто усугубляется плохими формулировками исходных требований к разрабатываемой системе. В качестве примера можно привести одно из «классических» требований, которое я не раз и не два встречал в реальных технических заданиях на программные системы. Выглядит оно примерно так: «ХХ.ХХХ. Пользовательский интерфейс должен быть интуитивно понятен».
Что с ним не так? Дело в том, что, если нет пояснений, детализирующих и конкретизирующих это требование, его нельзя протестировать в принципе! Попытка написать тест вида «Проверка интуитивной понятности пользовательского интерфейса…» может ввергнуть тестового инженера в глубокую депрессию и вызвать настоятельную необходимость посетить психиатра. Почему? Попробуем разобраться.
Основная сложность тестирования подобного требования заключена в неопределенности самого термина «интуитивная понятность». Хотя его часто используют в области разработки пользовательского интерфейса, точного определения нет ни в одном стандарте. Кроме того, эта характеристика еще и очень субъективна: то, что интуитивно понятно одному человеку, другому может быть непонятно вообще. В частности, разная трактовка неопределенных понятий является причиной многочисленных конфликтов между разработчиками программы и ее заказчиками на стадии приемочного тестирования. По этой же причине программист может не соглашаться с результатами тестирования, если он и тестовый инженер по-разному понимают одно и то же требование.
Что же делать, когда всё-таки нужно проверить подобное требование? Для решения этой задачи можно предложить следующий общий алгоритм, который в терминах таблицы выше можно выразить последовательностью преобразований:
QII → QI → MII → M1.
Рассмотрим этот алгоритм более подробно в виде последовательности шагов.
Шаг 1. Выявляем неопределенные характеристики
Прежде всего нужно выделить качественные характеристики проверяемого объекта, которые необходимо протестировать. Для этого обычно применяют следующие подходы:
- Выделение на основе опыта. На практике это делают в первую очередь, и подход замечательно работает в большинстве случаев. Действительно, даже небольшой опыт в тестировании позволяет довольно уверенно выделять качественные характеристики.
- Выделение на основе ключевых слов. Качественные характеристики описываются характерными словами, например «удобство», «информативность», «доступность», «логичность», «корректность». Список подобных ключевых слов можно оформить в виде справочника, который можно использовать при автоматизации тестов. Замечу, что первый подход неявно или интуитивно основан на втором.
- Выполнение специальных тестов. Они применяются либо к формулировкам требований, либо непосредственно к описанию характеристик. Простейший тест этого типа основан на поиске в специальных справочниках метрик, в которых каждой характеристике сопоставляется одна или несколько метрик. Если нужной характеристики в словаре нет, то она считается качественной. Можно предложить и более сложные тесты, например, основанные на использовании специальных классификаторов, в том числе с применением искусственного интеллекта.
В результате мы должны получить список качественных характеристик, которые нам нужно протестировать, с указанием их принадлежности к одному из классов QI или QII.
Шаг 2. Снижаем неопределенность
На втором этапе следует максимально конкретизировать качественные характеристики и представить их в наиболее простом виде. Другими словами, нужно характеристики класса QII привести к классу QI. Самый очевидный прием такого преобразования — замена сложной качественной характеристики набором более простых или более конкретных качественных характеристик. Например, «интуитивную понятность» интерфейса можно заменить на «стандартность» и «информативность» интерфейса.
Снизить неопределенность помогают следующие подходы:
- Уточнение требований к качественным характеристикам системы с помощью заказчиков системы и ее пользователей.
- Более тщательный анализ предметной области, составление подробной ее модели и словаря предметной области.
- Изучение внешних источников, таких как аналогичные системы, стандарты и специальная литература для поиска более точных определений качественных характеристик.
- Анализ проектной документации, составление детальной программной модели приложения, анализ алгоритмов и структур данных.
- Анализ исходного кода системы.
Этот этап на практике бывает самым трудоемким, поэтому работу желательно распределить между разработчиками, выполняющими разные роли. Например, пункты 1, 2 и 3 в идеале должны выполнять разработчики требований (в отечественной практике их роль играют бизнес-аналитики или системные аналитики), пункт 4 — дизайнеры системы (архитекторы, дизайнеры пользовательского интерфейса, разработчики баз данных), пункты 3 и 5 могут частично выполнять тестовые инженеры.
В результате все качественные характеристики класса QII должны быть представлены в виде более простых и конкретных характеристик класса QI.
Шаг 3. Заменяем качественные характеристики на количественные
На этом этапе каждая характеристика класса QI преобразуется в набор характеристики класса MII, а затем каждая характеристика класса MII преобразуется в набор характеристик класса MI. Проще говоря, каждая качественная характеристика сводится к набору количественных. Например, характеристику «информативность поля ввода» в конечном счете можно свести к набору хорошо проверяемых количественных характеристик, в число которых входят:
- наличие поясняющей надписи или всплывающей подсказки;
- индикация доступности поля для ввода значений;
- индикация фокуса ввода, то есть указание на то, в какое конкретно поле будет вводить данные пользователь;
- наличие указателя текущей позиции ввода;
- сообщения об ошибках ввода.
В результате все качественные характеристики заменяются набором количественных характеристик классов MI или MII.
Шаг 4. Разрабатываем тесты для проверки количественных характеристик
На последнем шаге разрабатываются тесты для всех характеристик классов MI и MII, определенных на предыдущем шаге.
Если стоит задача разработать тест по проверке простой количественной характеристики класса MI, то обобщенный алгоритм разработки теста выглядит следующим образом:
- Выбираем подходящую метрику для измерения проверяемой величины и единицу ее измерения.
- Выбираем метод измерения нужной величины.
- Определяем критерий успешности/приемлемости результата измерений.
- Разрабатываем и документируем спецификацию теста.
В качестве примера возьму задачу тестирования карандаша, которую или подобную которой любят задавать на собеседованиях. Набросаю проект теста по проверке длины карандаша в соответствии с вышеизложенным алгоритмом разработки теста.
- Выбираем метрику — длину, измеряемую в миллиметрах.
- Метод измерения — вручную с помощью линейки с миллиметровыми делениями.
- Критерий приемлемости определяем из спецификации требований заказчика к длине карандаша или выбираем его из документов типа ГОСТов или технических условий.
- В соответствии с принятыми правилами документируем тест.
Всё это замечательно работает, если речь идет о количественной и простой характеристике. Однако и тестирование сложных количественных характеристик класса MII в целом выполняется по этой же схеме. Различия проявляются лишь в том, что в случае сложных количественных характеристик применяются более сложные метрики, более сложные методы измерений и более сложные критерии приемлемости. Например, если нужно проверить объем карандаша, метрикой будет служить единица объема, измеряемая в кубических миллиметрах. Кроме этого, метод измерения объема карандаша должен включать методы измерения длины, площади основания карандаша и вычисления его объема.
Подведем итоги
Нетрудно заметить, что описанный метод основан на двух хорошо известных подходах. Первый — это принцип декомпозиции сложной задачи на более простые, как повелось еще со времен Древнего Рима: «Разделяй и властвуй». Второй заключается в поэтапной замене сложной качественной характеристики на набор более простых количественных характеристик, что позволяет:
- Относительно просто разрабатывать и выполнять тесты.
- Получать объективные оценки результатов тестов, поскольку они основаны на математически точных операциях сравнения чисел. Это важное преимущество, потому что на практике качественные характеристики часто оцениваются субъективно.
Бонус для тех, у кого хватило терпения дочитать до конца. Точно следовать методике тестирования довольно трудоемко, но это дает отличный результат с точки зрения полноты и точности тестирования качественных характеристик. Это особенно важно при автоматизации тестирования. На практике автоматизация тестирования качественных характеристик часто выполняется ограниченно или не выполняется вообще именно из-за незнания того, как это можно сделать.
Надеюсь, теперь вы знаете один из подходов к этому. Удачи!
