Пример end to end сценария

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

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

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

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

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

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

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

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

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

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

3. Разработка нового функционала. Главная причина, по которой появился наш проект. Вышеупомянутый Клиент видел свой вектор развития платформы, поэтому и было принято решение пойти своим путём.

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

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

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

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

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

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

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

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

Проблемы:

1. После расширения заметно сократилось межкомандное общение среди тестировщиков. Большая часть взаимодействия была на уровне команды и не выходила за её пределы. Т.е. все «варятся в собственном соку».

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

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

Выводы: 

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

Решение:

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

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

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

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

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

1. Полезные ссылки, которые могут пригодиться по ходу создания E2E-плана. Что можно добавить:

   • Wiki с инструкцией о том, как взаимодействовать с тест-планом (у нас она была написана параллельно с разработкой самого E2E).

   • Wiki с рекомендациями по продукту (product considerations) — справочник о том, какие есть ключевые области приложения, какие требования предъявляются к системе (разрешение экрана, браузеры, языки и т.д).

   • Wiki об обратной совместимости (backward compatibility) — если есть версионность.

1. Вопросы, на которые должен отвечать документ:

   • Какие сценарии должны быть протестированы, основываясь на функциональных требованиях к фиче?

   • Какие сценарии должны быть протестированы в рамках обратной совместимости?

   • Какие области продукта были затронуты при разработке фичи?

   • Какие из этих областей наиболее критичны и требуют особого внимания?

1. Нефункциональные требования (тут нужно выбрать то, что актуально, и описать, что именно будет тестироваться). Пример нашего списка:

   • Нагрузочное тестирование (Performance / Load testing).

   • Тестирование доступности (Accessibility testing).

   • Тестирование локализации (Localization testing).

   • Кроссбраузерное и кроссплатформенное тестирование (Cross browser and cross platform testing).

1. Автоматизированное тестирование (выделить нужное, описать сценарии):

   • Selenium.

   • API / Integration tests.

   • Unit tests.

2. Сценарии, которые не входят в данную фичу (out of scope).

3. Ссылки на все тест-кейсы по фиче.

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

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

1. С таким тест-планом можно и нужно начинать работать ещё на этапе планирования фичи, чтобы задать все вопросы как можно раньше.

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

3. Ревью тест-плана другой командой повысит прозрачность и поможет найти недочёты.

4. План следует дорабатывать по ходу разработки фичи.

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

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

1. К финалу разработки каждой фичи есть документ, в котором зафиксированы все особенности тестирования.

2. План — это user story, а значит он общедоступен для всех членов команд разработки: Заказчиков, Product Owner’ов и т.д.

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

4. План стал хорошим помощником в планировании задач, количество «неожиданно всплывших нюансов» заметно уменьшилось.

5. Т.к. черновик плана есть уже на этапе планирования, можно показать его Product Owner’у и уточнить, верно ли мы понимаем задачу.

6. К плану всегда можно вернуться и освежить знания по фичам.

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

P.S.:

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

1. Создайте шаблон, если ваша система управления задачами это позволяет. Не все люди встречают перемены с радостью (особенно те перемены, которые влекут за собой дополнительную работу). Но если попробовать облегчить процесс использования нововведений, сопротивления будет меньше.

2. Обсуждайте с командой. Плохая практика — создать что-то «в одного» и кинуть этим в коллег: «Нате, работайте». Обсуждения стоит начать сразу же, как только у вас будет первая версия документа. Чем больше вы вовлекаете людей, тем меньше будет «Фу, опять нам навязывают какую-то бюрократию», и тем больше будет чувства причастности и ответственности за совместные решения. 

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

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

5. Ревью. Перед внедрением покажите финальную версию документа тем, кто не принимал участие в его разработке, но всё же будет с ним сталкиваться в работе (например, разработчикам). Свежий взгляд может натолкнуть на новые полезные идеи. Главное — найти инициативного разработчика

Заключение

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

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

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

End-to-End Testing

End-to-End testing is a software testing approach that verifies the complete software, including its interaction with external interfaces, from beginning to end. End-to-end testing examines the entire software for dependencies, data integrity, and connectivity with other systems, interfaces, and databases in order to simulate a complete production environment.

It checks batch/data processing from various upstream/downstream systems in addition to the software system. As a result, the term «End-to- End» was coined. End-to-end testing is normally done after functional and system testing has been completed. It simulates real-time conditions by using real-world data and a test environment. Chain testing is another name for end-to-end testing.

What is the purpose of End-to-End Testing?

End-to-end testing evaluates the whole system flow and boosts confidence by discovering bugs and boosting subsystem test coverage. Modern software systems are sophisticated and linked, with various subsystems that may be different from those in use today. Failure of any subsystem can bring the entire system down, which is a big risk that can be avoided by End-to-End testing.

Process of End-to-End Testing

The End to End testing procedure is depicted in the diagram below.

• Requirements —

  • Requirements Capturing

  • Documentation

• E2E Design —

  • Design of components

  • E2E Design

• Component Design —

  • Component Design and Testing

• Development —

  • Development Coding and Design

• E2E Testing —

  • Environment setup for end 2 end setup

  • Test Design and Execution

Action Involved in End-to-End Testing

The following are the main actions involved in End-to-End Testing −

• An examination of end-to-end testing requirements

• Configuration of the test environment and hardware/software requirements

