E2e тестирование что это

Е2Е тестирование (E2E)

E2E (end-to-end) тестирование — это процесс тестирования программного обеспечения, который имитирует реальные действия пользователей на уровне интерфейса. Оно выполняется для проверки работоспособности всей системы в целом и для обнаружения возможных проблем взаимодействия между компонентами приложения.

E2E тестирование является последним этапом тестирования, который выполняется перед релизом приложения. Оно позволяет проверить работу приложения в целом и убедиться, что все компоненты работают правильно и взаимодействуют друг с другом без сбоев.

В процессе E2E тестирования тестировщики имитируют действия пользователя, запуская тесты, которые воспроизводят последовательность действий, начиная с ввода данных в приложение, и заканчивая проверкой результата, который пользователь должен получить. Такие тесты проверяют не только работу каждой отдельной функции и компонента приложения, но и их совместную работу.

Одной из ключевых проблем E2E тестирования является его сложность и трудоемкость. Из-за необходимости имитировать множество различных вариантов поведения пользователя, такие тесты могут занимать много времени и ресурсов. Кроме того, они могут быть достаточно хрупкими и ломаться при малейших изменениях в приложении.

Тем не менее, E2E тестирование является важной частью процесса разработки ПО, которая позволяет убедиться в том, что приложение работает правильно и соответствует требованиям пользователя. Хорошо написанные E2E тесты помогают снизить количество ошибок и сбоев в процессе эксплуатации приложения, что повышает удовлетворенность пользователей и улучшает репутацию компании-разработчика.

Руководство по сквозному тестированию: что такое E2E-тестирование с примерами

Сквозное тестирование (End-to-end, E2E, Chain testing) — это вид тестирования, используемый для проверки программного обеспечения от начала до конца, а также его интеграцию с внешними интерфейсами. Цель сквозного тестирования состоит в проверке всего программного обеспечения на предмет зависимостей, целостности данных и связи с другими системами, интерфейсами и базами данных для проверки успешного выполнения полного производственного сценария.

Наряду с программной системой тестирование также обеспечивает проверку пакетной обработки и обработки данных из других вышестоящих и нижестоящих систем. Отсюда и название «End-to-End». Сквозное тестирование обычно проводится после функционального и системного тестирования. Для его проведения используются реальные данные и тестовая среда для имитации рабочего режима.

Зачем нужно сквозное тестирование?

Сквозное тестирование проверяет весь системный флоу и повышает уверенность за счет своевременного обнаружения проблем и увеличения покрытия тестами подсистем. Современные системы ПО сложны и взаимосвязаны с большим количеством подсистем, которые могут существенно отличаться от существующих систем. Вся система может разрушиться из-за отказа любой подсистемы, что представляет собой серьезный риск. Этого риска мы как раз и стремимся избежать с помощью сквозного тестирования.

Процесс сквозного тестирования:

На схеме ниже представлен обзор процесса сквозного тестирования.

Основные виды деятельности, связанные со сквозным тестированием:

Изучение требований к сквозному тестированию;
Настройка тестовой среды и требования к оборудованию/программному обеспечению;
Описание всех процессов системы и ее подсистем;
Описание ролей и ответственности для всех систем;
Методология и стандарты тестирования;
Сквозное отслеживание требований и разработка тест-кейсов;
Входные и выходные данные для каждой системы.

Как писать тест-кейсы для сквозного тестирования?

Фреймворк сквозного тестирования включает в себя три части:

Создание пользовательских функций
Создание условий
Создание тест-кейсов

Рассмотрим каждую из них подробно.

Создание пользовательских функций

Как часть построения пользовательских функций, должны быть выполнены следующие действия:

Перечислить функции системы и их взаимосвязанные компоненты;
Перечислить входные данные, действия и выходные данные для каждой характеристики или функции;
Определить отношения между функциями;
Определить, является ли функция многократно используемой или независимой.

Например, рассмотрите сценарий, при котором вы входите в свой банковский аккаунт и переводите деньги со своего счета на счет в другой банк (сторонняя подсистема):

Войти в банковскую систему.
Проверить сумму остатка на счете.
Перевести определенную сумму со своего счета на другой банковский счет (сторонняя подсистема).
Проверить текущий баланс счета.
Выйти из приложения.

Построение условий на основе пользовательских функций

В рамках построения условий выполняются следующие действия:

Построение набора условий для каждой определенной пользовательской функции;
Условия включают последовательность, время и условия данных.

Например, проверка дополнительных условий, таких как:

Страница авторизации

Неверное имя пользователя и пароль
Проверка с действительным именем пользователя и паролем
Проверка надежности пароля
Проверка сообщений об ошибках

