Мой знакомый - сантехник. Перед подключением труб в новом здании к водопроводу он заполняет трубы дымом и смотрит, не попадает ли дым из труб в помещения. Зачем он это делает? Потому что, если имеются какие-то зазоры или плохо изолированы стыки, гораздо легче очистить здание от дыма (т. к. он просто рассеется), чем от воды. Заметить дым в комнатах также проще, чем проверять, если ли потечки на стенах. Это гораздо быстрее, чем проверять каждую трубу сантиметр за сантиметром, а в итоге получить ту же самую информацию. После завершения дымового теста поступает вода и начинается другое, более специфическое тестирование, например гарантирующее правильность давления на разных этажах.
Аналогично происходит дымовое тестирование программного обеспечения. Дымовой тест (smoke test) объединяет минимальное количество тестов, выполняемых для подтверждения того, что тестируемая система готова к проведению дальнейшего тестирования. Его можно назвать стражем дальнейшего тестирования — до тех пор, пока система не способна выполнять какой-то минимальный набор операций, вы не можете приступить к запуску полноценного тестового набора. Обычно дымовой тест представляет собой небольшое количество тестов, проверяющих, может ли быть установлена программа, работают ли ее основные функции и не возникают ли очевидные проблемы.
Например, если вы тестируете интернет-магазин, вам надо проверить, что пользователь может зайти на сайт, найти товар и добавить его в корзину. При полноценном тестировании проверяются многочисленные граничные случаи и пути, а также такая вспомогательная функциональность, как рекомендации и обзоры. В качестве другого примера можно привести дымовое тестирование компилятора, проверяющее, что он может откомпилировать программу "Привет, мир!", а полученный в итоге исполняемый файл действительно печатает на экране "Привет, мир!". В дымовом тестировании не будет проверяться, что произойдет, когда в коде присутствуют сложные булевы выражения, или если отсутствует библиотека, на которую имеется ссылка в коде, и будет ли выдаваться нужное сообщение об ошибке для кода, который нельзя откомпилировать. Дымовое тестирование просто определяет, что система способна выполнять базовые функции. Это очень полезно, когда система должна либо работать полностью, либо не работать вообще, например при установке части программного обеспечения на новой архитектуре. Если код скомпилировался неправильно, то весьма вероятно, что программа не запустится. Дымовое тестирование позволит нам обойти всю работу по настройке соответствующего тестового окружения, если программа просто не работает.
Зачем заморачиваться с дымовым тестированием перед выполнением полноценного тестового набора? Разве не найдутся и без него в итоге те же самые проблемы? По всей вероятности, да, но ключевыми словами здесь являются "в итоге". Дымовое тестирование позволяет вам определить, готова ли программа к тестированию без запуска полноценного тестового набора. Зачастую настройка системы для тестирования сопряжена с такими расходами, как установка ПО на серверах и компьютерах клиентов, изучение тест-планов и генерация тестовых данных. Если программа настолько неработоспособна, что даже не выполняет базовые функции, то благодаря дымовому тестированию вы не потратите время на работу, связанную с прогоном всех тестов.
Приведу пример из своей жизни. Однажды я работал над проектом, в рамках которого мы еженедельно выпускали новую версию программы. Каждую неделю эту новую версию необходимо было устанавливать в лаборатории примерно на 15 разных компьютерах. Установка программы и обновление тестовых данных для новой версии — даже при помощи скрипта через сеть — обычно занимали несколько часов. Однако иногда у программы было столько дефектов (или несколько, но критических), что она была практически непригодной для тестирования. Такие ошибки, как постоянное повреждение данных или неспособность пользователей авторизоваться, делали тестирование этой версии более сложным, чем обычно. Вместо того чтобы узнать об этом после утра, потраченного на установку и обновление, мы запускали быстрый дымовой тест и узнавали об этих ошибках в самом начале рабочего дня. Благодаря этому тестировщики получали дополнительное время для работы над чем-то еще (например, они могли заняться созданием тестовых скриптов или работой с инструментами автоматизации), а разработчики узнавали раньше, что существует проблема с программой. В результате дефекты исправлялись быстрее, и это означало, что тестировщики могли вернуться к работе по тестированию программы.
Дымовое тестирование может быть сценарным (scripted) и импровизационным (unscripted). В импровизационном тестировании опытный тестировщик или пользователь просто "играет" с программой некоторое время перед началом настоящего тестирования. Обычно этим занимается человек, хорошо знакомый с программой, для того, чтобы гарантировать, что протестирована наиболее важная функциональность, известные дефекты были исправлены, а программа в целом работает как необходимо. Сценарное тестирование означает, что существует конкретный тестплан, который определяет необходимые для выполнения тест-кейсы. И если сценарное тестирование дает нам отрегулированную среду и помогает отслеживать то, что уже работало, то импровизационное тестирование является гораздо более гибким и позволяет тестировщикам проверить различные аспекты программы для различных релизов.
Еще более мягкой версией дымового тестирования является медиатестирование. В нем проверяется, что все соответствующие файлы были записаны на носитель информации правильно и могут быть прочитаны. Это просто окончательная проверка, что диск не был поврежден перед отправкой его заказчику или что файлы были помещены на сервере в нужный каталог. Она может быть совсем простой — файлы на диске должны быть по битам эквивалентны файлам исходной локации, или же чуть более сложной, заключающейся в том, чтобы запустить диск на компьютере и убедиться, что начинается установка программы.