• Describe the processes of all the systems and their subsystems.

• Roles and duties for all systems are described.

• Methodologies and criteria for testing

• End-to-end requirement tracking and test case design

• Data for each system’s input and output

What is the best way to develop end-to-end test cases?

There are three aspects to the End to End Testing Design framework.

• Create user-defined functions

• Constructing Conditions

• Create Test Cases

Let’s take a closer look at them:-

Construct User Functions

As part of the construct user functions, the following actions should be completed

• Make a list of the system’s characteristics and their associated components.

• For each feature or function, make a list of the input data, action, and output data.

• Determine the functions’ interrelationships.

• Determine if the function is reusable or self-contained.

Consider the following scenario: you log into your bank account and transfer money from another bank account to your own (3rdparty subsystem)

• To use the banking system, you must first log in.

• Check the account balance to see how much money is left in the account.

• Make a money transfer from your account to another bank account (3rdparty sub-system)

• Examine your most recent account balance.

• Close the application.

Create conditions based on the user’s role.

As part of the construction conditions, the following operations are carried out −

• Creating a set of criteria for each defined user function

• Sequence, timing, and data conditions are examples of conditions.

Checking of additional criteria, such as −

A page for logging in

• Password and Username are both invalid.

• Validating the login and password

• Checking the strength of a password

• Error message inspection

Balance Amount

• After 24 hours, check the current balance. (In the case of a transfer to a different bank)

• If the transfer amount is larger than the existing balance, look for an error notice.

Construct a Test Scenario

Creating a Test Scenario for the stated user function

In this instance,

• Register with the system.

• Check the balance of your bank account.

• Transfer the funds to your bank account.

Create a number of test scenarios

For each scenario, create one or more test cases. Each condition may be included in a separate test case.

End-to-End Testing Metrics

The metrics listed below are just a handful of the many that are used in end-to-end testing.

• Test Case Preparation Status — It shows how far the test case preparation has progressed in comparison to the schedule.

• Progress on the Weekly Test — Shows % test completion week by week, including failed, not executed, and completed against planned execution tests.

• Faults Status & Details — This report shows the percentage of open and closed defects each week. In addition, week-by-week distribution of faults depending on severity and priority

• Availability of the environment — Total number of hours «up» / Total number of hours scheduled for testing per day

System Testing vs. End-to-End Testing

The following table highlights the major differences between System Testing and End-to-End Testing −

E2E Tests Come in a Variety of Forms

Manual E2E testing and automated E2E testing are the two basic forms.

To evaluate compliance with the application requirements, a business tester pretends to be the user (on as many devices and screen sizes as he has access to). Purchasing a purchase from an e-commerce store, for example.

The tester would buy the product in the same way that a regular user would: by clicking the add-to-cart button, opening the cart, proceeding to the purchase interface, and paying.

The tester’s goal is to see if any of the flow’s steps are broken.

Automated E2E testing has the same purpose. Only that automated testing provides more advanced capabilities that a human tester might not be able to provide. Various test automation systems provide automated testing services as well as a variety of devices (dubbed «device labs») on which tests may be conducted.

Automated Testing vs. Manual Testing

• As previously indicated, manual testing entails a tester manually executing tests. Poor testing might be caused by human mistakes. Testing is conducted automatically in automated tests. As a result, automated testing can be more accurate in many situations.

• Manual testing is more straightforward to set up and comprehend. Automated testing is usually difficult to set up. Automated testing usually has a steeper learning curve.

• Manual testing necessitates a lower initial cost and resource commitment. While automated testing requires a higher initial cost, it provides a large return on investment as your testing process grows and develops. As a result, this is something to think about while selecting automated testing solutions.

• It’s easier to recreate a production situation via manual testing. However, certain automated technologies make the procedure more difficult. It’s simple to check that certain requirements are satisfied manually before a feature functions, but automated testing methods might be complicated to set up.

Checklist for E2E Testing

Because a user interface is made up of numerous elements, E2E isn’t only about testing the user interface.

An API may be used to access material from a database for a blog site. It’s self-evident that the frontend design, database, and API must all be tested independently and jointly in this situation.

A checklist to follow during E2E tests is as follows −

• Database − You’ll need to test the database you’re using for your system. You might run tests to check that data is properly saved, structured, read, and updated.

• Performance − While a webpage may navigate well, user experience is influenced by its speed. As a result, it’s critical to evaluate a page’s or feature’s performance.

• Security − The security of a web application dictates how safe it is for both the user and the company. In this instance, vulnerability testing tools are very critical.

• Functionality − The major purpose of testing in the first place is to ensure that the product works properly. All features must work as intended. Unit tests can likewise be used in this situation.

• Usability − Components should be useable because they are functioning. Users are just as vital as the tool, therefore testing must include events (such as clicks) on items, as well as correct navigation.

Example of E2E Testing

For this example, we’ll utilize Perfecto Scriptless, a codeless testing platform that can be used for end-to-end interface testing, to test the Twitter sign-in process.

Let’s establish a test flow before we start building up our tests.

• Go to twitter.com to find out more.

• To log in, click the login button.

• If any of the inputs are empty, make sure the login button does nothing.

• When the inputs are not empty, submit the details by clicking the button (we’ll test with erroneous information).

• “The username and password you supplied did not match our records,” says the error notice. Please double-check your work and try again.») in red.

