что такое тестовая модель
Что такое тестовая модель
Что пишут в блогах
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Картинка с unsplash.com
Обеспечение качества, оно же Quality Assurance, оно же QA, включает в себя много разных активностей, позволяющих делать продукт лучше. Незаменимая и широко известная часть этого процесса — тестирование.
Принято считать, что тестирование следует после разработки ПО. В каком-то смысле это правда: нельзя проверить работающий продукт, пока он не готов. Однако в эпоху гибких методологий только ленивый не слышал про так называемый принцип «смещения влево», или shift left — включение специалиста по тестированию в процесс разработки продукта как можно раньше.
Как это возможно?
Пара слов обо мне: меня зовут Настя Заречнева, и я обеспечиваю качество рекламы ВКонтакте. Раньше я работала в аутсорсе на самых разных проектах, выполняя роли от тест-аналитика до руководителя команды QA, поэтому не понаслышке знаю, что начинать тестирование заранее — классный способ сэкономить себе время и нервы в будущем.
Содержание
Предисловие
Дело в том, что наиболее серьезные баги, как известно, можно найти на этапе проектирования продукта. Особенно актуально это для разработки новой фичи, которая так или иначе затрагивает уже работающие компоненты. Как правило, такие взаимосвязи продумывает архитектор (или человек, выполняющий эту роль в команде), но даже работу такого опытного специалиста необходимо тестировать — как минимум из-за человеческого фактора и возможности ошибиться, как максимум из-за силы коллективного разума.
Как тестировщик может помочь в этом случае? В ситуации, когда есть макеты или спецификация, все становится проще: можно использовать готовый нарисованный интерфейс для составления тестовой документации и продумывания неочевидных, но реальных кейсов.
Если же макеты еще не готовы, или есть только функциональные требования, или, что еще интереснее, задача затрагивает не столько интерфейс, сколько логику взаимодействия между компонентами тестируемой системы, довольно легко упустить важные зависимости, касающиеся разрабатываемого решения.
Есть 2 варианта: либо учиться читать код (что не панацея, ведь даже разработчики зачастую разбираются лишь в той части системы, с которой непосредственно работают), либо искать другой существующий способ тестировать функциональные аспекты продукта.
Тут нам и приходят на помощь тестовые модели. Это не rocket science и не что-то ультрановое: аналогией с использованием тестовых моделей в разработке ПО можно считать использование схем при проектировании электроприбора или электроустановки. Даже если сама установка еще не готова, мы уже можем увидеть части системы, их связи и слабые места, — например, на изображении ниже можно заметить будущее короткое замыкание.
По сути, тестовые модели — нечто похожее: это абстрактные наглядные схемы, описывающие состояние, взаимодействия и связи системных компонентов. Единственное, что компоненты у нас чуть менее материальные, чем в примере с электротехникой, однако это не избавляет нас от вероятности ошибки, а, возможно, даже несколько ее увеличивает.
Тестирование на основе моделей (Model-Based Testing, далее MBT) — одна из техник тестирования черного ящика. В непрерывной разработке (и, как правило, частых поставках) большого продукта ошибка может стоить дорого, и именно потому, что MBT — один из проверенных и эффективных способов предотвратить ее как можно раньше, мне захотелось собрать и представить вам информацию о нем.
Что такое тестовые модели
Как мы успели разобраться, тестовые модели — это схема, наглядное описание тестируемой системы. Тестовыми моделями могут служить схемы, таблицы, диаграммы переходов состояний и в некоторых случаях даже интеллект-карты. В идеале тестовые модели должны создаваться на этапе проектирования системы (или ее отдельного компонента) и понятно демонстрировать влияние одной части ПО на другую.
Аналогично другим моделям, они должны быть в меру точны, адекватны (соответствовать реальности), универсальны (могут быть использованы неоднократно и для разных задач) и целесообразно экономичны. Последнее очень важно: не стоит применять MBT ради галочки: важно понимать цель и ожидаемый результат такого подхода. Если создание и поддержание модели занимает больше времени, чем нахождение и исправление проблем без нее, а сам продукт не планируется поддерживать в долгосрочной перспективе, лучше сконцентрироваться на более доступных методах обеспечения качества.
Основные особенности тестовых моделей в том, что их можно начинать собирать еще до фактического старта разработки, и в том, что их можно обновлять и переиспользовать при изменении системы. Таким образом, тестовая модель дает более ясное представление о системе всем участникам разработки и упрощает поддержку будущей тестовой документации, — но обо всем по порядку.
Какое отношение к математике имеют тестовые модели
Как и другие модели — достаточно близкое. В математике довольно много абстракций, поэтому без моделирования никак — вспомнить хотя бы конечные автоматы — детерминированные и недетерминированные. В классическом случае они используются для математического моделирования и описания формальных грамматик, однако если заменить состояния автомата на состояния системы, а переходы — на возможные действия в каждом из состояний, то из вот такого академического примера НКА:
мы получим грубую и пока не исчерпывающую, но уже достаточно понятную тестовую модель, — например, с вариантами пополнения баланса в рекламном кабинете ВКонтакте.
Плюсы и минусы тестовых моделей
Как и любой подход, MBT имеет преимущества и недостатки. Давайте рассмотрим их по порядку.
Как начать использовать тестовые модели
Пример тестовой модели
Давайте немного отойдем от теории и рассмотрим на практике пример из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design», а именно диаграмму переходов состояний как иллюстрацию рабочей тестовой модели.
Тестировать будем покупку билета — например, на концерт.
Для начала, мы инициируем транзакцию: после того, как выбрали билет, мы ввели информацию о себе и перешли на страницу оплаты, в то время как система автоматически инициировала таймер оплаты. Так как нас интересует процесс оплаты и использования билета, можно сделать именно этот шаг входной точкой тестовой модели.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Что мы будем делать после этого? В идеальном случае оплатим билет, а затем распечатаем и предъявим его на входе. Отразим эти действия в нашей модели.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
После распечатывания и предъявления на входе у билета есть точка невозврата — мы использовали его на прошедшем мероприятии. Дальше билет недействителен и не может быть как-то использован, — значит, примерно здесь наш «золотой путь» и заканчивается: обозначим конец на нашей диаграмме.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Как тестировщики, мы прекрасно понимаем, что все не так просто и на каждом этапе что-то может пойти не по плану. Что будет, если пользователь отменил оплату? А если просто забыл про нее, и таймер оплаты истек, тем самым завершив сессию? Это будут 2 разных типа отмены. Добавим указанные ситуации в модель.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Еще мы помним, что покупатель может захотеть вернуть билет в момент после оплаты или после распечатывания билета, но до того, как начался концерт. Эти ситуации подходят под уже существующее состояние «Отмена по инициативе клиента», — осталось лишь добавить соответствующие переходы.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Та-дааааам! Наша небольшая, но гордая работоспособная модель готова. Двигаясь по вершинам-состояниям путем ребер-переходов, мы составляем сценарии, которые будем проверять при тестировании:
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Мы получили 5 рабочих кейсов и бонусом наглядное представление процесса. Совсем не трудно, правда? 🙂
Полезности для самостоятельного изучения
Тестирование на основе моделей — большая и интересная область, которая позволяет применять аналитические навыки для изучения системы как на уровне пользователя, так и на более глубоких слоях — например, для визуализации связей между микросервисами или таблицами в базе данных. Прелесть ее в том, что она позволяет распространять знания о системе внутри команды, достигать лучшего понимания разрабатываемого продукта, а еще порог вхождения для использования MBT достаточно невысок.
Как и любой другой подход к тестированию, она должна применяться с умом: лучше всего прикинуть время, которое сэкономит использование модели, и соотнести его со временем, необходимым для ее составления и поддержания. Модель обязательно нужно актуализировать и обновлять, иначе ее использование теряет смысл.
Тестирование на основе моделей
Картинка с unsplash.com
Обеспечение качества, оно же Quality Assurance, оно же QA, включает в себя много разных активностей, позволяющих делать продукт лучше. Незаменимая и широко известная часть этого процесса — тестирование.
Принято считать, что тестирование следует после разработки ПО. В каком-то смысле это правда: нельзя проверить работающий продукт, пока он не готов. Однако в эпоху гибких методологий только ленивый не слышал про так называемый принцип «смещения влево», или shift left — включение специалиста по тестированию в процесс разработки продукта как можно раньше.
Как это возможно?
Пара слов обо мне: меня зовут Настя Заречнева, и я обеспечиваю качество рекламы ВКонтакте. Раньше я работала в аутсорсе на самых разных проектах, выполняя роли от тест-аналитика до руководителя команды QA, поэтому не понаслышке знаю, что начинать тестирование заранее — классный способ сэкономить себе время и нервы в будущем.
Содержание
Предисловие
Дело в том, что наиболее серьезные баги, как известно, можно найти на этапе проектирования продукта. Особенно актуально это для разработки новой фичи, которая так или иначе затрагивает уже работающие компоненты. Как правило, такие взаимосвязи продумывает архитектор (или человек, выполняющий эту роль в команде), но даже работу такого опытного специалиста необходимо тестировать — как минимум из-за человеческого фактора и возможности ошибиться, как максимум из-за силы коллективного разума.
Как тестировщик может помочь в этом случае? В ситуации, когда есть макеты или спецификация, все становится проще: можно использовать готовый нарисованный интерфейс для составления тестовой документации и продумывания неочевидных, но реальных кейсов.
Если же макеты еще не готовы, или есть только функциональные требования, или, что еще интереснее, задача затрагивает не столько интерфейс, сколько логику взаимодействия между компонентами тестируемой системы, довольно легко упустить важные зависимости, касающиеся разрабатываемого решения.
Есть 2 варианта: либо учиться читать код (что не панацея, ведь даже разработчики зачастую разбираются лишь в той части системы, с которой непосредственно работают), либо искать другой существующий способ тестировать функциональные аспекты продукта.
Тут нам и приходят на помощь тестовые модели. Это не rocket science и не что-то ультрановое: аналогией с использованием тестовых моделей в разработке ПО можно считать использование схем при проектировании электроприбора или электроустановки. Даже если сама установка еще не готова, мы уже можем увидеть части системы, их связи и слабые места, — например, на изображении ниже можно заметить будущее короткое замыкание.
По сути, тестовые модели — нечто похожее: это абстрактные наглядные схемы, описывающие состояние, взаимодействия и связи системных компонентов. Единственное, что компоненты у нас чуть менее материальные, чем в примере с электротехникой, однако это не избавляет нас от вероятности ошибки, а, возможно, даже несколько ее увеличивает.
Тестирование на основе моделей (Model-Based Testing, далее MBT) — одна из техник тестирования черного ящика. В непрерывной разработке (и, как правило, частых поставках) большого продукта ошибка может стоить дорого, и именно потому, что MBT — один из проверенных и эффективных способов предотвратить ее как можно раньше, мне захотелось собрать и представить вам информацию о нем.
Что такое тестовые модели
Как мы успели разобраться, тестовые модели — это схема, наглядное описание тестируемой системы. Тестовыми моделями могут служить схемы, таблицы, диаграммы переходов состояний и в некоторых случаях даже интеллект-карты. В идеале тестовые модели должны создаваться на этапе проектирования системы (или ее отдельного компонента) и понятно демонстрировать влияние одной части ПО на другую.
Аналогично другим моделям, они должны быть в меру точны, адекватны (соответствовать реальности), универсальны (могут быть использованы неоднократно и для разных задач) и целесообразно экономичны. Последнее очень важно: не стоит применять MBT ради галочки: важно понимать цель и ожидаемый результат такого подхода. Если создание и поддержание модели занимает больше времени, чем нахождение и исправление проблем без нее, а сам продукт не планируется поддерживать в долгосрочной перспективе, лучше сконцентрироваться на более доступных методах обеспечения качества.
Основные особенности тестовых моделей в том, что их можно начинать собирать еще до фактического старта разработки, и в том, что их можно обновлять и переиспользовать при изменении системы. Таким образом, тестовая модель дает более ясное представление о системе всем участникам разработки и упрощает поддержку будущей тестовой документации, — но обо всем по порядку.
Какое отношение к математике имеют тестовые модели
Как и другие модели — достаточно близкое. В математике довольно много абстракций, поэтому без моделирования никак — вспомнить хотя бы конечные автоматы — детерминированные и недетерминированные. В классическом случае они используются для математического моделирования и описания формальных грамматик, однако если заменить состояния автомата на состояния системы, а переходы — на возможные действия в каждом из состояний, то из вот такого академического примера НКА:
мы получим грубую и пока не исчерпывающую, но уже достаточно понятную тестовую модель, — например, с вариантами пополнения баланса в рекламном кабинете ВКонтакте.
Кроме того, в проектировании тестов активно используются математические дисциплины: теория графов, комбинаторика, различные минимальные и максимальные значения. Если немного вспомнить курс матанализа в университете, можно понять, что тестовые модели — лишь одно из применений всего того, что вы уже умеете.
Плюсы и минусы тестовых моделей
Как и любой подход, MBT имеет преимущества и недостатки. Давайте рассмотрим их по порядку.
Как начать использовать тестовые модели
Мы поняли, что такое тестовые модели, откуда они взялись и что в них хорошего. Мы даже готовы к потенциальным челленджам тестирования на основе моделей. Осталось лишь сделать первый шаг. Ниже представлю один из допустимых вариантов, как это сделать.
Пример тестовой модели
Давайте немного отойдем от теории и рассмотрим на практике пример из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design», а именно диаграмму переходов состояний как иллюстрацию рабочей тестовой модели.
Тестировать будем покупку билета — например, на концерт.
Для начала, мы инициируем транзакцию: после того, как выбрали билет, мы ввели информацию о себе и перешли на страницу оплаты, в то время как система автоматически инициировала таймер оплаты. Так как нас интересует процесс оплаты и использования билета, можно сделать именно этот шаг входной точкой тестовой модели.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Что мы будем делать после этого? В идеальном случае оплатим билет, а затем распечатаем и предъявим его на входе. Отразим эти действия в нашей модели.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
После распечатывания и предъявления на входе у билета есть точка невозврата — мы использовали его на прошедшем мероприятии. Дальше билет недействителен и не может быть как-то использован, — значит, примерно здесь наш «золотой путь» и заканчивается: обозначим конец на нашей диаграмме.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Как тестировщики, мы прекрасно понимаем, что все не так просто и на каждом этапе что-то может пойти не по плану. Что будет, если пользователь отменил оплату? А если просто забыл про нее, и таймер оплаты истек, тем самым завершив сессию? Это будут 2 разных типа отмены. Добавим указанные ситуации в модель.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Еще мы помним, что покупатель может захотеть вернуть билет в момент после оплаты или после распечатывания билета, но до того, как начался концерт. Эти ситуации подходят под уже существующее состояние «Отмена по инициативе клиента», — осталось лишь добавить соответствующие переходы.
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Та-дааааам! Наша небольшая, но гордая работоспособная модель готова. Двигаясь по вершинам-состояниям путем ребер-переходов, мы составляем сценарии, которые будем проверять при тестировании:
Иллюстрация из книги Ли Коупленда «A Practitioner’s Guide to Software Test Design»
Мы получили 5 рабочих кейсов и бонусом наглядное представление процесса. Совсем не трудно, правда? 🙂
Полезности для самостоятельного изучения
Тестирование на основе моделей — большая и интересная область, которая позволяет применять аналитические навыки для изучения системы как на уровне пользователя, так и на более глубоких слоях — например, для визуализации связей между микросервисами или таблицами в базе данных. Прелесть ее в том, что она позволяет распространять знания о системе внутри команды, достигать лучшего понимания разрабатываемого продукта, а еще порог вхождения для использования MBT достаточно невысок.
Как и любой другой подход к тестированию, она должна применяться с умом: лучше всего прикинуть время, которое сэкономит использование модели, и соотнести его со временем, необходимым для ее составления и поддержания. Модель обязательно нужно актуализировать и обновлять, иначе ее использование теряет смысл.
Конечно же, эта статья дает лишь обзорное представление о том, что такое тестовые модели и зачем они нужны. Если тема заинтересовала вас и вы чувствуете, что хотите узнать больше и, возможно, даже применить знания на практике, рекомендую обратить внимание на источники ниже.
Test policy — управление тестовой моделью
Тестовая модель — это логическая структура, описывающая функциональность системы и/или поведения пользователя, по которой генерируются тест-кейсы. Построение тестовой модели начинается с построения структуры, а затем утвержденная структура наполняется тест-кейсами.
Модели обычно строятся на основе требований и/или ожидаемого поведения системы. Построение тестовой модели и управление ею подходят для больших систем со сложной бизнес-логикой и сложно применимы к проектам, работающим по гибким методологиям, т. к. затраты на поддержание процесса управления тестовой моделью и обеспечения качества будут слишком высокими.
Под управлением тестовой моделью понимается процесс, контролирующий покрытие тестовой модели, качество сценариев, описывающих тестовую модель, и ее актуализацию.
Управление тестовой моделью — непрерывный процесс на протяжении всего жизненного цикла продукта.
Покрытие тестовой модели
Для контроля покрытия всех требований можно использовать матрицы трассировки, которые определяют покрытие требований тестовыми сценариями (см. пример).
Перед тем как тест-кейсы будут описаны, структура тестовой модели должна быть утверждена с заказчиком.
Качество сценариев
Для управления качеством сценариев необходимо контролировать не только уровень описания тест-кейсов, но и их качество.
До начала описания тест-кейсов необходимо определить требования для каждого уровня описания и критерии качества описания тест-кейсов.
Возможные уровни описания тест-кейсов:
На четвертом уровне согласование с заказчиком может быть заменено на согласование с бизнес-аналитиком.
Критерии качества описания тест-кейсов могут быть следующими:
Тестирование — это процесс проверки соответствия продукта предъявляемым к нему требованиям. Поэтому в части общего описания тест-кейса (в тест-трекинговых системах обычно употребляется термин «Summary») необходимо ссылаться на конкретное требование в связке с фрагментами текста требований. Таким образом, для всех участников проекта будет понятно, на основании чего написан данный тест-кейс.
Как сэкономить время на выполнении тест-кейсов?
Установите правила форматирования для всех тест-кейсов. Так, тест-кейс будет удобен для понимания и чтения для любого участника проекта. Например, на проекте можно ввести следующие правила:
Тест-кейсы должны быть однозначными, т. е. должны быть составлены и сформулированы таким образом, чтобы они не допускали двусмысленного толкования, а четко понимались всеми участниками.
Если написание тест-кейсов занимает продолжительное время, то может возникнуть ситуация, когда специалист перестает видеть свои ошибки. Для этого необходим взгляд со стороны – здесь поможет проведение кроссс-ревью. Этот этап рекомендуется проводить в тех случаях, когда разработка тестовой модели растянута в сроках и длительна по времени. Например, когда разработка тестовых сценариев занимает более 1 месяца.
Процесс контроля качества сценариев можно вести с помощью test model control – специально заготовленного шаблона.
Актуализация тестовой модели
Необходимо регулярно проводить актуализацию тестовой модели и самих тест-кейсов на соответствие требованиям, а также пересматривать приоритеты тест-кейсов.
Для актуализации можно вести «Матрицу требований» (Requirement Traceability Matrix): после каждого изменения в определенном требовании из тест-трекинговой системы делается выборка всех связанных с этим требованием тестовых сценариев, и проводится их обновление.