Здравствуйте и добро пожаловать в статью серии "Лидерство в тестировании". В этой статье мы рассмотрим:
Что такое Тестовая Модель?
Использование Моделей для тестирования
Использование Моделей для Управления
Упражнение по быстрому созданию модели
Давайте погрузимся в эту тему.
Что такое Тестовая Модель?
Тестирование — это процесс, в ходе которого мы создаем ментальные модели окружающей среды, программы, человеческой природы и самих тестов. Каждая модель используется либо до тех пор, пока мы не признаем, что поведение является правильным, либо до тех пор, пока модель больше не будет достаточной для этой цели.
Борис Бейзер, Методы тестирования программного обеспечения, 1990
Разработка тестов (Test design) — это процесс, посредством которого мы выбираем из множества доступных вариантов те тесты, которые, по нашему мнению, будут наиболее ценными для нас и наших заинтересованных сторон. Тестовые модели помогают нам систематически отбирать тесты и являются основополагающими для тестирования.
Тестировщики используют модели следующим образом:
Мы выявляем и исследуем источники знаний для создания тестовых моделей.
Мы используем эти модели для проверки наших источников, совершенствуя наши источники и наши модели.
Мы используем эти модели для информирования о тестировании, а также для разработки.
Получив задание на тестирование, наша первая задача - определить Источники Знаний. Это могут быть:
Документация: спецификации, дизайны, требования, стандарты, руководящие принципы и так далее.
Люди: заинтересованные стороны, пользователи, аналитики, дизайнеры и разработчики и другие.
Опыт: ваши собственные знания и опыт работы с аналогичными (или непохожими системами), ваши предпочтения, предубеждения, догадки, предчувствия, убеждения.
Новая система: тестируемая система, если она существует, доступна.
Старая система: система, подлежащая замене, очевидно, является исходным кодом – в некоторых областях функциональности она может служить ориентиром для ожидаемого поведения.
Важно отметить, что все наши источники знаний подвержены ошибкам и неполноте, как и наши модели. Тестировщики используют опыт, навыки и суждения, чтобы просеять эти источники, сравнить, противопоставить и оспорить их, а также прийти к консенсусу.
Все модели неверны, некоторые полезны.
Джордж Бокс, экономист.
Тестовая модель может представлять собой контрольный список или набор критериев. Это также может быть диаграмма, полученная из проектного документа или анализа текста. Многие тестовые модели никогда не фиксируются на бумаге – они могут быть ментальными моделями, созданными специально для того, чтобы направлять тестировщика при изучении тестируемой системы.
Цель моделей состоит в том, чтобы упростить сложные ситуации, опуская детали, которые на данный момент не актуальны. Мы используем модели, чтобы упростить задачу – например, выбрать что-то для тестирования. Модель информирует наше мышление, и мы выбираем тесты, определяя вхождения в какой-либо ключевой аспект модели.
Мы могли бы выбрать ветви в блок-схеме или диаграмме потоков управления; переходы состояний в модели состояний; границы в модели входной (или выходной) области; сценарии, полученные из пользовательских историй, написанных на языке, специфичном для предметной области Gherkin.
Но будьте осторожны, иногда модели допускают небезопасные упущения – возможно, модель чрезмерно упрощает ситуацию, - и нам нужно обратить на это внимание.
Если у нас нет моделей непосредственно из наших источников, нам приходится их изобретать. Например, там, где требования представлены в виде повествовательного текста, нам нужно использовать язык требований для получения характеристик и логики их поведения. Это может быть сложно для разработчиков и тестировщиков, и часто это совместная работа, но мы должны проявлять настойчивость.
Использование Моделей для тестирования
Мы используем тестовые модели для:
Упрощения контекста теста. Несущественные или незначимые детали в модели игнорируются.
Того, чтобы сосредоточить внимание на одном аспекте поведения системы. Это могут быть критические или рискованные функции, технические аспекты, представляющие интерес пользовательские операции или аспекты построения или архитектуры системы.
Генерации набора уникальных (в контексте модели) тестов, которые разнообразны (по отношению к этой модели).
Того, чтобы оценивать тестирование, планировать его, контролировать и оценивать его полноту (покрытие).
С точки зрения тестировщика, модель помогает нам распознать аспекты системы, которые могли бы стать предметом тестирования.
Модели и покрытие
Покрытие — это термин, который мы используем для описания тщательности или полноты нашего тестирования в отношении нашей тестовой модели. Элемент покрытия — это то, что мы хотим использовать в наших тестах.
В идеале наша тестовая модель должна объективно определять элементы покрытия. Когда мы запланировали или выполнили тесты, охватывающие элементы, определенные нашей моделью, мы можем количественно оценить достигнутый покрытие и, как долю всех элементов в модели, выразить этот покрытие в процентах.
Можно использовать любую модель, позволяющую идентифицировать элементы покрытия.
Модели часто являются графическими с примерами, такими как блок-схемы, варианты использования, диаграммы последовательностей и так далее. Эти и многие другие модели содержат элементы (или большие двоичные объекты), соединенные линиями или стрелками. Обычно их называют ориентированными графами.
Представьте себе графическую модель, состоящую из больших объектов и стрелок. Можно было бы определить по крайней мере две цели покрытия:
Покрытие всех больших объектов (BLOB)
Покрытие всех направлений
И так далее
Таким образом, любая модель, представляющая собой ориентированный граф, может быть обработана таким же образом.
Формальная модель позволяет надежно идентифицировать элементы покрытия. Таким образом, количественный показатель покрытия может быть определен и использован в качестве поддающейся измерению цели.
Неформальные модели, как правило, представляют собой контрольные списки или критерии, используемые для мозгового штурма списка элементов покрытия, инициирования идей для тестирования или для тестирования в ходе ознакомительной сессии тестирования. Эти списки или критерии могут быть заранее определены или подготовлены как часть плана тестирования, или приняты в ходе ознакомительной тестовой сессии.
Неформальные модели отличаются от формальных моделей тем, что вывод элементов покрытия зависит от опыта, интуиции и воображения практикующего специалиста, использующего их, поэтому покрытие с использованием этих моделей никогда не может быть определен количественно. Мы никогда не сможем узнать, что означает полное покрытие в отношении этих моделей.
Тесты, полученные на основе неформальной модели, так же действительны, как и тесты, полученные на основе формальной модели, если они расширяют наши знания о поведении или возможностях нашей системы.
Модели упрощаются, поэтому используйте более одной
Хорошая модель обеспечивает средство понимания сложности и частично достигает этого за счет исключения деталей, которые не имеют отношения к делу. Ваша модель может использовать концепцию состояния, режимов сбоя или потоков, комбинаций входных данных, значений домена и так далее.
Одной модели никогда не бывает достаточно для полного тестирования системы. Все модели идут на компромисс, поэтому нам нужно несколько моделей. Эту концепцию обычно называют ‘разнообразными полумерами’. На практике это означает, что нам нужно множество частичных моделей для надлежащего тестирования системы.
Хотя обычно эти термины не описываются, этапы тестирования в проекте waterfall используют модели с разных точек зрения. Интеграция модулей, подсистем, тестирование на системном уровне и пользовательское тестирование - все они преследуют разные цели; в каждом используется своя модель и перспектива – вот откуда берется разнообразие.
Использование моделей для управления
Модели лежат в основе тестирования, а также управления тестированием. В этом есть четыре ключевых аспекта:
Вовлечение заинтересованных сторон
Обьем работ
Покрытие
Оценка и мониторинг прогресса
Вовлечение заинтересованных сторон
Когда мы планируем и покрываем тесты, а также объясняем заинтересованным сторонам прогресс и значение покрытия, мы должны использовать модели, которые понятны и значимы для целей заинтересованных сторон.
Если мы планируем пользовательский тест, мы, вероятно, примем поток бизнес-процессов в качестве нашей модели и шаблона для отслеживания путей реализации системных функций, которые важны для пользователя. Если мы тестируем интеграцию сервисных компонентов от имени технического архитектора, мы будем использовать архитектурную модель, схемы совместной работы, спецификации интерфейса и так далее в качестве основы нашего тестирования. Если мы тестируем функции, определенные пользователями, мы будем использовать пользовательские истории, которые были результатом более ранней совместной работы над требованиями.
Если заинтересованные стороны не понимают ваших моделей, они не будут понимать ваше тестирование, доверять ему или инвестировать в него. Они могут даже не доверять вам.
Управление объёмом работ
Первым действием в дисциплине системного мышления является определение границ системы. При тестировании первая модель, которую вы определите, поможет вам определить область тестирования. Приведенная ниже диаграмма представляет собой схему системной архитектуры – “системы систем” – в организации.
Каждая система (концентрические круги) находится в пределах прикладной области, такой как CRM, бухгалтерия или веб-сайт. Все системы и области применения находятся внутри "системы систем’. Конечно, в модели нет никаких подробностей, но ясно видно, как каждая система вписывается в общую архитектуру.
Мы могли бы легко определить область нашего тестирования, например, как ERP-системы.
На второй диаграмме ниже мы добавили еще несколько деталей к архитектуре системы и предложили три способа, которыми мы могли бы более конкретно определить область применения.
Системы, выделенные желтым цветом, являются так называемыми системами учета. Например, эти системы могут совместно использовать базу данных, и изменения в схеме базы данных могут негативно повлиять на любую из этих систем – и будут в области тестирования.
Системы, обведенные фиолетовой линией, могут иметь некоторую общую функциональность или инфраструктуру – возможно, все они используют общий набор веб-сервисов, одну и ту же систему обмена сообщениями или работают на одном сервере.
Пунктирная синяя линия обозначает путешествие пользователя, в котором используются системы, соединенные линией. Возможно, поведение пользователей изменилось, и мы сосредоточились на согласованности и точности потока данных между этими системами.
Модель может показать, что входит в сферу тестирования, но, что не менее важно, и то, что выходит за рамки.
Модель помогает определить объем тестирования, а также объяснить его заинтересованным сторонам в терминах, которые они понимают, ценят и (надеюсь) одобряют.
Когда мы используем модель для определения области применения, модель определяет территорию, а элементы в области применения определяют места, которые мы намерены исследовать и протестировать.
Управление покрытием
Измерение покрытия может помочь сделать тестирование более управляемым. Если у нас нет представления о покрытии, мы, возможно, не сможем ответить на такие вопросы, как "что было протестировано?", "что не было протестировано?", "мы уже закончили?", "сколько тестов осталось?” Это особенно неудобно для менеджера тестирования.
Покрытие, которого мы планируем достичь, является естественным следующим шагом после определения сферы покрытия.
Мы используем модель определения области видимости для определения мест, которые мы будем тестировать. Наша модель покрытия показывает заинтересованным сторонам, насколько тщательно мы планируем провести тестирование в этих местах.
Тестовые модели и показатели покрытия могут использоваться для определения количественных или качественных целевых показателей при разработке и выполнении тестов. В той или иной степени мы можем использовать такие цели для планирования и оценки. Мы также можем измерить прогресс и сделать вывод о тщательности или завершенности тестирования, которое мы запланировали или выполнили. Но нам нужно быть очень осторожными с любыми количественными показателями покрытия или процентами, которые мы используем.
Показатель покрытия (основанный на формальной тестовой модели) может быть рассчитан объективно, но не существует формулы или закона, согласно которым X означает покрытие, Y - качество или Z - достоверность. Все показатели покрытия дают лишь косвенное, качественное, субъективное представление о тщательности или полноте нашего тестирования. Не существует значимой взаимосвязи между покрытием и качеством или приемлемостью систем.
Количественные целевые показатели покрытия часто используются для определения критериев завершения тестирования, но эти критерии являются произвольными. При более жестком целевом показателе покрытия можно было бы покрыть в два раза больше позиций. Однако удвоенное количество тестов, стоимость которых в два раза выше, не делает систему в два раза более протестированной или в два раза более надежной. Такая интерпретация бессмысленна и глупа.
Иногда тестировщикам могут быть навязаны формальные модели, используемые для определения и построения системы, чтобы они могли использовать их для определения целевых показателей покрытия. В других случаях у тестировщиков может быть мало документации для работы, и им приходится изобретать собственные модели. Выбор любой тестовой модели и целевого показателя покрытия является в некоторой степени произвольным и субъективным. Следовательно, неформальные тестовые модели и меры покрытия могут быть столь же полезны, как и устоявшиеся формальные модели.
Упражнение по быстрому созданию модели
Небольшое упражнение, на котором закончим эту статью. В следующих примерах нарисуйте, как, по вашему мнению, могла бы выглядеть модель – только ее форму – либо в виде рисунка / диаграммы, таблицы или списка:
Пользователи обеспокоены сквозными поездками в системе.
Служба обмена сообщениями может находиться в четырех состояниях: выключена, запущена, запускается и завершает работу.
Калькулятор страховых взносов имеет 40 входных значений, которые в совокупности влияют на расчет; между некоторыми входными данными существуют зависимости.
Процесс извлечения/преобразования/загрузки состоит из семи этапов. После извлечения каждый этап либо отклоняет записи, либо отправляет их в файл приостановки, преобразует и передает записи на следующий этап. Последний этап — это процесс загрузки, который обрабатывает отклонения. Проверьте, учтены ли все извлеченные записи.
И это все для тестового моделирования, спасибо за чтение. Мы будем возвращаться к моделям на протяжении всей серии, так что следите за обновлениями!