• The test should be saved.

The user will be sent to their account if the credentials are accurate (which can be another test).

Conclusion

End-to-end testing is the process of checking a software system and its sub-systems in software engineering. The most difficult aspect of this testing is having sufficient knowledge of the entire system as well as an associated sub-system.

End-to-End Testing

End-to-End testing is a software testing approach that verifies the complete software, including its interaction with external interfaces, from beginning to end. End-to-end testing examines the entire software for dependencies, data integrity, and connectivity with other systems, interfaces, and databases in order to simulate a complete production environment.

It checks batch/data processing from various upstream/downstream systems in addition to the software system. As a result, the term «End-to- End» was coined. End-to-end testing is normally done after functional and system testing has been completed. It simulates real-time conditions by using real-world data and a test environment. Chain testing is another name for end-to-end testing.

What is the purpose of End-to-End Testing?

End-to-end testing evaluates the whole system flow and boosts confidence by discovering bugs and boosting subsystem test coverage. Modern software systems are sophisticated and linked, with various subsystems that may be different from those in use today. Failure of any subsystem can bring the entire system down, which is a big risk that can be avoided by End-to-End testing.

Process of End-to-End Testing

The End to End testing procedure is depicted in the diagram below.

• Requirements —

  • Requirements Capturing

  • Documentation

• E2E Design —

  • Design of components

  • E2E Design

• Component Design —

  • Component Design and Testing

• Development —

  • Development Coding and Design

• E2E Testing —

  • Environment setup for end 2 end setup

  • Test Design and Execution

Action Involved in End-to-End Testing

The following are the main actions involved in End-to-End Testing −

• An examination of end-to-end testing requirements

• Configuration of the test environment and hardware/software requirements

• Describe the processes of all the systems and their subsystems.

• Roles and duties for all systems are described.

• Methodologies and criteria for testing

• End-to-end requirement tracking and test case design

• Data for each system’s input and output

What is the best way to develop end-to-end test cases?

There are three aspects to the End to End Testing Design framework.

• Create user-defined functions

• Constructing Conditions

• Create Test Cases

Let’s take a closer look at them:-

Construct User Functions

As part of the construct user functions, the following actions should be completed

• Make a list of the system’s characteristics and their associated components.

• For each feature or function, make a list of the input data, action, and output data.

• Determine the functions’ interrelationships.

• Determine if the function is reusable or self-contained.

Consider the following scenario: you log into your bank account and transfer money from another bank account to your own (3rdparty subsystem)

• To use the banking system, you must first log in.

• Check the account balance to see how much money is left in the account.

• Make a money transfer from your account to another bank account (3rdparty sub-system)

• Examine your most recent account balance.

• Close the application.

Create conditions based on the user’s role.

As part of the construction conditions, the following operations are carried out −

• Creating a set of criteria for each defined user function

• Sequence, timing, and data conditions are examples of conditions.

Checking of additional criteria, such as −

A page for logging in

• Password and Username are both invalid.

• Validating the login and password

• Checking the strength of a password

• Error message inspection

Balance Amount

• After 24 hours, check the current balance. (In the case of a transfer to a different bank)

• If the transfer amount is larger than the existing balance, look for an error notice.

Construct a Test Scenario

Creating a Test Scenario for the stated user function

In this instance,

• Register with the system.

• Check the balance of your bank account.

• Transfer the funds to your bank account.

Create a number of test scenarios

For each scenario, create one or more test cases. Each condition may be included in a separate test case.

End-to-End Testing Metrics

The metrics listed below are just a handful of the many that are used in end-to-end testing.

• Test Case Preparation Status — It shows how far the test case preparation has progressed in comparison to the schedule.

• Progress on the Weekly Test — Shows % test completion week by week, including failed, not executed, and completed against planned execution tests.

• Faults Status & Details — This report shows the percentage of open and closed defects each week. In addition, week-by-week distribution of faults depending on severity and priority

• Availability of the environment — Total number of hours «up» / Total number of hours scheduled for testing per day

System Testing vs. End-to-End Testing

The following table highlights the major differences between System Testing and End-to-End Testing −

E2E Tests Come in a Variety of Forms

Manual E2E testing and automated E2E testing are the two basic forms.

To evaluate compliance with the application requirements, a business tester pretends to be the user (on as many devices and screen sizes as he has access to). Purchasing a purchase from an e-commerce store, for example.

The tester would buy the product in the same way that a regular user would: by clicking the add-to-cart button, opening the cart, proceeding to the purchase interface, and paying.

The tester’s goal is to see if any of the flow’s steps are broken.

Automated E2E testing has the same purpose. Only that automated testing provides more advanced capabilities that a human tester might not be able to provide. Various test automation systems provide automated testing services as well as a variety of devices (dubbed «device labs») on which tests may be conducted.

Automated Testing vs. Manual Testing

• As previously indicated, manual testing entails a tester manually executing tests. Poor testing might be caused by human mistakes. Testing is conducted automatically in automated tests. As a result, automated testing can be more accurate in many situations.

• Manual testing is more straightforward to set up and comprehend. Automated testing is usually difficult to set up. Automated testing usually has a steeper learning curve.

• Manual testing necessitates a lower initial cost and resource commitment. While automated testing requires a higher initial cost, it provides a large return on investment as your testing process grows and develops. As a result, this is something to think about while selecting automated testing solutions.