Сумма остатка

Проверьте текущий баланс через 24 часа (Если перевод отправляется в другой банк)
Проверьте сообщение об ошибке, если сумма перевода больше суммы текущего баланса.

Создайте тестовый сценарий

Построение тестового сценария для определенной пользовательской функции

Войти в систему
Проверить сумму остатка на банковском счете
Перевести сумму остатка на банковском счете

Создание нескольких тест-кейсов

Создайте один или несколько тест-кейсов для каждого определенного сценария. Тест-кейсы могут включать каждое условие как отдельный тестовый пример.

Инструмент сквозного тестирования

testRigor

В мире сквозного тестирования лидером отрасли является testRigor. Он помогает создавать тесты без кода для веб-интерфейса, нативных и гибридных мобильных приложений, мобильных браузеров и API. С его помощью можно тестировать электронную почту и SMS, загруженные файлы .XLS, .DOC, .PDF и т. д.

Функции:

Написание тестов без кода просто на английском языке.
Покрытие Web + Mobile + API в одном тесте. Кроссплатформенная и кроссбраузерная поддержка.
Создание тестов в 15 раз быстрее по сравнению с Selenium.
Сокращение обслуживания тестов до 99,5%.
testRigor безопасен и соответствует стандарту SOC 2 Type 2.
Интеграция с CI/CD и управлением тест-кейсами.
Выполнение 1000 тестов и получение результатов менее чем за 30 минут.

Метрики сквозного тестирования:

Ниже приведены некоторые метрики, используемые для оценки прогресса сквозного тестирования.

Статус подготовки тест-кейса: показывает реальный прогресс подготовки тест-кейса по сравнению с запланированным.
Еженедельный прогресс тестирования. Дает подробную информацию о завершении теста за неделю в процентах. Неудачные, не выполненные и выполненные тесты по сравнению с запланированными для выполнения тестами.
Статус и детали дефектов — показывает процент открытых и закрытых дефектов понедельно. Кроме того, распределение дефектов по неделям в зависимости от серьезности и приоритета.
Доступность среды — общее количество часов доступности / общее количество часов, запланированных в день для тестирования.

Сквозное тестирование vs системное тестирование

Сквозное тестирование

Системное тестирование

Проверяет программную систему, а также взаимосвязанные подсистемы.

Проверяет только программную систему в соответствии со спецификациями требований.

Проверяет весь сквозной поток процессов.

Проверяет функциональные возможности и функции системы.

Для тестирования рассматриваются все интерфейсы и серверные системы.

Рассматриваются функциональное и нефункциональное тестирование

Выполняется после завершения тестирования системы.

Сквозное тестирование включает в себя проверку внешних интерфейсов, которую сложно автоматизировать. Следовательно, ручное тестирование предпочтительнее.

Для тестирования системы можно выполнять как ручное, так и автоматизированное тестирование.

В заключение

Сквозное тестирование — это процесс проверки программной системы вместе с ее подсистемами. Самая большая трудность при этом типе тестирования состоит в том, что необходимо располагать достаточным количеством информации о всей системе, а также о взаимосвязанных подсистемах.

Приглашаем всех желающих на открытое занятие, на котором мы познакомимся с фреймворком Selenide и перепишем существующие тесты на него. Регистрация доступна по ссылке.

java qa
end-to-end testing
сквозное тестирование
E2E тестирование
selenide

Блог компании OTUS
Тестирование веб-сервисов

End-to-end, приди и порядок наведи

Не так давно у нас случилась полная неразбериха с тестированием. Быстрый рост проекта, новые команды, новые люди. Неожиданно, всё это негативно повлияло на качество продукта.

В данной статье поделюсь опытом и расскажу, как мы осознали проблему, искали пути её решения и что в итоге нам помогло. История борьбы за качество 🙂

Для начала, определимся с тем, что такое end-to-end тестирование.

End-to-end (E2E) — это верхушка пирамиды тестирования. Можно сказать, что это конечный этап тестирования. Проводя E2E, мы смотрим, как выглядит функциональность для её конечных пользователей. Всё ли работает так, как планировалось? Все ли потребности пользователя удовлетворяются?

При таком тестировании на первый план выходит именно то, что будет видеть пользователь. Как работает система изнутри, на данном этапе уже не проверяется (т.к. это задачи других уровней пирамиды тестирования). Мы смотрим на картинку в целом.

Немного предыстории

Наш проект появился 2 года назад, когда один из Клиентов крупного Поставщика платформы для проведения электронных экзаменов и сертификаций захотел купить эту платформу и разрабатывать её своими силами.

Основными нашими задачами стало следующее:

Поддержание уже имеющегося функционала. Платформа крупная, существует более 20 лет. С её помощью можно пройти весь путь от создания контента для теста до оценки пройденного кандидатом экзамена. Составных частей очень много, и наша задача — следить за их работоспособностью и взаимодействием.
Оптимизация уже имеющегося функционала. Как бы ни было хорошо, всегда можно сделать лучше.
Разработка нового функционала. Главная причина, по которой появился наш проект. Вышеупомянутый Клиент видел свой вектор развития платформы, поэтому и было принято решение пойти своим путём.

Так мы и начали работать. На старте у нас было всего 2 команды, в каждой по 2 тестировщика. Взаимодействие выстраивалось крайне просто.

Во-первых, у всех есть знание системы (все ребята ранее уже работали с этой платформой).

Во-вторых, нас всего 4 человека, а это значит, что большинство вопросов можно решить на уровне чата. В крайнем случае — созвониться в Teams и обсудить всё голосом. Просто и эффективно.

Работа шла хорошо. Старт получился довольно резкий и многообещающий: мы участвовали в глобальных планированиях, бесперебойно поставляли новые фичи, предлагали свои идеи по оптимизации приложения, трудились над улучшением продукта.

Результат не заставил себя долго ждать — Заказчик оценил наши труды и инициировал расширение. Происходило оно поэтапно, но в конечном счете мы пришли к 5 командам (10 тестировщиков) + стажёры + команды со стороны Заказчика, с которыми также идёт активное взаимодействие.

Мы гордились за себя и свой проект, но, к сожалению, не долго. Мало того, что начал затягиваться регресс, так ещё и после нас находились баги на предрелизном окружении. Ситуация крайне неприятная.

Уже этого было достаточно, чтобы забить тревогу и понять, что нужно срочно что-то менять.

Собравшись со Scrum Master’ами, Delivery Manager’ом и Quality Control командой Заказчика мы начали искать источник проблемы: что же мы упустили?

Проблемы

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

Выводы:

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

Решение

Для себя мы поняли, что нужно унифицировать процесс тестирования. Сконцентрировались мы на end-to-end тестировании. Оно у нас было, но каждая команда проводила его по-своему, а результаты нигде не фиксировались. При таком положении дел прозрачности просто нет: совершенно непонятно, что команда посмотрела, а что осталось за рамками ее внимания.

Унифицировать мы решили посредством общедоступного документа, который поможет не только зафиксировать E2E-сценарии, но и будет содержать в себе полезную информацию, которая поможет подойти к тестированию фичи структурированно и системно.

Мы приняли решение создавать такой документ к каждой из фич.То есть ещё на этапе планирования мы начали создавать ещё одну user story — E2E (в дополнение к уже описанным user story, относящимся к этой фиче). В ней по ходу разработки создаётся некий end-to-end тест-план по заданному шаблону.

Далее приведу немного обезличенный пример того, как это может выглядеть. За основу я взяла наш end-to-end тест-план, но опустила некоторые специфичные детали.

Пример структуры:

Полезные ссылки, которые могут пригодиться по ходу создания E2E-плана. Что можно добавить:
- Wiki с инструкцией о том, как взаимодействовать с тест-планом (у нас она была написана параллельно с разработкой самого E2E).
- Wiki с рекомендации по продукту (product considerations) — справочник о том, какие есть ключевые области приложения, какие требования предъявляются к системе (разрешение экрана, браузеры, языки и т.д).
- Wiki об обратной совместимости (backward compatibility) — если есть версионность.

Вопросы, на которые должен отвечать документ:
- Какие сценарии должны быть протестированы, основываясь на функциональных требованиях к фиче?
- Какие сценарии должны быть протестированы в рамках обратной совместимости?
- Какие области продукта были затронуты при разработке фичи?
- Какие из этих областей наиболее критичны и требуют особого внимания?

Нефункциональные требования (тут нужно выбрать то, что актуально, и описать, что именно будет тестироваться). Пример нашего списка:
- Нагрузочное тестирование (Performance / Load testing).
- Тестирование доступности (Accessibility testing).
- Тестирование локализации (Localization testing).
- Кроссбраузерное и кроссплатформенное тестирование (Cross browser and cross platform testing).

Автоматизированное тестирование (выделить нужное, описать сценарии):
- Selenium.
- API / Integration tests.
- Unit tests.
Сценарии, которые не входят в данную фичу (out of scope).
Ссылки на все тест-кейсы по фиче.

Данный список можно и нужно адаптировать под особенности своего проекта, чтобы эффект от него был максимальный. Наш же список может послужить отправной точкой в ваших поисках 🙂

Важные примечания:

