Отслеживание тестовых прогонов.

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

При отслеживании тестового прогона есть несколько информационных разделов, которые вы захотели бы включить:

1. Дата исполнения теста.

2. Имя или другой идентификатор (т. е. логин или ID-номер) тестировщика.

3. Название или другой идентификатор тестируемой системы.

4. Указатель того, какой код тестировался. Это могут быть тег, ссылка, номер версии, номер сборки или какая-то другая форма идентификации.

5. Тест-план, к которому относится тестовый прогон.

6. Итоговый статус каждого тест-кейса. Обратите внимание, что временные статусы, такие как "Остановлен", должны быть изменены на итоговый статус перед завершением тестового прогона.

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

Пример тестового прогона может выглядеть так:

Дата: 22 сентября 2022 г.

Имя тестировщика: Ivan K. Tester

Система: Meow Recording System (MRS)

Номер сборки: 342

Тест-план: Тест-план Meow Storage Subsystem

Результаты:

TEST 1: Пройден

TEST 2: Пройден

TEST 3: Неудавшийся (записан дефект #714)

TEST 4: Заблокирован (дополнительная функция программы пока не реализована)

TEST 5: Пройден

TEST 6: Неудавшийся (причина в известном дефекте #137)

TEST 7: Ошибка (очевидная ошибка в тест-плане; необходимо проверить с отделом системного инжиниринга)

TEST 8: Пройден

TEST 9: Пройден

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

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

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

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