приложения. Как долго добавить покупателя? А удалить? Получить сообщение об ошибке? Хотя может быть несколько причин плохой производительности, если вы не можете быстро добавить покупателя в маленькой базе данных, возможно, имеется проблема, требующая дополнительного исследования. Есть ли проблемы с драйверами БД? Может быть, у вас плохая структура БД? Нет ли претензий к промежуточному уровню? Чтобы это проверить, через определённое время нужно проводить мониторинг, устанавливать планку производительности для основных транзакций и регулярно сравнивать результаты, чтобы знать, что вы на верном пути.
Задача тестирования интеграции — убедиться в том, что к завершению первого этапа функциональность продукта удовлетворительна. Если это так, вы готовы приступить к следующему крупному этапу. Если нет, скажем, вы не можете добавить, отредактировать или удалить покупателя, остановитесь и исправьте всё, что мешает двигаться вперёд.
Тестирование бета-версий и кандидата на выпуск — ключевой этап проекта. Бета-тест — это возможность дать клиентам проверить и оценить ваше ПО за месяцы до его выпуска или применения в реальной рабочей среде. В большинстве проектов во второй половине цикла разработки предусматривается 2-3 бета-периода. Во время каждого такого периода привлекаются десятки или сотни, а иногда тысячи пользователей. Кандидат на выпуск потенциально является последней сборкой продукта, и он ещё важнее. Если последний круг тестирования завершился без серьёзных проблем, то он представляет ПО, которое вы намереваетесь предоставить потребителям. (Подробно о бета-тестировании см. главу 13, о тестировании кандидатов на выпуск — главу 14.)
Одна из главных задач при работе с бета-версиями и кандидатами на выпуск — определить, что следует протестировать в сборке, прежде чем предоставить её сторонним организациям. Конечно, вы не сможете заново протестировать весь продукт. Полное тестирование и доводка продукта займёт месяцы, если не годы. Вместо этого вам нужно составить очень конкретный и хорошо продуманный план, который будет выполнен в очень сжатые сроки. (Для большинства небольших и средних проектов норма составляет 7-10 дней.) В планы тестирования бета-версий и кандидатов на выпуск нужно включить:
• выполнение всего набора автоматических тестов;
• выполнение набора ручных тестов, включая:
* нормальную установку/проверку лицензии (полностью вручную);
* тестирование базовых функций продукта (полностью вручную);
* тестирование производительности и нагрузки (полностью вручную);
* выборочную проверку на всех поддерживаемых платформах;
* другие специфические разделы проекта.
Этот список послужит вам хорошей отправной точкой, но для каждого пункта вы должны определить конкретный сценарий тестирования. И если все эти тесты будут успешно пройдены, вы выпустите вашу программу. Если вы не можете успешно выполнить тесты, устраните неполадки и повторите процесс.
Одна из черт грамотного цикла тестирования бета-версии или кандидата на выпуск заключается в его предеказуемости. Вы должны знать, сколько времени займёт выполнение автоматических и ручных тестов. Имея эту информацию, вы сможете точно предсказать, сколько времени займёт тестирование следующей бета-версии или кандидата на выпуск. Зная, сколько времени нужно для тестирования другой сборки, вы сможете оценить риск и стоимость внесения дополнительных изменений.
Кто должен тестировать?
За тестирование должны отвечать все участники проекта, невзирая на лица и отведённые им роли. При использовании продукта с любой целью и в любой форме делать это надо с критической точки зрения. Кем бы вы ни были: менеджером проекта, радостно рассматривающим новую функцию, автором руководства пользователя, проверяющим, как будет работать пример, или специалистом по инженерной психологии, устанавливающим продукт для проверки пользовательского интерфейса — вы должны отслеживать, искать и сообщать о проблемах качества.
Имея сжатые сроки и ограниченные ресурсы, трудно ожидать, что одна группа сможет провести всю работу по тестированию, особенно если учитывать, что в командах тестировщиков дефицит кадров проявляется чаще всего. Так что убедитесь в том, что ваши разработчики, технические писатели, инженерные психологи, менеджер продукта, менеджер проекта, вице-президент или студенты, проходящие летнюю практику, будут искать проблемы каждый раз, когда они используют продукт для своих нужд. Любой ценой заставьте их сообщать о найденных проблемах.
В период стабилизации и интеграции к тестированию приступает вся команда разработчиков — это коллективная работа. Появляется шанс увидеть, где команда находится в данный момент и сколько ещё нужно сделать. Обычно руководитель группы контроля качества выполняет задачу, распределяя ответственность за тестирование между всеми членами команды. Большую часть времени работа проводится в областях, где автоматические тестовые задания справляются плохо. Также сотрудников просят «сыграть роль пользователя» для ключевых частей продукта. Итак, команда, работавшая над продуктом в течение всего цикла разработки, просто незаменима. Это то, что должно стать частью вашей культуры и одним из ваших основных технологических процессов.
Эту идею можно развить ещё дальше — самим использовать собственные программы. Такой подход называют
В определённый момент крайне необходимо чётко разграничить обязанности тестировщиков от обязанностей других членов команды (прежде всего разработчиков) в том, что касается тестирования. Чтобы люди концентрировались на своих прямых задачах, необходимо разделение труда.
Разработчики влияют на качество продукта больше всего. В конце концов они находятся ближе всего к коду, и риск внесения ошибок исходит прежде всего от них. Чтобы гарантировать отлов «жучков» до того, как команда тестировщиков увидит функциональный блок, они должны его тестировать в процессе написания. Хороший разработчик ускорит работу тестировщиков, предоставляя им надёжные функции. И наоборот, плохой разработчик затормозит работу тестировщиков, выдавая им компоненты с таким количеством ошибок, что о тестировании уже и речи не будет. Для тестировщика нет ничего более неприятного, чем находить массу очевидных проблем, которые разработчик мог найти сам всего за несколько минут работы.
