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

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

• Завершена последняя проверка пользовательского интерфейса

Группа уже закончила оценку и доводку пользовательского интерфейса, так что интерфейс останется неизменным вплоть до отправки продукта заказчику;

• Закончено тестирование программы

Группа выполнила план тестирования в полном объёме: проведено блочное, системное, нагрузочное тестирование, тестирование производительности и испытание пользовательского интерфейса, а также автоматизированное тестирование. Все тесты пройдены, по крайней мере, известны все неполадки и решено поставлять продукт, не устраняя их.

• Все ошибки исправлены

Все ошибки, которые планировалось исправить, уже исправлены. Что касается остальных ошибок, то, проанализировав все сообщения о неисправленных ошибках, группа пришла к выводу, что они не могут или не должны быть исправлены в этом выпуске ПО.

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

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

• остановить все изменения в системе управления версиями и заблокировать систему управления исходным текстом;

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

• прекратить создание новых сборок — с этого дня ежедневная сборка ПО отменяется;

• пометить нужные файлы в системе управления исходным текстом;

• уведомить всех участников команды о том, что кандидат на выпуск готов!

Одной из трудностей в работе с кандидатами на выпуск является отбор функций, которые должны быть испытаны в окончательной сборке. Помните: полностью протестировать весь продукт ещё раз не получится, так как на это уйдет несколько месяцев (а то и лет). Вместо этого нужно составить конкретный и чётко сформулированный план тестирования кандидата на выпуск, который можно будет выполнить в очень сжатые сроки. При этом ваши вложения в автоматизацию тестирования воздадутся сторицей. Если в своё время тестирование ключевых функций продукта было автоматизировано, затруднений возникнуть не должно. Тестирование избранных функций кандидата на выпуск должно быть на 70-80 или даже на 90% автоматизировано, что позволяет максимально сократить период испытаний кандидата на выпуск. При отсутствии полной автоматизации потребуется дополнительное время на проведение тестирования вручную. Помимо исполнения набора автоматизированных тестов, при проведении ручных тестов следует сосредоточиться на:

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

• тестировании базовой функциональности продукта, а именно:

— ключевых функций;

— основных элементов пользовательского интерфейса;

— важнейших ссылок в справочной системе;

— программ-примеров и электронных учебников;

• самых необходимых тестах производительности и нагрузочном тестировании;

• других специфичных для данного проекта функциях, которые требуется протестировать.

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