Devprom ALM: Руководство пользователя

Процесс тестирования (или верификация требований) обычно состоит из ручного и автоматизированного тестирования. Тестирование, выполняемое вручную, осуществляется с использованием тестовой документации (тестовых планов и тестовых сценариев). Автоматические тесты разрабатываются (кодируются) на основе тестовых сценариев.

На стадии тестирования можно выделить две основные задачи: подготовку тестовой документации (тест-дизайн) и тестирование, то есть заполнение тестовых отчетов, вручную или автоматизированными средствами.

Тестовая документация обычно содержится в тест-планах - устойчивых наборах тестовых сценариев, предназначенных для конкретной цели. Например, тест-план для проверки на регресс, для проверки конкретной функциональной области, для приемочного или дымчатого (smoke) тестирования.

Тестовый отчет (или тест) содержит информацию о следующем:

• кто, на какой версии и в каком контексте (сервер, браузер и т.п.), выполнил шаги тестовых сценариев;
• какие при этом были получены результаты;
• какие дефекты были зарегистрированы;

Для каждого тест-плана или тестового сценария может быть заполнено множество тестовых отчетов, отличающихся проверенными версиями ПО и окружениями (контекстом).

Тестирование в легковесных процессах

Определение основных направлений и видов тестирования осуществляется на этапе анализа пользовательских историй (для Kanban) или планирования историй в спринт (для Scrum). Существенные требования к качеству историй фиксируются в критериях приемки.

На стадии тестирования (для Kanban) или при выполнении задачи по тестированию в спринте (для Scrum) для каждой истории разрабатываются детальные тестовые сценарии для ручного тестирования. Важные сценарии включаются в тест-планы для последующих интеграционного и приемочного тестирования. Разрабатываются автоматизированные функциональные тесты, на основе которых будет осуществляться регрессионное тестирование продукта. По окончании реализации историй выполняются ручные и автоматизированные тесты, обнаруженные ошибки оперативно исправляются.

По окончании спринта (для Scrum) или перед выпуском сборки (для Kanban) производится регрессионное, интеграционное, приемочное и исследовательское тестирование, стресс- и нагрузочное тестирование. Для тестирования из списка последних билдов выбирается тот, по которому пройдены все автоматические тесты. Для ручного тестирования используются ранее подготовленные тест-планы, а также наборы тестовых сценариев по функциям или требованиям, затронутым изменениями.

Обнаруженные ошибки попадают в баклог продукта или спринта в зависимости от их критичности. Результаты ручного и автоматического тестирования сразу становятся доступны для всех участников проекта в списке сборок или тестов. В боевую эксплуатацию передается та сборка, по которой пройдены все автоматические и ручные тесты.

Тестирование с предварительным проектированием

Для создания качественных системных требований тестировщики привлекаются для ревью на этапе разработки требований, таким образом документируются важные аспекты требований, проверяется их тестируемость. Процесс ревью может быть формализован путем настройки жизненного цикла (состояний) требований и организации процесса согласования.

С началом разработки тестировщики определяют направления и виды тестирования, разрабатывают соответствующие планы тестирования, основные тестовые сценарии и связывают их с иходными требованиями. При изменении или уточнении требований Devprom ALM уведомляет о необходимости актуализировать тестовую документацию.

По окончании разработки релиза тестировщики дополняют и уточняют тестовую документацию, разрабатывают автоматизированные функциональные тесты. Из списка последних сборок выбирается та, по которой пройдены все автоматические тесты. Тестировщики выполняют функциональное, интеграционное, регрессионное и исследовательское тестирование на стабильной сборке.

Для ручного тестирования используются ранее подготовленные тест-планы, а также наборы тестовых сценариев по функциям или требованиям, затронутым изменениями. Обнаруженные ошибки попадают в баклог продукта, планируется исправление и затем ошибки перепроверяются по ранее подготовленным тестовым сценариям.

Тестовая документация добавляется в бейзайны, соответствующие версиям продукта (то есть версиям требований). Devprom ALM позволяет осуществлять тестирование нескольких версий продукта и эффективно обновлять и актуализировать тестовую документацию.

Тест-план представляет собой документ, состоящий из разделов с общей информацией и тестовых сценариев. В разделах с общей информацией можно фиксировать требования к окружению, перечень реквизита, необходимого для тестирования и т.п.

