Из собственного опыта
Во время разработки BoundsChecker одной из главных проблем была производительность. Ничего не стоило полностью поменять характеристики производительности продукта, добавив несколько строчек кода в критичные функции. Чтобы обнаружить источник проблем с производительностью, мы использовали несколько тестовых приложений, которые нагружали BoundsChecker до предела. Одно из таких приложений называлось Torture. Оно создавало 256 параллельных потоков и запрашивало и освобождало десятки тысяч блоков памяти в куче. В течение всего периода разработки мы запускали Torture (и подобные программы), чтобы определить, не снизилась ли производительность продукта. Так как мы хотели видеть результат сразу, мы стали каждую ночь запускать Torture как часть наших автоматических регрессивных тестов и сравнивать показатели производительности. С таким уровнем контроля мы обычно могли определять снижение производительности в сборке предыдущего дня. Весьма неплохо!

Коррекция после тестирования
Период стабилизации и интеграции также позволяет исправить серьёзные ошибки до перехода к следующему набору функций. Тестирование функций и их интеграции выявит множество ошибок, а это именно то, что нужно. Вы сможете заранее устранить эти ошибки, что увеличит продуктивность дальнейшей работы. Но время на поиск и исправление этих ошибок должно быть учтено в графике.
Оценка после тестирования
Когда период стабилизации и интеграции подходит к концу, не забудьте оценить результаты и произвести изменения. Усовершенствовать ли аппаратную часть? Нужно лучше тестировать подсистемы? Требуется ли лучшее определение API? Больше людей? Какие бы изменения ни требовалось провести, это нужно сделать сейчас.
Это также подходящий момент решить, что имеет смысл улучшить во время следующего периода стабилизации и интеграции. Смотрите на фазу стабилизации и интеграции, как на проверку ПО и команды, которая его создаёт. Вы должны оценить производительность и программ, и людей и провести все необходимые изменения.
Пример тестирования
Рассмотрим простой пример, чтобы показать, как все эти области работают вместе. Допустим, вы создаёте Web-приложение и проходите фазу стабилизации и интеграции. Вы уверены в работоспособности определённых функций. Скажем, вам нужно только создание, редактирование и удаление покупателей. Но чтобы заставить эти функции работать, нужно потрудиться. Их работа затрагивает пользовательский интерфейс, Web-сервер, промежуточные звенья и базу данных. Все эти компоненты взаимосвязаны. В этом случае проверка интеграции может состоять из таких заданий:
• попытаться добавить покупателя;
• некорректное добавление покупателя (проверка полей);
• повторное добавление одного и того же покупателя;
• редактирование сведений о покупателе (всех полей, ни одного поля);
• редактирование сведений о несуществующем покупателе;
• некорректное редактирование сведений о покупателе;
• удаление существующего покупателя;
• удаление несуществующего покупателя.
Завершив тестирование интеграции, вы будете обладать сведениями о производительности приложения. Как долго добавить покупателя? А удалить? Получить сообщение об ошибке? Хотя может быть несколько причин плохой производительности, если вы не можете быстро добавить покупателя в маленькой базе данных, возможно, имеется проблема, требующая дополнительного исследования. Есть ли проблемы с драйверами БД? Может быть, у вас плохая структура БД? Нет ли претензий к промежуточному уровню? Чтобы это проверить, через определённое время нужно проводить мониторинг, устанавливать планку производительности для основных транзакций и регулярно сравнивать результаты, чтобы знать, что вы на верном пути.
Задача тестирования интеграции — убедиться в том, что к завершению первого этапа функциональность продукта удовлетворительна. Если это так, вы готовы приступить к следующему крупному этапу. Если нет, скажем, вы не можете добавить, отредактировать или удалить покупателя, остановитесь и исправьте всё, что мешает двигаться вперёд.
Тестирование бета-версий и кандидатов на выпуск
Тестирование бета-версий и кандидата на выпуск — ключевой этап проекта. Бета-тест — это возможность дать клиентам проверить и оценить ваше ПО за месяцы до его выпуска или применения в реальной рабочей среде. В большинстве проектов во второй половине цикла разработки предусматривается 2-3 бета-периода. Во время каждого такого периода привлекаются десятки или сотни, а иногда тысячи пользователей. Кандидат на выпуск потенциально является последней сборкой продукта, и он ещё важнее. Если последний круг тестирования завершился без серьёзных проблем, то он представляет ПО, которое вы намереваетесь предоставить потребителям. (Подробно о бета-тестировании см. главу 13, о тестировании кандидатов на выпуск — главу 14.)
Одна из главных задач при работе с бета-версиями и кандидатами на выпуск — определить, что следует протестировать в сборке, прежде чем предоставить её сторонним организациям. Конечно, вы не сможете заново протестировать весь продукт. Полное тестирование и доводка продукта займёт месяцы, если не годы. Вместо этого вам нужно составить очень конкретный и хорошо продуманный план, который будет выполнен в очень сжатые сроки. (Для большинства небольших и средних проектов норма составляет 7-10 дней.) В планы тестирования бета-версий и кандидатов на выпуск нужно включить:
• выполнение всего набора автоматических тестов;
• выполнение набора ручных тестов, включая:
* нормальную установку/проверку лицензии (полностью вручную);
* тестирование базовых функций продукта (полностью вручную);
* тестирование производительности и нагрузки (полностью вручную);
* выборочную проверку на всех поддерживаемых платформах;
* другие специфические разделы проекта.
Этот список послужит вам хорошей отправной точкой, но для каждого пункта вы должны определить конкретный сценарий тестирования. И если все эти тесты будут успешно пройдены, вы выпустите вашу программу. Если вы не можете успешно выполнить тесты, устраните неполадки и повторите процесс.
Одна из черт грамотного цикла тестирования бета-версии или кандидата на выпуск заключается в его предеказуемости. Вы должны знать, сколько времени займёт выполнение автоматических и ручных тестов. Имея эту информацию, вы сможете точно предсказать, сколько времени займёт тестирование следующей бета-версии или кандидата на выпуск. Зная, сколько времени нужно для тестирования другой сборки, вы сможете оценить риск и стоимость внесения дополнительных изменений.
Кто должен тестировать?
За тестирование должны отвечать все участники проекта, невзирая на лица и отведённые им роли. При использовании продукта с любой целью и в любой форме делать это надо с критической точки зрения. Кем бы вы ни были: менеджером проекта, радостно рассматривающим новую функцию, автором руководства пользователя, проверяющим, как будет работать пример, или специалистом по инженерной психологии, устанавливающим продукт для проверки пользовательского интерфейса — вы должны отслеживать, искать и сообщать о проблемах качества.
Имея сжатые сроки и ограниченные ресурсы, трудно ожидать, что одна группа сможет провести всю работу по тестированию, особенно если учитывать, что в командах тестировщиков дефицит кадров проявляется чаще всего. Так что убедитесь в том, что ваши разработчики, технические писатели, инженерные психологи, менеджер продукта, менеджер проекта, вице-президент или студенты, проходящие летнюю практику, будут искать проблемы каждый раз, когда они используют продукт для своих нужд. Любой ценой заставьте их сообщать о найденных проблемах.
В период стабилизации и интеграции к тестированию приступает вся команда разработчиков — это коллективная работа. Появляется шанс увидеть, где команда находится в данный момент и сколько ещё нужно сделать. Обычно руководитель группы контроля качества выполняет задачу, распределяя ответственность за тестирование между всеми членами команды. Большую часть времени работа проводится в областях, где автоматические тестовые задания справляются плохо. Также сотрудников просят «сыграть роль пользователя» для ключевых частей продукта. Итак, команда, работавшая над продуктом в течение всего цикла разработки, просто незаменима. Это то, что должно стать частью вашей культуры и одним из ваших основных технологических процессов.
Эту идею можно развить ещё дальше — самим использовать собственные программы. Такой подход называют «питаться кормом своей собачки», он хорошо известен в нашей отрасли и может оказаться очень ценным. Для определения и разрешения проблем с качеством не нужно делать ничего, кроме как задействовать свои программы в реальной работе. Даже если в рамках вашей команды разработчиков продукт применить нельзя, попробуйте попросить нескольких опытных пользователей поэкспериментировать с программой. То, что они найдут, может оказаться для вас сюрпризом.
В определённый момент крайне необходимо чётко разграничить обязанности тестировщиков от обязанностей других членов команды (прежде всего разработчиков) в том, что касается тестирования. Чтобы люди концентрировались на своих прямых задачах, необходимо разделение труда.
Разработчики влияют на качество продукта больше всего. В конце концов они находятся ближе всего к коду, и риск внесения ошибок исходит прежде всего от них. Чтобы гарантировать отлов «жучков» до того, как команда тестировщиков увидит функциональный блок, они должны его тестировать в процессе написания. Хороший разработчик ускорит работу тестировщиков, предоставляя им надёжные функции. И наоборот, плохой разработчик затормозит работу тестировщиков, выдавая им компоненты с таким количеством ошибок, что о тестировании уже и речи не будет. Для тестировщика нет ничего более неприятного, чем находить массу очевидных проблем, которые разработчик мог найти сам всего за несколько минут работы.
Из собственного опыта
В NuMega мы готовили вторую бета-версию BoundsChecker 3. Для оценки продвижения проекта мы устраивали ежедневные совещания. Кэрол, наш ведущий специалист по контролю качества (в то время команда тестировщиков состояла из неё одной), настойчиво повторяла, что сборка была крайне неудачной. Она сказала, что больше не будет зря тратить время на её тестирование и останется дома до тех пор, пока разработчики не приведут все в порядок, и быстро ушла.
Я готов был зааплодировать. Не потому, что мне нравилось состояние бета-версии. Кэрол дала понять разработчикам, что в их обязанности входит базовое тестирование программ и самостоятельная работа над проблемами кода. До команды разработчиков это дошло. Мы согласились и занимались тестированием и исправлениями в программе, пока не почувствовали, что готовы позвать Кэрол. Это заняло около двух дней.
В отношении тестирования разработчики имеют ряд обязанностей:
• анализ плана тестирования;
• тестирование на уровне модулей (работает ли функция в большинстве ситуаций);
• предварительное интегральное тестирование (работает ли функция в связке с другими);
• протоколирование или устранение всех неполадок, обнаруженных в программе, когда они сами её использовали.
Команда, отвечающая за контроль качества, пропускает эту простейшую работу. Считается, что тестирование на таком уровне полностью проведено разработчиками до передачи функционального блока тестировщикам. Конечно же, тестировщики не слепо верят в то, что все абсолютно верно, они просто предполагают, что качество продукта находится на уровне, достаточном для того, чтобы приняться за свою работу.
Далее команда, отвечающая за контроль качества, проводит тестирование продукта на другом уровне. Она сосредоточивается на:
• планировании тестов;
• автоматизации создания тестов;
• автоматизации тестирования;
• тестировании функций в различных комбинациях;
• тестировании процедуры установки;
• тестировании интеграции и связи с системой;
• тестировании производительности и нагрузки;
• ручном тестировании (функций, для которых неприменимо автоматическое тестирование);
• диагностике проблем и их протоколировании;
• проверке исправлений и «закрытии» ошибок.
Хотя все эти обязанности привычны для тестировщиков, последняя может быть менее знакомой. «Закрытие» ошибки должен проводить только тестировщик — член оперативной команды. Задача разработчика — исправить ошибку в коде, занести исправление в систему управления исходным кодом и обновить статус ошибки на «Исправлено» в системе устранения неполадок. Но пересмотр всех исправленных ошибок и проверка того, что они действительно исправлены, входит в обязанности тестировщиков. Только после такой проверки ошибка считается официально «закрытой».
Другие критичные моменты для контроля качества
Почти каждая команда столкнётся с рядом других вопросов. Это проблема тестирования на разных платформах, должная роль и использование ручного тестирования, а также инфраструктура, отвечающая потребностям проекта.
Матрица тестирования
Одной из функций контроля качества, занимающей массу времени, является тестирование продукта на широком спектре конфигураций ПО. Сегодня большинство продуктов поддерживают работу под управлением нескольких ОС в различных конфигурациях. Тестировать продукт на всех (если речь идёт о ручном тестировании) — гиблое дело.
К счастью, существует способ здорово облегчить эту задачу. Если у вас есть надёжные автоматические тестовые задания для проверки важнейших функций, можете задействовать их все для всех конфигураций, которые решили поддерживать.
Из собственного опыта
В NuMega мы решили проблему тестирования на нескольких конфигурациях путём распределения их между разработчиками и тестировщиками. Один получил Microsoft Windows 95, другой — Microsoft Windows 98, третий — Microsoft Windows NT 3.51 и ещё один — Microsoft Windows NT 4.0. От каждого требовалось выполнить тест на своей ОС в надежде как можно раньше — в процессе разработки — обнаружить проблемы. Таким простым способом мы почти сразу находили проблемы на всех платформах.

