что такое тестовая модель в тестировании
Test Maturity Model: как тестировщику оценить проект и спланировать процессы
Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.
Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.
Первым делом вам стоит понять, на каком вы проекте
Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:
Что такое Maturity Model
Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности.
Если коротко и просто, это набор моделей, которые показывают, насколько хорошо налажены процессы в организации по определенным критериям. Имея подобную оценку, можно трезво оценить, стоит ли давать тот или иной заказ тому или иному подрядчику.
Собственно, с этого и началась разработка Maturity Model. В 80-х годах министерство обороны США осознало, что не может точно оценить качество работы подрядчиков по разработке ПО. А так как это государственная структура еще и такого уровня, это неприемлемо. Деньги-то государственные, дедлайны четко очерчены, да и надежное ПО для вооружения позволит всем спать спокойнее. Исходя из этого, министерство поручило Software Engineering Institute заняться созданием подобной системы оценки и спустя год был создан первый опросник, а спустя 4 года была создана первая версия модели.
Уровни Maturity Model
Это 5 уровней, в рамках которых и оценивается работа/надежность/стабильность предприятия.
Где в Maturity Model тестирование
Для тестировщиков есть своя особая ММ, ее называют ТММi. Она также содержит 5 уровней, на которых я хотел бы остановиться детальнее и рассмотреть, что характерно для каждого из них.
Первый уровень — «Начальный»
На первом уровне тестирование происходит не структурировано и хаотично. Отсутствует стабильная среда для поддержки процессов тестирования. Команда не уделяет внимание планированию и стандартам.
Главная цель — доставить продукт в срок без критических проблем, потому тестирование тут используется, лишь чтобы показать, что приложение работает без серьезных сбоев. Зачастую успех подобных проектов зависит исключительно от героизма и навыков отдельных людей, а не налаженных процессов.
На втором уровне тестирование становится управляемым процессом. Дисциплина и достигнутый прогресс позволяет обеспечить сохранение этих практик во время стресса. Тестирование все еще расценивается активностью, которая следует за разработкой. Разрабатываются и внедряются тест-планы, с помощью которых четко определяют, какое тестирование необходимо провести, когда и кем.
Главная цель — убедиться, что продукт соответствует заданным требованиям.
На третьем уровне тестирование больше не расценивается как активность, идущая вслед за программированием. Тестирование полноценно интегрировано в проект. Планирование тестирования выполняется на более ранних этапах и закрепляется в мастер-плане. Внедряется нефункциональное тестирование (например, usability).
На четвертом уровне тестирование четко определенный, прочно устоявшийся и измеряемый процесс. Тестирование воспринимается как оценка и состоит из всех операций жизненного цикла разработки ПО. Внедряется практика измерения качества тестирования. Эти измерения используются для прогнозирования производительности и стоимости тестирования.
На пятом уровне все подходы и процессы хорошо налажены. Команда не останавливается на этом этапе, а продолжает систематически улучшать процессы, постоянно пытаясь снизить время цикла тестирования и time-to-market без снижения качества проекта. Тестирование сфокусировано на превентивности. Добавляется автоматизация для более эффективного использования ресурсов.
Каким образом помогает знание этой структуры
Кейс № 1. Недобросовестное тестирование
Однажды я попал на небольшой проект, где тестирование проводилось заказчиком, его друзьями или котейкой. Оценив ситуацию и взглянув на модель, мы можем понять, что мы находимся на уровне № 1 и нам стоит ориентироваться на уровень № 2 во время планирования активностей. После приведения в порядок Jira, где было огромное количество багов (из которых большинство — дубликаты или не воспроизводимы), я занялся составлением тестовой документации в виде чек-листов и налаживанием основных процессов тестирования. Таких как регрессионное тестирование и санити проверки во время крупных изменений.
Кейс № 2. Без тестирования
На мой взгляд, проекты такого типа могут быть в трех случаях:
Кейс № 3. Тестирование было
По правде говоря, наиболее редкий кейс: человек в силу тех или иных событий, решил сменить команду/отдел/работу и передает вам свои наработки. В такой ситуации у вас уже есть налаженная система взаимодействия с разработчиками, определенная база тестовой документации. Дальнейшими путями развития может быть как улучшение устоявшегося процесса, так и продвижение к третьему уровню — внедрять тестирование на более ранние этапы или добавлять нефункциональное тестирование.
Кейс № 4. Три в одном
Когда я пришел на свой проект в Provectus, я столкнулся с ситуацией, в которой было всего по чуть-чуть от трех кейсов, описанных выше. Как и в кейсе № 1, первым делом необходимо было привести в порядок Jira. Как во втором случае, было решено все делать сразу качественно, чтобы сразу руководствоваться вторым уровнем. Потому я сразу начал разрабатывать тестовую документацию и внедрять тест-менеджмент инструментарий. Также постарался выжать максимум из артефактов прошлых итераций, как было в третьем случае.
Спустя совсем короткий срок, я могу смело сказать, что мы уже целенаправленно идём на третий уровень — даже подключили тестирование на этапе бизнес требований 🙂
Выводы
На моем опыте, большинство украинских проектов, а также проектов, которые не рассчитаны на длительный срок, успешно удается довести до «Go live» на 3 уровне. Но если у вас долгосрочный проект, возможности улучшать его безграничны и можно смело руководствоваться наработками высших уровней.
В заключение, я хотел бы сказать, что целью этой статьи было показать не столько то, как работать с самой классической ММ или ТММ, а то, что с ее помощью можно четко понять, на каком этапе находится проект, на который ты попал, и какие движения предпринимать, а какие не стоит. Более того, взяв за основу ее принципы, можно создать собственную модель, которую можно применять не только в разработке, но и в различных сферах жизни. И что самое главное — это проверено и работает 🙂
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Онлайн-тренинги
Что пишут в блогах (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 достаточно невысок.
Как и любой другой подход к тестированию, она должна применяться с умом: лучше всего прикинуть время, которое сэкономит использование модели, и соотнести его со временем, необходимым для ее составления и поддержания. Модель обязательно нужно актуализировать и обновлять, иначе ее использование теряет смысл.
Test policy — управление тестовой моделью
Тестовая модель — это логическая структура, описывающая функциональность системы и/или поведения пользователя, по которой генерируются тест-кейсы. Построение тестовой модели начинается с построения структуры, а затем утвержденная структура наполняется тест-кейсами.
Модели обычно строятся на основе требований и/или ожидаемого поведения системы. Построение тестовой модели и управление ею подходят для больших систем со сложной бизнес-логикой и сложно применимы к проектам, работающим по гибким методологиям, т. к. затраты на поддержание процесса управления тестовой моделью и обеспечения качества будут слишком высокими.
Под управлением тестовой моделью понимается процесс, контролирующий покрытие тестовой модели, качество сценариев, описывающих тестовую модель, и ее актуализацию.
Управление тестовой моделью — непрерывный процесс на протяжении всего жизненного цикла продукта.
Покрытие тестовой модели
Для контроля покрытия всех требований можно использовать матрицы трассировки, которые определяют покрытие требований тестовыми сценариями (см. пример).
Перед тем как тест-кейсы будут описаны, структура тестовой модели должна быть утверждена с заказчиком.
Качество сценариев
Для управления качеством сценариев необходимо контролировать не только уровень описания тест-кейсов, но и их качество.
До начала описания тест-кейсов необходимо определить требования для каждого уровня описания и критерии качества описания тест-кейсов.
Возможные уровни описания тест-кейсов:
На четвертом уровне согласование с заказчиком может быть заменено на согласование с бизнес-аналитиком.
Критерии качества описания тест-кейсов могут быть следующими:
Тестирование — это процесс проверки соответствия продукта предъявляемым к нему требованиям. Поэтому в части общего описания тест-кейса (в тест-трекинговых системах обычно употребляется термин «Summary») необходимо ссылаться на конкретное требование в связке с фрагментами текста требований. Таким образом, для всех участников проекта будет понятно, на основании чего написан данный тест-кейс.
Как сэкономить время на выполнении тест-кейсов?
Установите правила форматирования для всех тест-кейсов. Так, тест-кейс будет удобен для понимания и чтения для любого участника проекта. Например, на проекте можно ввести следующие правила:
Тест-кейсы должны быть однозначными, т. е. должны быть составлены и сформулированы таким образом, чтобы они не допускали двусмысленного толкования, а четко понимались всеми участниками.
Если написание тест-кейсов занимает продолжительное время, то может возникнуть ситуация, когда специалист перестает видеть свои ошибки. Для этого необходим взгляд со стороны – здесь поможет проведение кроссс-ревью. Этот этап рекомендуется проводить в тех случаях, когда разработка тестовой модели растянута в сроках и длительна по времени. Например, когда разработка тестовых сценариев занимает более 1 месяца.
Процесс контроля качества сценариев можно вести с помощью test model control – специально заготовленного шаблона.
Актуализация тестовой модели
Необходимо регулярно проводить актуализацию тестовой модели и самих тест-кейсов на соответствие требованиям, а также пересматривать приоритеты тест-кейсов.
Для актуализации можно вести «Матрицу требований» (Requirement Traceability Matrix): после каждого изменения в определенном требовании из тест-трекинговой системы делается выборка всех связанных с этим требованием тестовых сценариев, и проводится их обновление.
Тестирование на основе моделей
Картинка с 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 достаточно невысок.
Как и любой другой подход к тестированию, она должна применяться с умом: лучше всего прикинуть время, которое сэкономит использование модели, и соотнести его со временем, необходимым для ее составления и поддержания. Модель обязательно нужно актуализировать и обновлять, иначе ее использование теряет смысл.
Конечно же, эта статья дает лишь обзорное представление о том, что такое тестовые модели и зачем они нужны. Если тема заинтересовала вас и вы чувствуете, что хотите узнать больше и, возможно, даже применить знания на практике, рекомендую обратить внимание на источники ниже.