• It’s easier to recreate a production situation via manual testing. However, certain automated technologies make the procedure more difficult. It’s simple to check that certain requirements are satisfied manually before a feature functions, but automated testing methods might be complicated to set up.

Checklist for E2E Testing

Because a user interface is made up of numerous elements, E2E isn’t only about testing the user interface.

An API may be used to access material from a database for a blog site. It’s self-evident that the frontend design, database, and API must all be tested independently and jointly in this situation.

A checklist to follow during E2E tests is as follows −

• Database − You’ll need to test the database you’re using for your system. You might run tests to check that data is properly saved, structured, read, and updated.

• Performance − While a webpage may navigate well, user experience is influenced by its speed. As a result, it’s critical to evaluate a page’s or feature’s performance.

• Security − The security of a web application dictates how safe it is for both the user and the company. In this instance, vulnerability testing tools are very critical.

• Functionality − The major purpose of testing in the first place is to ensure that the product works properly. All features must work as intended. Unit tests can likewise be used in this situation.

• Usability − Components should be useable because they are functioning. Users are just as vital as the tool, therefore testing must include events (such as clicks) on items, as well as correct navigation.

Example of E2E Testing

For this example, we’ll utilize Perfecto Scriptless, a codeless testing platform that can be used for end-to-end interface testing, to test the Twitter sign-in process.

Let’s establish a test flow before we start building up our tests.

• Go to twitter.com to find out more.

• To log in, click the login button.

• If any of the inputs are empty, make sure the login button does nothing.

• When the inputs are not empty, submit the details by clicking the button (we’ll test with erroneous information).

• “The username and password you supplied did not match our records,” says the error notice. Please double-check your work and try again.») in red.

• The test should be saved.

The user will be sent to their account if the credentials are accurate (which can be another test).

Conclusion

End-to-end testing is the process of checking a software system and its sub-systems in software engineering. The most difficult aspect of this testing is having sufficient knowledge of the entire system as well as an associated sub-system.

Оригинальная публикация

Источник

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

End-2-end тесты на практике

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

• Команда завершила свой этап программирования на неделю позже (и много работала сверхурочно).
• Поиск основной причины неудачного end-2-end теста является трудоемким и может занять много времени.
• Неудачи параллельной команды и сбои в оборудовании сдвинули результаты тестов на несколько дней.
• Многие мелкие ошибки были спрятаны за большими ошибками.
• Результаты end-2-end тестов временами были ненадежными.
• Разработчикам пришлось подождать до следующего дня, чтобы узнать, сработало ли исправление или нет.

Итак, теперь, когда мы знаем, что пошло не так в end-2-end стратегии, нам нужно изменить наш подход к тестированию, чтобы избежать многих из вышеперечисленных проблем. Но каков правильный подход?

Истинная ценность тестов

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

Построение правильной обратной связи

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

• Он должен быть быстрым. Ни один разработчик не хочет ждать часами или днями, чтобы узнать, работает ли его изменение. Иногда изменение не работает (никто не совершенен), и цикл обратной связи должен выполняться несколько раз. Более быстрый цикл обратной связи приводит к более быстрым исправлениям. Если цикл достаточно быстр, разработчики могут даже запустить тесты перед проверкой изменений.
• Он должен быть надежным. Ни один разработчик не хочет тратить часы на отладку теста, только для того, чтобы выяснить, что сам тест был ошибочным. Ненадежные тесты снижают доверие разработчика к ним, и в результате такие тесты часто игнорируются, даже когда они обнаруживают реальные проблемы с продуктом.
• Он должен позволять быстро находить ошибки. Чтобы исправить ошибку, разработчикам необходимо найти конкретное строки кода, вызывающие ошибку. Когда продукт содержит миллионы строк кодов, а ошибка может быть где угодно, это все равно что пытаться найти иголку в стоге сена.

Думайте о малом, а не о большем

• Модульные тесты быстрые. Нам нужно написать небольшой блок кода и мы уже можем тестировать его. Модульные тесты, как правило, довольно маленькие. На самом деле, одна десятая секунды — слишком долго для модульных тестов.
• Модульные тесты надежны. Простые системы и небольшие модули кода, как правило, гораздо более устойчивые. Кроме того, лучшие практики модульного тестирования — в частности, практики, связанные с герметичными тестами — полностью устраняют такие проблемы.
• Модульные тесты позволяют быстро найти ошибки. Даже если продукт содержит миллионы строк кода, если модульный тест не пройден, то вы, скорее всего, взглянув на тестируемый модуль сразу поймете в чем ошибка.

Пирамида тестов

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

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

Вакансии

Если вы любите и умеете писать модульные тесты, то вам к нам! В компании ЛАНИТ открыта вакансия разработчика Java в DevOps команду, где вы найдете себе единомышленников.

Обсудить в форуме

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

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

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

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

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

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

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

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

• Изучение требований к сквозному тестированию;

• Настройка тестовой среды и требования к оборудованию/программному обеспечению;

• Описание всех процессов системы и ее подсистем;

• Описание ролей и ответственности для всех систем;

• Методология и стандарты тестирования;

• Сквозное отслеживание требований и разработка тест-кейсов;

• Входные и выходные данные для каждой системы.

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

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

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

2. Создание условий

3. Создание тест-кейсов

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

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

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

