Умелые ручки: собираем тест-кейсы как конструктор
Каждый проект имеет свою специфику, и правильно подобранный подход к написанию тестовой документации — залог качества и скорости выпуска проекта. В этой статье расскажем вам, как и почему на одном из наших проектов родился и прижился конструктор тест-кейсов, как мы его используем и в чем его преимущество.
Откуда родилась идея конструктора тест-кейсов
Наш проект представляет собой Платформу, которая используется как основа для разработки прикладных Приложений для промышленных предприятий.
Приложения автоматизируют процессы на разных уровнях: само производство, логистика, документооборот, бухгалтерия и т. д. Они сходны друг с другом по структуре, что позволяет использовать в их основе шаблонное решение, которое настраивается под нужды конкретного процесса на предприятии.
Платформа состоит из библиотек и сервисов. Основной компонент — это таблица с различными настройками и элементами. Также туда входят сервис авторизации, лаунчер, хранилище файлов и т. д.
Прикладники берут этот набор и на его основе собирают своё Приложение. Платформа даёт возможность гибкой настройки. Если каких-то настроек или частей Платформы не хватает для реализации функциональности Приложения, то прикладник делает заявку на реализацию недостающих элементов, они создаются командой Платформы и передаются прикладнику.
Для тестирования Платформы был разработан специальный «тестовый» проект, который включает в себя всю ее функциональность с максимально возможными настройками. Благодаря этому можно охватить часть комбинаций функциональности, реализуемой и в Приложениях.
Проект разделен на модули, покрывающие различные сценарии использования частей Платформы (Рис. 1).
Модули имеют повторяющиеся части функциональности. Соответственно, нет необходимости проверять всю функциональность каждого модуля. Например, для проверки базового функционала CRUD-операций компонента «Таблица» достаточно это сделать для модуля со всеми возможными типами колонок, плоской и иерархической таблицей.
Написание тест-кейсов на уровне Платформы (не говоря уже о Приложениях на её базе) требовало какого-то решения, позволяющего использовать общую описанную функциональность. Тогда родилась идея устроить написание тестовой документации аналогично разработке — разбить функциональность по частям, описать эти части и использовать их в тест-кейсах.
Процесс внедрения конструктора
Теперь было необходимо придумать:
1. как организовать разбиение функциональности на части так, чтобы их можно было использовать как для Платформы, так и для любого Приложения, и
2. как это оформить в нашей системе управления тестами.
Со вторым пунктом все был просто: мы используем Test IT, который позволяет реализовать данный подход с помощью Общих шагов. Общий шаг в Test IT может создаваться на любом уровне (как чек-листы и тест-кейсы) и добавляться как шаг в тест-кейсы.
Оставалось придумать, как мы будем создавать эти Общие шаги. Сложность состояла в том, чтобы поделить функциональность системы на атомарные элементы так, чтобы каждый элемент был достаточен для проверки кусочка функциональности и при этом не был избыточен. А мы помним, что компоненты Платформы в Приложениях могут применяться в разных комбинациях и с разными настройками. В итоге в некоторых Приложениях покрытие одной части функциональности требовало нескольких Общих шагов, что делало сборку тест-кейса несколько сложнее.
Какое-то время у нас, конечно, ушло на отработку подхода. Но теперь ясно, какой атомарности требуют Общие шаги, и их написание уже не занимает много времени и практически не требует корректировки в процессе использования.
Использование подхода. Практические рекомендации
Рассмотрим подход на примере операции добавления записи в таблицу.
Данная операция может быть выполнена различными способами (Рис. 2):
1. через кнопку «Добавить» на тулбаре,
2. через опцию «Добавить» контекстного меню,
3. через кнопку «Добавить» в служебной колонке таблицы.
Но результат один: открывается диалог «Добавление записи».
Общий шаг на добавление записи показан в Таблице 1:
Действие | Ожидаемый результат | |
1 | Откройте диалог Добавления, используя все возможные способы. | — диалог Добавления закрыт |
2 | Откройте диалог Добавления, используя все возможные способы. | — диалог Добавления открыт |
3 | Откройте диалог Добавления, используя все возможные способы. | — диалог Добавления закрыт |
4 | Откройте диалог Добавления, используя все возможные способы. | — диалог Добавления закрыт |
Для того чтобы в дальнейшем упростить использование Общего шага, необходимо сделать его описание:
1. Описание сценариев тестирования Проверка: — сохранения новой записи со значениями в обязательных полях, — валидации обязательных полей на сохранение при добавлении записи, — сохранения новой записи со значениями во всех полях, — отмены добавления записи. 2. Что требуется дописать в тест-кейсах с учетом специфики в конкретном модуле Проверка названия, состава полей и вида диалога «Добавление записи» должны быть вынесены в отдельный тест-кейс для конкретной таблицы. 3. Как использовать Общий шаг Перед этим Общим шагом в тест-кейсах использовать шаг, в котором будет описываться, через какой элемент открывается диалог добавления. Шаг: Нажмите ЛКМ на: — кнопку «Добавить» тулбара таблицы, — опцию «Добавить» контекстного меню, — кнопку «Добавить» в служебной колонке. Ожидаемый результат: — открыт диалог «Добавление записи». |
Сейчас для покрытия функциональности «Добавление записи» используется следующий список Общих шагов:
детальный общий шаг (Рис. 3),
smoke общий шаг (Рис. 4),
детальный общий шаг для случая с использованием выбора записей чекбоксами (Рис. 5).
Пример использования Общего шага с «Добавлением записи» в конкретном тест-кейсе для одного из прикладных приложений показан на Рис. 6.
Как видно из этого примера, при создание тест-кейса для проверки добавления в этом модуле используются два Общих шага: «детальный общий шаг» и «детальный общий шаг с использованием чекбоксов», так как в таблице данного модуля есть колонка с чекбоксами для выбора записей. Также перед Общим шагом «Добавление записи» указано, каким образом можно открыть диалог добавления, чтобы проверить последующие шаги Общего шага.
Пример для smoke тест-кейса модуля «Типы документов» приведён на Рис. 7.
Так же как и для детального тест-кейса, создан шаг с описанием, как открыть диалог «Добавление записи» в конкретном модуле. А далее идет «Smoke общий шаг».
Преимущество подхода
Главным преимуществом использования данного подхода является экономия времени на написание тест-кейсов. Это даже больше касается написания тест-кейсов в проектах Приложений. Чтобы была возможность использовать Общие шаги в ряде проектов в Test IT создан один большой Проект, в котором секциями выступают Платформа и Приложения. Прикладникам остаётся только собрать Общие шаги в нужном составе и порядке и указать в тест-кейсах специфику работы данной функциональности в их Приложении.
Второе преимущество данного подхода — удобство поддержания тест-кейсов. Изменение сценариев работы в Общих шагах Платформы сразу применяется во всех тест-кейсах с этими Общими шагами. Изменения помечаются версией Платформы в Общем шаге, пока все прикладные проекты не перейдут на последнюю версию Платформы с этими изменениями.
Подход с конструктором тест-кейсов хорошо ложится и на процесс написания автотестов, в котором также создаются Общие шаги отдельными классами, а сами автотесты используют данные классы. Для упрощения работы мы вынесли эти классы (Общие шаги) в отдельную библиотеку.
Заключение
Конструктор тест-кейсов подходит платформенным проектам, компоненты которых используются в прикладных приложениях.
Конструктор тест-кейсов предполагает набор компонент — общих шагов, каждый из которых описывает один максимально обособленный функциональный элемент. На основе этих общих шагов можно описать работу любого прикладного приложения на базе Платформы, которое использует частичный или полный набор её функциональных элементов.
Данный подход помогает сократить время на написание и поддержание тест-кейсов и сделать процесс написание тестовой документации более увлекательным и интересным, превращая его в логическую головоломку.