Один и тот же тестовый сценарий может входить в разные тест-планы, чтобы использоваться для различных целей тестирования. Чтобы включить тестовый сценарий в тест-план выберите соответствующее действие в контекстном меню для сценария.

Сохраните тест-план как шаблон, чтобы быстро создавать типовые тест-планы, с уже предварительно заполненными разделами. Если необходимо продублировать тестовый план или произвольный набор тестовых сценариев, отметьте их галочками в списке и меню массовых операций выберите действие "Дублировать".

Тест-план может быть импортирован из документа и экспортирован в него обратно, например, для согласования или передачи исполнителю. Используйте собственные шаблоны документов для выгрузки тест-плана с нужным оформлением, стилями, титульными листами и т.п.

Тестовые сценарии содержат условия для проверки. Для разных видов тестирования тестовые сценарии могут быть записаны по-разному. Например, для функционального тестирования удобно использовать форму с перечнем шагов, требуемых действий и ожидаемого результата. При помощи шаблонов тестовых сценариев вы можете использовать тот формат, который необходим именно для этого вида тестирования. Добавляйте собственный шаблоны или развивайте те, что мы предлагаем по умолчанию.

Для каждого тестового сценария можно задать Важность, Трудоемкость или другие атрибуты, определяемые пользователями. Тэги позволяют легко реализовать пользовательскую классификацию и использовать ее для отбора сценариев. Связи (трассировки) позволяют зафиксировать причинно-следственные связи, чтобы ответить на вопрос: откуда и зачем появился этот сценарий.

Тестовые сценарии могут быть созданы при редактировании тест-планов (тестовых документов), либо существовать независимо от них.

Наши типовые процессы настроены таким образом, что, на соответствующих стадиях жизненного цикла требований или доработок, система предлагает создавать тестовые сценарии. Таким образом, разработка тестовой документации встроена в технологический процесс реализации требований. При этом система автоматически создает все необходимые связи, которые в дальнейшем конечно можно отредактировать.

Трассировка тестовой документации на требования используется для следующих задач:

• вычисления процента покрытия требований тестовой документацией;
• отслеживания изменений в требованиях и отображения их в тестовой документации.

Тестовые сценарии можно создавать на основе требований, непосредственно при чтении и анализе документов требований (спецификаций, функциональных требований и т.п.). Напротив каждого раздела требований есть зеленая кнопка с плюсом, с помощью которой можно создавать тестовую документацию на основе требования.

Для быстрого покрытия требований тестовой документацией, используйте массовую операцию. Отберите требования, отметьте их галочками и в массовых операциях выберите "Создать тестовые сценарии". Приложение создаст тестовые сценарии на основе требований и свяжет их друг с другом.

Бейзлайн - это версия тест-плана привязанная к какому-то этапу проекта, к релизу или итерации. Бейзлайны отображаются в плане проекта. Это позволяет контролировать наличие тест-планов, актуальных для данного этапа, а также использовать их в рабочих целях. Вы можете сравнивать произвольные бейзлайны тест-планов между собой для выявления отличий. При помощи фильтра "Текст на дату" можно получить именно тот текст сценариев, который сооветствует указанной дате.

Разработка новой версии продукта

Создавайте бейзлайны тест-планов перед внесением изменений, возникающих в результате доработок в новой версии продукта. Это позволит вам хранить текст сценариев для проверки функциональности предыдущих версий.

Одновременная разработка нескольких версий продукта

Если вам необходимо вносить изменения сразу в несколько версий продукта или в редакции продукта частично адаптированные для разных клиентов, используйте возможность ветвления тестовой документации.

Бейзлайны можно использовать в качестве дополнительных веток тестовой документации, реализуя тем самым ветвление (бранчевание) документации по аналогии с ветками программного кода. Это позволяет параллельно вести разработку документации сразу для нескольких версий одного продукта.

Devprom ALM автоматически подскажет какие изменения основного бейзлайна документации нужно перенести в другие ветки документации.