• Перечислить функции системы и их взаимосвязанные компоненты;

• Перечислить входные данные, действия и выходные данные для каждой характеристики или функции;

• Определить отношения между функциями;

• Определить, является ли функция многократно используемой или независимой.

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

1. Войти в банковскую систему.

2. Проверить сумму остатка на счете.

3. Перевести определенную сумму со своего счета на другой банковский счет (сторонняя подсистема).

4. Проверить текущий баланс счета.

5. Выйти из приложения.

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

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

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

• Условия включают последовательность, время и условия данных.

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

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

• Неверное имя пользователя и пароль

• Проверка с действительным именем пользователя и паролем

• Проверка надежности пароля

• Проверка сообщений об ошибках

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

• Проверьте текущий баланс через 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 и перепишем существующие тесты на него. Регистрация доступна по ссылке.

Сквозное тестирование, оно же End-to-end или E2E, — это процесс тестирования, при котором происходит подробная эмуляция пользовательской среды. То есть при данном тестировании имитируют:

• щелчки мышью, 

• нажатия на кнопки, 

• заполнение форм, 

• переходы по страницам и ссылкам,

• и другие поведенческие факторы. 

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

Е2Е—процесс — это конечный этап тестирования, после него никакого тестирования не проводят. Он самый трудозатратный и дорогой, именно поэтому находится на вершине пирамиды тестирования.

 

Е2Е—процесс — что это?

Е2Е—процесс происходит при помощи сложных программ для тестирования, написанных специально для тестирования или «вручную», от этого данный процесс требует много времени и затрат. Поэтому до его применения обычно проводят более дешевые и нетребовательные виды тестирования. 

К примеру, компания Гугл при разработке своих продуктов следует правилу «70-20-10», цифры которого показывают процентное соотношение от общего количества тестов, то есть:

• 70% занимают юнит-тесты;

• 20% занимают интеграционные тесты;

• 10% занимают Е2Е—тесты.

Конечно, такая комбинация тестов не является эталонной. Для каждого проекта она будет своя. Но идея в том, что количество Е2Е—тестов должно быть куда меньше, чем остальных тестов. В некоторых проектах сквозного тестирования вообще может не быть, так как unit-тесты и интеграционные тесты покрывают все процессы программы. А иногда просто их нецелесообразно проводить из-за того, что проект небольшой и тестируемый функционал может быть еще много раз переписан. Поэтому можно сказать, что E2E — это процесс больших и сложных проектов.

 

Какие бывают Е2Е—тесты

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

Типы Е2Е—тестирования:

1. Метод «черного ящика». Это специальный E2E-процесс тестирования, при котором само тестирование проводится только с интерфейсом пользователя. «Черным ящиком» называется, потому что тестировщика интересуют только проблемы интерфейса: работоспособность функций, ошибки при взаимодействии, ошибки при определенном поведении пользователей и т. д., и его абсолютно не интересует, как это все работает внутри программы. В большинстве случаев тестировщик даже не понимает, как с помощью кода получается тот или иной функционал. Такой тип тестирования считается самым распространенным.

2. Метод «белого ящика». В этом типе тестирования тестировщику известна «внутренняя кухня» программы. А это значит, что ему известно, как себя должна повести программа при определенном действии пользователя. Он анализирует, совпадает ли задуманный результат поведения с реально происходящим, и понимает, где нужно вносить необходимые корректировки.

Любой сквозной тест — это:

• в первую очередь тестирование UI;

• тяжелый и медленный тест;

• применение метода «черного ящика» и найм сторонних тестировщиков, никак не связанных с разработкой программы;

• тяжелый «отлов» найденной проблемы;

• тестирование всех модулей и всех систем целиком, поэтому требуется сложный и эффективный софт или работа «руками»;

• гарантия, что программа работает так, как задумано, или нет.

 

Заключение

Е2Е — это дорогой и сложный процесс тестирования, к которому нужно подготавливаться основательно. Давайте проведем аналогию с мостом. Мост через реку — это тестируемая программа. Так вот Е2Е—тестирование — это не просто проехать по мосту груженными КАМАЗами и смотреть издалека: выдержит или не выдержит. Е2Е — это куча всевозможных датчиков, расставленных по всему мосту, которые сигнализируют о каждом шаге и готовы фиксировать любой сценарий развития на «мосту»:

• перегруз;

• колебания;

• микротрещены;

• нагрузку на каждый трос или балку;

• поведение моста при наводнении, землетрясении, пожаре или аварии на нем;

• и др.

Нужен или нет Е2Е именно вашей компании/программе/разработке? Это дело индивидуальное и зависит только от поставленных целей и потребностей. Практика показывает, что до сквозного тестирования должно проводиться множество других более простых тестов и на основе полученных от них результатов решается, нужен ли проекту Е2Е—тест или нет.

Всем привет, сегодня я рад представить материал по end-to-end (e2e) тестированию. Данный вид тестирования поможет вам сэкономить время, если у вас есть задачи по проверке работоспособности веб-приложения.

Статья рассчитана на новичков в программировании (как начинающих разработчиков, так и начинающих тестировщиков).

End-to-end тестирование — это вид тестирования, при котором компьютер максимально близко к реальности эмулирует поведение пользователя. То есть, ваше web-приложение загружается в браузере, затем нажимаются кнопки, происходят переходы по ссылкам, страница прокручивается и так далее. При данном подходе backend не «мокается», таким образом все http-запросы происходят в реальном времени.

