Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

Я готов был зааплодировать. Не потому, что мне нравилось состояние бета-версии. Кэрол дала понять разработчикам, что в их обязанности входит базовое тестирование программ и самостоятельная работа над проблемами кода. До команды разработчиков это дошло. Мы согласились и занимались тестированием и исправлениями в программе, пока не почувствовали, что готовы позвать Кэрол. Это заняло около двух дней.

В отношении тестирования разработчики имеют ряд обязанностей:

• анализ плана тестирования;

• тестирование на уровне модулей (работает ли функция в большинстве ситуаций);

• предварительное интегральное тестирование (работает ли функция в связке с другими);

• протоколирование или устранение всех неполадок, обнаруженных в программе, когда они сами её использовали.

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

Далее команда, отвечающая за контроль качества, проводит тестирование продукта на другом уровне. Она сосредоточивается на:

• планировании тестов;

• автоматизации создания тестов;

• автоматизации тестирования;

• тестировании функций в различных комбинациях;

• тестировании процедуры установки;

• тестировании интеграции и связи с системой;

• тестировании производительности и нагрузки;

• ручном тестировании (функций, для которых неприменимо автоматическое тестирование);

• диагностике проблем и их протоколировании;

• проверке исправлений и «закрытии» ошибок.

Хотя все эти обязанности привычны для тестировщиков, последняя может быть менее знакомой. «Закрытие» ошибки должен проводить только тестировщик — член оперативной команды. Задача разработчика — исправить ошибку в коде, занести исправление в систему управления исходным кодом и обновить статус ошибки на «Исправлено» в системе устранения неполадок. Но пересмотр всех исправленных ошибок и проверка того, что они действительно исправлены, входит в обязанности тестировщиков. Только после такой проверки ошибка считается официально «закрытой».

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

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

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

Из собственного опыта

В NuMega мы решили проблему тестирования на нескольких конфигурациях путём распределения их между разработчиками и тестировщиками. Один получил Microsoft Windows 95, другой — Microsoft Windows 98, третий — Microsoft Windows NT 3.51 и ещё один — Microsoft Windows NT 4.0. От каждого требовалось выполнить тест на своей ОС в надежде как можно раньше — в процессе разработки — обнаружить проблемы. Таким простым способом мы почти сразу находили проблемы на всех платформах.

Я столько внимания уделил автоматическому тестированию, что у некоторых из вас мог возникнуть вопрос: стоит ли вообще использовать ручные тесты? Да, но нужно понимать, где их применять. Ручные тесты используются в следующих случаях:

• Для тестирования ключевых функций в случаях, когда автоматические тесты запаздывают или вовсе не существуют

Что, если у вас нет времени или ресурсов для написания всех автоматических тестов, а команда разработчиков уже выдаёт вам готовую функцию? В таком случае нужно приступить к ручному тестированию, чтобы оценка функции проходила согласно графику. Раннее обнаружение ошибок и их устранение остаётся главной задачей.