Благодаря актуализации кейсов смоука наша команда может обеспечить быстрый и качественный смоук функционала в любой момент, когда возникает такая необходимость. В-третьих, провели тест-анализ основного функционала чтобы наконец-то зафиксировать, как он реализован на текущий момент и какие есть возможности для более полного покрытия подсистем. Для оценки поставленных задач мы проанализировали полноту текущего покрытия, а также прикинули какое количество кейсов нужно для более полного покрытия функционала. После того, как основная сборка программного обеспечения будет завершена, оно будет протестировано, чтобы определить, работает оно хорошо или нет.
Если все будет работать без багов, доработки не понадобятся. Например, проект не сможет зарабатывать деньги, если система не умеет обрабатывать платежи. Чтобы проверить, что все работает, тестировщики заходят на страницу с платежами и проверяют, выводит их система или нет. А еще мы продолжаем работу по актуализации кейсов регресса. Например, в начале нашей работы было 1186 кейсов, которые покрывали около 25% функционала. Вместо них появилось 1106 новых, которые мы предложили добавить.
Тестирование
Собрали вы новое устройство, включили его в розетку, а оно громко бабахнуло и выпустило белый дым – значит smoke test не пройден. Дымовое тестирование может применяться как к новому, так и к модернизированному продукту. Не проводят тестирование производительности (нагрузочное, smoke тестирование стрессовое тестирование, тестирование стабильности), тестирование установки, безопасности, конфигурационное тестирование. Если этот этап пройден успешно, тестировщик двигается дальше. Если находит ошибку — создает задачу для разработчиков на доработку.
Smoke Tests легче автоматизировать, чем более глубокое и интеллектуальное тестирование. Автоматизация снижает количество ручного труда и поэтому позволяет проводить эти тесты чаще. Чем чаще выполняются тесты, тем раньше становится известно о проблемах, выявляемых этими тестами. Чем раньше становится https://deveducation.com/ известно о проблеме, тем легче её устранить. Автоматизация тестирования часто выполняется с помощью средств непрерывной интеграции. Тестирование на работоспособность проводится для проверки того, что после исправления функциональные возможности работают правильно в соответствии с требованиями.
Цикл дымового тестирования
Тестировщики проверяют корректность исправлений и доработок всех недочетов, которые были обнаружены на предыдущем этапе. Пересматриваются все функции, чтобы новые исправления не повлияли на уже протестированные функции системы. Когда реализованы отдельные функции системы, нужно подтвердить, что система соответствует функциональным требованиям. Тестировщики проверяют пользовательские сценарии и не смотрят на нефункциональные требования. Короче говоря, дымовой тест проводится в атмосфере разработки, чтобы убедиться, что сборка удовлетворяет требованиям.
Кроме того, тестовые сценарии нуждаются в периодическом обновлении, чтобы исключить риск пропуска новых ошибок. Простыми словами, смок-тестирование — это как бы тестирование «вширь и всего», а санити-тестирование это как бы «вглубь и одного модуля». Смок-тесты должны быстро «покрыть» критический функционал в сжатые сроки, а санити-тесты — для тщательной проверки «подозреваемой» функции. Smoke-тестирование (или дымовое тестирование) — это минимальный набор тестов, прохождение которых показывает, что продукт готов к дальнейшему тестированию.
Преимущества дымового тестирования
Сидеть и ждать – губительно сказывается на морали наших ребят. Крупица за крупицей собрали информацию, написали инструкции и постепенно забрали исправление/настройку машин себе. В итоге команда тестирования перестала зависеть от специалистов заказчика и работоспособности инфраструктуры. На самом деле количество тестировщиков на проекте определялось не только на основании указанных выше параметров.
- Дымовой тест обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.
- Например, в начале нашей работы было 1186 кейсов, которые покрывали около 25% функционала.
- Например, сайт открывается на разных устройствах, пользователь может отправить контакты через форму, видео воспроизводится, баннеры открываются.
- Если этот этап пройден успешно, тестировщик двигается дальше.
- Таким образом, smoke-тесты — это простой и действенный способ проверить основной функционал сборки.
Это причина, по которой нам нужно провести дымовой тест, прежде чем переходить к полноценному циклу тестирования. Не зная об этом факте, все 10 тестировщиков начинают тестировать приложение и выявляют дефекты для обнаруженных сбоев. Дымовое тестирование имеет смысл размещать не на серверах CI, а у конкретных разработчиков либо на хуки системы контроля версий на development сервере. Конкретные этапы смок-тестирования зависят от приложения — далее.
I believe in QA, все о тестировании
Смок-тестирование проверяет общую пригодность приложения. Приложение должно запуститься и продемонстрировать работоспособность своих базовых функций. Smoke-тестирование также можно назвать «проверкой сборки», так как с помощью дымовых тестов мы проверяем работоспособность и стабильность сборки.
Сам термин появился впервые в среде инженеров, занимавшихся отопительным оборудованием. Когда изготавливалась новая печь или котел, все ее заглушки задвигались, после чего она затапливалась. Если дым шел только из положенных мест (например дымохода), то отопительное устройство было собрано правильно. Тестовый план — документ с описанием тестируемых функций, стратегий, сроков начала и окончания тестирования. Если разобраться, у нас почасовка, финансовой заинтересованности в консалтинге проектов и их улучшении у нас почти никогда нет. Но заставьте состоявшегося специалиста в области тестирования просиживать штаны и терпеть происходящий бардак… Одним словом, вы не захотите увидеть гнев терпеливого человека.
