Skip to content

Instantly share code, notes, and snippets.

@jigi-33

jigi-33/MBT-approach_methodology_in_testing.md

Created June 12, 2020 10:23
Show Gist options
  • Save jigi-33/6c0210d28df8258b9feaa2819abaf897 to your computer and use it in GitHub Desktop.
Save jigi-33/6c0210d28df8258b9feaa2819abaf897 to your computer and use it in GitHub Desktop.
Download ZIP
Использование тестовых моделей в тест-дизайне. MBT-подход в тестировании
Raw
MBT-approach_methodology_in_testing.md

Использование тестовых моделей в тест-дизайне. MBT

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

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

Плюсы:

  • Использование тестовых моделей развивает аналитическое мышление за счет постоянного анализа (!) тестируемой системы. Лучший способ развить этот тип мышления - применять его для решения задач, например, для создания абстрактной схемы продукта или его компонента.

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

  • Тестовую модель поддерживать легче, чем много тест-кейсов (за счет абстрактности и того, что кейсов много, а модель одна).

  • MBT позволяет взглянуть на систему (или ее часть) в целом и увидеть неочевидные зависимости.

  • Создание и поддержание тестовой модели способствует синхронизации понимания работы системы внутри команды. Это очень полезно для избегания неоднозначных ситуаций и решения спорных вопросов "на берегу" до начала разработки.

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

  • Несомненно, модель делает процесс адаптации новичка в проект более эффективным. "Лучше один раз увидеть, чем сто раз услышать" тут как раз работает. Кроме того, у нового члена команды могут возникнуть вопросы, которые не пришли в голову команде, или другие участники процесса разработки могут вспомнить что-то важное, презентуя модель новичку.

  • Тестирование на основе моделей прекрасно подходит для долгосрочных проектов, где большое число тест-кейсов затруднит понимание принципов работы системы, а простая и наглядная схема, наоборот, упростит его.

Минусы:

  • Если в модели есть ошибка, это может привести к фундаментальному недопониманию внутри команды. Именно поэтому важен следующий пункт.

  • Желательно, чтобы в моделировании (или ревью модели) участвовала вся команда. Во-первых, это позволяет исключить недопонимания, во-вторых, активирует силу коллективного разума.

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

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

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

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

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

  1. Определить наиболее удобный для восприятия (собой, командой или бизнес-оунерами) вид схемы (таблица, диаграмма, граф... ). Важно, чтобы те, для кого делается модель, легко "читали" ее - это наша основная задача;

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

  3. Определить для отдельно взятого модуля возможные состояния системы, действия пользователя, переходы между состояниями, а также начальные и конечные точки взаимодействия (т.н. точку входа и точку выхода).

  4. Схематично нарисовать "золотой путь", то есть идеальный вариант взаимодействия пользователя и системы.

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

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

  7. Решить, будете ли вы объединять модули в одну схему или хранить их по отдельности.

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

  9. Поддерживать! Не забывать актуализировать и обновлять модель - особенно когда добавляете новые компоненты, связи или даже новые модели.

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

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

Тестировать будем покупку билета - например, на концерт.

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

Что мы будем делать после этого? В идеальном случае оплатим билет, а затем распечатаем и предъявим его на входе. Отразим эти действия в нашей модели.

После распечатывания и предъявления на входе у билета есть точка невозврата - мы использовали его на прошедшем мероприятии. Дальше билет недействителен и не может быть как-то использован, - значит, примерно здесь наш "золотой путь" и заканчивается: обозначим конец на нашей диаграмме.

Как тестировщики, мы прекрасно понимаем, что все не так просто и на каждом этапе что-то может пойти не по плану. Что будет, если пользователь отменил оплату? А если просто забыл про нее, и таймер оплаты истек, тем самым завершив сессию? Это будут 2 разных типа отмены.

Добавим указанные ситуации в модель.

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

Та-даааа! Наша небольшая, но гордая работоспособная модель готова. Двигаясь по вершинам-состояниям путем ребер-переходов, мы составляем сценарии, которые будем проверять при тестировании:

Мы получили 5 рабочих кейсов и бонусом наглядное представление процесса.

Дополнительные материалы

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

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment