Основные понятия

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

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

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

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

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

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

Типовые схемы

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

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

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

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

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

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

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

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

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

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

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

Тест-дизайн

Тест-планы

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

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

Сохраните тест-план как шаблон, чтобы быстро создавать типовые тест-планы, с уже предварительно заполненными разделами.

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

Создание тестовых сценариев

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

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

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

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

Трассировка на требования

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

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

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

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

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

Версии и бейзлайны

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

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

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

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

Управление тест-дизайном

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

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

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

Ручное тестирование

Результаты ручного тестирования оформляются в виде тестовых отчетов (или тестов).

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

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

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

Сборки и окружения

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

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

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

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

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

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

Заполнение отчетов

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

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

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

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

Тип процесса Действия для постановки задачи на исправление
Scrum, параллельная работа над требованиями

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

НЕВЕРНО отклонять требование. Это может быть сделано только на демонстрации.

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

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

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

Управление тестированием

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

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

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

Автоматизированное тестирование

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

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

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

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

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

Применение BDD

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

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

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

Графики, метрики и отчеты

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

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

Результаты тестирования по версиям

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