Можно провести аналогию, что за компьютером сидит робот и нажимает кнопки в указанном порядке.

Содержание:

Введение

Не скоро проза складывается, да скоро тесты пишутся. Распрощаемся с музой и посмотрим на исходный код. На выбор у нас два репозитория:

Также два репозитория докажут нам на деле, что Cypress’у не важно на чем написано приложение.

В master ветке находится логика и верстка, а тесты мы сейчас с вами добавим.

Установка Cypress

NPM / Yarn на ваше усмотрение. Я буду использовать npm и устанавливать Cypress как локальную зависимость. Все примеры я выполнял на macOS.

Установка может занять продолжительное время.

Добавляем скрипт для запуска тестов

Запустить любой «исполняемый» скрипт можно командой:

Но это не удобно, поэтому давайте добавим в package.json в секцию scripts новую строку:

Теперь наши тесты можно запускать с помощью команды:

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

Если установка прошла успешно, у вас откроется окно с тестами-примерами, которые были добавлены командой разработчиков Cypress. Рекомендую их запустить, чтобы ознакомиться с возможностями инструмента.

Можно выбрать Electron 83 (Chromium), Google Chrome (настоящий) или Firefox. Я оставлю Electron 83 по умолчанию.

Перед тем, как мы начнем писать наши тесты, давайте удалим все тесты-примеры из директории cypress/integrations/examples.

Добавляем тесты

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

Наш план автоматического тестирования будет состоять из следующих пунктов:

Начнем с первого пункта — проверки, что приложение загрузилось.

Создадим новый файл в директории с проектом:

cypress/integration/main.js

context (вы можете так же использовать describe) — это название категории (группы) ваших тестов. it — элемент в группе, то есть сам тест.

Сразу же запустим наш тест…

Почему ошибка? Потому что мы забыли запустить приложение.

Давайте еще раз повторим: end-to-end тестирование — это «эмуляция» действий реального пользователя в реальном браузере. Мы можем посетить «vc.ru» и кликнуть на заголовок первого материала, если мы хотим это протестировать. Но, так как мы тестируем наше приложение в режиме разработки, то нам необходимо до запуска e2e-тестов запустить наше приложение и оставить его запущенным. Поэтому, запустите приложение в соседней вкладке терминала и запустите тесты вновь.

Приложение загрузилось, порядок. Можно заниматься поиском элементов. Для этого, как советует раздел документации, добавим тестируемым элементам data-cy аттрибут (привожу примеры на react, elm код здесь)

src/App.js

Данный атрибут нам нужен, чтобы наверняка найти нужный элемент. Давайте напишем тесты для проверки, действительно ли кнопки «+» и «-» отрисованы на странице.

cypress/integration/main.js

Порядок. Мы нашли элементы, этого достаточно.

Для проверки, что «результат» при загрузке приложения равен нулю, нам нужно не только найти DOM-элемент, но также посмотреть чему равно его текстовое содержимое.

(троеточие означает, что часть кода скрыта для краткости)

cypress/integration/main.js

Проверяем:

Обратим внимание на синтаксис: сначала мы нашли элемент (cy.get), затем проверили его с нашим «утверждением/ожиданием» (в англ — assertion). Такой подход проверки результата с ожиданием используется в тестах повсеместно. Все возможные «ожидания» и примеры представлены в документации.

В руководствах часто игнорируют возможные ошибки, но это не наш случай, давайте изменим 0 на 1 в файле с тестами и Cypress автоматически «прогонит» наши тесты вновь.

Подведем итог. В данном разделе мы узнали:

Больше тестов, стабильней результат

Капитан Очевидность поработал над заголовком, а мы поработаем над новой партией тестов:

Как я уже отмечал выше, Cypress позволяет не только найти элемент на странице, но также позволяет нам выполнить весь набор возможных действий (click, double click, right click, и т.д.). Нам потребуется click.

cypress/integration/main.js

Принцип тестов не изменился: сначала находим элемент с помощью cy.get, затем производим необходимые манипуляции.

Обратите внимание на порядок выполнения тестов. Сначала приложение загрузилось, затем мы кликнули на «плюс» — проверили, кликнули еще раз на «плюс» — проверили, кликнули на «минус» — проверили. Если мы в текущем коде поменяем it секции местами, то тесты могут сломаться. Так как мы тестируем последовательность действий, то наши тесты должны отрабатывать в корректной последовательности.

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

Новая фича: Reset (сброс результата)

Сначала напишем код, а затем напишем тест. Кое-кто воскликнет: «Постойте, а как же TDD?» На что мы ответим: спокойствие, end-to-end тесты можно (и я думаю даже нужно) писать после того, как код уже написан.

Добавляем кнопку (примеры кода на react, elm код здесь)

src/App.js

Добавляем тесты, но сначала план. Нам необходимо:

В данном тестовом наборе у нас есть избыточный тест, в котором мы убеждаемся, что кнопка «Сбросить» отрисована. Так как в следующем тесте мы кликаем по данной кнопке и если кнопки не будет — Cypress сообщит нам об этом. Поэтому тест отрисовки кнопки «Сбросить» можно удалить.

На этом мы завершаем практическую часть. Исходный код приложения с тестами можно найти в соответствующей ветке (elm-репозиторий, react-репозиторий)

