QA снова начинает тестирование дыма с новой версией сборки. Дымовое тестирование выполняется на новой сборке и будет интегрировано со старыми сборками для поддержания правильности системы. Прежде чем проводить тестирование на дым, команда QA должна проверить правильность версий сборки. Набор тестов — это сгруппированная совокупность тестовых случаев, связанная определенным образом (к примеру, по функциональности). Smoke-тесты созданы для того, чтобы проверить основную функциональность и должны быть неотъемлимой частью процесса тестирования.
Бывает так, что разработчик может упустить какой-либо момент. При сверке с макетами это будет сразу заметно, и не потребуется дёргать дизайнера для уточнения каких-то деталей. C помощью Kibana можно найти ошибки, возникшие при тестировании. Умение с ней работать – очень полезный навык, не пренебрегайте поиском логов. На картинке ниже, например, я выполнила поиск сотрудников, который выдал определённый результат.
Тестирование дыма
Если баг был найден в релизе или в процессе функционального тестирования определённой задачи, очень важно прикреплять ссылку на этот релиз или задачу к багу. Так будет проще их находить, а остальным членам команды понимать количество ошибок и их статус. Это гарантирует, что все критические функции работают правильно или нет. Это простой тест, который показывает, что продукт готов к тестированию. Это помогает определить, является ли сборка дефектной, что делает дальнейшее тестирование пустой тратой времени и ресурсов.
В Smoke-прогон входят кейсы с Priority High и Severity Critical — как правило, это основные пользовательские сценарии, набор кейсов для проверок интеграционных модулей. Регрессионное тестирование проходит каждые 2 недели, так как каждый спринт мы обновляем production стенд (далее – прод). Кто-то может сказать, что это очень часто, но на это есть свои причины.
Нужно протестировать конвертер температуры, используя техники тест-дизайна?
Во время тестирования очень часто приходится имитировать разные случаи, скажем, сделать себя руководителем или установить себе день рождения на текущую дату. Тут на помощь приходит база данных, где можно изменять данные, как душе угодно. Уточню, что все изменения в рамках тестирования проводятся исключительно на тестовой базе данных, никакого влияния на прод нет. В моей работе достаточно использовать простые запросы, типа SELECT, UPDATE и т.д. Тестирование дыма играет важную роль в разработке программного обеспечения, поскольку оно обеспечивает правильность работы системы на начальных этапах.
Чтобы нашим коллегам было удобно пользоваться сервисами, не включая рабочий компьютер, мы каждый день улучшаем старую и добавляем новую функциональность. Требуется срочно узнать номер коллеги или оформить командировку, находясь вдали от рабочего компьютера? Есть даже фичи, которых нет на корпоративном портале, но есть в нашем МП. Поэтому объём тестирования довольно большой и с каждым релизом становится всё больше.
Зачем нужно smoke-тестирование?
Как ворваться в IT, даже если вы не умеете программировать?
Они могут включать что-то простое, вроде “Могу ли я зарегистрироваться? Smoke-тестирование предполагает ответы ДА/НЕТ и все тест-кейсы должны быть пройдены с положительным результатом. Smoke test должны быть быстрыми и легковесными, для того, чтобы их можно было запускать часто.
Пример Smoke-тестирования
Ручное смок-тестирование — это процесс проверки ключевых функций на явные дефекты. Чаще всего этим и ограничиваются, особенно если приложение небольшое. Если смотреть интегрально, с точки зрения QA и CI-CD-пайплайна, то смок-тестирование — это о том smoke тестирование как проверить, что остальные виды тестирования уже валидные, то есть можно идти дальше. Ведь если билд падает при установке, или если половина страниц сайта не грузится, то нет смысла продолжать тестирование, пока такие крупные дефекты не уберут.
- Они могут включать что-то простое, вроде “Могу ли я зарегистрироваться?
- Как только мы закончим тестирование дыма, только мы начнем функциональное тестирование.
- Команда QA проверяет наличие showtoppers в тестируемом приложении.
- Лучше быстро завести понятный и лаконичный баг, чем полдня сидеть, скрупулезно заполняя все поля.
- Как я уже сказала, приложение довольно объёмное и многофункциональное, поэтому и тестирование назвать тривиальным и однообразным нельзя.
Вместо них появилось 1106 новых, которые мы предложили добавить. Так планируемое количество кейсов регресса выросло до 2050 и в нынешнем составе команды мы можем пройти его за 2 недели. Дымовой тест легче автоматизировать, чем более глубокое и интеллектуальное тестирование. Автоматизация снижает количество ручного труда и поэтому позволяет проводить эти тесты чаще. Чем чаще выполняются тесты, тем раньше становится известно о проблемах, выявляемых этими тестами.
Пример smoke testing:
Очень важно фиксировать баги на любых этапах тестирования. Баг-репорты нужно оформлять как можно тщательнее, чтобы для коллег из группы разработки описание было понятным и прозрачным, а исправление – корректным и быстрым. Давайте на своём примере чуть подробнее расскажу, что должен иметь хороший баг-репорт. Его функциональность меньше, чем у Postman’a, но в этом есть и свои преимущества. Он так же, как и Postman позволяет проверять методы API, но пользоваться им попроще.
Тем не менее они не отменяют необходимость проведения более глубоких проверок, затрагивающих функции, не столь важные для самой сборки, но имеющие большое значение для пользователя. Кроме того, тестовые сценарии нуждаются в периодическом обновлении, чтобы исключить риск пропуска новых ошибок. Меня зовут Аня, и я работаю ручным тестировщиком мобильных приложений (далее – МП) в компании Tele2. В этой статье я подробно опишу процесс тестирования, который провожу из спринта в спринт, а также свой опыт, полученный в ходе этого тестирования. Статья носит ознакомительный характер и подойдет новичкам в профессии, а также тем, кто интересуется процессом проверки мобильных приложений. «На связи» создаётся как карманный помощник в работе, а в чём-то даже и замена веб-сервисов.