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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Для редко изменяемых, некритичных функций

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

• Когда все трещит по швам

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

Но помните: нельзя быть зависимым от ручного тестирования. Его наращивание потребует больших затрат, а тестирование параллельно с разработкой продукта становится затруднительным.

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

• 2-3 компьютера на каждого тестировщика

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

• 2 компьютера на одного разработчика

Помните: разработчики тоже занимаются тестированием. Один компьютер им нужен для разработки, другой — для тестирования. Разработчики могут переконфигурировать его при «охоте на жучков», и это не помешает их основной работе. Повторю: хорошо, если одна машина представляет компьютер конечного пользователя.

• Доступная библиотека программ

Все ПО, которое требуется для разработки или тестирования, должно быть постоянно доступно. Для быстрого и простого доступа сотрудников к инструментам, продуктам и ОС, необходимым для работы, удобен дисковод с автоматической сменой компакт-дисков. Конечно, придётся позаботиться о наличии лицензий, но избавление сотрудников от хождения по коридорам в поисках нужного диска того стоит.