Декомпозиция — научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач, пусть и взаимосвязанных, но более простых. (wikipedia)
Декомпозиция, как процесс расчленения, позволяет рассматривать любую исследуемую систему как сложную, состоящую из отдельных взаимосвязанных подсистем, которые, в свою очередь, также могут быть расчленены на части.
Например, стандартный персональный компьютер начала 21в. состоит из системного блока, монитора, клавиатуры, мышки и проводов, которые соединяют эту систему. Системный блок – это материнская плата, процессор, кулер, винчестер и т.д. Мышка – это датчик перемещения, управляющие элементы, интерфейс подключения к компьютеру. Управляющие элементы мышки – это правая и левая кнопки, колёсико, дополнительные кнопки.
Декомпозиция системы чаще всего представляется в виде иерархического дерева, вершина которого – сама система, а уровни – выделенные подсистемы.
Подобные иерархические деревья для приложений можно строить с целью:
- сбора и сохранения информации о структуре приложения. Глубина расчленения (количество уровней) будет варьироваться в зависимости от того, кто будет пользоваться этой структурой и как.
- создания чеклиста, который можно будет использовать в процессе тестирования. Для этого необходимо достичь очень глубокого расчленения.
Однако, даже если декомпозиция приложения не представляется в виде иерархического дерева, для тестировщика принцип декомпозиции обозначает то, что тестируемое приложение (отдельный его модуль или функционал) можно рассматривать как состоящий из относительно независимых друг от друга подсистем, каждую из которых тестировать гораздо проще и понятнее, чем всю систему сразу. Принцип декомпозиции необходимо и полезно использовать повсюду:
- при создании чеклистов или тест-кейсов
- при выполнении тестирования исследовательским способом
- при проведении тестирования требований
- при планировании и оценке задач по тестированию
Осмысленное применение декомпозиции в процессе тестирования помогает достигнуть как лучшего качества, так и большей уверенности в этом качестве.
Признаки декомпозиции
Для разделения одного и того же приложения на подсистемы могут использоваться разные признаки декомпозиции. В качестве задачи на декомпозицию мы будем рассматривать приложение “Браузер” (см. рис. 1). Следует учесть, что во всех примерах, которые будут приведены ниже, декомпозиция не полная. Показаны лишь некоторые из подсистем первого и второго уровней.
Рис. 1. Скриншот приложения “Браузер”
В качестве признака разделения приложения могут использоваться:
- внешний интерфейс (экран, окно, закладка и т.п. со всеми элементами интерфейса). На рис. 2 показан пример декомпозиции по этому признаку.
- компонентная структура (функциональные модули приложения и их интеграция в более сложные модули). См. пример на рис. 3.
- функции приложения и их варианты использования (см. пример на рис. 4),
- обрабатываемые приложением объекты и данные (и часто нужно анализировать не то, что видно, а то что скрыто внутри – что передается на вход, что на выходе, что храниться внутри системы),
- характеристики (параметры) объектов и данных или в целом всей системы (например, если объект – это файл, то параметры это – формат, размер, создатель, дата создания и т.д.),
- действия над объектами (если объект “файл”, то действия – удалить, переименовать, переместить, а если объект “список файлов”, то действия – сортировать, фильтровать, выделить несколько файлов)
- состояния, в которые переходит приложение или его модули,
- этапы взаимодействия пользователя с приложением (см. пример на рис. 5),
- виды пользователей,
- характеристики качества (функциональность, удобство использования, производительность и т.д.),
- и другие.
Рис. 2. Пример декомпозиции по элементам интерфейса приложения “Браузер”
Рис. 3. Пример компонентной декомпозиции приложения “Браузер”
Рис. 4. Пример функциональной декомпозиции приложения “Браузер”
Рис. 5. Пример декомпозиции по этапам взаимодействия пользователя с приложением “Браузер”
Часто декомпозиция одной и той же системы может осуществляться по нескольким признакам, порядок их выбора зависит от квалификации и предпочтений тестировщика. Декомпозиция – задача очень субъективная. И самое главное, чтобы тестировщик осознавал свой выбор принципа декомпозиции в каждый момент времени.
Принципы декомпозиции
1. Каждое разделение образует свой уровень.
Исходная система располагается на нулевом уровне. После её разделения получаются подсистемы первого уровня. Разделение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т.д.
Тестирование системы или подсистемы обозначает тестирование всех уровней всех подсистем, на которые она разбивается.
2. Все подсистемы одного уровня, являющиеся подсистемами одной и той же системы, должны разделяться по одному признаку
Другими словами, должны отвечать на один и тот же вопрос относительно своего родителя.
По правилам декомпозиции все подсистемы одного уровня должны обладать одним признаком и разделяться по нему но часто при тестировании ПО подобного разделения достичь очень тяжело либо требует слишком много времени, поэтому я руководствуюсь упомянутым упрощенным правилом – в рамках одного узла деление должно быть выполнено по одному признаку.
3. Вычленяемые подсистемы в сумме должны составлять всю систему (как пазл соединяться в одну картинку). При этом они должны взаимно исключать друг друга.
Если сложить все выделенные подсистемы вместе, то мы должны получить всю систему. Однако целостность и качество этой системы можно гарантировать только с учётом взаимодействия подсистем. Например, нет гарантии, что системный блок компьютера будет работать, если работают по отдельности материнская плата, процессор, компьютер и др. компоненты. Их нужно собрать вместе и проверить взаимодействие.
В процессе декомпозиции допускается выделять группу (подсистему) “Другие”, в которую включаются те подсистемы, для которых невозможно выделить один общий признак или подсистем получается слишком много, чтобы выделять их на верхний уровень. Но в «Других», должен всё равно применяться некий свой внутренний признак расчленения.
К неоднозначности может привести использование на одном уровне взаимно пересекающихся подсистем. Например, в сводке расходов за месяц, в большинстве случаев немного странно будут выглядеть пункты: еда, аренда помещения, канцелярия, коммунальные услуги, подогрев воды. Обычно подогрев воды относится к коммунальным услугам.Соответственно, при выделении этих пунктов на один уровень могут возникнуть вопросы формата: расходы на подогрев воды – это дополнительные расходы сверх нормы? Или это постоянные ежемесячные расходы? А не платим ли мы дважды за подогрев воды?
4. Выбирайте глубину декомпозиции в зависимости от задач, которые решаете с помощью неё и в зависимости от уровня знаний специалистов, которые будут ей пользоваться. Ищите компромисс между полнотой и простотой.
Глубина декомпозиции (количество уровней) и степень подробности описания определяются требованиями обозримости и удобства восприятия получаемой иерархической структуры, её соответствия уровням знания работающему с ней специалисту.
Для специалиста, знающего систему хорошо, декомпозиция может быть неглубокой, менее детализированной. Если же предполагается, что результат декомпозиции будет использоваться не работавшим ранее с системой специалистом, то декомпозировать следует более детально и глубоко.
Раньше рекомендовалось выделять 3-6 уровней. В настоящее время существует специальное ПО для создания интеллектуальных карт и управлять декомпозицией стало проще. Однако всё равно следует искать золотую середину, подходящую под ваши условия работы, и учитывать, что когда в структуре получается много уровней, то система становится труднообозримой, в ней сложно ориентироваться. Если же глубину делать небольшую, то вероятнее всего возрастет число находящихся на одном уровне подсистем и становится сложно связать их в единую полную систему, сложно искать взаимосвязи.
Системы нижнего уровня называются элементарными.
Если иерархическая схема используется как чеклист, то элементарные системы – это и есть идеи тестов.
Если же схема используется как структура приложения, то элементарные системы – это системы с такой степенью детализации, которую будет очевидно, как тестировать человеку, использующему эту схему в процессе тестирования.
5. Проводите критическую оценку декомпозиции каждого из построенных уровней и системы в целом.
Всё ли охвачено? Не пропущено ли? Может быть есть избыточные ветви или пересекающиеся?
Понятно ли как тестировать системы нижнего уровня? Можно ли расчленить эти системы еще больше? Если ваших знаний недостаточно для дальнейшей декомпозиции, то привлекайте других участников проекта (проектных менеджеров, программистов и т.д.)
Связанные тренинги
Декомпозиция в тестировании
Ключ к качественному выполнению своих задач — от анализа приложения, до планирования работы.
|
2 занятия
|
9,5 ч. видео
|
22 задания
|
 |