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

• Предыдущая
• 26/64
• Следующая

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

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

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

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

• качество продукта улучшается регулярно при завершении каждого планового этапа разработки;

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

• качество является частью культуры и технологии.

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

Ниже представлен идеальный график параллельного тестирования набора функций программы (табл. 6-1). Заметьте, что разработка и тестирование идут максимально плотно друг за другом. Реализация функции завершается в конце недели, команда испытателей готова приступить к тестированию в начале следующей. Хотя разработчики ответственны и за создание кода, и за его базовое тестирование, команда тестировщиков в заданный период проверяет функцию по максимуму. Так как разработчики и тестировщики должны работать над функцией вместе, их называют «оперативной командой».

Табл. 6-1. График работы оперативной команды над функциями А, В и С.

Разработчики и тестировщики несут обоюдную ответственность за своевременное обеспечение качества. В такой системе реализация функции не завершается написанием кода. Функция считается законченной, если она проверена тестировщиками и соответствует заданным критериям. Разработчики и тестировщики должны осознавать, что для завершения работы над функцией они должны работать вместе. У каждой группы свои задачи (написание кода, тестирование, автоматизация и т.п.), но чтобы сделать всю работу, они должны действовать сообща. Нельзя переходить к следующей функции, если текущий набор функций не проработан окончательно и не стабилизирован.

Запомните: одновременно должно разрабатываться функций не более, чем вы можете обеспечить их сотрудниками. Иначе говоря, число оперативных команд должно основываться на числе функций, для которых допустима параллельная работа (разработка и тестирование). Если тестировщиков больше, чем разработчиков, или наоборот, то при использовании такой модели разработки команда считается несбалансированной, и вам следует набрать дополнительный персонал в те области, где испытывается дефицит.

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

Через каждые 4-6 недель команда должна отводить 1-2 недели (в зависимости от сложности проекта) на тестирование, стабилизацию и интеграцию функций, завершённых к данному моменту. Такие периоды стабилизации и интеграции идут на пользу команде, функциональности и качеству. Вы можете завершить незаконченное тестирование, начать интегральную проверку функциональности и определить проблемы, которые следует решить, прежде чем продолжить работу над проектом. Не обращайте особого внимания на мелкие неисправности и детали. Просто перед началом очередной стадии убедитесь, что структурно и функционально проект находится в хорошем состоянии. В течение этого периода все члены команды должны направлять свои усилия только на стабилизацию и интеграцию. Не работайте над новыми функциями, кодом или чем-то ещё до тех пор, пока вы не будете уверены в стабильности того, что уже построено.

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

Максимально возможная автоматизация процесса тестирования — ключ к параллельному тестированию (и раннему обнаружению ошибок). Автоматизация предоставит вам следующие преимущества:

• Сокращение внутреннего цикла тестирования

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

• Сокращение потребностей в персонале

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

• Проверка изменений, внесённых в последний момент

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

• Обеспечение полноты тестирования для новых выпусков

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

• Предыдущая
• 26/64
• Следующая