Смок тестирование на небольшом проекте: как началось и какие результаты Хабр

Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить автоматизацию тестовых сценариев для дымового тестирования. В-третьих, провели тест-анализ основного функционала чтобы наконец-то зафиксировать, как он реализован на текущий момент и какие есть возможности для более полного покрытия подсистем. Предложенные нами изменения и умение стоять на своём спустя некоторое время обеспечили нам полноценный доступ к 17 машинам. Новые машины да еще и на всех участников команды – это же отлично!

Таких тестов еще меньше количественно, но они еще сложнее чем интеграционные и тем более модульные (и требуют больше опыта от тестировщика). Ручное смок-тестирование — это процесс проверки ключевых функций на явные дефекты. Чаще всего этим и ограничиваются, особенно если приложение небольшое.

Как проводится дымовое тестирование

(Более правильно “санитарное тестирование” называется “тестированием согласованности”, но термин “санитарное” уже прижился у российских тестировщиков). Пожалуйста, заполните небольшую анкету, чтобы мы могли ознакомиться с продуктом, https://deveducation.com/ который нуждается в тестировании. Во-первых, с учетом того, что машин было впритык, да еще и они могут отличаться по свойствам, мы создали документ для учета их занятости, а также описания проблем и основных характеристик.

Дымовое тестирование выполняется на каждом новом билде и является очень «общим», поверхностным. Смок-тестирование выполняется при каждой новой сборке (новой версии). Пишется минимальный набор тест-кейсов для критически важного функционала, с уточнением серьезности и приоритета. Это короткий цикл тестов, подтверждающий (отрицающий) факт того, что приложение стартует и выполняет свои основные функции. Данный тип тестирования позволяет на начальном этапе выявить основные быстро находимые критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать.

Примеры smoke-тестирования

Чтобы работать без простоев и облегчить задачу себе и другим командам, которые работают с нами и могли бы работать после нас, мы постоянно собирали актуальную информацию о работе системы. Особенно в те смок тестирование моменты, когда у нас не было полноценного доступа ко всем рабочим машинам. На вопросы «как правильно должно работать приложение» ответ был «смотрите на стенды, как работает – значит так и правильно».

• Выявлять и устранять подобные ошибки — задача тестирования надежности (reliability testing).
• Несистематичность — отличающий признак ад-хок-тестирования.
• А на период отсутствия машин, обучение происходило с помощью видео, схем и таблиц, созданных более опытными первопроходцами из первого десанта.
• Иногда это бывает целесообразно, если действия стандартные и повторяемые.

Специфический тип QA-тестирования командой, работающей «по эджайлу», то есть с соблюдением так называемого манифеста Agile, и с учетом точки зрения пользователей в первую очередь. Часто приложения обновляют, чтобы соответствовать изменившимся стандартам нового окружения, или чтобы «осовременить» общий стиль и вид приложения. Теперь нужно провести тестирование обратной совместимости — ведь пользователи «старой» версии этого окружения, которых может быть очень много, не должны терять возможность пользоваться приложением. Проверка того, что новая (обновленная) версия приложения совместима с предыдущими версиями окружения, например операционными системами, в которых работает (или браузерами, в которых открывается веб-приложение). Еще называемое интуитивным, поскольку проводится в «интуитивной» манере, на усмотрение тестировщика, без тест-кейсов, планов и другой оформляемой документации. Несистематичность — отличающий признак ад-хок-тестирования.

Преимущества Smoke-тестирования

Приложение должно запуститься и продемонстрировать работоспособность своих базовых функций. Автоматизированное смок-тестирование — пишутся скрипты, проверяющие ключевые функции. Иногда это бывает целесообразно, если действия стандартные и повторяемые. Благодаря актуализации кейсов смоука наша команда может обеспечить быстрый и качественный смоук функционала в любой момент, когда возникает такая необходимость. То есть, легко ли, и быстро ли, расширяются его возможности в программном и аппаратном измерении?

Для бета-тестирования нужно реальное пользовательское окружение. Выбирается ограниченное количество реальных пользователей-«добровольцев» (клиентов), которые, не будучи специалистами в QA, тестируют продукт на свое усмотрение. Затем они дают фидбек, и конструктивную критику, после чего разработчики, при необходимости, вносят изменения в так называемую бета-версию продукта. Далее исправленный и доработанный продукт поступает на релиз, то есть становится доступен всем пользователям.

🔥 Большая дорожная карта развития тестировщика

Повторное «рождение» термина произошло в радиоэлектронике. Первое включение нового радиоэлектронного устройства, пришедшего из производства, совершается на очень короткое время (меньше секунды). Затем инженер руками ощупывает все микросхемы на предмет перегрева. Сильно нагревшаяся за эту секунду микросхема может свидетельствовать о грубой ошибке в схеме.

Что произойдет, если количество пользователей, объемы данных, количество транзакций — возрастут в разы? Проверка, может ли веб-приложение (сайт) без проблем открываться во всех распространенных версиях браузеров. Более подробно о таком специфическом типе тестирования — отдельный материал. Она требует знания языка программирования, на котором написан код приложения, а также хорошего знания его архитектуры, «внутренностей».