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