Декомпозируй это!
Привет, народ, сегодня поговорим про декомпозицию.
Что такое декомпозиция?
Это научный метод разделения или разбиения чего-либо на части. Применительно к сфере тестирования мы используем декомпозицию в тест-анализе и исследовательском тестировании продукта.
В тест-анализе мы можем посмотреть на тестируемый продукт, как на единое целое, и как на множество отдельных частей и моделей, тем самым обретая представление, что из себя представляет продукт, и что именно будет протестировано. Что касается исследовательского тестирования, здесь декомпозиция применяется для того, чтобы систематизировать тестирование, упорядочить его и не перескакивать с одной функциональной области продукта в другую, несмотря на всю гибкость исследовательского тестирования.
Принцип декомпозиции состоит в том, что тестируемое приложение можно рассматривать как состоящее из независимых друг от друга нескольких частей, блоков, каждый из которых тестировать гораздо проще и понятнее, чем всю программу сразу.
Применительно к тестированию продуктов декомпозицию можно рассматривать по нескольким принципам.
Функциональная декомпозиция — разбиение продукта на выполняемые им функции.
Глубина декомпозиции (то есть количество уровней) и степень подробности их описания определяются удобством восприятия и уровнем квалификации работающего с ней специалиста. Для специалиста, который знает продукт хорошо, декомпозиция может быть неглубокой. Если же с продуктом будет работать новичок или специалист, ранее не работавший с продуктом, то декомпозировать следует более детально и глубоко.
Обратите внимание на рисунок: там показано, как для функции «Навигация» проведена более глубокая декомпозиция.
Компонентная декомпозиция – когда мы с вами смотрим, из каких компонентов или частей состоит тестируемая программа.
Декомпозиция графического пользовательского интерфейса (GUI) – опираясь на данный принцип, декомпозиция проводится по тем элементам, что визуально доступны для пользователя программы.
Декомпозиция этапов взаимодействия пользователя с программой или с продуктом, то есть декомпозиция тех действий и операций, которые могут быть выполнены при взаимодействии пользователей с нашим продуктом.
И в любом описанном случае, независимо от переменного принципа, нам нужно смотреть, насколько глубоко мы хотим (или можем) исследовать продукт, какую глубину декомпозиции выбрать. Когда у нас достаточно времени для тестирования, мы можем уходить вглубь продукта с каждой новой тестовой сессией. Когда время ограничено — рекомендуем удостовериться, что основной (бизнесовый) функционал продукта работает и работает исправно.
Декомпозиция применяется не только в части анализа и исследования продукта. Она помогает работать с задачами (это полезно знать не только менеджерам проектных команд).
В теории все видится достаточно просто и ясно: из большой задачи нужно получить ряд маленьких — никаких проблем. Но когда суть доходит до дела, многие просто не понимают критериев декомпозиции задачи. Это непонимание ведет к неприятным вещам: неравномерная нагрузка на тестировщиков проекта, неверная оценка трудозатрат, неправильное понимание задач и разное представление о результатах внутри команды. Чтобы вам стало проще, хотим рассказать про принцип SMART.
Принцип SMART в декомпозиции
SMART – это мнемоническая аббревиатура, которую используют управленцы разных уровней для запоминания принципов постановки задач. Каждая буква аббревиатуры имеет свою расшифровку:
Specific – конкретный. Это про результат. Какого результата хотим достичь?
Результат должен быть однозначным и понятным всем участникам процесса: сотрудникам команды тестирования, заказчикам, руководителям разных уровней.
Measurable – измеримый. Нам нужны задачи, которые могут быть измерены. Количественно и / или качественно.
Attainable – достижимый. В данном случае определение «достижимый» мы бы переименовали в «доступный» (доступный для выполнения сотрудником с определенным уровнем подготовки и квалификации). Грамотный руководитель никогда не даст новичку сверхсложную задачу, так как понимает, что новичок с ней просто не справится, а время, затраченное на попытки решения, уже не вернуть. Учет личностных особенностей и качеств сотрудников команды тестирования на проекте позволит очень четко (а главное – равномерно и посильно) распределить нагрузку, дать новичкам несложные задачи, а «звездочкам» и профи – задачи со сложной логикой в соответствии с их силами и навыками.
Relevant – актуальный, значимый. Действительно ли выполнение задачи так важно для нас? Является ли данная задача необходимой именно сейчас? Что мы получим, если решим эту задачу? А что будет, если не решим?
Time-bound – ограниченный во времени. Любая задача должна иметь свой срок, в течение которого ее необходимо решить. Установление временных рамок и границ для выполнения задачи позволяет сделать процесс контролируемым и прозрачным. Руководитель в любой момент времени может увидеть прогресс выполнения задачи.
Кроме того, оценить прогресс и понять, что уже протестировано, а что еще — нет, также помогает декомпозиция. Обратите внимание на приведенную таблицу:
Отмечая проверенные области таким образом, вы, ваши коллеги и ваш руководитель сразу будете видеть статус продукта, что уже проверено, а что нет, избегая дублирования проверок.
А теперь хотим задать вопрос в студию: как вы считаете, техника «эквивалентное разделение» в тест-дизайне — это декомпозиция?
P.S.: Примеры по декомпозиции продукта «Браузер» уважительно подсмотрены у Натальи Савастюк и размещены в статье за их наглядность и простоту.
Ссылка: Декомпозиция в тестировании и при анализе приложения