Приложение должно запуститься и продемонстрировать работоспособность своих базовых функций. Как правило Smoke-тестирование выполняется вручную, но если приложение обновляется часто и есть повторяющиеся от сборки к сборке текст-кейсы, то их можно автоматизировать для экономии времени и ресурсов. Очень важно не принимать за аксиому то, что если какое-либо действие было пройдено один раз, оно будет всегда с положительным исходом. Smoke-тесты позволяют постоянно проверять, что основные функции не пострадали с течением времени или не были поломаны в течение долгого периода. Smoke-тесты созданы для того, чтобы проверить основную функциональность и должны быть неотъемлемой частью Вашего процесса тестирования.
Чек-листы мы писали в экселе, каждый лист называя по функционалу или по роли пользователя в системе. Как оформить лист “здания”, если нам надо вернуться к нему дважды — сначала создать и подредакировать, и через какое-то время удалить. Только проверку того, что тулза скомпилировалась – сложно назвать smoke-test. Как бы там не было, ежедневная сборка усиливает дисциплину и держит тенденцию стремления кода к состоянию энтропии под контролем. В чрезвычайных случаях, ошибки интеграции могут послужить причиной отмены проекта. Было бы неплохо установить конкретные сроки для пятого шага, поскольку анализ и итерации могут продолжаться бесконечно, а результаты смоук-теста должны быть получены как можно раньше.
Примеры smoke-тестирования
Смок-тестирование проверяет общую пригодность приложения. Автоматизированное смок-тестирование — пишутся скрипты, проверяющие ключевые функции. Иногда это бывает целесообразно, если действия стандартные и повторяемые. Как и при проведении регулярных сплит-тестов, смоук-тесты приведут вас к положительным итогам, даже если ваш продукт вдруг окажется никому не нужным.
Эти тесты и называются дымовыми (от англ. smoke — дым). Чаще всего этот процесс достаточно хорошо автоматизирован (или должен таким быть). В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование – это одно и тоже.
Зачем маркетологам смоук-тесты?
Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов. Smoke Tests легче автоматизировать, чем более глубокое и интеллектуальное тестирование. Автоматизация тестирования часто выполняется с помощью средств непрерывной интеграции . Тестирование сборки (Build Verification Test) – это тестирование, направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. Если смотреть интегрально, с точки зрения QA и CI-CD-пайплайна, то смок-тестирование — это о том как проверить, что остальные виды тестирования уже валидные, то есть можно идти дальше. Это чек-лист для быстрой проверки релиза на production, то есть на реальном сервере, с которым работают пользователи.
Ежедневная прогонка минимального набора дымовых тестов не дает ошибкам и проблемам взять верх на проекте. Если вы довели проект до стабильного состояния раз, он будет оставаться стабильным всегда. Этим вы никогда не допустите снижения качества до уровня, на котором и возникают ошибки. Регрессионными могут быть как функциональные, так и нефункциональные тесты. Смок-тестирование выполняется при каждой новой сборке (новой версии). Пишется минимальный набор тест-кейсов для критически важного функционала, с уточнением серьезности и приоритета.
Контрольные вопросы, которые нужно знать для собеседования / junior QA Interview Questions & Answers: smoke testing
Кто знаком с нашим подходом или работал с нами, тот знает – в ЛК уже как 5 лет работает отличная система наставничества и обучения. Каждый новичок имеет индивидуальный план погружения на проект с мануалами и ссылками на необходимые ресурсы. А на период отсутствия машин, обучение происходило с помощью видео, схем и таблиц, созданных более опытными первопроходцами smoke тестирование из первого десанта. Для смоук-тестов мы решили оставить старое количество кейсов, потому что стояло требование укладываться с ними в 1 день. Основной упор делался на то, что кейсы должны быть актуальны, максимально понятны и покрывать основной функционал -1 приоритета (блокеры). Дымовое тестирование осуществляется при выпуске каждой новой сборки.
Мы стараемся логировать все запросы, которые делал упавший тест, так, чтобы их легко можно было повторить. Во-первых, это позволяет быстро руками совершить набор аналогичных действий для воспроизведения ошибки, во-вторых – выявить часто падающие тесты, если такие у нас имеются. Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования.
Пример Smoke-тестирования
Чаще всего этим и ограничиваются, особенно если приложение “небольшое”. Основная цель дымового тестирования – раннее обнаружение проблем в сборке. Если в сборке присутствуют ошибки, то дальнейшее тестирование будет лишь тратой времени и ресурсов. Иными словами – это минимальный набор тестов, прохождение которых показывает, что продукт готов к дальнейшему тестированию. Smoke-тестирование можно также назвать «Проверкой сборки», так как с помощью Smoke-тестов мы проверяем работоспособность и стабильность сборки.
- Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны.
- А накат новой версии длился несколько дней и в это время все тестировщики учились гадать на кофейной гуще и плясать с бубном.
- Как ворваться в IT, даже если вы не умеете программировать?
- Также чек-лист ассоциируются с гибкими подходами в тестировании.
- Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны. Как правило, для регрессионного тестирования используются тест кейсы, написанные на ранних стадиях разработки и тестирования. Это дает гарантию того, что изменения в новой версии приложения не повредили уже существующую функциональность.
Определение группы сборки
Чем проще архитектура, тем больше тестов будет написано и тем меньше времени будет занимать написание нового. — Регрессия побочного эффекта (Side effect regression) – попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения. Smoke-тестирование проводится после обновления ПО, также может быть проведено и при выходе первой версии системы в промышленную эксплуатацию. На тестовом стенде Smoke-тестирование может проводиться в качестве приемочных испытаний перед функциональным тестированием. Поскольку smoke-тестирование проводится с довольно высокой периодичностью и на него затрачиваются существенные ресурсы тестировщиков, рекомендуется автоматизировать это направление. Но даже посмотреть, как все работает на стендах, у нас не было возможности, так как на проекте наблюдался недостаток машин, и не все они были в рабочем состоянии.
Принцип 4 — Скопление дефектов (Defects clustering) Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей. Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной https://deveducation.com/ системы или ее основной части, и затем проводится интеграционное тестирование. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования. Системное тестирование (System Testing) Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом.