В этой статье мы рассмотрим работу с тестовой документацией при постановке процесса тестирования программного обеспечения. Материал собран исходя из опыта работы на различных проектах и того, с какими сложностями приходилось сталкиваться. Но вначале хочу сделать краткое отступление, которое касается тестовой стратегии, поскольку перед началом разработки тестовых документов должны быть четко определены границы тестирования.
Подготовительные работы
Прежде чем приступить к построению процесса, необходимо определить функциональность системы, которая будет тестироваться. В большинстве случаев для не слишком масштабных проектов существует высокая вероятность тестирования всего, что будет разработано, но в более крупных проектах мы можем столкнуться с ограничениями: определенная функциональность может проверяться другой командой или сторонней компанией, также в некоторых случаях мы можем использовать временные сервисы-заглушки, которые не будут использоваться в проде, следовательно, не будет необходимости тестировать их, для таких случаев мы, вероятно, должны будем проверить только интеграцию, также некоторые модули могут быть протестированы исключительно по запросу клиента.
Итак, когда функциональность, подлежащая тестированию, определена, мы можем перейти к определению видов и глубины тестирования. Для этого можно использовать контрольный список с видами тестирования, выделив те, которые должны проводиться. Виды тестирования, которые не будут проводиться, также стоит выделить и обосновать причины отказа от них. Например, при разработке MVP стадии B2B приложения мы, скорее отдадим предпочтение тестированию скорости и надежности, чем тестированию дизайна со всеми полями, шрифтами и цветами, но не во всех случаях — всегда помним, что в первую очередь мы смотрим на потребности клиента. Определившись с типами тестирования, следует выбрать и обосновать глубину тестирования. Не каждый раз нам потребуется расширенное тестирование. В случае, когда для нас важна скорость, скорее всего, придется ограничиться Smoke тестированием. Но это редкий кейс. Как правило, в каждом серьезном проекте проводится тестирование критического пути, а расширенным для ускорения доставки иногда можно пренебречь. На этом этапе важно договориться о том, следует ли готовить тестовую документацию для всех уровней или только для определенных. Перейдем к тестовой документации.
Выбор тестовой документации
Два наиболее распространенных варианта — чек-листы и тест-кейсы. Нужно определить, какой из них подходит для проекта в зависимости от его сложности, продолжительности, стабильности и других факторов. Если по каким-то причинам использование тест-кейсов или чек-листов не является оптимальным, можно разработать кастомные варианты тестовой документации. Также стоит отметить, что можно комбинировать несколько вариантов, в этом случае необходимо определить условия, при которых будет использоваться тот или иной тип документов.
Организация работы с тестовой документацией
Определив виды и глубину тестирования, а также тип тестовой документации, переходим к организации модификации и хранения. Необходимо подготовить место для хранения. Это может быть один из следующих вариантов:
платная или бесплатная система управления тестированием (TMS);
удаленный репозиторий;
расшаренная сетевая папка;
расшаренная коллекция тестов в инструментах тестирования (например, Postman);
общедоступный google doc;
другие инструменты.
Место хранения должно быть выбрано на основе имеющихся ресурсов и потребностей, важно учитывать, что каждая заинтересованная сторона должна иметь доступ к тестовой документации, но в то же время мы должны быть уверены, что безопасность обеспечена ограничением доступа для третьих лиц.
Далее следует определить необходимость и частоту бэкапов документации, кто и когда должен заниматься этой деятельностью. Если не определить ответственное лицо, сроки и/или триггеры для резервного копирования, то в какой-то момент команда может остаться без тестовой документации, например, в случае сбоя сервиса хранения или проблем с потерей данных.
Подготовительные работы выполнены. Теперь настало время организовать процесс разработки тестовой документации. Для этого хорошей практикой будет предоставление всем участникам команды тестирования шаблона документа. При подготовке шаблона помните о следующем:
зафиксируйте назначение документа (можно указать название, краткое описание, целевую аудиторию и т.д.);
зафиксируйте все необходимые обозначения в легенде документа (например, статусы выполнения теста, названия модулей и т.д.);
зафиксируйте ссылки на спецификацию функциональности, для которой разрабатывается тестовый документ;
определите обязательные и необязательные атрибуты;
определите причины заполнения необязательных атрибутов;
определите список статусов прохождения тестов;
при необходимости определите список приоритетов, а также список возможных значений других атрибутов.
Шаблон должен разрабатываться с учетом специфики каждого конкретного проекта, а также может быть расширен, сокращен или модифицирован для определенной функциональности, для тестирования которой, лучше использовать другие атрибуты.
Теперь, когда команда тестирования приступает к разработке тестовой документации, не забывайте обращать внимание на следующие аспекты:
грамотность формулировок: названия элементов пользовательского интерфейса, действий системы и пользователя должны соответствовать названиям в спецификации; необходимо следить за краткостью, однозначностью, точностью формулировок;
декомпозиция тестов: тесты должны быть структурированными и последовательными;
простота восприятия и возможность быстро найти нужный тест: следует использовать инструменты для простой визуализации, разбиение на компоненты и действия, четкую структуру, фильтрацию, поиск, группировки, форматирование и т.д.;
подготовка тестовых данных;
избегание копипаста: путем осмысления и переработки информации из спецификации избегаем копирования требований в тестовые документы, а копирования одинаковых тестов, используемых в разных модулях системы, избегаем путем вынесения повторяющихся тестов в отдельные группы;
соблюдение структуры документа: все необходимые атрибуты должны присутствовать и быть заполнены;
поддержание тестовой документации в актуальном состоянии.
Чтобы команда тестирования следовала лучшим практикам, она как минимум должна о них знать. Можно составить документ, описывающий требования к тестовой документации, разместить его в общем доступе и по приходу новичка в команду, ознакамливать его с общепринятыми в компании практиками. Так появится возможность создать единообразный стиль ведения тестовой документации и сделать команду взаимозаменяемой.
Резюме
В заключение подведем итог, что нужно сделать для эффективной организации работы с тестовой документацией. Прежде всего определите функциональность, которую необходимо тестировать. Зафиксируйте используемые и не используемые виды тестирования, а также глубину тестирования. Определите тип документации и подготовьте шаблон. Организуйте хранение тестов и не забывайте о резервном копировании и поддержании актуальности документации. Постройте работу так, чтобы команда имела возможность придерживается лучших практик. Соблюдение этих несложных принципов позволить избежать большинства трудностей с процессами.