Тест-дизайн. Часть 3

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

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

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

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

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

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

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

Две из них мы рассмотрели. Это «Классы и границы эквивалентности» и «Комбинаторные схемы классов и границ».

Пример составленной модели "Состояний и переходов"
для тестирования калькулятора

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

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

Подведем итог. Правильно его подвести общими словами по всем трем статьям отвечая на ранее поставленные вопросы. Будем пробовать.

«Что делать ?» или «Какие тесты надо делать на следующем шаге?»

Для определения оптимального набора тестов (сугубо мое личное мнение) необходимо выполнить следующие действия:

1. Проанализировать существующие параметры на предмет наличия границ и разбить их на классы эквивалентности.
2. Если параметров очень много и разделения на классы эквивалентности самих параметров невозможно, то проводим дополнительный анализ на связанность параметров.
3. Если получаем достаточно большое количество малосвязанных параметров с малым количеством значений (2 или 3 – это идеальный вариант), то используя инструменты формирования комбинаторных схем, готовим тестовые наборы.
4. Если в предыдущем пункте не выполняется условие малости значений параметров, то все множества значений необходимо разбить на классы эквивалентности, но необходимо соблюсти ограничение, что на один параметр не менее двух классов эквивалентности значений.
5. Проанализировать список тестируемых операций и тестируемых состояний программного продукта.
6. На основе составленных списков тестируемых операций и состояний составляем модель «Состояний и переходов».
7. Получившиеся модели согласуем с руководством и только потом приступаем к следующим пунктам, если согласовать не получилось, выясняем причину и устраняем ее путем переделывания или до уточнения полученных моделей (без согласования выполнение последующих пунктов бессмысленно).
8. Суммируя все полученные данные, составляем  тестовый набор  (здесь стоит разделить понятия тестового сценария и тестового случая).
9. Проводим анализ получившегося тестового набора на предмет возможности группировки тестов. На данном этапе необходимо помнить, что группировать можно тесты на «положительный» результат, поскольку «отрицательные»  тесты позволяют нам локализовать  ошибку.
10. Полученный тестовый набор документируем в системе учета тестов.

Вот на этом я пожалуй и остановлюсь. Дальше что делать с тестами, которые уже задокументированы в TMS, я думаю, каждый понимает.