909
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Тестируем качественные характеристики. Как сделать сложное простым

Время чтения 5 минут
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
909
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Здравствуйте! Меня зовут Юрий Заковряшин. Я занимаюсь разработкой программного обеспечения с 1984 года, а также читаю курсы по технологиям разработки программного обеспечения и программированию на платформе Java в Санкт-Петербургском политехническом университете Петра Великого.

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

Тестируем качественные характеристики. Как сделать сложное простым

Какие бывают характеристики

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

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

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

Замечу, что характеристики, которые можно свести к логическому значению, например наступление какого-либо события, также относятся к количественным: их легко выразить числом по правилу «ложь = 0, истина = 1».

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

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

  • статистическая обработка субъективных оценок;
  • косвенная оценка по количественным характеристикам.

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

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

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

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

Протестируем качественные характеристики

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

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

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

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

QII → QI → MII → M1.         

Рассмотрим этот алгоритм более подробно в виде последовательности шагов.

Шаг 1. Выявляем неопределенные характеристики

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

  1. Выделение на основе опыта. На практике это делают в первую очередь, и подход замечательно работает в большинстве случаев. Действительно, даже небольшой опыт в тестировании позволяет довольно уверенно выделять качественные характеристики.
  2. Выделение на основе ключевых слов. Качественные характеристики описываются характерными словами, например «удобство», «информативность», «доступность», «логичность», «корректность». Список подобных ключевых слов можно оформить в виде справочника, который можно использовать при автоматизации тестов. Замечу, что первый подход неявно или интуитивно основан на втором.
  3. Выполнение специальных тестов. Они применяются либо к формулировкам требований, либо непосредственно к описанию характеристик. Простейший тест этого типа основан на поиске в специальных справочниках метрик, в которых каждой характеристике сопоставляется одна или несколько метрик. Если нужной характеристики в словаре нет, то она считается качественной. Можно предложить и более сложные тесты, например, основанные на использовании специальных классификаторов, в том числе с применением искусственного интеллекта. 

В результате мы должны получить список качественных характеристик, которые нам нужно протестировать, с указанием их принадлежности к одному из классов QI или QII.

Шаг 2. Снижаем неопределенность

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

Снизить неопределенность помогают следующие подходы:

  1. Уточнение требований к качественным характеристикам системы с помощью заказчиков системы и ее пользователей.
  2. Более тщательный анализ предметной области, составление подробной ее модели и словаря предметной области.
  3. Изучение внешних источников, таких как аналогичные системы, стандарты и специальная литература для поиска более точных определений качественных характеристик.
  4. Анализ проектной документации, составление детальной программной модели приложения, анализ алгоритмов и структур данных.
  5. Анализ исходного кода системы.

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

В результате все качественные характеристики класса QII должны быть представлены в виде более простых и конкретных характеристик класса QI.

Шаг 3. Заменяем качественные характеристики на количественные

На этом этапе каждая характеристика класса QI преобразуется в набор характеристики класса MII, а затем каждая характеристика класса MII преобразуется в набор характеристик класса MI. Проще говоря, каждая качественная характеристика сводится к набору количественных. Например, характеристику «информативность поля ввода» в конечном счете можно свести к набору хорошо проверяемых количественных характеристик, в число которых входят:

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

В результате все качественные характеристики заменяются набором количественных характеристик классов MI или MII.

Шаг 4. Разрабатываем тесты для проверки количественных характеристик

На последнем шаге разрабатываются тесты для всех характеристик классов MI и MII, определенных на предыдущем шаге.

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

  1. Выбираем подходящую метрику для измерения проверяемой величины и единицу ее измерения.
  2. Выбираем метод измерения нужной величины.
  3. Определяем критерий успешности/приемлемости результата измерений.
  4. Разрабатываем и документируем спецификацию теста.

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

  1. Выбираем метрику — длину, измеряемую в миллиметрах.
  2. Метод измерения — вручную с помощью линейки с миллиметровыми делениями.
  3. Критерий приемлемости определяем из спецификации требований заказчика к длине карандаша или выбираем его из документов типа ГОСТов или технических условий.
  4. В соответствии с принятыми правилами документируем тест.

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

Подведем итоги

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

  • Относительно просто разрабатывать и выполнять тесты.
  • Получать объективные оценки результатов тестов, поскольку они основаны на математически точных операциях сравнения чисел. Это важное преимущество, потому что на практике качественные характеристики часто оцениваются субъективно.

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

Надеюсь, теперь вы знаете один из подходов к этому. Удачи!

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники