Оглавление
-
Часть 3:Оформляем wiki-страницы
Ведение wiki-страниц
Связи
Мы способны управлять по-настоящему комплексными и масштабными системами через взаимодействие с атомарными частями. Так, монолитная архитектура приложения разбивается на микросервисы. Наиболее распространенная методология в программировании, ООП, подразумевает распределение всего когда приложения по классам и объектам. В ныне хайповом zettelkasten, подходе для ведения базы знаний, необходимо создавать вместо одной объёмной заметки — множество небольших и объединять их через линки и теги. Кстати, после ухода Notion'а из России одной из наиболее популярных альтернатив стал Obsidian, разработчики которого вдохновлялись, в частности, этим подходом.
Мы делаем сложные вещи проще с помощью связей. Тестирование - не исключение. Проверки функциональности распределяются по шагам тест-кейса, который, в свою очередь, является составной частью тестового набора. Современные TMS позволяют объединять эти наборы в тест-планы, по которым создаются тестовые прогоны (Test Run, Test Execution).
Вместе с тем мы на проекте заметили, что обычно результат работы типичной задачи по написанию тестовой документации — это тест‑кейсы. Их составление и публикация. При этом подготовка тестовых данных и их описание на отдельной странице, — остается на усмотрение тестировщика. Артефакты тест‑дизайна, в частности, чек‑листы обычно воспринимаются как драфт для тест‑кейсов и зачастую не публикуются. Однако и тестовые данные, и чек‑листы, опубликованные в пространстве тестирования, по опыту нашей команды на текущем проекте, помогает сократить время на поддерживаемость тестовой документации и создать более полный контекст об объекте тестирования.
Мы используем раздел «Связи» почти на каждой wiki‑странице, в самой верхней её части. Бывает так, что мы сначала публикуем основную информацию, а связи описываем позже. Да, если вы раньше не использовали этот раздел, то по началу можете часто забывать о его добавлении. При этом описание отношений между артефактами тестирования, помимо ранее описанных преимуществ, приводит к упрощению навигации по тестовой документации и способствует более быстрому и полному усвоению информации. Поэтому со временем привычка добавлять связи воспринимается как нечто естественное и само собой разумеющееся.
В нашей реализации этот раздел выглядит примерно так:
Мы указываем сначала краткое описание, затем ссылку.
На отдельнойобщей wiki‑странице, не посвященной какой‑либо функциональности (у нас такая называется «Конструктором»), можно описать «Библиотеку связей», чтобы синхронизировать видение команды по их оформлению:
SQL-запрос для добавления данных;
SQL‑запрос для отладки (и обратная связь — нужен для отладки);
SQL‑запрос для очистки тестовых данных (и обратная связь — очищает тестовые данные);
SQL‑запрос на получение данных для заполнения переменных;
SQL‑запросы, сформированные на основе проверок;
SQL‑запросы, сформированные на основе шаблона (и обратная связь — основано на шаблоне);
Данные в теле ответов основаны на;
Данные из ответов нужны для страниц;
Дочерние страницы;
Может быть полезно;
Полученные данные используются в;
Проверки, на основе которых сформированы тестовые данные;
Проверочный SQL-запрос;
Реализовано на основе идеи;
Справка;
Тест-кейсы;
Хэдеры для Kafka-сообщений.
На практике также очень удобны «обратные связи» (backlinks). Если в Wiki есть такая функциональность, то они формируются автоматически на страницах, на которые ссылается линк. Обратные связи генерируются в Confluence, их можно посмотреть в Page Information. Для наглядности мы также используем макрос Linkgraph с отображением только входящих связей (Incoming links) и заворачиваем его в Expand с текстом «Упоминания этой страницы». В Obsidian также есть такая функциональность, реализованная на уровне Core Plugins. При работе со связями следует убедиться, что после обновления заголовка страницы или после её перемещения ссылка на эту страницу по-прежнему остается работоспособной.
В некоторых случаях связи также полезно наследовать. Ранее упоминал про используемые для этого макросы Excerpt + Excerpt Include в Confluence. Приведу еще пример — для разных проверочных SQL‑запросов может использоваться один и тот же запрос INSERT, один и тот же тест‑кейс и единый шаблон:
Наследование в wiki также позволяет переиспользовать одну и ту же информацию без копирования объектов. Предположим, у нас есть алгоритм. Он берет данные из 10-ти таблиц (входных, in) и наполняет 3 таблицы (выходные, out). В этом случае мы можем написать 1 скрипт с запросами INSERT для 10-ти таблиц и связать его с 3-мя проверочными запросами:
Кстати переиспользование объектов вдохновлено одним из принципов программирования — DRY.
Еще в «Связях» мы наследуем короткую справочную информацию:
Дочерние страницы мы указываем как связь с одноименным описанием «Дочерние страницы» и генерируем ссылки автоматически через макрос Children Display.
Бывает так, что один объект потенциально может иметь большое количество обратных связей. Например, шаблон проверочного запроса, на который ссылаются множество страниц с кодом, реализованным под тестируемую функциональность. Один из алгоритмов, который я тестирую, наполняет 21 таблицу. Под каждую из них нужен отдельный проверочный SQL‑запрос для быстрого анализа рассчитанных значений. Страницы с кодом хранятся в отдельной родительской странице, которая, в свою очередь, содержит 1 связь с шаблоном проверочного запроса. Конечно, алгоритм, наполняющий множество таблиц, у меня в работе меня не единственный. Поэтому чтобы связи упрощали работу, а не стали сущностями, которые усложняют поддерживаемость, их нужно грамотно группировать:
Для каждого проверочного запроса, проиллюстрированных на схеме выше, полезно наследовать связи родительских страниц. Если ваша Wiki позволяет реализовать такое наследование, например, в ней есть аналоги макросов Excerpt + Excerpt Include, то вы таким образом можете добавить наглядности и интерактивности к документации без дополнительных трудозатрат.
Связи — это мощный инструмент для работы с комплексными объектами. Выше я описал, как мы его используем при тестировании задач на проекте. Предлагаю и вам попробовать делить большие тестовые артефакты на документы поменьше и связывать их между собой. Вполне возможно, вы будете использовать этот инструмент иначе, чем мы. Главное — результат. Осведомленность о том, что при работе со сложным объектом можно сконцентрироваться на его составных частях и на связях между ними, — может привести не только к повышению эффективности вашей работы, но и в целом к увеличению количества задач, которые вы способны решить.
Разделы "Сведения" и "Код"
Разделы, названия которых полностью отражают их суть.
В «Сведениях» мы храним справочную информацию. Польза и удобство этого раздела наиболее очевидны при совместном использовании с разделом «Код». Да, комментарии к коду можно оставить и в предусловиях, и в шагах тест‑кейса, но в каждом из этих случаев возможности для описания сильно ограничены. Конечно, мы оставляем комментарии и в самих SQL‑запросах, что можно увидеть в примерах выше. А в «Сведениях» у нас хранится более детальная информация, где может, например, содержаться таблица с пояснениями:
Информацию, поделенную на отдельные темы, распределяем по пунктам, каждый из которых начинается с индекса с краткой формулировкой в формате хэдера h5:
Вместе со «Сведениями», или вместо них, можно использовать и другие разделы. Например, «Инструкцию», где будет описана какая‑либо последовательность шагов. Или «ToDo» — все, что было бы неплохо сделать, но по каким‑либо причинам нецелесообразно добавлять в бэклог в текущее время.
Назначение раздела «Код» и его использование — интуитивно предсказывается. Сегодня, наверно, почти в каждой системе для ведения проектной документации есть возможность описать код в специально предназначенном для этого блоке. В Confluence мы используем макрос Code Block. Такое форматирование не только добавляет удобную подсветку синтаксиса, но также позволяет быстро скопировать код по двойному клику с последующим использованием ctrl + c / ctrl + v или просто по нажатию специальной кнопки (тут реализация зависит от вашей wiki). При работе с SQL это настолько удобно, что этот язык у нас стал наиболее часто используемым инструментом при тестировании бэкенда.
Таким образом, раздел «Код» в сочетании с использованием связей дает возможность использовать повсеместную частичную автоматизацию в ручном тестировании. С минимальными требованиям к навыкам программирования и без необходимости работы с фреймворками АТ. Хотя, если у вас все же используется такой фреймворк, по нашему опыту, скрипты могут сильно упростить работу автоматизатору. А свои первые шаги в автоматизации можно делать с помощью нейросетей. Собственно, я так и изучил SQL: у меня возникали вопросы, я писал промты, получал ответы, использовал полученные знания.
Код также можно хранить и на платформах с репозиториями проекта, но в нашем случае сейчас это избыточно. :)
Кстати, не видел ни в корпоративных wiki, ни в Obsidian возможность наследования в блоке кода. Например, чтобы на 1-й странице, было описание на SQL создание временной таблицы, а на 2-й странице — в блок кода подтягивался бы код из 1-й страницы:
Странно, что такая возможность еще не реализована.
Нейминг страниц
Для названий страниц мы используем шаблон:
Произвольный краткий ключ, привязываемый к тестируемой функциональности + Путь до страницы + Краткое описание страницы
И добавляем точки в качестве разделителя.
На протяжении всей статьи я использую примеры, связанные со смартфонами. Поэтому в большинстве случаев названия страниц на скриншотах начинаются с фрагмента SMRT. Это ключ, позволяющий идентифицировать тестовые артефакты, которые относятся к тестированию смартфонов. Дальше через точки описывается место хранения. Например, ТД — это страница с тестовыми данными, а SQL — тестовые данные, описанные в запросах к БД.
Вот еще несколько примеров:
SMRT. Вопросы;
SMRT. Проверки. Таблица принятия решений. Алгоритм прогнозирования цен;
SMRT. ТД. REST. Добавление моделей смартфонов;
SMRT. ТД. SQL. INSERT. settings. Конфигсет по умолчанию.
Иногда полезно организовать сортировку с помощью индексов:
SMRT. ТД. REST. 01 Добавление моделей смартфонов;
SMRT. ТД. REST. 02 Получение моделей смартфонов;
SMRT. ТД. REST. 03 Изменение моделей смартфонов;
SMRT. ТД. REST. 04 Удаление моделей смартфонов.
Некоторые словосочетания можно резервировать с приданием ему особого смысла. Например, на отдельной wiki-странице с шаблонами SQL-запросов (в «Конструкторе») у нас есть ранее продемонстрированный универсальный проверочный запрос. Назвали эту страницу CON. SQL. Универсальный проверочный запрос (CHECK VALUES). После этого для указания наличия такого кода в каком‑либо объекте — мы добавляем в название фрагмент CHECK VALUES. И получаются такие формулировки:
SMRT. ТД. SQL. CHECK VALUES. models;
SMRT. ТД. SQL. CHECK VALUES. price_forecast;
SMRT. ТД. SQL. CHECK VALUES. production.
При регулярном использовании такого подхода нейминга сходу становится понятно, что каждая из этих страниц содержит проверочный запрос для определенной таблицы БД.
В нашей реализации есть и другие особенности составления названий. Например, дочерки родительской страницы «SMRT. Информация» у нас содержат только ключ и описание:
-
SMRT. Информация
SMRT. Обработка ошибок;
SMRT. Промежуточный отчет о результатах тестирования алгоритма прогнозирования цен;
SMRT. Формирование тестовых записей на основе существующих данных.
Или можно еще вот так:
-
SMRT. Информация (INFO)
SMRT. INFO. Обработка ошибок;
SMRT. INFO. Промежуточный отчет о результатах тестирования алгоритма прогнозирования цен;
SMRT. INFO. Формирование тестовых записей на основе существующих данных.
В целом описанный способ нейминга имеет несколько преимуществ:
Название страницы содержит большое количество полезной информации о контексте. Даже если вы перейдете на страницу с таким названием, которая относится к тестированию функциональности вашего коллеги, вы сходу многое можете понять из одного только названия;
Появляется единообразие формулировок, что, в свою очередь, упрощает коммуникацию между участниками команды;
Сокращается время на придумывание названия.
Структура wiki-страниц
Корневая страница
Под каждую тестируемую функциональность в пространстве тестирования корпоративной Wiki мы создаем отдельную страницу. Её условно можно назвать «корневой». Основная информация здесь — это перечисление дочерних страниц:
Это тот же самый пример, который я использовал ранее. Фактически он связан сразу с несколькими темами, о которых я пишу. Неплохая иллюстрация для раскрытия основной идеи, которой посвящена статья. :)
Ссылка на корневую страницу прикладывается к тест‑кейсу в блоке «Описание». Выглядит это так:
Поэтому иногда некоторую справочную информацию полезно указывать именно здесь. В частности, ссылки на wiki-страницы, которые чаще всего используются во время тестирования.
Вопросы
Нет, здесь хранится не просто текст с использованием нумерованного списка. Каждый вопрос на странице — отдельный объект с атрибутами, которые вы определяете сами. Это упрощает работу, что особенно ощутимо при существенном недостатке информации.
Приведу пример шаблона, который мы используем:
Атрибуты вопросов в шаблоне, которые мы используем:
Ключ, имеющий формат хэдера h3. Позволяет обращаться к каждому вопросу отдельно, что удобно при построении связей. Это может пригодиться, например, при составлении таблицы с проверками:
Статус на той же строке, что и ключ (в примере выше: если статус отсутствует, то на вопрос есть ответ);
Уточнение, если не удалось получить всю необходимую информацию за одну формулировку. Имеет формат хэдера h4. Не указывается, если в уточнении нет необходимости;
Текст вопроса, при работе с которым доступны все возможности форматирования текста вашей корпоративной wiki и добавление приложений без каких-либо ограничений. В некоторых случаях, когда вопросы оформлены в виде списка, возможности оформления могут быть ограничены. Например, может быть недоступен отступ в рамках одного и того же пункта (иначе говоря, при использовании shift + enter создается новый пункт в списке вместо отступа в пределах одного и того же пункта). Или ломается верстка от добавления изображения или какого-либо блока (с кодом, например).
-
Теги для добавления различной дополнительной информации. Примеры:
Приоритет вопроса (#высокий, #низкий)
Необходимость добавления полученной информации в документацию от аналитика (#обновить_документацию)
Группировка по отдельным частям функциональности (#числовые_параметры, #источники_данных)
Ключи и уточнения автоматически формируют оглавление при использовании формата хэдеров (в Confluence — с помощью макроса Table of Contents). Это особенно полезно при наличии большого количества вопросов. По такому оглавлению можно быстро получить важную информацию: общее количество вопросов, вопросы без ответа, наличие уточнений и их статус.
Хранение вопросов на отдельной странице экономит место в комментариях к документации. Весь текст вопросов и ответов может занимать много пространства. При этом не всем коллегам, заходящим на страницу, нужна эта информация, а её пролистывание будет занимать дополнительное время.
При использовании шаблона с вопросами ответ гарантированно будет идти после текста вопроса. А при публикации списка с вопросами в комментариях к документации, по моему опыту, аналитик даст ответы также в виде отдельного списка. В этом случае необходимо мысленно сопоставлять списки при обращении к комментарию, что особенно неудобно при большом количестве пунктов. Оцените сами:
Пример списка вопросов и списка ответов
SMRT. Вопросы. Альтернативный вариант
Александр (Специалист по тестированию), 01.11.2024, 09:00
Как зарегистрировать новый профиль?
Можно ли создать профиль, используя учетную запись в другой социальной сети?
Какие данные обязательны для заполнения профиля?
Как изменить имя пользователя в профиле?
Можно ли добавить дополнительную информацию, такую как биография или интересы?
Как добавить или изменить профильную фотографию?
Есть ли возможность скрыть определённые разделы профиля от других пользователей?
Как удалить профильные данные?
Как настроить уведомления для профиля?
Можно ли сделать профиль приватным?
Как восстановить доступ к профилю, если забыл пароль?
Есть ли ограничения на количество друзей или подписчиков у профиля?
Как заблокировать или разблокировать других пользователей?
Какие типы действий можно выполнять с профиля (публикации, сообщения и т. д.)?
Как долго хранится история моих действий в профиле?
Могу ли я перенести данные профиля в другое приложение или платформу?
Что произойдет с данными профиля при удалении учетной записи?
Как можно защитить свой профиль от взлома?
Есть ли функция проверки двухфакторной аутентификации?
Как связаться с поддержкой, если возникли проблемы с профилем?
Екатерина (Системный аналитик), 01.11.2024, 10:30
Чтобы зарегистрировать новый профиль, посетите страницу регистрации и заполните необходимые поля, такие как адрес электронной почты и пароль.
Да, вы можете создать профиль, используя учетные записи Facebook, Google или Apple для упрощенной регистрации.
Для создания профиля необходимо указать имя, фамилию, адрес электронной почты и пароль.
Чтобы изменить имя пользователя, перейдите в настройки профиля и выберите соответствующий раздел для редактирования.
Да, вы можете добавить биографию, интересы и другую произвольную информацию в разделе «Личная информация» профиля.
Чтобы добавить или изменить фотографию, нажмите на текущую фотографию профиля и загрузите новый файл.
Да, вы можете скрыть определённые разделы, такие как контактные данные, настроив параметры конфиденциальности.
Чтобы удалить данные из профиля, перейдите в настройки и выберите соответствующую опцию для удаления информации.
Настройки уведомлений доступны в разделе «Уведомления», где вы можете включить или отключить нужные события.
Да, в настройках конфиденциальности вы можете установить профиль как приватный, ограничив доступ неавторизованным пользователям.
Чтобы восстановить доступ, используйте функцию «Забыли пароль?» на странице входа и следуйте инструкциям для сброса пароля.
Ограничений на количество друзей может не быть, но могут существовать лимиты для подписчиков в зависимости от политики приложения.
Чтобы заблокировать пользователя, перейдите на его страницу и выберите опцию «Заблокировать». Аналогично, в разделе «Заблокированные пользователи» можно разблокировать его.
С вашего профиля вы можете публиковать посты, отправлять сообщения, комментировать и ставить «лайки».
История действия может храниться разное время, обычно это указывается в настройках конфиденциальности или политики хранения данных.
Да, вы можете экспортировать данные профиля через настройки в разделе «Экспорт данных».
При удалении учетной записи все связанные данные будут стерты через 30 дней после подтверждения удаления.
Рекомендуется использовать сложные пароли и регулярно менять их, чтобы обеспечить безопасность профиля.
Да, двухфакторная аутентификация может быть активирована в разделе «Безопасность аккаунта».
Вы можете связаться с поддержкой через форму обратной связи на сайте или по электронной почте, указанной в разделе «Поддержка».
Еще хранение вопросов на отдельной странице дает больше возможностей для контроля на стороне тестирования: аналитик может пообещать внести изменения по каким‑либо ответам и забыть про это. При работе со списками такое сложно зафиксировать, как следствие, легко пропустить. С описанным шаблоном вы можете внести ответ самостоятельно, указав дополнительные сведения, например, автора ответа.
Возможность связывать вопросы при использовании шаблона с другими объектами пространства тестовой документации упрощает работу с комплексной информацией. Без связей указание на отсутствие недостающих сведений может дублироваться в списке вопросов, в шагах тест‑кейса, в чек‑листе, в скриптах. В этом случае при получении ответов необходимо помнить обо всех местах, куда нужно внести обновления. Если новая информация добавлена, например, к списку вопросов и в тест‑кейсы, но не добавлена в чек‑лист и в скрипты, — нарушается целостность системы тестовой документации. Это приводит к дополнительным трудозатратам. А мы стремимся поддерживать тестовую документацию в актуальном состоянии. И это не самоцель — как упоминал ранее, система, которую составляют наши тестовые артефакты, позволяет нам эффективно работать с объектами тестирования, в том числе со сложными.
Информация
На этой странице прежде всего в разделе Связи формируется список ссылок на документацию по тестируемой функциональности: HLD, LLD, ТЗ, код, макеты.
Сюда же можно добавить «ToDo», если по каким‑либо причинам доработки тестовой документации нет возможности зафиксировать в системе ведения задач. А также раздел «Сведения» с информацией, которая может упростить понимание объекта тестирования. Еще здесь полезно указывать логику формирования ключа, например:
Ключ SMRT образован от слова smartphone.
В «Информацию» можно добавить подстраницы со сведениями по работе со сложными функциональностями. Например, я пользуюсь ими при тестировании алгоритма для решения оптимизационных задач. По нему нет документации, и из‑за нехватки ресурсов её пока нет возможности описать, поэтому я составил подстраницы «OPT. Таблицы», где описаны таблицы БД, используемые оптимизатором, «OPT. Входные параметры», и «OPT. Логика». Эту информацию я брал из кода, после чего проверял её корректность путем сравнения описанных сведений и результатов наблюдений за работой алгоритма. Также я добавил такие подстраницы
Инструкция по созданию своих тестовых данных на основе существующих;
Промежуточный отчет по тестированию одной из доработок Оптимизатора;
Описанием способов обработки возникающих ошибок.
Проверки
Страница для хранения подстраниц, где содержатся артефакты тест‑дизайна: чек‑листы, таблицы с проверками, таблицы принятия решений, диаграммы переходов и состояний. На основе этих артефактов составляются тестовые данные, которые хранятся на отдельной странице. Пункты проверок можно связывать с шагами и таким образом их переиспользовать — примеры этого описаны в разделах «Данные запросов и сообщений для интеграционного тестирования» и «Использование артефактов тест‑дизайна в шагах» (во 2-й части: Сила связей в ручном тестировании. Часть 2: Связываем тест-кейсы с wiki-страницами). Вот еще пример:
Таблица проверок
Возможность связывания артефактов тест‑дизайна с другими объектами является весомым аргументом для публикации этих артефактов в Wiki вместо их локального хранения. Описанные проверки таким образом становятся частью системы тестовой документации и периодически используются. Без публикации артефакты тест‑дизайна, как и, например, ответы на вопросы по‑прежнему оказывают значительное влияние на тест‑кейсы. Это говорит о наличии связей, но без явного их описания — наличие таких связей и их роль не всегда осознается в полной мере, что приводит к сложностям при взаимодействии с тестовой документации. Эти сложности могут возникать не только у коллег, но и у самого автора.
ТД
ТД — сокращение от словосочетания «тестовые данные». В нашей интерпретации эта страница содержит в себе подстраницы «SQL», «REST», «Kafka» и «Входные параметры». Для одной из функциональностей еще была «UI», где я описывал ожидаемые UI‑элементы, но эта подстраница пока осталась на стадии экспериментов.
С учетом того, что тестовые данные в описываемом подходе хранятся в Wiki, — появляется возможность их связывать. Удобство использования связей в данном случае легче всего проиллюстрировать на SQL‑запросах — если есть скрипт для добавления ТД, то вместе с ним ожидается и скрипт, который будет эти ТД очищать:
Когда ТД описаны в Wiki, появляется еще одна возможность — добавлять справочную информацию в разделе «Сведения»:
Вместо SQL‑запросов в «Коде», соответственно, могут быть описаны json'ы для kafka‑сообщений и тел http‑запросов. Также вместо «Кода» может быть и таблица, как в случае с входными параметрами, в которой описаны используемые наборы значений.
При описании полезной нагрузки в интеграционном тестировании мы часто используем наследование:
Небольшая таблица с проверками, если в примере выше нужно больше контекста:
Страница с ТД может иметь и более сложную структуру. Например, я составил страницу для генерации тестовых данных на основе существующих данных в БД. В ней используются 7 типов связей, есть разделы «Сведения», «Шаги для клонирования данных» и «Примечания», а раздел «Код» разбит на 3 части: SQL‑запрос для формирования временных таблиц с обогащенными текущими данными, SQL‑запрос для формирования модифицированных данных и набор регулярных выражений для постобработки. Такая страница подтверждает тезис о том, что описываемый подход не только позволяет упростить работу с тестовой документацией и сделать её более удобной — без информации на этой странице мы бы вообще не могли достичь нормального покрытия тестами для оптимизатора. К сожалению, показать эту страницу по понятным причинам не могу. Но такой пример ценен с учетом того, что это — реальный случай.
Доработки
Подстраница, добавляемая в корневую страницу тестируемой функциональности. Содержит в себе отдельные корневые страницы доработок, в названии которых используется отдельный ключ. Например, если для алгоритма прогнозирования цен задать ключ FPA (Forecast Price Algorithm), то доработка, в рамках которой подразумевается добавление параметров для указания разных таблиц (вместо фиксированного набора таблиц), с которыми будет работать алгоритм, может иметь ключ FPA_PCT (PCT — Parameter Change Table). Корневая страница доработки имеет описанные выше дочерки: «Информация», «Вопросы», «Проверки» и «Тестовые данные». Выглядит это так:
Конструктор
Есть информация, актуальная для всех тестируемых функциональностей. Шаблоны SQL-запросов, SQL‑запросы для получения полезных метаданных или для генерации данных под таблицы, которые связаны с несколькими функциональностями приложения, справочная информация по выполнению скриптов. Выше в примерах вы уже могли видеть упоминание о таких универсальных объектах в «Связях»:
Подобную информацию мы храним на отдельной странице с названием «Конструктор» (CON). В нашем случае это в основном код на SQL и связанные с этим кодом сведения. Есть также страница с описанием идеи простого проверочного запроса (CHECK SIMPLE), код которого реализуется по‑разному в зависимости от контекста:
Вполне возможно, что у вас на проекте не используется SQL. Вместе с тем, полагаю, логична мысль: если у вас есть системы тестовой документации со связанными тестовыми артефактами, каждая из которых посвящена отдельной тестируемой функциональности, то наверняка найдется информация, актуальная для каждой из этих систем. Эту мысль можно проиллюстрировать одной из ранее использованных схем:
Еще пара идей страниц, которые можно хранить в «Конструкторе», — это «Библиотека связей», которую я ранее упоминал, и «Шаблон вопросов».
Дополнительные разделы
Помимо перечисленных ранее страниц («Вопросы», «Информация», «ТД» и т. д.), структуру можно расширить и иными разделами. Например, полезна для публикации информация о встречах. Но в нашем случае процессы разработки сложились таким образом, что мы к этой информации обращаемся редко, поэтому ведем её локально.
Несмотря на то, что описываемый подход гибок, полагаю, важно помнить, что каждый элемент системы должен выполнять какую‑либо полезную функцию. По этой причине следует избегать создания лишних объектов. Здесь можно позаимствовать еще один принцип программирования — YAGNI — с некоторой адаптацией под текущий контекст: не следует усложнять структуру без необходимости. Вместе с тем ко многим описываемым практикам мы пришли не сразу, а спустя несколько итераций. Поэтому и эксперименты могут принести пользу, если соблюдать разумный баланс между исследованиями потенциальных возможностей упрощения своей работы без потери качества и сохранением текущей эффективности решения повседневных задач с использованием привычных, уже сложившихся подходов.
Послесловие
Идеясвязей является неотъемлемой частью разработки. Наиболее популярный и используемый подход (парадигма), ООП, во многом строится на описании правил взаимодействия классов и объектов друг с другом. Связи также неотъемлемая часть схем и диаграмм, которые формируют аналитики, а масштабируемые приложения сегодня обычно проектируются по микросервисной архитектуре, где логика обработки данных распределена по сервисам, связанным между собой. По моим наблюдениям, идея связей в ручном тестировании не используется столь же повсеместно, как в соседних областях IT. В этой статье я постарался описать, какие преимущества мы можем получить в тестировании, если расширим свой майндсет этой идеей.
Думаю, и TMS было бы неплохо проектировать с учетом удобства использования связей. Мне кажется странным, что в тест‑кейсах наличие предусловий является чем‑то само собой разумеющимся, а отдельный блок для постусловий зачастую отсутствует. Для обеспечения воспроизводимости тест‑кейсов мы готовим наборы тестовых данных. И затем обращаемся к этим данным через предусловия, добавляя их в БД. Если у нас отсутствует постусловие по очистке ТД после прогона тест‑кейса, то БД со временем будет «замусориваться». Это, как минимум, сопряжено с возникновением неудобств, которых можно избежать. В Xray мы добавляем постусловия через отдельные тест‑кейсы, вызываемые с помощью функции Call Test, но это, соответственно, костыль. Также в Xray нет возможности задать однократное выполнение предусловий при прогоне тестового набора. В Test Execution по каждому тест‑кейсу всегда нужно проходить все предусловия, но это далеко не всегда требуется:
Вот еще аргумент к тому что при разработке TMS связям не всегда уделяется должное внимание: в Xray ссылки в Test Execution на страницы Wiki подтягиваются, а названия страниц — нет:
Было бы интересно посмотреть и на реализацию наследования текста из Wiki в поля тест-кейса. Но я такого тоже нигде не видел:
И на реализацию подстановки кода в предусловие в зависимости от страницы, заданной в блоке ссылок тест-кейса:
Хотелось бы посмотреть на реализацию работы с тест-кейсами в других TMS. Я ранее работал с Kiwi и с TestRail, но уже мало что помню оттуда. Доступ без танцев с бубнами сейчас к этим инструментам по понятным причинам отсутствует. А в одной из небезызвестных российских TMS я не смог зарегистрироваться и пройти аутентификацию. :/Поэтому в статье ограничивался упоминанием Xray и использовал Obsidian для иллюстраций идей.
Писал эту статью я тоже в Obsidian. Напоследок оставлю скриншот, как она выглядит в Graph View:
