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

• Тестовая лаборатория

Великая вещь! Стойка с тестовыми компьютерами, на которых установлены различные ОС, с различными языками и сервисными пакетами здорово упростит работу по контролю качества для всей команды. Тестовая лаборатория хороша и для установки сложной среды тестирования, сборка и настройка которой отнимает массу времени.

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

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

На заре NuMega у нас не было постоянно доступной библиотеки программ, а охота за компакт-дисками здорово раздражала и отнимала драгоценное время. Часто наши планы требовали поддержки самой последней ОС или компилятора Microsoft. К счастью, мы участвовали в тестировании их бета-версий и регулярно получали обновления. Жаль, что только на одном компакт-диске. Когда кому-то требовалась последняя бета-версия Windows или Visual Studio, начиналась охота за диском. Если везло, мы находили человека с диском, который нам требовался, но чаще всего мы слышали: «Я отдал его тому-то», — и продолжали идти по следу. (Однажды я ходил так от одного к другому и только пятый человек в цепочке сказал мне, что этого диска в глаза не видел!) Если такой способ не работал, мы писали сообщение по электронной почте и с надеждой ждали ответа, а это время занимались чем-то другим.

После того, как в течение нескольких месяцев мы столкнулись с десятками таких сообщений, мы окончательно поняли, что проблему нужно решать, тем более что наша компания росла. Решением стала «вертушка» компакт-дисков. Это сработало, но только после того, как мы перевели все в режим онлайнового доступа. Наши попытки создать традиционную библиотеку не увенчались успехом, так как люди, бравшие компакт-диски, никогда не возвращали их на место, и мы вновь задавались вопросом: «У кого диск?»

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

Нехватка ресурсов (здесь я имею в виду ресурсы человеческие), вероятно, является наиболее частой проблемой системы контроля качества, и, честно говоря, она гораздо сложнее, чем может казаться. Если для контроля качества у вас нет необходимых ресурсов, прежде всего определите, в чём проблема. Если вам постоянно не хватает ресурсов для осуществления контроля качества, а рабочие места остаются вакантными, значит, вы испытываете проблемы с набором персонала, обратитесь к главе 1 за дополнительными разъяснениями. Если сотрудники, отвечающие за контроль качества, из-за дополнительной работы или сокращения графиков уже работают на износ, стоит рассмотреть возможность привлечения контрактников. Однако, прежде чем пойти на этот шаг, у вас должны быть полностью готовы планы тестирования. Важно, чтобы временные сотрудники выполняли план, а не писали его.

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

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

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

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

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

Многие проекты «встают не с той ноги» и, честно говоря, обречены с самого начала, так как члены команды просто к ним не готовы. У вас должны быть основные планы, средства автоматизации и оборудование, о которых говорилось выше. Все это потребуется почти с самого начала разработки. Если вы будете писать планы или ждать поставки нужного оборудования в процессе разработки, вы уже опоздаете и не сможете делать то, что от вас требуется — тестировать.

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

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

Проблемы с качеством не всегда являются результатом игнорирования приёмов и концепции контроля качества. Это может быть следствием ненадлежащего исполнения обязанностей. Если вам приходилось беседовать с менеджерами или ведущими специалистами о контроле качества в таком проекте, они, вероятно, постарались наговорить много всего о том, что нужно сделать. Но когда вы видите их проекты, то замечаете, что ничего не делается. Создание качественного продукта требует усилий: сосредоточенности, активного участия, исполнительности. Это не теоретические выкладки — все члены команды должны действовать активно и увлечённо.