Какие минусы имеют end-to-end тесты?

Стабильность

По мнению многих, end-to-end тесты не стабильны. Сложно опровергать данное заявление, так как достичь 100% стабильности затруднительно. Однако, за многие годы Cypress добился достойных показателей по стабильности. Зачастую проблема не в том, что Cypress плох и не может выдать стабильный результат, а в том, что тест написан плохо и поэтому его результат не стабилен.

Медлительность

Прогон end-to-end тестов занимает много времени. Тем не менее, это в разы быстрее чем ручное тестирование.

Конкуренты

Конкуренты на рынке есть, самый известный мне — puppeteer (от Google, между прочим). Определенно заслуживает внимания. В свое время, в 2017м году, мы сделали выбор в сторону puppeteer для тестирования десктопного приложения на electron.

Больше автоматизации

Любые тесты, в том числе и написанные на Cypress, приятнее запускать не в ручную, а в автоматическом режиме. На деле это выглядит так: у вас есть скрипт, который выпускает ваше приложение в свет. На одном из этапов у вас автоматически запускаются тесты, и если все в порядке — скрипт продолжает свою работу. Если вам интересно, почитайте материалы по CI/CD (например здесь).

Заключение

В данном материале мы узнали:

Также на простых примерах мы попрактиковались в написании тестов.

Что дальше?

Почитайте как тестировал свой продукт Саша Беспоясов.

Начните внедрять e2e тесты в вашей работе!

End-to-end тестирование не заменяет unit-тестов. Тестирование — это комплекс мер по поддержанию высокой планки качества, и e2e тесты лишь часть пирамиды тестирования.

Спасибо всем, кто дочитал до конца, а так же спасибо Selectel за мотивацию поработать «пером».

Если у вас остались вопросы — напишите в комментариях.

E2E Testing also called End to End testing, is a very common testing methodology where the objective is to test how an application works by checking the flow from start to end. Not only the application flow under dev environment is tested, but the tester also has to check how it behaves once integrated with the external interface. Usually, this testing phase is executed after functional testing and system testing is completed. The technical definition of end to end testing is – a type of testing to ensure that behavioural flow of an application works as expected by performing a complete, thorough testing, from the beginning to end of the product-user interaction in order to realize any dependency or flaw in the workflow of the application.

Why End to End Testing is Required?

In the current Agile world, an application is interconnected and integrated with multiple systems that are outside of the application environment. The entire flow of the application thus gets complicated. End to end testing ensures that the application is tested from all layers – front end to backend along with its interfaces and the endpoints. Let’s see why it is needed.

Health of Back-end – End to end testing checks the database as well as backend layer of the application. Since the core functionalities of the application depend on the back end and database layer, testing this layer checks how accurately the application can perform the critical functions.

Errors in Distributed Environment – End to end testing makes it possible to test an application that is based on SOA or cloud environments. Also, in application consisting multiple components that require an all-around check, it helps to pinpoint problems in the core.

App Behavior Validation in Multi-tier System – In applications having a complex architecture or a workflow that is subdivided into multiple tiers, the end to end testing checks the overall functioning as well as functioning in individual layers. It also identifies the behavior of the application in connected systems.

Ensuring Interaction Accuracy – Since front-end testing is also involved, it is ensured that the application behaves accurately a provides a user experience that is consistent across multiple platforms, devices and environments.

Reusability of Test Cases – During different processes of the application’s lifecycle, the end to end testing provides the option to execute test cases that are repeatable. Moreover, it also increases the test coverage and makes the owner confident in the performance of the application.

Now that we have seen why the E2E testing is required, let’s see how it is carried out.

How End to End Testing is Performed?

Let’s summarize the key activities that are must to include during the end to end testing.

• Thoroughly analyze the requirements before starting the testing phase.
• Setting up the test environment following all the prerequisites.
• Analyze the software and hardware requirements ( both minimum as well as recommended configuration).
• Study the main system along with connected subsystems.
• List down the responsibilities of all systems involved.
• List down the testing methods along with the description of the standards to be followed.
• Design the test cases and while doing so also trace the requirement matrix.
• Save the output results and input data before testing each system.

Key activities being set, let’s dive in deep.

End to end testing process can be divided into 3 categories.

User Functions

As a part of user functions, the following activities should be performed.

• List down the software system’s features and the subsystems that are interconnected.
• Keep track of the actions performed for any functionality along with the input data and output results.
• Between different functionalities performed from the user’s end find out if there is any relation.
• Check whether the user functions are independent or can be reused. In short – find their nature.

Let’s explore a scenario that will help us to understand E2E testing. We’ll consider an online theatre booking service like BookMyShow.

1. Log into the application
2. Search for a movie show.
3. Book your seats.
4. Check the payment gateway.
5. Check the message confirmation for the booked tickets.
6. Logout from the application.

Conditions Depending On User Function

As a part of building conditions, do the following:

• For each user function, build a set of conditions.
• Conditions should include parameters like timing, data conditions, and sequence.

Considering our previous example of BookMyShow we can have the following condition check.
In the login page

1. Check whether error messages are reflected properly in case of incorrect password or username.
2. Check the same scenario with valid user details and see if login is successful.
3. Check the strength of a password.
4. Check email address validation.
5. Check the error messages if the amount to be transferred is greater than your wallet balance.

Payment page

1. Invalid pin.
2. Invalid CVV.
3. Invalid Debit/Credit credentials.
4. Validate all mandatory fields are working.

Build the Test Cases

Before building the test cases, consider the following factors.

• Write more than one test cases for every scenario and every functionality.
• Enlist each condition as separate test cases.

Watch this video to learn how to write end-to-end automation tests using Selenium WebDriver and perform cross browser and parallel testing at scale.

Parameters Involved During End to End Testing

Let’s move on to the important parameters that are involved during the end to end testing.

1. Test Case Preparation – An important thing to track is at what is the current state of the test case preparation. The tester can track this in form of a graph. It gives an idea of the progress of test case preparation (current vs planned).
2. The progress of Weekly Test – This provides a percentage base report of the test completion. Currently executed, not executed and failed test cases are compared weekly with the planned report.
3. Details of Defect – This report provides a percentage of defects that are closed or opened by the end of a week. Weekly distribution of defects based on priority and criticality is also taken into account.
4. Availability of Environment – This report provides a comparison of the total time scheduled for testing every day versus the total hours actually spent.

How Is It Different From System Testing?

After discussing all the aspects involved in End to end testing, let us discuss how different it is from system testing.
Before moving on to that, we should know what is system testing. It is basically a kind of black box testing, where the application is tested after integrating it with the external system. The testing is performed from a user’s point of view considering real-world conditions.
But how different it is from End to end testing? Well,

• System testing validates only the integrated software system whereas End to end testing checks both the main as well as interconnected systems.
• System testing checks features and functionalities of the system while E2E testing checks the complete flow of the system.
• Only non-functional and functional testing are considered in system testing, while in E2E testing, backend systems along with all other interfaces are considered.
• System testing is executed once Integration testing is completed. End to end testing is carried out immediately after system testing is completed.
• Both Automation, as well as manual procedures, can be used for System testing. However, for an end to end testing, the process gets much complex since it is hard to automate testing of external interfaces. Hence, manual testing is preferred.

Automation and E2E Testing

No matter how much advantageous, automation has a very little scope at the end to end testing. This is because of the following:

• The architecture of complex applications and more interconnected systems makes it difficult to write test cases.
• When database testing is involved, that requires constant updating and deleting table or data, it is impossible to write an automated script that can do the job.

However partial automation testing is possible. Especially with the UI layer of the application or testing the functionality, selenium web driver or related tools can be used to write automated scripts for partial testing.

Challenges Faced During E2E Testing

Although detecting bugs in a complex workflow is considered to be the biggest challenge in the end to end testing, apart from that there are other complications as well. Let’s take a look.

• Building a Workflow – The test cases in E2E testing must be executed sequentially. In a distributed workflow, it is difficult to manage a workflow where a thousand cases can be run in a sequential order.
• Access Issue – Custom applications can be tested easily in a virtual dev environment. The real challenge arrives when you have to test an offline application in client or production environment. There is limited availability of test environments and you have to install local agents and log in to virtual machines. After all of these, you will need to figure out a way to keep the machine on during the time of the test and prevent unforeseen situations like system updates from interrupting the execution of test cases.

Best Practices for E2E Testing

A typical end to end testing can be a lot of time-consuming when performed manually and a lot complex as well. However, following certain best practices will ensure a smooth completion of testing and efficient cost management. Let’s take a look at them.

• Test from the Perspective of an End User – Think like a user, focus more on features rather than how the functionalities are implemented. Use documents related to acceptance testing, user stories that will help you to capture the user’s point of view and design test cases accordingly.
• Limit Scenarios Involving Exception Testing – Use end to end testing only to capture typical user scenarios. For exception scenarios, use integration testing and low-level unit testing.
• Risk Analysis – This is an important thing to consider. Concentrate on the features of your application whose failure will cause high risk. A risk assessment matrix will become quite a useful tool for this purpose.
• Maintain an Order – With complexity in test cases and increasing components, points of failure also increases and it becomes difficult to debug them. How to avoid it? Execute unit testing and integration testing beforehand and resolve errors that are easier to detect. Once E2E testing starts, run smoke tests, sanity tests along with other high-risk test scenarios.
• Manage the Environment – Make sure the system set up for running the test cases are proficient enough. Document the requirements and make sure they are fulfilled by your system administrator before the testing starts. An easier solution is to follow the system requirement of the production environment. Also, to keep your staging environment as close to production as possible.
• Setup and Teardown Optimization – Make sure that your environment is ready to start the job at a moment’s notice. Once testing is done, clear the test data so that the environment is restored to the state it was originally and can be used anytime for another round of testing.

What The Future Has in Store?

With the advancement of IoT and the introduction of modern applications, we are seeing more and more interconnected applications with every device in our surrounding environment. Their workflow is a bit complicated but can be a lot beneficial.

Scenarios have often arisen when an organizational application is deployed at a place outside the organization and it failed, affecting business processes. Such situations can be avoided if an end to end testing is carried out effectively. It ensures that the application performs properly at all layers, especially when it is integrated with external systems.

With information technology growing more, the testing industry has already become a mandatory part of any software development methodology. If the correct solution and best practices are added, effort spends on end to end testing can be a lot beneficial. Also, with software systems getting more complicated day by day and as said before, IoT becoming the next top trend in the software industry, the future holds a lot in store for testing professionals specializing in End to end testing.