Ручное тестирование
Я столько внимания уделил автоматическому тестированию, что у некоторых из вас мог возникнуть вопрос: стоит ли вообще использовать ручные тесты? Да, но нужно понимать, где их применять. Ручные тесты используются в следующих случаях:
• Для тестирования ключевых функций в случаях, когда автоматические тесты запаздывают или вовсе не существуют
Что, если у вас нет времени или ресурсов для написания всех автоматических тестов, а команда разработчиков уже выдаёт вам готовую функцию? В таком случае нужно приступить к ручному тестированию, чтобы оценка функции проходила согласно графику. Раннее обнаружение ошибок и их устранение остаётся главной задачей.
• Для редко изменяемых, некритичных функций
Иногда значимость автоматического тестирования проигрывает простоте и быстроте ручных тестов. Если небольшую функцию легко протестировать и в ней не предвидится изменений, лучше пропустить автоматические тесты и направить свои усилия на более серьёзные задачи.
• Когда все трещит по швам
Когда сроки поджимают, а вам нужно быстро провести массу тестов, многие любят приглашать дополнительных испытателей, часто это оказываются люди, у которых опыт работы с продуктом небольшой или отсутствует вовсе. Для эффективного выполнения такой задачи следует иметь чёткий план ручного тестирования. В нём нужно описать важнейшие части продукта, которые требуется обследовать, и те моменты, которые нужно проверить наиболее тщательно. Это позволит просто распределить обязанности по тестированию всего продукта, и вы будете уверены, что самые критичные части продукта вошли в планы тестирования.
Но помните: нельзя быть зависимым от ручного тестирования. Его наращивание потребует больших затрат, а тестирование параллельно с разработкой продукта становится затруднительным.
Оборудование для тестирования
В проектах с жёсткими временными рамками нужно быть уверенным, что работа команды не замедляется из-за недостатка элементарного аппаратного или программного обеспечения. В разных командах и проектах требования к оборудованию будут заметно меняться, поэтому ниже перечислены основные требования к оборудованию.
• 2-3 компьютера на каждого тестировщика
Один будет использоваться для производственных нужд: электронной почты, отчётов о неполадках, автоматизации разработки и т.д., а остальные для тестирования. Нужно иметь возможность в любой момент менять конфигурацию тестовых компьютеров.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30