У тестовой документации есть статусная модель (или жизненные цикл разделов и сценариев). Используйте ее для управления процессом подготовки тестовой документации. Вы можете ввести собственные статусы, например, для организации согласования документации с заинтересованными лицами. График разработки тестовой документации отражает сходимость тест-дизайна: количество разделов в работе, на согласовании, в стадии готовности.

Синхронное изменение состояний разделов и сценариев можно использовать для ускорения управления статусами. Например, при отметке готовности тест-плана достаточно изменение состояние самого тест-плана, чтобы все его подразделы также перешли в статус "Готово". Такие синхронные операции настраиваются в ЖЦ тестовых сценариев, при помощи соответствующих системных действий.

При разработке тестовой документации можно создавать задачи на основе тестовых сценариев или разделов тест-планов. Такие задачи позволяют распределять работу между тестировщикам, планировать трудозатраты, осуществлять план/факт анализ, управлять человеческими ресурсами.

Перечень назначенных задач доступен списке "Мои задачи". Планом работ по тестированию можно управлять при помощи доски задач или специально настроенной доски задач по тестированию.

Управление правками в тестовой документации

В процессе ревью тестовых сценариев могут возникать вопросы и замечания по тексту. Выделив часть текста, можно добавить комментарий. На дополнительной панели справа отображаются незавершенные комментарии по документу. Кликнув на комментарий вы можете перейти к соответствующему разделу документа.

При помощи фильтра "Комментарии" вы можете отобразить только те разделы документа, по которым есть незавершенные комментарии, либо только ваши комментарии. Это существенно ускоряет процесс согласования тест-плана.

Сигнализируйте о том, что комментарий учтен (реализован путем внесения изменений), либо более не актуален (если предоставлен исчерпывающий ответ), при помощи состояния комментария: завершен или открыт. Управление состоянием комментария доступно при помощи галочки на панели комментариев справа, либо при помощи контекстного меню на вкладке Комментарии на форме редактирования тестового сценария или раздела тест-плана.

Требования непрерывно меняются, поэтому команде и необходимо поддерживать тестовую документацию в актуальном состоянии, чтобы исключить псевдо-дефекты, связанные с проверкой продуктов по устаревшей тестовой документации.

Devprom ALM значительно сокращает трудозатраты на поддержку документации за счет автоматизации процесса отслеживания изменений. Теперь поддержка технической документации не является проблемой для проектов, в которых требования часто меняются. Система автоматически сохраняет связи между проектными артефактами, например, между требованиями и технической документацией.

В процессах с предварительным проектированием

Когда бизнес- или системное требование изменится, система отметит покрывающие его тестовые сценарии как устаревшие (неактуальные). Вам останется только отфильтровать их в списке и перейти к редактированию.

Система отобразит изменения, которые были внесены в требования, а вам останется только подправить соответствующие разделы технической документации.

В легковесных процессах разработки

Если команда работает с первичными требованиями, то поддержка тестовой документации в актуальном состоянии осуществляется при помощи дерева функций (импакт-мэппинга, стори-мэппинга или эпиков). Истории пользователей и тестовая документация привязываются к функциями или эпикам.

После того как история будет реализована, Devprom ALM автоматически отметит устаревшими тестовые сценарии, связанные с функцией (или эпиком) этой истории. Вам остается открыть реестр устаревших сценариев, внести нужные изменения и восстановить покрытие.

Результаты ручного тестирования оформляются в виде тестовых отчетов (или тестов). Каждый тестовый отчет состоит из набора тестовых сценариев, которые образуют позиции тестового отчета.

В позиции тестового отчета содержится копия текста исходного тестового сценария. Это позволяет параллельно заполнять разные тестовые отчеты, созданные на основе одного сценария (одновременно тестировать на разных окружениях). Можно хранить и анализировать историю ранее заполненных отчетов. А также параллельно вести доработку тестовой документации, например, под новую фичу, и заполнение тестовых отчетов, при тестировании ранее реализованной функциональности (процесс Kanban).

Если тестовый сценарий находится "В работе", то изменения в тексте отчета будут сохранены в тексте сценария.

Тестовые отчеты создаются на основе:

