Проводить дымовое и санитарное тестирование начинают сразу же после выхода очередной версии проекта. Для многих молодых тестировщиков этот процесс кажется абсолютным хаосом. Узнал себя? Тогда эта статья для тебя. Сейчас мы рассмотрим определения дымового и санитарного тестирования, а также покажем разницу между ними на легких для понимания примерах.
Дымовое тестирование:
Дымовое тестирование проводят для того, чтобы убедиться в пригодности полученного билда к тестированию. Его также называют проверкой “нулевого дня”.
Именно этот вид тестирования не даст потратить время впустую. Логично, что тестирование всего приложения не имеет смысла, если есть проблемы с ключевыми характеристиками и не исправлены критичные баги.
Санитарное тестирование:
Санитарное тестирование проводят на стадии релиза для проверки основного функционала приложения. Дальше обычно не углубляются. Такое тестирование иногда называют сокращенной версией регрессионного тестирования.
Когда сроки релиза поджимают, выполнить тщательное регрессионное тестирование практически невозможно. В этом случае с работой отлично справляется санитарное тестирование, которое проверяет работу главных функций приложения.
Пример для лучшего понимания разницы между дымовым и санитарным тестированием:
Есть проект, для которого запланирован первоначальный релиз. Команда разработчиков выпускает билд на тестирование, команда тестировщиков начинает работу. Самое первое тестирование — это тестирование на пригодность. Нужно выяснить, можно работать с этой версией или нет. Это и есть дымовое тестирование. Если команда дает добро на дальнейшую работу с билдом, он отправляется на более глубокие стадии тестирования. Представим, что у билда есть три модуля: “Логин”, “Админ” и “Сотрудник”. Команда тестировщиков проверяет работоспособность исключительно основных функций каждого из модулей, не углубляясь в проверку частностей. Это будет санитарное тестирование.
Еще несколько различий между дымовым и санитарным тестированием:
- Дымовое тестирование проводится и разработчиками, и тестировщиками;
- Санитарное тестирование проводится только тестировщиками.
- Дымовое тестирование охватывает весь основной функционал приложения от начала до конца;
- Санитарное тестирование проверяет только определенный компонент приложения.
- Дымовое тестирование проходит как стабильный, так и не стабильный билд;
- Санитарное тестирование проходит относительно стабильная версия сборки.
Кирилл Флягин, геймдизайнер, QA Lead
Проведем летнюю аналогию с этими видами тестирования. Допустим, вы хотите купить арбуз. Дымовое тестирование — это когда вы проверяете его визуально, смотрите на полоски, сжимаете, стучите, оцениваете. Есть мастера, которые умудряются так купить действительно вкусную ягоду. В санитарном тестировании вы вырезаете пирамидку в верхней части и проверяете ее цвет (как один из компонентов), при этом совсем не знаете, такой ли арбуз весь. Но за вырезанную часть вы полностью уверены.
Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:- Дымовые тесты : выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции AUT (Application Under Test) работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьёзные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.
- Санитарное тестирование : используется каждый раз, когда мы получаем относительно стабильный билд ПО, чтобы определить работоспособность в деталях. Иными словами, здесь проходит валидация того, что важные части функциональности системы работают согласно требованиям на низком уровне.
- Ре-тест : проводится в случае, если фича/функциональность уже имела дефекты, и эти дефекты были недавно исправлены
- Регрессионные тесты : собственно то, что занимает львиную долю времени и для чего существует автоматизация тестирования. Проводится регрессионное тестирование AUT тогда, когда нужно убедиться что новые (добавленные) функции приложения / исправленные дефекты не оказали влияния на текущую, уже существующую функциональность, работавшую (и протестированную) ранее.
| Дымовые (Smoke) | Санити (Sanity) | Регрессионные (Regression) | Ре-тест (Re-test) |
|---|---|---|---|
| Исполняются с целью проверить что критически важные функциональные части AUT работают как положено | Нацелено на установление факта того, что определённые части AUT всё так же работают как положено после минорных изменений или исправлений багов | Подтверждают, что свежие изменения в коде или приложении в целом не оказали негативного влияния на уже существующую функциональность/набор функций | Перепроверяет и подтверждает факт того, что ранее заваленные тест-кейсы проходят после того, как дефекты исправлены |
| Цель - проверить «стабильность» системы в целом, чтобы дать зелёный свет проведению более тщательного тестирования | Целью является проверить общее состояние системы в деталях, чтобы приступить к более тщательному тестированию | Цель - убедиться что свежие изменения в коде не оказали побочных эффектов на устоявшуюся работающую функциональность | Ре-тест проверяет что дефект исправлен |
| Перепроверка дефектов не является целью Smoke | Перепроверка дефектов не является целью Sanity | Перепроверка дефектов не является целью Regression | Факт того что дефект исправлен подтверждает Re-Test |
| Дымовое тестирование выполняется перед регрессионным | Санитарное тестирование выполняется перед регрессионным и после smoke-тестов | Проводится на основании требований проекта и доступности ресурсов (закрывается автотестами), «регресс» может проводиться в параллели с ре-тестами | - Ре-тест выполняется перед sanity-тестированием - Так же, приоритет ре-теста выше регрессионных проверок, поэтому должно выполняться перед ними |
| Может выполняться автоматизированно или вручную | Чаще выполняется вручную | Лучший повод для автоматизации данного вида тестирования, т.к. ручное может быть крайне затратным по ресурсам или времени | Не поддаётся автоматизации |
| Является подмножеством регрессионного тестирования | Подмножество приёмочного тестирования | Выполняется при любой модификации или изменениях в уже существующем проекте | Ре-тест проводится на исправленной сборке с использованием тех же данных, на том же окружении, но с различным набором входных данных |
| Тест-кейсы часть регрессионных тест-кейсов, но покрывающие крайне критичную функциональность | Санитарное может выполняться без тест-кейсов, но знание тестируемой системы обязательно | Тест-кейсы регрессионного тестирования могут быть получены из функциональных требований или спецификаций, пользовательских мануалов, и проводятся вне зависимости от того, что исправили разработчики | Используется тот же самый тест-кейс, который выявил дефект |
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
- Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
- Мы знаем все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json.
- Выполнив один простой GET-запрос к одной из этих точек входа, и получив ответ в формате json, мы уже убеждаемся что дымное тестирование пройдено.
Если же одна из этих точек входа так же возвращает данные из БД, тогда как первая - нет, нужно дополнительно выполнить ещё один запрос, чтобы убедиться что приложение
верно обрабатывает запросы к базе. И на этом «дымный» тест закончен.То есть мы выполнили запрос - от сервиса пришёл ответ, и он не «задымился», то есть не вернул ошибку 4хх или 5хх, и что-то невнятное, вместо json. На этом можно сказать что «дымный» тест пройден. Для проверки того, что работает так же и UI достаточно просто один раз открыть страницу в браузере.
- Санитарное тестирование в данном случае будет состоять из выполнения запроса ко всем 10 точкам входа в api, сверкой полученного json с ожидаемым, а так же наличием требуемых данных в нём.
- Регрессионные тесты будут состоять из smoke + sanity + UI выполняемые вместе в одной куче. Цель: проверить что добавление 11-ой точки входа не поломало, к примеру, восстановление пароля.
- Ре-тест в данном примере это точечная проверка что, к примеру, сломавшаяся точка входа в api в следующем билде отрабатывает как задумывалось.
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.UPD
:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность . В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».
Спасибо за наводку
Означает минимальный набор тестов на явные ошибки . «Дымовой тест» обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.
Примеры
- Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным.
- Ошибки при соединении с базой данных, актуально для архитектуры клиент-сервер .
История
Первое своё применение этот термин получил у печников, которые, собрав печь , закрывали все заглушки, затапливали её и смотрели, чтобы дым шёл только из положенных мест.
Повторное «рождение» термина произошло в радиоэлектронике. Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме. Если первое включение не выявило перегрева, то прибор включается снова на большее время. Проверка повторяется. И так далее несколько раз. Выражение «smoke-test» используется инженерами в шуточном смысле, так как появления дыма, а значит и порчи частей устройства, стараются избежать.
Автоматизация
Smoke Tests легче автоматизировать, чем более глубокое и интеллектуальное тестирование. Автоматизация снижает количество ручного труда и поэтому позволяет проводить эти тесты чаще. Чем чаще выполняются тесты, тем раньше становится известно о проблемах, выявляемых этими тестами. Чем раньше становится известно о проблеме, тем легче её устранить. Автоматизация тестирования часто выполняется с помощью средств непрерывной интеграции .
Напишите отзыв о статье "Smoke test"
Ссылки
- на Jargon File (англ.)
- msdn.microsoft.com/ru-ru/library/ms182613(VS.90).aspx - Правила по кратким тестам от Майкрософт.
Отрывок, характеризующий Smoke test
Весь день она жила только надеждой того, что ночью она уввдит его. Но теперь, когда наступила эта минута, на нее нашел ужас того, что она увидит. Как он был изуродован? Что оставалось от него? Такой ли он был, какой был этот неумолкавший стон адъютанта? Да, он был такой. Он был в ее воображении олицетворение этого ужасного стона. Когда она увидала неясную массу в углу и приняла его поднятые под одеялом колени за его плечи, она представила себе какое то ужасное тело и в ужасе остановилась. Но непреодолимая сила влекла ее вперед. Она осторожно ступила один шаг, другой и очутилась на середине небольшой загроможденной избы. В избе под образами лежал на лавках другой человек (это был Тимохин), и на полу лежали еще два какие то человека (это были доктор и камердинер).Камердинер приподнялся и прошептал что то. Тимохин, страдая от боли в раненой ноге, не спал и во все глаза смотрел на странное явление девушки в бедой рубашке, кофте и вечном чепчике. Сонные и испуганные слова камердинера; «Чего вам, зачем?» – только заставили скорее Наташу подойти и тому, что лежало в углу. Как ни страшно, ни непохоже на человеческое было это тело, она должна была его видеть. Она миновала камердинера: нагоревший гриб свечки свалился, и она ясно увидала лежащего с выпростанными руками на одеяле князя Андрея, такого, каким она его всегда видела.
Он был таков же, как всегда; но воспаленный цвет его лица, блестящие глаза, устремленные восторженно на нее, а в особенности нежная детская шея, выступавшая из отложенного воротника рубашки, давали ему особый, невинный, ребяческий вид, которого, однако, она никогда не видала в князе Андрее. Она подошла к нему и быстрым, гибким, молодым движением стала на колени.
Он улыбнулся и протянул ей руку.
Для князя Андрея прошло семь дней с того времени, как он очнулся на перевязочном пункте Бородинского поля. Все это время он находился почти в постояниом беспамятстве. Горячечное состояние и воспаление кишок, которые были повреждены, по мнению доктора, ехавшего с раненым, должны были унести его. Но на седьмой день он с удовольствием съел ломоть хлеба с чаем, и доктор заметил, что общий жар уменьшился. Князь Андрей поутру пришел в сознание. Первую ночь после выезда из Москвы было довольно тепло, и князь Андрей был оставлен для ночлега в коляске; но в Мытищах раненый сам потребовал, чтобы его вынесли и чтобы ему дали чаю. Боль, причиненная ему переноской в избу, заставила князя Андрея громко стонать и потерять опять сознание. Когда его уложили на походной кровати, он долго лежал с закрытыми глазами без движения. Потом он открыл их и тихо прошептал: «Что же чаю?» Памятливость эта к мелким подробностям жизни поразила доктора. Он пощупал пульс и, к удивлению и неудовольствию своему, заметил, что пульс был лучше. К неудовольствию своему это заметил доктор потому, что он по опыту своему был убежден, что жить князь Андрей не может и что ежели он не умрет теперь, то он только с большими страданиями умрет несколько времени после. С князем Андреем везли присоединившегося к ним в Москве майора его полка Тимохина с красным носиком, раненного в ногу в том же Бородинском сражении. При них ехал доктор, камердинер князя, его кучер и два денщика.
Простые ошибки могут быть фатальными для вашего сайта — особенно если Вы — SaaS (eng. Software as a Service) компания, как мы. Если пользователь заходит на Ваш сайт и не может справиться с простым заданием, таким как зарегистрироваться или сбросить свой забытый пароль, Вы рискуете потерять этого пользователя навсегда.
Мы испытали это на своей собственной шкуре. Безусловно, иметь своих людей в команде, которые тестируют приложение и ищут баги — это важно, но не всегда уместно или недостаточно тщательно. В этой статье, мы хотим представить Вам, гуманитариям, мир smoke-тестов.
Если все же у Вас останутся вопросы — восполнить пробелы вы сможете, посетив
Smoke-тестирование первоначально было придумано, чтобы объяснить как инженеры-электротехники проверяли работает ли их прибор — включали его и если дым шел…
Подождите, как это может быть применимо к приложениям?
Важность (и рентабельность) smoke-тестов, как правило, неизвестна для менеджеров-гуманитариев и соучредителей. Систематические smoke-тесты могут рассматриваться как неотъемлемая часть для предотвращения роста вероятности взлома. Они минимизируют вероятность того, что в Вашем веб-приложении или приложении для телефона произойдет сбой — и как все мы знаем, только одна неудача и вы можете потерять клиента навсегда.
Это вводное руководство о том, что это такое, как это может быть реализовано, какие ресурсы используются для его проведения и примеры, направляющие читателей.
Smoke-тесты созданы для того, чтобы проверить основную функциональность и должны быть неотъемлемой частью Вашего процесса тестирования. Они могут включать что-то простое, типа «Могу ли я зарегистрироваться?».
Smoke-тестирование помогает убедиться, что ни одна из основных и очевидных неудач не оставлена на волю случая. Не следует проводить более глубокий тест, пока вы не выполнили smoke-тесты на 100%, потому что они очищают программное обеспечение от фундаментальных ошибок.
Шаг 1: Решите, что надо тестировать
Определите, что Ваше приложение стремится достичь. Каковы наиболее очевидные «детские» шаги, которые необходимы, чтобы в него попасть? Каковы минимальные жизненно важные требования и в какой логической последовательности Вы их перечислите?
Создайте набор тестов. Набор тестов — это сгруппированная совокупность тест-кейсов (тестовых случаев), связанная определенным образом (например, по функциональности).
Smoke-тестирование не будет включать в себя переменные или вопросы вида «что если?». Оно предполагает только ответы да/нет, но прежде чем переходить к более подробному тестированию, все тест-кейсы должны быть пройдены с положительным результатом.
Давайте возьмем для примера создание интерактивного форума. Для того, чтобы он работал я должен:
- зарегистрироваться.
- создать Имя пользователя.
- загрузить фото на аватарку.
- писать сообщения.
- отвечать на сообщения.
Шаг 2: Записываем результаты в таблицу
Изображение выше — пример от нашей команды. Вы можете найти шаблон . Это необходимо для того, чтобы сохранить записи того, что у нас работает, а что нет — базовая организация сэкономит кучу времени в дальнейшем. Мы разделили наши результаты на пройдено, частично и провалено.
- Пройдено: все работает идеально.
- Частично: изначально вы можете не понимать, что некоторые действия могут быть еще подразделены, и поэтому одна часть работает, а другая — нет.
- Провалено: не работает.
Мы описали точные шаги, которые мы хотели воспроизвести, а затем, в следующей графе, добавили краткое описание того, что мы ожидаем на выходе. Пример:
Шаг 3: Автоматизируем smoke-тесты
Очень важно не принимать за аксиому то, что если какое-либо действие было пройдено один раз, оно будет всегда с положительным исходом. Smoke-тесты позволяют постоянно проверять, что основные функции не пострадали с течением времени или не были поломаны в течение долгого периода.
Не прекращай smoke-тестирование. Никогда.
Когда Ваш набор тест-кейсов для smoke-тестирования завершается с успешным исходом на 100%, подумайте об их автоматизации . Рекомендуемая частота проведения smoke-тестов — каждый день, если Ваша компания занимается разработкой каждый день.
Минимальная необходимость — проводите прогон smoke-тестов перед каждым релизом и после каждого патча.
Эмпирическое правило для smoke-теста:
- Минимальное время: 30 минут.
- Максимальное время: 60 минут.
В дальнейшей перспективе автоматизация smoke-тестов экономит время, но при прогоне одних и тех же тестов снова и снова человеческий глаз может перестать замечать детали, а машина нет.
Если Вы хотите создать простую компьютерную программу, которая состоит из одного файла, Вам просто необходимо собрать и связать весь написанный вами код в этот файл. На самом обычном проекте, которым занимается команда разработчиков, существуют сотни, даже тысячи файлов. Это «способствует» тому, что процесс создания выполнимой программы становится всё более сложным и трудоёмким: вы должны «собирать» программу из различных компонентов.
Практика применяемая, к примеру, в Microsoft и некоторых других компаниях, занимающихся разработкой ПО, заключается в ежедневной сборке (билдовании) программы, которая дополняется дымовым тестированием. Ежедневно, после того, как каждый файл собран (сбилдован, построен), связан (слинкован), и объединен в выполнимую программу, сама программа подвергается достаточно простому набору тестов, цель которых заключается в том, чтобы увидеть, «дымит» ли программа во время работы. Эти тесты и называются дымовыми (от англ. smoke - дым). Чаще всего этот процесс достаточно хорошо автоматизирован (или должен таким быть).
ПРЕИМУЩЕСТВА. Этот простой процесс обеспечивает несколько существенных преимуществ.
Минимизация риска при интеграции
Один из самых существенных рисков, с которым сталкивается команда разработчиков, заключается в том, что сами разработчики работают с кодом отдельно, независимо друг от друга, в результате чего сложная программа не работает, как ожидается при сборке наработанного кода. В зависимости от того, когда была обнаружена несовместимость в проекте, отладка программы может происходить дольше, чем при более ранней интеграции, особенно в случае изменения интерфейса программы или после имплементации серьезных правок основных частей программы.
Ежедневная сборка и прогонка дымовых тестов дает возможность снизить риск интеграционных ошибок, вовремя реагировать на них и не допускать их накопления.
Снижения риска низкого качества программного продукта
Низкое качество продукта напрямую зависит от неудач и проблем при интеграции. Ежедневная прогонка минимального набора дымовых тестов не дает ошибкам и проблемам взять верх на проекте. Если вы довели проект до стабильного состояния раз, он будет оставаться стабильным всегда. Этим вы никогда не допустите снижения качества до уровня, на котором и возникают ошибки.
Помощь в диагностике ошибок
Если в один прекрасный день продукт не собрался (собрался с ошибками), то с помощью ежедневной сборки и прогона набора дымовых тестов гораздо проще найти причину проблемы. Работающий продукт вчера и не работающий сегодня - это явный намек на то, что что-то не ладное произошло между двумя сборками.
Улучшение морального духа
Если продукт работает и с каждым днем обрастает все более новыми качествами и функциями, моральный дух разработчиков, по идее, должен расти и абсолютно не важно, что же именно должен делать этот продукт. Разработчику всегда приятно наблюдать за своим работающим «детищем», даже если продукт выводит на экран прямоугольник:)
Использование ежедневного билдования и дымовых тестов
Вот несколько подробностей этого принципа.
Ежедневная сборка приложения
Фундаментальной частью ежедневной сборки является сборка той части, что была сделана последней. Джим Маккарти (Jim McCarthy) в журнале Dynamics of Software Development (Microsoft Press, 1995) назвал ежедневное билдование проекта его сердцебиением. Если сердцебиения нет - проекта нет, он мертв. Менее образно ежедневное билдование описали Майкл Касамано (Michael Cusumano) и Ричард Селби (Richard W. Selby), назвав его синхронизирующим импульсом проекта (Microsoft Secrets, The Free Press, 1995). Каждый разработчик пишет код по своему и он, код, может выходить за общепринятые на проекте рамки - это нормально, но при каждом воздействии синхронизирующего импульса код возвращается к стандарту. Настаивая на ведении разработки с использованием импульса синхронизации постоянно, Вы препятствуете выходу проекта из синхронизации полностью.
В некоторых компаниях принято собирать проект не каждый день, а раз в неделю. Эта система ошибочна, т.к. в случае «поломки» в проекте на текущей неделе, может пройти ещё пара недель до следующей удачной сборки. В таком случае компания теряет все преимущества системы ежедневной сборки проекта.
Проверка на неудачную сборку
В случае ежедневной сборки проекта подразумевается, что проект должен работать. Однако, если же проект оказывается не рабочим, то его починка становится задачей с приоритетом 1.
На каждом проекте есть свой стандарт и признак того, что называется «поломка при сборке». Этот стандарт должен задавать уровень качества, который является достаточным для того, чтоб отслеживать незначительные дефекты и не упускать из внимания дефекты, «блокирующие» проект.
Хорошей сборкой является та, при которой как минимум:
- успешно компилируются все файлы, библиотеки и другие компоненты;
- ссылки на все файлы, библиотеки и другие компоненты действительны;
- не содержатся никаких устойчивых системных, исключающих возможность правильной работы прикладной программы, блокирующих ошибок;
- все дымовые тесты проходят.
Ежедневные дымовые тесты
Дымовые тесты должны выполняться на всем проекте от начала до конца. Они не должны быть исчерпывающими и всесторонними, но должны содержать проверку всех основных функций. Дымовое тестирование должно быть достаточно глубоким, чтоб, в случае удачного их прохождения, можно было назвать проект стабильным и назвать его таким, что может подвергаться более глубокому тестированию.
Смысл ежедневной сборки теряется без дымового тестирования. Этот процесс стоит на страже качества продукта и не допускает никаких интеграционных проблем. Без этого процесс ежедневной сборки является пустой тратой времени, цель которой - проверка компиляции.
Дымовое тестирование должно развиваться на уровне с проектом. В начале, дымовые тесты будут проверять что-то простое, например, может ли проект выдавать сообщение «Hello, World!». С развитием системы, дымовые тесты становятся более глубокими. Время, которое тратится на первые дымовые тесты, исчисляется несколькими секундами, однако с ростом системы растет и количество необходимого для дымового тестирования времени. В конце проекта дымовое тестирование может длится на протяжении часов.
Определение группы сборки
На большинстве проектов, есть определенный сотрудник, ответственный за проверку ежедневной сборки системы и выполнение дымовых тестов. Эта работа является частью обязанностей данного сотрудника, но на больших проектах таких сотрудников может быть больше и такая работа является основной их обязанностью. Например, в группе сборки проекта Windows NT 3.0 было четыре человека (Pascal Zachary, Showstopper! , The Free Press, 1994).
Добавляйте ревизию в сборку только если это имеет смысл
Обычно, разработчики по отдельности пишут код достаточно медленно, чтобы можно было добавлять значимые изменения в систему ежедневно. Они должны работать над большой частью кода и интегрировать его в систему раз в несколько дней.
|
Введите систему штрафов за срыв выпуска очередной сборки (выпуск не рабочей сборки). |
На большинстве проектов есть система штрафов за срыв выпуска очередной сборки. В самом начале проекта стоит четко дать понять, что сохранение рабочего проекта является задачей самого высокого приоритета. Срыв выпуска очередной сборки может быть исключением, но ни как не правилом. Настаивайте на том, чтоб разработчики оставляли все дела до тех пор, пока система опять не заработает. В случае частого срыва сборки (выпуска не рабочей сборки) достаточно трудно вернуть проект в нормальное русло.
Незначительные штрафы подчеркивают высокую степень необходимости следить за качеством сборки системы. На некоторых проектах разработчикам, по вине которых сборка «падает», выдают леденцы за выпуск неработающей сборки. На двери кабинета такого разработчика висит соответствующая вывеска до тех пор, пока он не починит сборку (при условии, что у разработчиков отдельные кабинеты:)). На других проектах виновные разработчики должны носить искусственные козлиные рога или вносить определенную сумму в «фонд морального духа» (примеры взяты из истории реальных компаний).
Но на некоторых проектах вводятся более серьезные штрафные санкции. Например, разработчики компании Microsoft, состоящие в проектах с высоким приоритетом (Windows NT, Windows 95, Excel), носили пейджеры и, в случае обнаружения проверки, они должны были прибыть на работу. Даже если поломка или ошибка были обнаружены в 3 утра.
Собирайте систему и «дымите» ее даже под давлением
Когда давление графика выпуска проекта усиливается, работа по ежедневной проверке сборки системы может казаться бессмысленной тратой времени. Однако это не так. В стрессовых ситуациях разработчики часто допускают ошибки. Они чувствуют такое давление необходимости выпускать имплементации, какого в обычных условиях просто нет. Они проверяют свой код unit-тестами куда менее внимательно, нежели обычно. В таких ситуациях код стремится к состоянию энтропии гораздо быстрее чем в менее стрессовых ситуациях.
Кто выигрывает от этого процесса? Некоторые разработчики протестуют против ежедневных сборок, обосновывая свои протесты непрактичностью этого занятия и его большими временными затратами. Но все сложные системы последнего времени подвергались ежедневным сборкам и прогонке дымовых тестов. К моменту своего выпуска, Microsoft Windows NT 3.0 содержала в 40 000 файлах 5,6 миллионов строк. Полная сборка занимала 19 часов и выполнялась на нескольких компьютерах. Несмотря на это, разработчики умудрялись ежедневно собирать систему. Будучи профессиональной командой, группа разработчиков NT, своим успехом во многом обязана ежедневной сборке. Те разработчики, которые работают на менее сложных проектах и, поэтому, не пользуются преимуществами процесса ежедневной сборки, должны задуматься над тем, чтоб придумать себе какие-то разумные объяснения.
