Тестирование на основе моделей11.06.2020 17:17

Картинка с unsplash.com

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

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

Пара слов обо мне: меня зовут Настя Заречнева, и я обеспечиваю качество рекламы ВКонтакте. Раньше я работала в аутсорсе на самых разных проектах, выполняя роли от тест-аналитика до руководителя команды QA, поэтому не понаслышке знаю, что начинать тестирование заранее — классный способ сэкономить себе время и нервы в будущем.

Содержание

Предисловие

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

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

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

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

Тут нам и приходят на помощь тестовые модели. Это не rocket science и не что-то ультрановое: аналогией с использованием тестовых моделей в разработке ПО можно считать использование схем при проектировании электроприбора или электроустановки. Даже если сама установка еще не готова, мы уже можем увидеть части системы, их связи и слабые места, — например, на изображении ниже можно заметить будущее короткое замыкание.

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

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

Что такое тестовые модели

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

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

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

Какое отношение к математике имеют тестовые модели

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

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

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

Плюсы и минусы тестовых моделей

Как и любой подход, MBT имеет преимущества и недостатки. Давайте рассмотрим их по порядку.

Плюсы MBT:

Использование тестовых моделей развивает аналитическое мышление за счет постоянного анализа (сюрприз!) тестируемой системы. Лучший способ развить этот тип мышления — применять его для решения задач, например, для создания абстрактной схемы продукта или его компонента.
Моделирование улучшает понимание системы как у того, кто модель создает, так и у команды, которая ревьюит и использует ее. Приятный бонус: спустя некоторое время благодаря модели можно научиться предугадывать поведение системы в тех или иных обстоятельствах.
Тестовую модель поддерживать легче, чем много тест-кейсов (за счет абстрактности и того, что кейсов много, а модель одна).
MBT позволяет взглянуть на систему (или ее часть) в целом и увидеть неочевидные зависимости.
Создание и поддержание тестовой модели способствует синхронизации понимания работы системы внутри команды. Это очень полезно для избегания неоднозначных ситуаций и решения спорных вопросов «на берегу» до начала разработки.
Благодаря математической подоплеке наличие модели позволяет автоматизировать нахождение оптимального пути, пути с задействованием всех состояний и т.д. Кроме того, тестовую модель можно использовать как основу для проектирования автотестов.
Несомненно, модель делает процесс адаптации новичка в проект более эффективным. «Лучше один раз увидеть, чем сто раз услышать» тут как раз работает. Кроме того, у нового члена команды могут возникнуть вопросы, которые не пришли в голову команде, или другие участники процесса разработки могут вспомнить что-то важное, презентуя модель новичку.
Тестирование на основе моделей прекрасно подходит для долгосрочных проектов, где большое число тест-кейсов затруднит понимание принципов работы системы, а простая и наглядная схема, наоборот, упростит его.

Минусы MBT:

Если в модели есть ошибка, это может привести к фундаментальному недопониманию внутри команды. Именно поэтому важен следующий пункт.
Желательно, чтобы в моделировании (или ревью модели) участвовала вся команда. Во-первых, это позволяет исключить недопонимания, во-вторых, активирует силу коллективного разума.
Как и в случае с тестовой документацией, надо не лениться, поддерживать и регулярно обновлять модель. Если на это нет времени и/или недостаточно знаний, стоит поставить под сомнение целесообразность использования тестовых моделей в проекте.
Иногда создание модели занимает больше времени, чем написание простого чек-листа. Особенно это актуально для больших и многокомпонентных систем: если модель начинают создавать после того, как внутри системы уже существует куча не до конца понятных зависимостей, это может стать довольно долгим (но, скорее всего, того стоящим!) процессом.
Использование тестовых моделей требует определенных навыков абстрактного мышления вкупе с внимательностью к мелочам. Скорее всего, если вы успешно работаете в тестировании, у вас есть все эти навыки, но нужно быть осторожными и никогда не отключать критическое мышление даже по отношению к собственным трудам.

Как начать использовать тестовые модели

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

Определить наиболее удобный для восприятия (собой, командой или бизнес-оунерами) вид схемы (таблица, диаграмма, граф…). Важно, чтобы те, для кого делается модель, легко «читали» ее — это наша основная задача;
Декомпозировать систему, которую собираемся описать, на модули (руководствуясь приоритетами, функциональностью, логикой или другими критериями). Скорее всего, ваша система многокомпонентна. Не стоит пытаться описать все и сразу: начните с малого.
Определить для отдельно взятого модуля возможные состояния системы, действия пользователя, переходы между состояниями, а также начальные и конечные точки взаимодействия (т.н. точку входа и точку выхода).
Схематично нарисовать «золотой путь», то есть идеальный вариант взаимодействия пользователя и системы.
Расширить этот путь для модуля так, чтобы помимо идеальных случаев модель включала и иные варианты: подумайте, что может пойти не так на каждом шаге.
Не забудьте о влиянии каждого состояния и перехода на другие части системы. Это особенно актуально, если вы создаете не первую модель для тестируемого продукта.
Решить, будете ли вы объединять модули в одну схему или хранить их по отдельности.
Поделиться полученной моделью с командой. Можно презентовать, отдать на ревью или пригласить коллег на ограниченную по времени сессию мозгового штурма, чтобы дополнить то, что вы могли забыть или упустить.
Поддерживать! Не забывать актуализировать и обновлять модель, — особенно когда добавляете новые компоненты, связи или даже новые модели.

Пример тестовой модели

Давайте немного отойдем от теории и рассмотрим на практике пример из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design», а именно диаграмму переходов состояний как иллюстрацию рабочей тестовой модели.
Тестировать будем покупку билета — например, на концерт.

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