Привет.
Статья получилась объемной, поэтому я разделил её на 3 части «Оглавление» будет дополняться вместе с публикацией материала.
Оглавление
-
Часть 1: Формулируем подход для решения сложных задач
Стоит ли вам читать эту статью?
Во-первых, несмотря на то, что в статье описан целостный подход к работе с тестовой документацией, - вам необязательно заимствовать его целиком. Здесь есть множество, на мой взгляд, интересных идей. Поэтому и к материалу вы можете отнестись как к сборнику лайфхаков, которые можно попробовать внедрить в свою работу. Может быть и так, что вы возьмете описанные идеи за основу, вдохновитесь и придумаете что-то свое.
Во-вторых, описанный подход ценен тем, что, по моему опыту и опыту моих коллег, он приносит практическую пользу в повседневной работе. Иначе говоря, это не просто гипотезы, висящие в воздухе, и само использование подхода - не самоцель.
В-третьих, ниже приведу несколько цитат из статьи. Тизерну, так сказать.
Таким образом, раздел "Код" в сочетании с использованием связей дает возможность использовать повсеместную частичную автоматизацию в ручном тестировании. С минимальными требованиям к навыкам программирования и без необходимости работы с фреймворками АТ. Хотя, если у вас все же используется такой фреймворк, по нашему опыту, скрипты могут сильно упростить работу автоматизатору. А свои первые шаги в автоматизации можно делать с помощью нейросетей. Собственно, я так и изучил SQL: у меня возникали вопросы, я писал промты, получал ответы, использовал полученные знания.
Тем временем привязанная к тест-кейсам таблица с описанием проверок дает значительно больше контекста по объекту тестирования. Это упрощает работу, что, в свою очередь, приводит к экономии ресурсов. Автору тест-кейса, который составил описанный выше http-запрос, вполне может через некоторое время прийти задача на расширение тестового набора в связи, например, с доработками по связанной функциональности. И если в рамках этой активности необходимо будет править тело запроса, то без артефакта тест-дизайна сделать это будет затруднительно. Особенно по прошествии времени, после переключения на другие задачи.
Вместе с тем мы на проекте заметили, что обычно результат работы типичной задачи по написанию тестовой документации - это тест-кейсы. Их составление и публикация. При этом подготовка тестовых данных и их описание на отдельной странице - остается на усмотрение тестировщика. Артефакты тест-дизайна, в частности, чек-листы обычно воспринимаются как драфт для тест-кейсов и зачастую не публикуются. Однако и тестовые данные, и чек-листы, опубликованные в пространстве тестирования, по опыту нашей команды на текущем проекте, помогает сократить время на поддерживаемость тестовой документации и создать более полный контекст об объекте тестирования.
Нет, здесь хранится не просто текст с использованием нумерованного списка. Каждый вопрос на странице - отдельный объект с атрибутами, которые вы определяете сами. Это упрощает работу, что особенно ощутимо при существенном недостатке информации.
Несмотря на то, что описываемый подход гибок, полагаю, важно помнить, что каждый элемент системы должен выполнять какую-либо полезную функцию. По этой причине следует избегать создания лишних объектов. Здесь можно позаимствовать еще один принцип программирования - YAGNI - с некоторой адаптацией под текущий контекст: не следует усложнять структуру без необходимости. Вместе с тем ко многим описываемым практикам мы пришли не сразу, а спустя несколько итераций. Поэтому и эксперименты могут принести пользу, если соблюдать разумный баланс между исследованиями потенциальных возможностей упрощения своей работы без потери качества и сохранением текущей эффективности решения повседневных задач с использованием привычных, уже сложившихся подходов.
В-четвертых, большое количество слов в статье, начиная со 2-й части, щедро разбавлено схемами, скриншотами, таблицами, списками и кодом на SQL.
В некоторых местах я использую термин "объект". Под ним подразумевается все, что связано с тестовой документацией с учетом контекста в предложении: предусловия, постусловия, тест-кейсы, тестовые данные, страницы в корпоративной wiki, чек-листы, таблицы с проверками и т.д. При этом словосочетание "объект тестирования" имеет тот же смысл, как он сформулирован в ISTQB.
Иногда в тексте я использую местоимение "мы" и его разные склонения. Над подходом я работал не в одиночку. Выдвижение гипотез, их проверка экспериментами, обсуждение результатов, внедрение подхода в повседневную работу, корректировки - все это я делал совместно со своим лидом, опытным коллегой и коллегой, который был на стажировке, и за это время успел стать частью команды. Сердечно благодарен им за совместную работу. ❤️
Ладно. Заканчиваю с прелюдией и лирикой. Поехали.
Контекст
В августе 23-го года я присоединился к команде тестирования на проекте по разработке аналога SAP'а. Это web-приложение, которое содержит, помимо платформенной части, алгоритмы для прогнозирования и решения задач оптимизации. В основном я занимаюсь тестированием таких алгоритмов. И большую часть времени провожу на backend'е.
В ходе работы я сталкиваюсь со специфическими сложностями:
Некоторые алгоритмы в системе - это готовые решения, по которым отсутствует документация. Возможности тестирования "методом черного ящика" в таком случае ограничены. Нам изначально неизвестны источники данных, с которыми работают подобные алгоритмы. И нам неизвестна их логика. Привлечение аналитиков для написания документации запланировано в будущем, а результаты тестирования нужны уже сейчас. Сложности особенно ощутимы при работе с алгоритмом для решения оптимизационных задач, который забирает данные из большого количества таблиц и выполняет большое количество преобразований данных;
Для тестирования алгоритмов нужна подготовка тестовых данных. В некоторых случаях датасеты для проверок суммарно содержат более тысячи записей. Такое же количество данных алгоритм может вернуть на выходе, распределяя их по нескольким таблицам, каждая из которых может иметь более десятка столбцов. Исключительно ручные проверки в данном случае приводят к тому, что либо на тестирование тратится большое количество времени, либо полнота покрытия остается недостаточной;
Тест-кейсы по алгоритмам должны быть предельно понятны и воспроизводимы. В том числе потому, что по ним согласовывается отчет сторонней командой ручных тестировщиков;
Аналитики описывают таблицы с примерами расчетов, на основе которых мы формируем тестовые данные для подготовки перед тестированием. Однако зачастую эти расчеты нужно самостоятельно дополнять по аналогии с описанными примерами, чтобы покрыть проверки по чек-листу. В результате возникает необходимость хранения нескольких разных версий файлов с указанием комментариев, чтобы не запутаться;
При тестировании алгоритмов мы собираем много информации. Набор таблиц, их атрибутивный состав, структура метаданных, общие требования к алгоритмам, требования к конкретному алгоритму, вопросы, артефакты тест-дизайна, договоренности, результаты которых какое-то время нет в документации до их внесения, результаты встреч и еще много всякого разного. Все это необходимо собирать и обрабатывать при работе с такими комплексными объектами тестирования. Но хранить собранную информацию мало - её нужно структурировать таким образом, чтобы с ней было удобно работать, и чтобы она приносила реальную пользу. Иначе сбор сведений превращается в самоцель.
Сегодня тестирование алгоритмов - это по-прежнему нетривиальная задача. На ранних этапах разработки, с учетом описанных трудностей, всей нашей команде тестирования это казалось чем-то невозможным. Тем не менее мы нашли способы выполнять такую работу, и сейчас у нас уже есть несколько закрытых протоколов тестирования. В статье я расскажу о подходе, который нам удалось выработать в процессе решения непростых рабочих задач. Он подразумевает выстраивание системы тестовой документации, где тестовые артефакты связаны между собой, а способы их связывания заимствованы из принципов ООП и zettelkasten'а.
Технологии и инструменты, которые будут упоминаться в статье:
SQL;
PostgreSQL;
DBeaver;
json'ы в телах http-запросов;
Jira + Confluence;
Xray (TMS, плагин для Jira);
Obsidian.
Описываемый подход довольно гибок, поэтому его вполне можно внедрить и при использовании других инструментов.
Суть подхода
Обычно вся информация для тестирования той или иной функциональности описана в тест-кейсах. Очевидно, что шаги воспроизведения должны быть выполнимы любым заинтересованным лицом. На практике достичь этого не так просто, как кажется. Сделать воспроизводимыми тест-кейсы, предназначенные для проверки комплексных объектов тестирования, - целое искусство. Зачастую с этим возникают сложности:
Информации для воспроизведения - недостаточно. В этом случае тестировщик, выполняющий прогон тест-кейса, вынужден искать дополнительные сведения для прохождения шагов. Затраты времени в этом случае особенно велики, если автор тестового набора ушел с проекта и не оставил никакой справочной информации;
Информации для воспроизведения - избыточно много. Такие тест-кейсы сложно поддерживать. Экземпляры одних и тех же сведений используются в разных местах. Их суть всегда сохраняется, иногда меняется форма. Пример такого явления: перечисление одних и тех же предварительных действий перед воспроизведением в описании тест-кейса вместо использования специальной функции TMS, которая позволяет описывать предусловия в отдельных объектах;
Информация для воспроизведения - не структурирована. Признак этого - отсутствие композиции тестовых артефактов, в результате чего появляются "разбухшие" от информации тест-кейсы, где хранятся и скрипты, и ссылки, и чек-листы, и вопросы, и еще много всякого. Обычно отсутствие структуры связано с тем, что каждый тестировщик сам принимает решение, какие сведения указывать в тест-кейсе, и как их описывать. В таком случае качество тестовой документации становится непостоянным, а в её оформлении отсутствует единообразие;
К информации для воспроизведения затруднен доступ. В корпоративной wiki, в пространстве тестирования, может храниться полезная справочная информация, но о её существовании обычно узнают от автора страницы. Иногда она может вовсе затеряться и вследствие этого не принести пользы, что обидно с учетом потраченного времени на её оформление.
Основная идея подхода, который помогает нам справляться с описанными выше сложностями: привязка страницы корпоративной wiki с информацией по тестируемой функциональности к каждому тест-кейсу. Такая страница поддерживается тестировщиком и имеет строго определенную структуру из дочерних страниц:
Вопросы;
Доработки (опционально: когда они появляются);
Информация;
Проверки;
ТД (тестовые данные).
Это единый шаблон для хранения информации, который не зависит от тестируемой функциональности. Упомянутые дочерние страницы хранят свои дочерки, явно связанные между собой ссылками. Это позволяет структурировать информацию атомарно: каждая страница содержит ровно столько сведений, сколько того требует контекст. Если нужно больше - можно перейти по указанным ссылкам. В этом подход чем-то напоминает Википедию. При этом в дочерних страницах шаблона часто используются универсальные разделы - "Связи" и "Сведения".
Описание подхода начну с объяснения, зачем связывать тест-кейсы со страницами в корпоративной wiki.
Эффект использования подхода на примере подготовки тестовых данных
Рассмотрим пример. Предположим, у нас есть база данных smartphones в СУБД типа SQL. В ней, в дефолтной схеме, есть таблица models с 3-мя столбцами: id, name и manufacturer:
Данные из этой таблицы передаются через бэкенд-сервис на фронт и отображаются на странице "Модели" (без id):
Предположим, нам нужно проверить, что данные из таблицы действительно передаются на фронт. Во время выполнения тест-кейса, который содержит такую проверку, в таблице models могут храниться любые произвольные записи. Их также может не быть вовсе, как на скриншоте выше, и тогда проверка будет недостоверной. Или записей может быть очень много - в этом случае сложно будет найти те, которые, например, нужны для проверки валидации наибольшего количества символов в полях.
Чтобы обеспечить воспроизводимость тест-кейса, необходимо добавить предусловие по подготовке тестовых данных перед прогоном. Рассмотрим поэтапно различные варианты составления такого предусловия: будем двигаться, начиная с наименее удачного варианта.
Добавить тестовые данные в таблицу "Модели".
Слишком абстрактно. Непонятно, как нужно добавить тестовые данные.
Добавить тестовые данные в таблицу "Модели" через панель администратора.
Уже лучше. Но при тестировании просмотра страницы нужно проверить пагинацию, а для этого требуется, скажем, 21 запись. Добавление данных через UI может занять несколько минут. В этом случае также возможно срабатывание человеческого фактора, в результате чего датасет для тестирования будет не таким, как ожидается. С учетом того, что в тест-кейсе, который мы рассматриваем, проверяется просмотр (READ по CRUD), а не добавление (CREATE по CRUD), - необязательно выполнять подготовку данных через UI. В текущем контексте есть более быстрый и стабильный способ.
Добавить тестовые данные в таблицу "Модели" с помощью SQL-запроса.
С помощью SQL-запроса можно добавить большое количество записей за доли секунд. К тому же INSERT-запрос будет содержать один и тот же набор данных, что также важно для обеспечения воспроизводимости. Однако создание подобного предусловия для каждого тест-кейса усложняет поддерживаемость.
Сделаем его универсальным.
Добавить тестовые данные с помощью SQL-запроса, который приложен к этому тест-кейсу в файле с фрагментом INSERT в названии.
Такое предусловие можно переиспользовать в различных тест-кейсах. Да, здесь следует отметить, если ваша TMS это позволяет (в большинстве TMS, с которыми я работал, есть такая функциональность). Мы на проекте используем Xray - плагин для Jira. В нем предусловия представлены в виде отдельного типа тикета - Pre-Condition, который можно прилинковать к тест-кейсам (в Xray - это тикет типа Test). Предусловия, как и в других TMS (где они есть), отображаются до шагов.
Переиспользование предусловий упрощает поддерживаемость, что в, свою очередь, позволяет экономить ресурсы. Остается решить, как прикрепить SQL-запрос к тест-кейсу. Есть несколько способов это сделать:
Добавить SQL-запрос к предусловию. Но с учетом того, что оно универсальное, и мы планируем его использовать во множестве тест-кейсов, этот вариант не годится. Да, иногда один и тот же код для подготовки тестовых данных может использоваться в нескольких тест-кейсах, и это хорошо. Но все же такие SQL-запросы зачастую будут отличаться друг от друга в разных тест-кейсах;
Описать SQL-запрос в одном из шагов. Этот способ противоречит логике тест-кейса: в шагах описаны действия, которые необходимо выполнить для проверки какой-либо части функциональности. Подготовка тестовых данных не является проверкой. Также текстовое поле шага может быть неудобным для работы с кодом;
Приложить к тест-кейсу файл с SQL-запросом. В большинстве TMS есть возможность прикладывать файлы. К каждому тест-кейсу можно приложить отдельный файл с кодом. Предусловие в этом случае остается универсальным, отпадает необходимость его клонирования.
Среди описанных способов использование файла для хранения SQL-запроса кажется наиболее оптимальным. Однако в этом случае мы не можем переиспользовать код. Вместо клонирования экземпляров предусловия - мы клонируем файл с запросом. В этом случае будущие изменения придется вносить в каждую копию файла. Это как раз пример усложнения поддерживаемости.
Рассмотрим еще один вариант.
Добавить тестовые данные, выполнив INSERT-запросы, которые указаны в разделе "Связи запроса".
По такому предусловию для подготовки тестовых данных используется SQL-запрос, который хранится на странице в корпоративной wiki. Мы на проекте используем Jira + Confluence. С учетом того, что тест-кейсы у нас - это тикеты Jira, мы используем раздел "Связи запроса". Там ссылки на wiki-страницу с кодом появляются автоматически, когда мы добавляем на такую wiki-страницу ссылку на тест-кейс. Получается двунаправленная связь. Да, далеко не на всех проектах используется софт Atlassian, особенно сейчас. Но, полагаю, в большинстве случаев создание таких связей - реализуемо. Например, если в тест-кейсе есть текстовое поле - туда можно добавить ссылку на wiki-страницу с SQL-кодом.
Пользуясь такой структурой для подготовки тестовых данных, мы создаем минимальное количество объектов и переиспользуем их максимальное количество раз.
У нас на проекте есть предусловие, которое прилинковано к 101-му тест-кейсу, и 4 wiki-страницы - по 1-му SQL-скрипту на каждой - которые используются в 30+ тест-кейсах. Экономия времени в случае необходимости внесения изменений - колоссальна. Это особенно ощутимо на ранней стадии динамического тестирования разрабатываемой функциональности. Наличие таких связи позволяет, в случае необходимости, редактировать 1 предусловие вместо 101-го и 4 скрипта вместо ~120-ти.
Кстати, почему бы не линковать к тест-кейсам wiki-страницу, где расположен файл с кодом, а не сам код? Сравните последовательность действий:
Код в специальном блоке
Перейти на wiki-страницу;
Скопировать код;
Вставить код в СУБД-клиент;
...
Код в файле
Перейти на Wiki-страницу;
Скачать файл;
Открыть файл;
Скопировать код;
Вставить код в СУБД-клиент;
...
На 2 шага меньше при работе непосредственно с кодом на странице. Следовательно, затраты времени на рутинные действия немного ниже. Плюс, файлы копятся в папке с загрузками, и её в этом случае нужно периодически чистить. Экономия небольшая, но на длинной дистанции - ощутимая. В Confluence есть специальный макрос Code Block. Он подсвечивает синтаксис кода и позволяет выделить его целиком по двойному клику. Думаю, в большинстве корпоративных wiki есть аналогичный инструмент форматирования.
Еще одно неочевидное преимущество описания кода на странице в wiki - ведение истории изменений. При необходимости можно просмотреть предыдущие версии скрипта. Впрочем, эта удобная функция распространяется на все документы в wiki. В Xray изменения в тест-кейсах тоже фиксируются, т.к. фактически это тикет типа Test, но в Jira их просмотр не так удобен, как в Confluence. Отдельные экземпляры тест-кейсов после внесения изменений в нашей версии плагина также не сохраняются. Следовательно, нет и возможности откатить их одним действием, зато такая функция обычно есть в корпоративных wiki.
Для описания примера я использовал язык SQL. Сейчас для нашей команды тестирования это наиболее подходящий инструмент для автоматизации бэкендовых тест-кейсов. Но для рутинных активностей, в частности, подготовки тестовых данных, можно использовать и другие удобные для вас инструменты.
Продолжение - в следующих частях.