Test Environment. Разбираем тестовые среды
Тестировщик работает не в вакууме, а в определенной среде: устройства, операционная система, браузер и т.д. На самом деле таких сред целых пять. Давайте с ними познакомимся.
Тестировщик » QA-блог » Инструменты » Test Environment. Разбираем тестовые среды
6 месяцев назад 0 1078
Среда тестирования
Среда тестирования, окружение тестирования (Test Environment) – это конфигурация программного и аппаратного обеспечения, позволяющая QA-специалисту запускать проверки ПО. Это своего рода песочница, в которой тестировщик может делать проверочные действия, чтобы найти дефекты программного обеспечения.
Корректная настройка среды тестирования обеспечивает эффективность тестирования ПО. Поэтому в настройке Test Environment участвуют не только тестировщики, а в первую очередь системные администраторы и разработчики.
Зачем нужны тестовые среды
Согласно определению из стандарта программного инжиниринга IEEE-610, среда тестирования представляет собой окружение, включающее в себя аппаратное обеспечение, измерительную аппаратуру, имитаторы, программный инструментарий и прочие инструменты, необходимые для проведения теста.
Тестовые среды нужны для того, чтобы проверить работу IT-продукта на правильно настроенном оборудовании, с корректным программным обеспечением и сетью. Их настройки обуславливаются заявленными требованиями к ПО. Тестовые среды позволяют начать тестирование еще до его релизной версии. Это важно, т.к. чем раньше будет найдет дефект ПО, тем дешевле обойдется его исправление.
Какие бывают тестовые среды
Обычно выделяют 5 сред:
- Среда разработки (Development Environment);
- Среда тестирования (Test Environment);
- Интеграционная среда (Integration Environment);
- Превью или Предпродакшн среда (Preview/Preproduction Environment);.
- Продакшн среда (Production Environment).
Среда Development
Окружение разработки (Development Environment) – это среда, в которой пишется код программы. Также в ней проводят исправление ошибок, откладку ПО, выполняют модульное тестирование.
За функционирование среды разработки отвечают разработчики.
Среда Test
Окружение тестирования (Test Environment) – это среда, в которой работают главным образом тестировщики. В ней проверяют функционал продукта, проводят дымовое, санитарное и другие виды тестирования.
За функционирование Test Environment отвечают, как правило, тестировщики.
Среда Integration
Окружение интеграции (Integration Environment) – это среда, в которой проводят интеграционное тестирование, т.е. проверку взаимодействия модулей друг с другом. Иногда она реализована внутри Test Environment или Preview Environment, иногда подключена к внешним базам данных, справочникам, другим системам.
Среда Preview/ Preproduction
Окружение Превью/Предпродакшн (Preview/Preproduction Environment) – это среда, максимально адаптированная к продакшену. В этой среде проводится финальное тестирование функционала ПО.
В Preview/Preproduction Environment QA-специалисты проводят сквозное (End-to-End), приемочное и другие виды завершающего тестирования. Обычно за эту среду отвечает группа тех.поддержки.
Среда Production
Окружение Продакшн (Production Environment) – это среда, где работают пользователи IT-продукта. В основном за Production Environment отвечает группа поддержки. Они устанавливают ПО, настраивают его, обновляют и исправляют.
Тестовый стенд
Испытательный стенд (Test Bed) – это более широкое понятие, нежели среда (окружение) тестирования. Test Bed включает в себя многообразие операционных систем, конфигурации настроек продукта, сети, устройств, тестовых данных, смежных IT-продуктов и т.п.
Сейчас достаточно иметь испытательные стенды не физически, а виртуально. Есть компании, которые предлагают свои тестовые стенды в аренду за небольшую плату. Это помогает сэкономить на закупке устройств в несколько тысяч долларов.
Как мы увидели, исполнение тестов необходимо, но не менее важны и сопровождающие действия – планирование и документирование процесса. В обязанности тестировщиков входит разработка тестовых сценариев, а также подготовка тестирования и оценка его результатов. Становление идеи фундаментального тестового процесса на всех уровнях тестирования заняло годы. В рамках этого процесса можно выделить ключевые шаги:
– планирование и управление;
– анализ и проектирование;
– внедрение и реализация;
– оценка критериев выхода и написание отчетов;
– действия по завершению тестирования.
Здесь действия описаны в логической последовательности, но в условиях реального проекта они могут накладываться, происходить одновременно или даже повторяться. Обычно, происходит адаптация этих шагов под нужды конкретной системы или проекта. Рассмотрим их
1. Планирование и управление
Планирование тестирования включает действия, направленные на определение основных целей тестирования и задач, выполнение которых необходимо для достижения этих целей.
В процессе планирования мы убеждаемся в том, что мы правильно поняли цели и пожелания заказчика и объективно оценили уровень риска для проекта, после чего ставим цели и задачи для, собственно, тестирования.
Для более ясного описания целей и задач тестирования составляются такие документы как тест-политика, тест-стратегия и тест-план.
Тест-политика – высокоуровневый документ, описывающий принципы, подходы и основные цели компании в сфере тестирования.
Тест-стратегия – высокоуровневый документ, содержащий описание уровней тестирования и подходов к тестированию в пределах этих уровней. Действует на уровне компании или программы (одного или больше проектов).
Тест-план – документ, описывающий средства, подходы, график работ и ресурсы, необходимые для проведения тестирования. Помимо прочего, определяет инструменты тестирования, функциональность, которую требуется протестировать, распределение ролей в команде, тестовое окружение, используемые техники тест-дизайна, критерии начала и окончания тестирования и риски. То есть, это подробное описание всего процесса тестирования.
В любой деятельности, управление не заканчивается планированием. Нам нужно контролировать и измерять прогресс. Именно поэтому управление тестированием – непрерывный процесс.
Управление тестированием – сопоставление текущей ситуации в процессе тестирования с планом и составление отчетности.
В свою очередь, данные, полученные в ходе контроля над процессом, учитываются при планировании дальнейших действий.
2. Анализ и проектирование
Анализ и проектирование тестов – это процесс написания тестовых сценариев и условий на основе общих целей тестирования.
В процессе анализа и проектирования мы разрабатываем тестовые сценарии на основании общих целей тестирования, определенных во время планирования.
Тестовый сценарий – документ, определяющий установленную последовательность действий при выполнении тестирования.
3. Внедрение и реализация
Во время выполнения тестирования происходит написание тест-кейсов, на основе написанных ранее тестовых сценариев, собирается необходимая для проведения тестов информация, подготавливается тестовое окружение и запускаются тесты.
Тест-кейс – документ, содержащий набор входных значений, пред- и постусловий, а также ожидаемый результат проведения теста, разработанный для проверки соответствия определенной функциональности системы заданным для этой функциональности требованиям.
Тестовое окружение – аппаратное и программное обеспечение и другие средства, необходимые для выполнения тестов.
4. Оценка критериев выхода и написание отчетов
Критерии выхода определяют, когда можно завершать тестирование. Они необходимы для каждого уровня тестирования, поскольку нам необходимо знать, достаточно ли было проведено тестов.
При оценке критериев выхода необходимо:
– проверить, было ли проведено достаточное количество тестов, достигнута ли нужная степень обеспечения качества системы.
– убедится в том, что нет необходимости проводить дополнительные тесты. Если все же такая необходимость есть, возможно, потребуется изменить установленный критерий выхода.
После окончания тестирования происходит написание отчета, который будет доступен всем заинтересованным сторонам. Ведь не только тестировщики должны знать результаты выполнения тестов, – эта информация может быть необходима многим участникам процесса создания ПО.
5. Действия по завершению тестирования
При завершении тестирования мы собираем, систематизируем и анализируем информацию о его результатах. Она может пригодиться позже – при выпуске готового продукта. Могут быть и другие причины для сворачивания тестирования, например, досрочное закрытие проекта или завершение определенного этапа разработки.
Основные цели этого этапа:
– убедиться, что вся запланированная функциональность действительно была реализована;
– проверить, что все отчеты об ошибках, поданные ранее, были, так или иначе, закрыты;
– завершение работы тестового обеспечения, тестового окружения и инфраструктуры;
– оценить общие результаты тестирования и проанализировать опыт, полученный в его процессе.
- Выбери курс для обучения
- Тестирование
- Базовый модуль тестирования
- Тестирование ПО
- Тестирование WEB-сервисов
- Тестирование мобильных приложений
- Тестирование нагрузки с JMeter
- Расширенный модуль автоматизации тестирования
- Автоматизация тестирования с Selenium WebDriver (Python)
- Автоматизация тестирования с Selenium WebDriver (Java)
- Автоматизация тестирования с Selenium WebDriver (C#)
- Автоматизация тестирования на JavaScript
- Java для автоматизаторов
- Fullstack Web Developer
- Java
- Python
- JavaScript
- HTML5 И CSS3
- Полный стек разработки на фреймворке Laravel
- Разработка CMS на основе PHP
- Git для автоматизаторов
- Практический SQL
- Основы Unix и сети
- WEB-серверы и WEB-сервисы
- Создание проекта автоматизации и написания UI тестов
- Составление комбинированных тестов UI и API. Написание BDD тестов
- IT Project Manager
- HR-менеджер в ИТ-компании
- Как правильно составить резюме и пройти собеседование
- Подготовка к сертификации ISTQB Foundation Level на основе Syllabus Version 2018
- Тестирование
- Базовый модуль тестирования
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно
Сколько в вашем проекте тестовых стендов — 5, 10 или больше 10? Навскидку, нужны стенды для каждой команды разработки, стенды для QA под каждый проект, менеджерам проектов тоже нужны стенды, а еще CI — трудно это все точно разграничить и не вызвать конфликтные ситуации. Одним словом, почему бы нам не делать тестовый стенд ровно тогда, когда он нужен? Нужен сейчас тестовый стенд — мы его сделали, не нужен — мы его удалили.
Именно такой подход предложил Александр Дубровин (adbrvn) на Highload++ 2017 в своем докладе, расшифровку которого вы найдете под катом.
О спикере: Александр Дубровин работает в Superjob. Известно, что проекты этой компании высоконагруженные. Но сегодня мы не будем говорить о том, сколько пользователей посещают портал, и сколько данных хранится на серверах, а затронем другие показатели.
Забегая вперед, скажем, что, на самом деле, Superjob не знают, сколько у них тестовых стендов. Но обо всем по порядку. Начнем с небольшой истории.
Немного истории
Представим себе небольшой проект S. В нем есть команда разработчиков, которым надо где-то тестировать свой код. Чтобы организовать тестирование, мы поставим тестовую машину, сделаем ее похожей на продакшен, накатим туда код, запустим и разработчики смогут там что-то тестировать.
В какой-то момент команда начинает расти, и необходим штат тестировщиков. Появляются QA-специалисты, и им тоже нужно где-то тестировать.
Можно использовать простой подход — выделить какой-то участок для тестировщиков, накатить туда такую же копию, и вот они уже могут тестировать. Все замечательно и хорошо!
Проект продолжает расти, и появляется дополнительная команда разработки. Им также требуется где-то что-то тестировать. Подход уже знаком — мы отделяем еще одну часть тестового сервера.
Но на самом деле команды тоже растут — по одному тестовому стенду им становится мало. Задач они тоже делают больше, поэтому тестировщикам нужно много тестировать.
Примерно в такой стадии можно начать замечать интересные истории. Допустим, есть тестировщик Вася, который хочет протестировать какую-то задачу. Он выбирает тестовый стенд, раскатывает туда код и начинает тестировать. Кликает, кликает и понимает, что что-то не то, что-то не работает, и вообще задача не сделана.
В JIRA начинают падать тикеты, возле Васи начинают собираться разработчики со словами: «Да как же так? Все же сделано!» и кто-то наконец спрашивает: «А у тебя какая ветка на тест раскатана?» Вася смотрит — не та. Ветка быстро исправляется, тикеты в JIRA закрываются, все хорошо. Вася продолжает тестировать, у него все работает.
Но в это время в другом конце комнаты разработчик Вова думает: «Странно, а почему у меня не работает?» Но он быстро понимает, что ветка не та. Раскатывает ту, что нужно, и проблемы снова у Васи.
За пару итераций они понимают, что они просто тестируют на одном тестовом стенде и мешают друг другу. В результате время потрачено впустую, Вася и Вова недовольны.
Другая история. Разработчик Коля знает про Васины проблемы, заранее приходит к нему и спрашивает, какой тестовый стенд сейчас свободен. Вася указывает свободный, и все хорошо. Через пару дней они встречаются снова, и Вася спрашивает у Коли: «Ты нам тестовый стенд вернешь? Ты его занимал на часок, а уже 2 дня прошло».
И снова проблема — либо разработчику искать другой стенд, либо все будут бодро ждать, пока он закончит тестирование.
На самом деле на схеме выше отображено не все. Здесь не хватает менеджеров. Иногда менеджеры хотят смотреть еще не протестированный сырой код. Подход стандартный — мы снова выделяем уголок тестового сервера и делаем еще тестовые стенды.
Самая последняя часть этой системы — это конечно CI — он тоже хочет куда-то стрелять, где-то тестировать.
Плавно развивая такую схему, мы получаем бесконтрольное изменение тестовых стендов. Схема плоха тем, что мы действительно не контролируем такие стенды — мы не знаем:
- кто тестирует на этом стенде в данный момент;
- что там раскатано;
- мы вообще не знаем, занят он сейчас или свободен.
Идея
В этот момент мы задумались — что же делать? Зачем нам столько тестовых стендов? Почему бы нам не делать тестовый стенд ровно тогда, когда он нужен? Нужен сейчас тестовый стенд — мы его сделали, не нужен — мы его удалили.
Следующий шаг в этой идее — делать тестовый стенд под каждую ветку кода.
Вроде идея хорошая, но есть технические нюансы. Нам нужны стенды:
- независимые;
- очень похожие на продакшен — мы хотим тестировать ближе к продакшен-окружению;
- с возможностью быстро создавать стенды, потому что мы хотим, чтобы, как только ветка появилась, тут же под нее появился бы и тестовый стенд.
Суровая реальность
Еще есть суровая реальность, в которой у нас:
- Большой сложный проект — огромный php монолит с достаточно большой историей.
- Сервис в четырех доменных зонах. Мы одновременно поддерживаем российскую, украинскую, узбекскую и белорусскую зоны.
- Куча поддоменов —геоподдомены и сервисные поддомены — такие, как API, students.superjob.ru и прочее.
Сказано — сделано!
Docker/docker-compose
Во-первых, мы говорили о том, что тестовые стенды должны быть изолированными и максимально похожими. В наше время это позволяет реализовать docker. Он даст возможность запускать контейнеры. Очевидно, что одним контейнером мы не обойдемся, более того, нам надо запускать кучу похожих стеков. Поэтому нужен docker-compose.
Замечательно — мы будем использовать docker — это стильно, модно, молодежно.
Распиливаем монолитвыделяем сервисыDocker пропогандирует микросервисный подход и здесь мы встаем перед проблемой, потому что у нас монолит.
Вы когда-нибудь пробовали оценить, сколько стоит распилить монолит по микросервисам? Очевидно, что эта цифра измеряется в человеко-годах.
В какой-то момент мы посмотрели на компонентную схему нашей системы и увидели, что здесь у нас есть load-balancing, здесь — приложение на php, здесь — node.js-приложение. Почему бы нам не запускать именно это, как сервис. Давайте найдем то, что мы можем запускать в docker-контейнерах.
Настраиваем сеть
Дальше нам необходимо каким-то образом достучаться до нашего тестового стенда. Естественно, нам необходимо вытащить 80-ый порт наружу, чтобы браузер мог открыть наш тестовый стенд, но если такие стенды будут запускаться в рамках одной машины, нам нужно выдавать IP.
В документации имеется целый огромный раздел про настройку сетей.
Docker умеет использовать различные типы сетей. В нашем случае очень помогла сеть типа macvlan. Это технология, которая позволяет на одном физическом сетевом интерфейсе реализовывать пачку виртуальных сетевых интерфейсов. При этом docker сам будет управлять этими интерфейсами: создавать, добавлять на машину и получать уже внешние, по отношению к хост-машине, IP-адреса.
Таким образом мы можем запустить пачку контейнеров, дать фронт-контейнеру (балансеру) возможность получить внешний IP-адрес и открыть на нем 80-ый порт. Мы уже можем постучаться туда при помощи браузера.
Поднимаем DNS и API
Мы помним, что у нас есть доменные зоны и куча поддоменов. Таким образом, обратиться к тестовому стенду мы можем только по домену 2-го уровня. Здесь есть как колоссальный плюс, так и колоссальный минус:
- Минус — нам очевидно придется каким-то образом перекрывать реальные домены в зоне ru, ua, uz, by.
- Плюс — в качестве домена 2-го уровня можно зашить прямо конкретное название ветки — мы же делаем тестовые стенды под каждую ветку кода.
Минус обходится на самом деле просто. Если нам приходится перекрывать домены, мы просто добавляем префикс и таким образом ограничиваем набор перекрываемых доменов — с этим уже можно мириться.
В нашем случае мы выбрали префикс sj. Получается, нам приходится перекрывать домены только с префиксом sj — таких явно немного.
Еще одна часть DNS — это API. Как уже говорилось, необходимо поднимать тестовые стенды быстро. Поэтому нам нужен DNS-сервер, который позволяет быстро добавлять и быстро убирать запись по API в автоматическом режиме.
Решение — PowerDNS. Этот сервер позволяет достаточно быстро и просто прикрутить к нему API и при помощи скриптов добавлять и удалять тестовые стенды.
Замечательно! Мы подняли и настроили DNS, научили наши контейнеры в него прописывать свои IP, но чего-то не хватает.
Делаем SSL-CA
Мы живем в XXI веке. Очевидно, что весь интернет — SSL и тестовые стенды должны поддерживать SSL. Достаточно много багов специфичны для SSL, и mixed content — только вершина айсберга.
Итого, нам нужен способ быстро получить сертификат и быстро его применить на поднимающийся тестовый стенд. В нашей компании уже был центр сертификации, основанный на OpenSSL. Здесь мы пошли простым методом написания своего велосипеда.
Велосипед пишется за один день и позволяет при помощи GET-запросов получать сертификаты, сгенерированные уже на конкретное имя домена.
Осталось самое малое. Нужно это автоматизировать, потому что мы же хотим все это делать одной кнопкой.
Автоматизируем
Для себя на начальном этапе мы написали консольный скрипт, который позволяет просто поднять тестовый стенд или его удалить.
Очевидно, тестировщикам это не очень удобно. Поэтому можно, например, сделать специальную сборку, которая соберет тестовый стенд и запустит его.
Но на самом деле самый крутой шаг в этом плане — это добавить такую кнопку прямо в JIRA-тикет. Представьте, ваш тестировщик открывает JIRA-тикет, читает требование, нажимает кнопку и получает через пару минут тестовый стенд — здорово же?
Плюсы
- Изначально мы планировали это именно под ручное тестирование, чтобы тестировщик мог запустить и прокликать любую версию своего кода, и это круто заработало.
- Следующий дополнительный бонус — у нас появились демо-хосты. Это то же самое, только в JIRA-тикет заходит не тестировщик, а менеджер проекта. Он тоже может посмотреть и покликать сырой код.
- Мы получили колоссальный плюс для CI. Когда мы обучили CI точно так же поднимать тестовый стенд на конкретную версию кода и потом его удалять, у нас появилась возможность запускать абсолютно любые тесты для любой ветки. Даже самые сложные интерфейсные selenium тесты я могу одним кликом прогнать для любой ветки в моем проекте.
Минусы
Но есть и минусы, я бы сказал, нюансы в управлении стендов. Нужно научиться правильно ими управлять.
Первую версию своей системы мы выкатили на старый слабый сервер и настроили создание тестовых стендов под каждую новую ветку. Конечно, где-то через день-полтора сервер не справился — просто потому, что веток появляется очень много.
Тогда, мы перестали их создавать автоматически, а появилась кнопка в JIRA, CI научилась запускать и останавливать тестовые стенды, собирать с них логи.
Определенно есть класс задач, которые эта система не позволит решать. Например, часто всплывающая проблема — это общее время для всех контейнеров. Некоторые задачи было бы удобно тестировать, сдвинув время на сервере. Эта система, к сожалению, не позволяет решать такие задачи. Но такие задачи можно решить, добавив в код специальные ветки для тестирования, чтобы можно было, например, посмотреть, как поведет себя форма через 2 недели.
Итог
На входе мы имели систему тестовых стендов, которая заставляла нас искать тестовый стенд и не гарантировала нам то, что никто не будет мешать друг другу на этих тестовых стендах.
Было: «Вася, а какой тестовый свободный — мне свою задачу раскатить потестировать».
На выходе получилась одна кнопка, которую можно нажать и получить через пару минут готовый тестовый стенд под конкретную версию кода. Даже если этим стендом будет пользоваться несколько человек, гарантировано то, что эти люди хотят смотреть именно эту версию кода.
Стало: «Жму кнопку и через полторы минуты получаю новый тестовый стенд под конкретную задачу».
Бонусом мы получили все тесты в один клик. Как я уже говорил, любые тесты на любой ветке прямо из CI выбираются одной кнопкой. Дальше машина все сделает сама: поднимет тестовый стенд, обстреляет его, соберет с него логи и удалит.
Возвращаясь к своему первому вопросу, сколько же тестовых стендов нам нужно? Я не знаю, сколько нам нужно тестовых стендов, потому что сегодня их нужно 20, завтра — 15, послезавтра 25.
Но я точно знаю, что у нас ровно столько тестовых стендов, сколько нужно здесь и сейчас.
Время летит незаметно, и до фестиваля конференций РИТ++ осталось совсем немного, напомним он пройдет 28 и 29 мая в Сколково. Пользуясь случаем, приводим небольшую подборку заявок RootConf для широкого круга слушателей:
- Даниил Мигалин (Microsoft). Автоматический, надежный и управляемый деплой с помощью простых инструментов.
- Алексей Палажченко (Percona). Долгосрочное хранение метрик Prometheus’а.
- Михаил Кузьмин (JetBrains). Конвейер поставки виртуальных машин.
- Николай Сивко (okmeter.io). Тонкая настройка балансировки нагрузки.
- тестирование
- тестовая среда
- docker-compose
- Блог компании Конференции Олега Бунина (Онтико)
- Тестирование IT-систем
- IT-инфраструктура
Окружение в баг репорте: что это и зачем нужно
Погрузимся в мир тестирования и узнаем, что такое «окружение» в баг репорте и почему оно так важно.
Алексей Кодов
Автор статьи
27 сентября 2023 в 8:49Окружение в баг репорте – это ключевой элемент, без которого трудно представить эффективную работу тестировщика. Но что это такое и почему оно настолько важно? В этой статье мы изучим, что такое «окружение», как его описать в баг репорте и зачем это нужно.
Чтобы стать тестировщиком и разбираться во всех тонкостях работы, приходите на курс «Инженер по тестированию». Научитесь выполнять ручное и автоматическое тестирование, составлять тестовую документацию и пользоваться необходимыми инструментами для работы.
Что такое «окружение» в баг репорте? ��
«Окружение» – это общее название для описания всей среды, в которой происходит тестирование. К нему относятся версия операционной системы, браузера, установленных программ, а также любые другие факторы, которые могут повлиять на работу тестируемого приложения или программы. Причем важно указывать не только программные, но и аппаратные характеристики, такие как модель устройства, его разрешение экрана, объем оперативной памяти и так далее.
Зачем описывать окружение в баг репорте? ��
Определение окружения в баг репорте имеет ряд преимуществ. Во-первых, это помогает разработчикам воспроизвести баг в точно таких же условиях, как и при тестировании. Во-вторых, оно позволяет увидеть, как одна и та же программа ведет себя в различных условиях. Например, одно и то же приложение может корректно работать на одной операционной системе, но вызывать ошибки на другой.
Как описать окружение в баг репорте? ��️
Описание окружения в баг репорте – это не просто перечисление всех возможных характеристик. Важно выбрать те, которые действительно могут влиять на работу тестируемого продукта. Например, для веб-приложения важно указать версию браузера и операционной системы, а для мобильного приложения – модель устройства и версию ОС.
Этому учат на курсе «Инженер по тестированию». Разобраться во всех нюансах помогут преподаватели-практики и наставники. После обучения соберете портфолио и получите диплом установленного образца.
Пример описания окружения может выглядеть так:
- Операционная система: Windows 10
- Браузер: Google Chrome 89.0.4389.82
- Разрешение экрана: 1920×1080
- Подключенные устройства: мышь, клавиатура
Важно помнить, что каждая деталь может быть важной. Например, проблема может возникать только на определенных моделях устройств или при использовании конкретных версий программ.
Разбор примера баг репорта с описанием окружения ��
Посмотрим на пример баг репорта с описанием окружения. В этом случае мы тестируем веб-приложение в браузере Google Chrome на компьютере с ОС Windows 10.
- Описание: При клике на кнопку «Отправить» ничего не происходит
- Шаги воспроизведения: Запустите приложение -> Введите данные во все поля -> Нажмите кнопку «Отправить»
- Фактический результат: Ничего не происходит. Нет никакого ответа от системы.
- Ожидаемый результат: Появляется сообщение о том, что данные отправлены.
- Окружение: Windows 10, Google Chrome 89.0.4389.82
В данном случае, описание окружения поможет разработчикам лучше понять условия, в которых проявляется проблема, и ускорит процесс ее решения.
Теперь вы знаете, что такое окружение в баг репорте и как его описывать. Это важный шаг на пути к профессиональному тестированию. Если вы хотите узнать больше о тестировании и баг репортах, рекомендую прочитать статьи Как создать баг-репорт, Как составить и оформить баг-репорт и Структура и атрибуты баг репорта: детальный разбор.
Если же вы хотите углубить свои знания в тестировании и прокачать свои навыки, предлагаю пройти курс по «Тестирование» в онлайн-университете Skypro, перейдя по ссылке.
- Тестирование