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

Роли в тестировании. Проведение тестирования предполагает наличие в команде нескольких ролей. Как правило, роли оказываются совмещенными, т. е. один человек имеет 1—2 роли. Роли в тестировании таковы:

• • тест-менеджер (Test Manager) производит управленческий контроль тестирования;
• • тест-дизайнер (Test Disigner) разрабатывает план тестирования, а также оценивает эффективность тестирования;
• • тестировщик (Tester) производит тесты и фиксирует результаты, а также восстанавливает тесты и систему после сбоев;
• • администратор тестовой группы (Test Administrator) управляет тестировщиками;
• • разработчик тестов (Test Developer) занимается созданием конкретных тестов, которые в дальнейшем будут использованы тестировщиками.

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

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

Как правило, указывают 1—2 цели для каждого тестирования. Цели не должны конфликтовать друг с другом и затруднять тестирование.

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

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

Прецеденты тестирования содержат ответ на вопрос: что мы собираемся тестировать? Если в проекте использовалось визуальное моделирование на языке UML, то прецеденты тестирования строятся на основе Диаграммы прецедентов. Прецедент тестирования — это абстрактный мотив проведения теста, который нужен для понимания целей тестирования и общей логики. Во многих случаях данный этап может быть пропущен. Его применение обязательно только для сложных И С, в которых принципиально важны качество и безопасность.

И, наконец, существует еще один важный документ — Модель рабочей нагрузки. Этот документ содержит описание типичных и исключительных нагрузочных условий ИС. Система должна выдерживать рабочие условия, указанные в данном документе. Его создание обязательно, поскольку он служит основой для проведения тестирования на соответствие нефункциональным требования.

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

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