С таким тест-планом можно и нужно начинать работать ещё на этапе планирования фичи, чтобы задать все вопросы как можно раньше.
Как только будет готова первая версия, можно дополнительно визуализировать план — создать по нему mind-map. Глянуть на картинку быстрее и проще, чем читать полное описание. Наши Заказчики особенно оценили этот пункт.
Ревью тест-плана другой командой повысит прозрачность и поможет найти недочёты.
План следует дорабатывать по ходу разработки фичи.

Увидеть первые результаты после внедрения мы смогли уже в рамках ближайшего регресса. К нему мы подошли более подготовленными, что не могло не сказаться положительно на качестве нашего тестирования.

Что нам дали изменения

К финалу разработки каждой фичи есть документ, в котором зафиксированы все особенности тестирования.
План — это user story, а значит он общедоступен для всех членов команд разработки: Заказчиков, Product Owner’ов и т.д.
Благодаря ревью планов, увеличилось взаимодействие между тестировщиками из разных команд; к тому же появилась возможность расшаривать экспертизу по областям.
План стал хорошим помощником в планировании задач, количество «неожиданно всплывших нюансов» заметно уменьшилось.
Т.к. черновик плана есть уже на этапе планирования, можно показать его Product Owner’у и уточнить, верно ли мы понимаем задачу.
К плану всегда можно вернуться и освежить знания по фичам.

Не скажу, что получилось сразу хорошо. К финальной версии мы шли через несколько этапов обсуждений. Весь процесс создания, апробации и оттачивания занял у нас примерно 2-3 месяца.

P.S.:

Так как не все любят перемены, вот небольшой бонус — пара слов о том, как сделать процесс внедрения максимально комфортным (советы капитана Очевидность):

Создайте шаблон, если ваша система управления задачами это позволяет. Не все люди встречают перемены с радостью (особенно те перемены, которые влекут за собой дополнительную работу). Но если попробовать облегчить процесс использования нововведений, сопротивления будет меньше.
Обсуждайте с командой. Плохая практика — создать что-то «в одного» и кинуть этим в коллег: «Нате, работайте». Обсуждения стоит начать сразу же, как только у вас будет первая версия документа. Чем больше вы вовлекаете людей, тем меньше будет «Фу, опять нам навязывают какую-то бюрократию», и тем больше будет чувства причастности и ответственности за совместные решения.
Совершенствуйтесь. Опыт показывает, что с первого раза идеально не бывает. Да и со второго, да и с третьего… Дополнительные встречи-обсуждения после реального использования плана помогут понять, с чем работать хорошо, с чем не очень, что можно улучшить. Проведите несколько таких сессий, чтобы довести ваш документ до его лучшего воплощения. Оно того стоит.
При необходимости, создайте wiki. Ссылку на wiki можно поместить прямо в шаблон. Первые месяцы после внедрения это будет очень полезно. Вы получите единый справочник с актуальной информацией, которая будет полезна как настоящим, так и будущим участникам проекта.
Ревью. Перед внедрением покажите финальную версию документа тем, кто не принимал участие в его разработке, но всё же будет с ним сталкиваться в работе (например, разработчикам). Свежий взгляд может натолкнуть на новые полезные идеи. Главное — найти инициативного разработчика 🙂

Заключение

Обсуждения, безусловно, требуют время. Так же как и создание end-to-end тест-плана для каждой фичи, когда он уже введён в эксплуатацию. Но эффект, который мы наблюдаем от внедрения этого документа, с лихвой покрывает все эти усилия. Мы получили прозрачность в тестировании и стандартизацию процесса.

К тому же наша идея понравилась и используется теперь и другими командами Заказчика. Мы все идём по одному пути, вместе ищем узкие места и улучшаем их, стараемся сделать процесс общим, удобным для каждого из его участников.

На этом у меня всё, спасибо за внимание 🙂

Что такое сквозное тестирование? Пример E2E

Сквозное тестирование — это метод тестирования программного обеспечения, который проверяет все программное обеспечение от начала до конца, а также его интеграцию с внешними интерфейсами. Целью сквозного тестирования является тестирование всего программного обеспечения на наличие зависимостей, целостности данных и связи с другими системами, интерфейсами и базами данных для реализации полного производственного сценария.

Наряду с системой программного обеспечения он также проверяет пакетную обработку/обработку данных из других вышестоящих/нисходящих систем. Отсюда и название «Концы с концами». Сквозное тестирование обычно выполняется после функционального и Тестирование системы. Он использует фактическую производственную среду, такую как данные и тестовую среду, для моделирования настроек в реальном времени. E2E-тестирование также называется Цепное тестирование.

Руководство по комплексному тестированию: полное руководство по E2E-тестированию