Документирование и оценка индустриального тестирования

Тестовые процедуры

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

Рис. 10.1. Пример фрагмента тестовой процедуры для ручного тестирования

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

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

Рис. 10.2. Пример фрагмента автоматизированной тестовой процедуры

Описание тестов

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

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

Документирование и жизненный цикл дефекта

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

1. Наименование подсистемы, в которой обнаружен дефект.
2. Версия продукта (номер build ), на котором дефект был найден.
3. Описание дефекта.
4. Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5. Номер теста, на котором дефект был обнаружен.
6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.

Занесенный в базу дефектов новый дефект находится в состоянии " New " . После того, как команда разработчиков проанализирует дефект, он переводится в состояние " Open " с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние " Resolved ". При этом разработчик должен указать следующую информацию:

1. Причину возникновения дефекта.
2. Место исправления, как минимум, с точностью до исправленного файла.
3. Краткое описание того, что было исправлено.
4. Время, затраченное на исправление.

После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние " Verified ". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на " Open ".

Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние " Postponed " с указанием лиц, ответственных за это решение, и причин его принятия.

Тестовый отчет

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

1. Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2. Количество выполненных тестов – запланированное и реально исполненное.
3. Время, затраченное на тестирование каждой функции, и общее время тестирования.
4. Количество найденных дефектов.
5. Количество повторно открытых дефектов.
6. Отклонения от запланированной последовательности действий, если таковые имели место.
7. Выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла.

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

Рис. 10.3. Фрагмент тестового отчета