Обеспечить представление данных любой большой системы, чтобы человек мог легко с этими данными работать — задача нетривиальная, но она давно решена.
«Дерево» уже давно выиграло эту гонку.
Структуры папок в операционных системах знакомы всем, и исторически простое дерево в UI/UX становится первым решением для организации и хранения данных.
Сегодня мы поговорим о тестировании, поэтому в нашем случае объектами хранения будут тест-кейсы.
Как их чаще всего хранят? Правильно, в папочки! Это обычное дело? Да.
Но является ли это решение хорошим и универсальным? Вопрос подтверждается наличием исключений: почта, билеты JIRA и многое другое не хранятся в папках.
Давайте разберемся, почему.
Одиночное дерево
Такой подход позволяет быстро приступить к работе и смоделировать структуру построения тестовой базы.
Например, организовать хранение тест-кейсов для веб-сервиса постранично (или по фичам) — на каждой странице есть папка для тест-кейсов, даже если самих тестов еще нет. Это удобно — сразу можно понять масштаб работы, и по наполненности папок можно примерно оценить охват. 
В результате получается красивое решение, позволяющее команде тестирования спокойно и системно, с разделением зон ответственности, наполнять дерево тестами.
Однако, если бы все было хорошо, такой ситуации бы не возникло.
Что случилось с ним?
Представим, что у нас есть замечательный веб-сервис, тесты для него написаны, разложены по папкам (по одной на каждую страницу) и выполняются раз в неделю, все довольны.Однако в какой-то момент к QA-менеджеру (а они всегда приходят!) приходит менеджер и просит рассказать о тестовом покрытии микросервисов.
Не то чтобы это большая проблема - просто теперь помимо существующей структуры нужно как-то собирать информацию о тестах из папок и соотносить ее с микросервисами и делать соответствующую( новый ) отчет. Однако, чтобы в следующий раз не заниматься рутиной, старший тестировщик предлагает ввести фиксированные уровни в дереве: так мы сможем иметь данные по командам в нашей структуре данных, и команды будут гораздо быстрее разбираться со своими репозиториями! Отличное решение, только в следующий раз менеджер попросит статистику покрытия по функциям( еще один новый отчет ).
Если тестов много, сотни или тысячи, то создание каждого нового среза потребует погружения во все вложенные ветки и перераспределения тест-кейсов в новую структуру для анализа.
В результате общее дерево в конечном итоге делится на поддеревья: у каждой команды есть свое поддерево со своими правилами.
Если необходимо добавить в тесты дополнительную фичу, никто не пойдет редактировать чужие поддеревья: неудобно, это не нужно, процессы уже привязаны к текущей структуре, нет времени этим заниматься, «не надо».
потрогайте наши тесты!» и по миллиону других причин.
В результате получается картинка, где дерево папок общее, но каждое поддерево имеет свои уровни.
Недостатками дерева папок являются отсутствие гибкости в доступе к данным и аналитике, а также сложность рефакторинга при изменении требований к тестированию.По мере роста проекта и возникновения требований к прозрачности тестирования возникает второе ограничение структуры папок: ее очень сложно поддерживать.
Продукты редко становятся проще, поэтому со временем наступает момент, когда созданная в начале структура хранения тест-кейсов устаревает. Со временем обнаружится, что папочки в первоначальной структуре размножились и превратились в неуправляемый ад. Разумным решением было бы перестроить конструкцию по другому критерию, по особенностям.
Для этого нужно спроектировать новую структуру, вместе с аналитиком (если он у вас есть) разобраться в особенностях и аккуратно перенести все тесты в новую структуру.
Выглядит просто, но такой процесс в крупных проектах занимает недели и месяцы, и те, кто с этим еще не сталкивался, — счастливые люди.
В результате папки снова станут управляемыми, уровни вложенности будут структурированы, но срез снова будет только один — по функциям.
Если вы попытаетесь создать структуру сразу с двумя разделами, функциями и компонентами, ее сложность и запутанность создаст больше проблем, чем того стоит. Что, если у вас есть 3000 тестовых случаев? А если 10 000? Однако, чтобы столкнуться с ограничениями структуры папок хранения тестов, не обязательно ждать от менеджера какого-то «хитрого» запроса.
Если вам нужно найти самый «красный» компонент в недавно переработанной структуре признаков, вы, скорее всего, не сможете этого сделать: вы найдете самого красного «папу» с признаком, но сразу не будет понятно, какие компоненты являются в нем проходят испытания.
Любыми показателями тестирования или качества продукта придется заниматься головой и руками.
Еще один подводный камень хранения тестов в папках ждет тех, кто планирует хранить в них автоматизированные тесты, написанные на разных языках программирования.
Здесь все просто: в Java тесты хранятся по полному имени пакета типа io.qameta.allure, а в JavaScript или Python — просто по имени пакета.
Это означает, что при автоматической генерации тест-кейсов из автотестов каждый фреймворк будет ограничивать свои подструктуры в дереве и вся нормализация и базовая структура будут нарушены.
Конечно, под каждый фреймворк можно написать свою интеграцию, но мы ведь пытаемся облегчить себе жизнь, правда? 
Изначально роботы не все делают одинаково.
Пришло время задуматься, причем здесь принятие решения, вынесенное в заголовок этой статьи.
Ответ прост: все эти недостатки связаны с тем, что папочная организация хранения тест-кейсов вынуждает команду тестирования с самого начала определяться со структурой тестов, а не просто хранить информацию о тестовых сценариях и их результатах.
.
Просто «думать наперед» будет недостаточно — вам придется просчитать, что будет с проектом и командой тестирования через год-два, а еще лучше — через три.
К сожалению, чаще всего прогнозы оказываются неверными: можно переоценить темпы роста и годами сидеть в структуре «роста», либо, наоборот, недооценить их и оказаться в структуре, неудобной для вашей команды и коллег.
Как ОП решил эту проблему?
С ограничениями классического дерева мы разобрались, но как их обойти? На самом деле, с этой проблемой уже столкнулись многие люди, и нет необходимости изобретать велосипед. Большинство систем, работающих с большими объемами данных или большим количеством объектов, переходят на плоскую структуру с навигацией по признакам.Наиболее яркими недавними примерами являются такие инструменты мониторинга, как Grafana и Graphite. Давайте посмотрим поближе и попробуем применить это к тестированию.
Администраторы и все те, кто работает в Ops, относятся к метрикам и данным с большой чуткостью и любовью.
Просто потому, что вы хотите узнать об сбое сервиса, сбое сети или недоступности кластера раньше пользователя, не так ли? Изначально весь мониторинг был построен по классической иерархической структуре: дата-центр → кластер → машина → метрики (ЦП, ОЗУ, хранилище и т. д.).
Удобная и понятная система, которая работает, если вам не нужно отслеживать десятки метрик в реальном времени, не привязанных к физическим машинам.
А метрики очень важны для Ops. Например, вам нужно получить снимок загрузки всех машин, на которых работает какой-либо микросервис.
Построение такого среза с единой иерархической структурой — нетривиальная задача.
Проблему решили понятно и изящно: поместили все объекты в единый пул и начали помечать каждый нужными тегами.
Набор меток хранится в плоской структуре и свободно используется — меткой становится любой критерий поиска, фильтрации или группировки: метрика, статус, география, сервис или компонент, положение в иерархии или отношение к команде.
Такой подход позволяет освободить систему хранения от навязывания решений по структуре и хранить размеченные данные и метаданные таким образом, чтобы к ним можно было получить доступ без «лишней» нагрузки.
Набор меток хранится в плоской структуре и свободно используется — любой критерий поиска, фильтрации или группировки становится меткой.Чтобы получить отчет или анализ данных, вам достаточно указать, по каким критериям срезы нас интересуют: загрузка процессора по инстансам, по географическому признаку.
Этот метод управления данными позволяет не только фильтровать и делать выборки внутри структуры.
Он предоставляет еще один уровень свободы в виде упомянутой выше группировки: теперь можно смело делать запрос к хранилищу вида «показать статистику доступности всех машин, на которых запущен такой-то микросервис, сгруппированных по кластеры».
Парсер перебирает все машины, берет статистику доступности с тех, у которых есть метка микросервиса, и группирует их в кластеры.
В этом случае следующим запросом можно легко получить «загруженность кластера по географии» — дерево перебалансируется, перемещая кластеры на нижний уровень, а географию на первый.
В любой момент по запросу пользователю доступна любая аналитика и любой срез данных.
Зайдите в дашборды любой Ops-команды крупного сервиса — здесь вы найдете отчеты по десятку метрик (время безотказной работы, загрузка ресурсов, количество пользователей и т. д.), разделенных по множеству критериев (география, балансировка между серверами и т. д.).
).
— Да это просто папиная автоматизация! - ты говоришь.
И это здорово — это классическое решение проблемы масштабирования.
Конечно, у системы тегов есть несколько недостатков:
- Вы не можете создать «скелет» папок и оставить их пустыми.
Классическая практика из начала статьи, позволяющая продумать архитектуру на старте.
- Неудобно для тех, кто последние годы работал с папами.
Создание тестов требует тщательной компоновки и осмысленного подхода к формулированию каждого тестового примера.
Если «проваленные» или «ненужные» тесты просто теряются в папках, здесь они будут бельмом на глазу.
Тестовые примеры: дерево против меток
— Ладно, с админами всё понятно.Они сидят и целый день смотрят на показатели и обрабатывают данные.
Зачем нам это нужно?
Ответ прост: мир разработки, к сожалению или к счастью, давно отошел от жесткой структуры — релизы ускоряются, сборки автоматизируются.На фоне этих изменений мир тестирования в большинстве компаний выглядит несколько архаичным: для новых функций готовится пачка новых тест-кейсов для ручного тестирования и автоматизации, они раскладываются по папкам и отправляются в тестирование на неопределенный срок.
период (от 1-2 дней до недели), результат тестирования собирается и после полного завершения отправляется обратно в разработку.
Вам ничего не напоминает? Это старая добрая каскадная застройка (то есть водопад)! В 2021 году.
Если послушать Баруха Садогурского в один из подкастов , где он вполне убедительно рассказывает о том, что любой процесс по сути является гибким, в котором «мы стараемся отложить принятие решения, насколько это возможно, чтобы собрать больше данных, прежде чем сделать это», станет понятно, почему весь мир разработки гонится за короткими итерации и быстрые релизы.
Вот почему разработчики долгое время писали программное обеспечение итеративно, вводя одну функцию или пару исправлений в каждом выпуске, операторы выпускают эти выпуски как можно скорее, которые предварительно тестируются.
Как они тестируются? Скорость разработки и развертывания требует от тестирования быстрого получения результатов — больше нет времени на полуавтоматический анализ статического дерева — вашим коллегам нужно много данных из разных срезов.
И если вам сложно их подготовить, действительно ли тестирование самое полезное? Посмотрите на последние тенденции в тестировании DevOps, которые заключаются в том, чтобы тестировать как можно меньше и как можно быстрее: это приводит к таким подходам, как сдвиг вправо И тестируйте как можно меньше .
Практики, направленные на скорость, повторяемость и стабильность выполнения тестов, а не на покрытие и оценку качества в широком смысле — об этом я со временем напишу отдельные статьи.
Поэтому, чтобы остаться в мире, где за качество продукта отвечает тестирование, давайте вернемся к нашим папочкам и приметам.
При создании структуры папок мы изначально помещаем в хранилище тест-кейсов принятое нами решение о том, в какой форме мы хотим получать отчеты и видеть результаты.
Проблема в том, что мы не знаем, какие отчеты понадобятся в будущем.
Если у вас нет времени готовить отчеты для коллег и бизнеса, то действительно ли тестирование приносит максимальную пользу?Ведь никто не хочет иметь дело с закостеневшей структурой, удобной для отдела контроля качества.
Чтобы тесты были полезными, их результаты должны быть гибкими и максимально атомарными, готовыми к сборке произвольных отчетов.
Итак, давайте соберем метаданные и потом во всем разберемся.
На их основе можно будет построить отображение дерева тестов в нужном виде: для тестировщиков — по функциям, для разработчиков — по классам или вообще список, отсортированный по названию: 
Пример представлений, которые можно получить в Allure TestOps в пару кликов из базы размеченных тестов.
Тестирование, как и мониторинг из примера, работает с метриками.
Их может быть много или очень много, и придумать универсальную и вечную структуру просто невозможно.
Но можно собрать и сформулировать комплексный набор показателей и критериев.
По сути, вместо одного статического дерева управление через атрибуты позволяет простым и понятным способом создать генератор деревьев по необходимым критериям, расширяемый и масштабируемый без лишних танцев с бубном.
И как только мы получим автоматически сгенерированные образцы и группы, мы сможем настроить автоматическое создание отчетов в режиме реального времени и создание отчетов.
Самый наглядный пример — JIRA, где можно построить график, тренд или дашборд любого типа по любому полю тикета, собирать, фильтровать или группировать тикеты (могут понадобиться плагины! :)) в любую структуру прямо на встрече.
Согласитесь, звучит заманчиво: иметь гибкость билетов JIRA в управлении тест-кейсами.
Осталось только автоматизировать запуски для слияния веток и вот тестирование уже соответствует требованиям DevOps! 
Теги: #тестирование #Тестирование веб-сервисов #Тестирование ИТ-систем #тестирование веб-приложений #автоматизация тестирования #лучшие практики
-
Интеграция Спутников И Ansible Tower
19 Oct, 24 -
И Они Посчитают Меня
19 Oct, 24 -
Статистика Переходов На Сайт «Откуда Пришли»
19 Oct, 24