• Тест-планов. Для этого нужно открыть тест-план и нажать зеленую кнопку "+ Начать тестирование".
• Набора тестовых сценариев. Откройте список тестовых сценариев и отфильтруйте их по нужному критерию. Отметьте галочками сценарии и в массовых операциях выберите действие "Начать тестирование".
• Функций. Для этого связывайте тестовые сценарии с теми функциями системы, для которых они созданы. Из дерева функций легко перейти к тестовому набору и запланировать тестирование.
• Вручную, например, при исследовательском тестировании. Откройте модуль "Тестовые отчеты" и нажмите кнопку "Добавить". Вы можете создавать новые сценарии и включать их в отчет, либо добавлять в отчет ранее созданные сценарии.

Чтобы указать в каком состоянии тестового сценария (или тест-плана) можно создать тестовый отчет, используйте настройку "Артефакты" на вкладке "Дополнительно" у состояния.

Для тестирования и воспроизведения дефектов важно обозначить контекст:

• сборку или версию, использованную для тестирования;
• сервер, бразуер, операционную систему и другое окружение, на котором производится тестирование.

Тестирование на разных окружениях вскрывает зависимости приложения от установленных компонетов или особенностей вспомогательного ПО.

Сборки можно добавлять вручную, перед началом тестирования. Однако, лучше интегрировать систему выпуска сборок (сборочный сервер, например Jenkins или TeamCity) и Devprom ALM. В этом случае, сборки (номера и пути к их расположению) будут регистрироваться автоматически по факту их выпуска. Делается это простыми командами к REST API, примеры которых приведены в контекстной справке к модулю "Сборки".

По каждой сборке можно узнать какие требования были в ней реализованы, какие обнаружены дефекты, какие тестовые отчеты заполнены. По сборке можно вести обсуждения, например, на тему ее готовности к передачи на следующий этап контроля качества.

Окружения также можно добавлять вручную, либо при помощи REST API. Например, если ваша тестовая среда динамична, то есть используются виртуальные машины или docker-контейнеры, то окружения можно регистрировать в момент создания таких сред, перед запуском автоматических тестов.

В стандартной форме тестового отчета тестировщик заполняет текст сценария и в поле "Результат" отмечает статус прохождения каждого из действий. В текст сценария можно вставлять комментарии и скриншоты, поясняющие проблемы, возникшие при прохождении сценария.

Логи, дампы и прочие бинарные файлы можно прикладывать к отчету при помощи кнопки "+ Файл".

При обнаружении дефекта, его можно зарегистрировать при помощи кнопки "+ Ошибка". В описании дефекта не нужно описывать все шаги, которые привели к его обнаружению. С дефектом будет связана ссылка на позицию тестового отчета. Когда разработчик приступит к исправлению, он сможет перейти по ссылке и по отчету восстановить контекст обнаружения дефекта. Если тестовый сценарий был связан с требованием, то ошибка также будет связана с этим требованием, сообщая участникам проекта о проблемах в реализации требований.

Поскольку тестовая документация создается на основе доработок или первичных требований, с позицией тестового сценария будет связана одна или несколько доработок. Вместо того, чтобы создавать массу дефектов, причина которых в некорректной реализации конкретной доработки, необходимо поставить задачу на исправление исходной дефектной доработки. В разных процессах это можно организовать по-разному:

Списковое представление отчета удобно для выполнения массовых операций и просмотра всех результатов по заданным критериям. Например, для ускорения тестирования по большому тест-плану, можно распределить работу между несколькими тестировщикам. Отмечайте порцию тестовых сценариев и назначайте их на конкретного тестировщика. При заполнении отчета тестировщик может отфильровать свои позиции и заполнять только их.

Тестовый отчет может быть связан с одной или несколькими задачами. Таким образом вы можете назначать работу на тестировщиков. В каждой задаче указываются плановые трудозатраты, исполнитель и фактические трудозатраты.

Назначенные тестировщику задачи отображаются в списке "Мои задачи" и в верхней части приложения, в списке ближайших задач. Распределение задач по команде, итерациям удобно осуществлять на доске задач. Зафиксируйте фильтр по типу задач, чтобы показывать доску задач тестирования.

На основе плановых трудозатрат можно просматривать загрузку участника и выявлять свободные ресурсы или определять перегрузку, с учетом вовлеченности тестировщиков в нескольких проектов. На основе фактических трудозатрат можно строить план/факт анализ.

