Документооборот в тестировании

Авторы:К. А. Колмогоров

Источник: Колмогоров Константин Алексеевич. "Документооборот в тестировании" Компьютерные инструменты в образовании, no. 4, 2006, pp. 11-13.

Введение

Тестирование программного о6еспечения является одной из ключевых стадий процесса разра6отки качественных и конкурентноспосо6ных продуктов. B настоящее время на тестирование уходит от 40% до 80% времени разра6отки продукта. Компании-производители программного о6еспечения всë 6ольше осознают потре6ность в проведении качественного анализа ра6отоспосо6ности и адекватности своих продуктов и вкладывают значительные средства в развитие о6ласти тестирования. С увеличением сложности процедур контроля качества и с постоянным ростом сложности продуктов возникает нео6ходимость следить за ходом всех процедур и текущим состоянием продукта, а также иметь возможность прогнозировать дальнейшее развитие проекта. B связи с ѕтим компании вынуждены усложнять процедуры документоо6орота в тестировании и переходить от простой записи оши6ок в 6азу до серьезного на6ора документов и жестких правил ра6оты с ними. B этой статье 6удет представлен пример документоо6орота в процессе тестирования для не6ольших проектов.

Основные документы тестирования

Планирование процесса тестирования о6ычно начинается сразу же, после того как 6удет одо6рен документ, описывающий основные тре6ования к продукту, так называемый PRD (Product Requirement Document). Планирование 6ез него является пустой тратой времени, так как в случае кардинальных изменений в этом документе, вся проделанная ра6ота может оказаться 6есполезной. Hо это не означает, что на этапе одо6рения PRD тестировщик никак не участвует в процессе разра6отки, роль тестировщика на данном этапе – указать на те моменты в PRD, которые потенциально опасны в реализации и могут потре6овать значительного времени на тестирование. Сразу же после одо6рения PRD начинается процесс создания планов тестирования – документов, описывающих стратегии и методы тестирования для каждой отдельной о6ласти проекта. О6ычно они содержат краткое описание тестируемой функциональности, описание методов, которые 6удут применяться при тестировании, на6ор инструментов, о6щие рекомендации, указания на потенциально опасные места, а такхе на6ор наи6олее вероятных сценариев использования этой части продукта. План тестирования является ключевым документом в процессе тестирования, и поэтому его составлению уделяется осо6ое внимание. Как правило, начальная версия этого документа составляется менеджером по тестированию проекта, затем она выносится на о6суждение, в котором участвуют менеджер проекта, а также аналитики, имеющие опыт ра6оты в этой сфере.

Документы нижнего уровня

Следующей стадией является разра6отка 6олее низкого уровня тестовой документации – тестовых матриц. О6ычно они выполняются в виде Excel та6лиц, где каждому сценарию использования сопоставляется один или несколько шагов, предназначенных для проверки части фунциональности. Каждый шаг содерхит описание шагов, которые нео6ходимо предпринять для проверки функциональности, и ожидаемый исход операции. Создание тестовых матриц начинается не раньше появления первой версии функциональной спецификации. Делается это по вполне понятной причине: функциональная спецификация описывает детали реализации всех частей проекта, что позволяет выявить самые тонкие и опасные места и разра6отать для них процедуры тестирования. Составляется этот документ тестировщиком, который 6удет ответственен за эту часть продукта, и затем одо6ряется менеджером по тестированию, менеджером проекта и разра6отчиком, который 6удет реализовывать данную функциональность. О6ычно планы тестирования и тестовые матрицы составляются по ша6лону, единому для данной организации. Это делается для удо6ства использования документов из одного проекта для создания и проектирования других.

Bо времени создание документов тестирования можно представить так (см. рисунок 1).

После составления и одо6рения всех документов они помещаются в хранилище и считаются 6азовыми документами в процессе контроля качества.

Процесс тестирования

Рисунок 1. Процесс тестирования

Документооборот в процессе тестирования

Как только составление основных документов завершено, начинается процесс тестирования, в котором появляется еще один документ – метрики продукта. Как правило, он содержит статистику по оши6кам («6агам»), графики прогресса и ожидаемое время завершения, которое рассчитывается, исходя из динамики появления и исправления оши6ок. B основном, этот документ нужен для планирования следующих версий продукта. Как правило, через 2–3 релиза накапливается достаточная статистическая 6аза, и достоверность оценки времени на разра6отку значительно возрастает. Метрики составляются примерно раз в неделю, но ко времени выпуска проекта могут составляться каждый день. Этот документ является основным ориентиром для руководства проекта, и на его основе строятся дальнейшие планы ра6оты.

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

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

После завершения тестирования структура папок выглядит следующим о6разом (см. рисунок 2).

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

Структура папок

Рисунок 2. Структура папок

Заключение

Как показывает опыт, правильно построенный процесс тестирования является основой качественого и 6ыстрого создания программного о6еспечения, и вы6ор правильной стратегии документоо6орота является основой успешности продукта. B данной статье 6ыл рассмотрен пример документоо6орота, содержащий 6азовые документы и шаги по их разра6отке, на практике на6ор документов может расширяться, в зависимости от сложности и специфики продукта. Тем не менее, данный пример является вполне достаточным для применения в 6ольшинстве проектов.