Итак, друзья мои, мы с вами совершили увлекательное путешествие в мир дымового тестирования — от его исторических корней в отопительном оборудовании до современных автоматизированных решений. Как говорится, «дым есть — значит, работает» Локализация программного обеспечения (правда, в нашем случае дым как раз таки не должен появляться). Если в сборке есть ошибки, это помогает нам определить, будет ли любое дальнейшее тестирование пустой тратой времени и ресурсов. Smoke-тесты могут выполняться вручную или автоматически и обычно включают запуск серии простых тестов приложения, чтобы убедиться, что оно отвечает ожидаемому. Этот процесс обычно состоит из из небольшого набора тестов, выполняемых в каждой сборке.
#1 Дымовое Тестирование Вручную
В отличие от тестирования всего программного приложения, основное внимание здесь уделяется проверке базовой функциональности приложения, а не проведению подробного тестирования. Как правило, его выполняют на сборке, для https://deveducation.com/ которой требуется немедленное развёртывание в продакшен среде, например, в случае исправления критической ошибки. Sanity-тестирование обеспечивает быстрый и легковесный способ убедиться, что программное обеспечение работает должным образом, прежде чем переходить к дальнейшему тестированию. В современной разработке ПО этот термин, к счастью, уже не подразумевает реального задымления (хотя некоторые баги иногда заставляют процессор так нагреваться, что невольно начинаешь искать глазами огнетушитель). Теперь это метафора для быстрой проверки жизнеспособности новой сборки программного продукта.
Эта метафора настолько прижилась в IT, что даже самые серьезные технические документации используют её без тени смущения. Команды QA выбирают некоторый набор автоматизированных тестовых сценариев для проведения дымового тестирования. Это экономит больше времени и позволяет разработчику немедленно узнать о статусе сборки. Всякий раз, когда новая сборка развертывается, для этой сборки выполняются записанные скрипты дымового тестирования. Если тест не проходит, они немедленно исправляют сборку и выпускают новую сборку. Команда контроля качества приступит к тестированию основных функций приложения, чтобы найти какие-либо серьезные проблемы в системе или нет.
Вывод из всего этого один, если нет нормальной работы всего D&D – нет нормальной прибыли компании, нет ресурсов на премии, зарплаты, на новые рабочие места и вот это вот всё. Поэтому бизнес так сильно любит нам рассказывать, что нужно быть вовлечённым в продукт, интересоваться происходящим вокруг и смотреть на свою работу чуть шире, чем базовые скиллы твоей компетенции. Рассмотрим для примера нашего клиента — интернет-магазин «Конфаэль». Определение критически важного функционала начинается с анализа сайта. Если есть возможность, лучше дополнительно запросить аналитику у клиента и посмотреть, на что он обращает внимание.
Если твоя команда всё сделала правильно, то на этом этапе у вас есть классный дашборд с продуктвыми метриками фичи. Мы видим как именно пользователи юзают фичу, какие сценарии и пути у них самые востребованные и популярные. Да и в целом круг замкнулся, и теперь все эти данные будут служить прочным фундаментов для дальнейших идей и инициатив. Чем больше таких проработанных циклов разработки, тем дешевле и качественнее будет следующий цикл. Дымовые тесты могут минимизировать усилия по тестированию и могут улучшить качество приложения.
Автоматизированное смок-тестирование — пишутся скрипты, проверяющие ключевые функции. Иногда это бывает целесообразно, если действия стандартные и повторяемые. Итак, дымовая методика фокусируется на проверке ключевых функций и обнаружении серьезных проблем, чтобы удостовериться, что приложение готово к более подробному тестированию и разработке.
После завершения пайки, прибор на очень короткое время подключали к электросети. Если из прибора не начинал выходить дым, это считалось положительным знаком, говорящим о том, что прибор успешно прошел первичное испытание. Если у вас остались вопросы, которые связаны с полным циклом разработки, напишите нам в основной канал slack-комьюнити Хекслета.
- А дефект, обнаруженный на более поздних этапах, может быть показателем препятствий, когда он может повлиять на выпуск результатов.
- Вместо того, чтобы повторять тестирование вручную при каждом развертывании новой сборки программного обеспечения, для сборки выполняются записанные примеры дымовых тестов.
- Если программа «чудит» и очевидным образом не выполняет основные функции – значит, она еще не готова для проверок.
Disclaimer: Честно О Роли Product Proprietor (po)
Если smoke тесты не проходят, это сигнал для тестировщиков о том, что в системе есть критические проблемы, которые нужно решить перед тем, как продолжить детальное тестирование. В контексте программного обеспечения термин был адаптирован для описания быстрого набора тестов, которые выполняются после сборки, развертывания новой версии программы. Цель такого тестирования – проверить, что после очередной сборки программного продукта нет явных, грубых дефектов, «блокирующих дальнейший путь». Основная цель заключается в раннем выявлении дефектов в программном обеспечении с целью избежать бесполезных затрат на дальнейшее тестирование.
Smoke-тестирование может проводиться как на стабильных, так и на нестабильных сборках. Smoke-тестирование проводится как разработчиками, так и тестировщиками. Однажды в одном крупном банке (назовем его «Банк с большой буквы Б») разработчики выкатили новую версию мобильного приложения. Благодаря раннему обнаружению, баг не дошел до продакшена, и все сохранили свои рабочие места. Инструменты тестирования дыма можно использовать для тестирования различных приложений, включая веб-приложения, мобильные приложения и настольные приложения. Дымовое тестирование иногда также называют “проверочным тестированием сборки” или “проверкой достоверности”.
Анализ и оценка — это этап, на котором полученные результаты в процессе тестирования сравниваются с заранее установленными критериями. Если результаты соответствуют этим критериям, то сборка считается работоспособной и может быть направлена на более глубокое тестирование, дальнейшую разработку или согласование с заказчиком. Если результаты не соответствуют установленным критериям, то продукт передается разработчикам для доработки и устранения ошибок. Смоук-тесты могут быть запущены вручную или автоматически, и они обычно включают выполнение простых тестовых задач, чтобы убедиться, что приложение соответствует ожиданиям. Они помогают поддерживать стабильность и уверенность в том, что каждая новая версия работает без сбоев. Автоматизированный вариант предполагает привлечение специальных программных решений для выполнения тестов.
Самая активная жизнь QA проходит на этапе “Разработка и Тестирование”, и в зависимости от процессов в компании может смещаться чуть левее или чуть правее. Поэтому, как правило, QA отлично ориентируется в процессах, которые протекают на этом этапе, и примерно представляют, что происходит на соседних. Если смещение идёт вправо, то все ожидают участие в релизе фичи, сопровождение ее на проде, мониторинг приборов и общение с саппортом. Я не буду писать декомпозировано про каждый этап цикла продуктовой разработки, а просто разобью их на 3 части.
В двух словах, внедрение smoke-тестов позволяет своевременно выявлять и устранять потенциальные критические ошибки на ранних этапах разработки, до погружения в более сложные аспекты. Такой smoke тестирование это проактивный подход обеспечивает бесперебойную работу ПО и повышает его общее качество. А теперь представьте, что дымовое тестирование — это как свидание вслепую. Вы быстро понимаете, стоит ли продолжать общение или лучше сразу искать другие варианты. И да, иногда первое впечатление обманчиво, но чаще всего оно экономит вам кучу времени и нервов. Например, мы выкладываем какой то новый билд со определенным списком фичей.