Результаты выполнения автоматических тестов могут быть импортированы в систему на одном из этапов подготовки и выпуска сборки. Обычно этим занимаются сборочные серверы (или сборщики), такие как Jenkins или TeamCity. Команда для импорта тестового отчета указана в подсказке в модуле "Тестовые отчеты". Для проверки возможности импорта вашего отчета используйте действие "Импортировать отчет".

Помимо стэка вызова и другой отладочной информации, в отчет по тестированию удобно вставлять скриншоты приложения. Такие скриншоты формируют контекст для анализа и воспроизведения дефектов. Включение скриншота в отчет осущствлятся средствами вашего инструмента запуска автотестов. Например, для случая Selenium, это небольшой кусочек кода.

Разрабатывайте функциональные и интеграционные автотесты на основе тестовой документации. Затем, после реализации соответствующего тест-класса или тест-метода, добавьте аннотацию Description, в которой укажите идентификатор автоматизированного сценария. Таким образом, в результатах тестирования вы сможете просмотреть как текст сценария, так и результат его тестирования.

@Test(description="S-1685")
public void myTestMethod() {
// ...
}

Это позволит связать автотест с исходным сценариев. Так куда удобнее анализировать проблемы, поскольку в тексте отчета будет виден исходный текст сценария.

BDD (Behavior Driven Development) - практика разработки кода на основе приемочных сценариев (так называемых исполняемых спецификаций). Приемочный сценарий пишется на специальном языке (Gherkin), который позволяет автоматически создавать заглушки программного кода. Эти заглушки реализуют программисты, вызывая при этом программный код. Получаются такие автотесты, сценарии по которым пишут не программисты, а реализуют их программисты.

Существует много фреймворков для реализации этого подхода, под разные языки программирования. Сложность у всех одна: кто и где пишет эти самые сценарии, где они хранятся, как отслеживается их актуальность в соответствии с требованиями. Devprom ALM позволяет разрешить эту проблему.

Приемочные сценарии на языке Gherkin пишутся в рамках разработки тестовой документации. При разработке и перед запуском таких автотестов, акуальная версия сценариев выгружается из системы и виде набора файлов (сценариев). Программисты используют эти файлы для разработки новых тестов или исправления сломаных. Сборщик использует эти файлы для запуска тестов через фреймворк. Для бесшовной интеграции можно систематически сохранять изменения в используемой системе контроля версий.

В процессе тестирования программных продуктов образуется большой объем полезной информации, которую можно использовать для анализа процесса, качества продуктов и измерения продуктивности работы команды. В Devprom ALM реализованы наиболее полезные метрики, которые команды используют в своей работе:

• Таблица ошибок - используйте график для анализа прогресса решения критичных ошибок, выявления этапов процесса, на которых сосредотачивается наибольшее количество критичных ошибок.
• История обнаружения ошибок по неделям - используйте отчет для выявления дисбаланса в скорости обнаружения ошибок тестировщиками. При значительном количестве обнаруженных ошибок стоит вернуть сборку разработчикам для стабилизации. При снижении общего количества обнаруженных ошибок прогнозируйте дату выхода релиза.
• Распределение пожеланий по приоритетам - с помощью этого графика можно, например, увидеть динамику появления критичных ошибок в проекте в целом или в рамках конкретного релиза.
• График сходимости дефектов - график сходимости позволяет оценить динамику заведения новых дефектов, исправления дефектов, а так же визуализировать общее количество дефектов, находящихся в состояниях добавлено и выполнено.
• Производительность тест-дизайна - используйте отчет для анализа объема изменений в тестовой документации, для выявления моментов разработки тестовой документации, для сравнения продуктивности тест-дизайнеров.
• График разработки тестовой документации - используйте график для контроля за подготовкой тестовой документации в релизе или проекте. Перед началом тестирования очередного релиза продукта требуемые разделы тестовой документации должны быть уже подготовлены.

Назначение этого модуля - выявлять версии, начиная с которых "сломались" тесты. Укажите нужный тест-план для отбора сценариев и приложение покажет таблицу с результатами их выполнения в разрезе версий.

Используйте метрики для верхнеуровневого контроля за процессом тестирования. Перечень метрик с их значениями доступен в модуле "Метрики". В категории "Тестирование" вычисляются следующие метрики: