Из собственного опыта
В NuMega менеджер проекта определял качество как главный приоритет для каждого члена команды. Он устанавливал продукт и использовал его почти ежедневно, фиксировал ошибки и обсуждал обнаруженные неполадки со своей командой на совещании, в обеденное время и встреч в коридоре. Это подгоняло всю команду, и каждый её участник включался в работу. Тестированием и оценкой результатов занимались все. Все осознали: ошибки — это зло, и с ними надо бороться. Мы давали всем понять, что до самого конца проекта о качестве будут помнить и не забудут после продажи продукта.
Что, когда и как тестировать
Тестирование эффективно, только если понятно, какую часть продукта, когда и как тестировать. Вроде вопросы простые, но если вы работаете в жёстком графике и с ограниченными людскими ресурсами, то вам нельзя терять время, тестируя объект слишком глубоко или, наоборот, слишком поверхностно. Нужно сосредоточиться на проверке в следующих ключевых областях продукта:
• процедуре установки;
• функциональных возможностях;
• интеграции функций;
• производительности.
Тестирование в этих областях должно происходить постоянно в течение всего цикла разработки. Однако для эффективного выполнения этой процедуры вам нужно знать, когда и как проводить тесты в каждой из этих областей. Короче говоря, для каждого крупного мероприятия в процессе разработки вы должны обладать набором хорошо определённых процессов и процедур, которые будут отлавливать проблемы. Эти процессы и процедуры источают в себя следующие компоненты:
• Входные тесты
Проверяют ПО перед подтверждением внесённых изменений.
• Ежедневные базисные тесты
Выполняются для каждой сборки программы.
• Тесты по завершении функции
Проверяют функцию сразу же после завершения работы над ней.
• Тесты при стабилизации и интеграции
Проверяется интеграция функций через определённые интервалы времени.
• Бета-тестирование и кандидаты на выпуск
Производится внешнее тестирование продукта через определённые интервалы времени.
В оставшейся части этой главы мы поговорим об этих пяти ключевых разновидностях тестирования.
Входное тестирование
Позволяет разработчикам проверить важные функции в локальной сборке перед помещением кода в основную базу. Хорошие тесты должны обладать:
• совместимостью между всеми машинами;
• простотой установки, запуска и выполнения;
• проверять ключевые функции или подсистемы продукта.
Входные тесты представляют наибольшую ценность для случаев, когда вы вносите исправления в критичную или сложную часть системы. Если входной тест выполняется неудачно, вы можете самостоятельно найти и устранить неполадку. Вы не нарушите работу остальных разработчиков, которые могут взять исходные файлы с ошибками, после внесения этих файлов вами в систему. Также входные тесты предотвращают внесение критических ошибок в ежедневную сборку и сбой базисного теста.
Ежедневное базисное тестирование
Ещё один способ реализации стратегии «тестировать как можно раньше», помимо входных тестов, — ежедневные базисные тесты. Так как вы строите продукт каждый день, то и тестировать его нужно ежедневно. Базисные тесты — это основной набор автоматизированных регрессивных тестов, проверяющих, что ключевые функции продукта работают. Они обеспечивают создание работоспособной сборки и гарантию того, что за прошедшие 24 часа не было значительных ухудшений. С добавлением новых ключевых компонентов базисные тесты также следует улучшать и расширять.
Из собственного опыта
Продукт BoundsChecker компании NuMega хорошо известен за свою способность находить утечки памяти в приложениях C/C++. Ежедневные базисные тесты для этой программы включали в себя приложение BugBench, в котором было множество утечек памяти, а также других отвратительных «жучков». Мы использовали эту программу-пример для генерации ошибок, которые BoundsChecker должен был уметь искать. Если BoundsChecker находил не все ошибки в программе-примере, тогда по определению сборка считалась плохой. Нам нравилось получать по утрам «ещё дымящийся отчёт о тесте» с результатами проверки сборки минувшей ночи. Такой процесс позволял нашему проекту почти всегда быть стабильным и работающим, поскольку наши базисные тесты сразу находили критические проблемы.
Читать дальше