What end-to-end (E2E) means? I know what it doesn't mean, regression tests. They are confused with each other all the time, and that's ok, as E2E are part of the regression test suite and have the objective to check if a bug was introduced after a change, but keep in mind that regression test involves the execution of the entire test suite, which includes the ent-to-end ones.
End-to-end test can be also referred as Broad Stack Tests and basically implies that we are testing some part of the system entirely, fully integrated, which can be done in a bunch of different ways, but let's focus on two of them, Journey Tests and Smoke Tests.
Journey Test
Journey tests are also kinds of Business Facing Tests and have the intent to simulate real-world scenarios consisting in the execution of user journeys inside the app. The idea is to cover the whole application, checking how different components interact and whether the system behaves correctly in complex scenarios.
Smoke Test
First of all, we are not planning to stress a device until we see it smoking.. The Smoke Test term comes from the idea of turning on a piece of electronic equipment for the first time to see if it starts smoking due to a major flaw, indicating that there might be a serious issue with the hardware.
In software, a smoke test is a kind of end-to-end test that consist in execute some user journeys on the application to check if the basic functionalities works, which means that smoke tests can be seen as a small version of User Journey Tests. The selected journey depends on how critical is the given feature to the system.
How to write
Automated or not, test scenarios also serves as a documentation to the system, which means that we should care about well defined scenarios and readability.
Readability may depend on who's the target of the message and who's receiving that message (e.g A technical engineering page read by someone who doesn't have any affinity with the subject), but we have the option to change the structure of the message and make it niche or comprehensive. So, what would be the structure that would make our E2E readable for Engineers and Stakeholders?
The domain-specific language (DSL) is the answer. We can also combine the given DSL with the Gherk Syntax and use a set of special keywords to give structure and meaning to the test scenarios. In this context, the keywords that we are interested in are Given, When, And, and Then.
Here's how we can structure a test scenario using these keys:
Given my application is installed
And I tap on the app icon
When the app is launched
Then I see the Login screen
The scenario above can be executed manually, by an automation or both. But it's important to have these scenarios documented somehow, in a spreadsheet, a Confluence page, or any kind of document that anyone in the team can have access to reproduce the test step or search for some business rule in the system.
What about automating this kind of test scenarios? Sure, just wait a little for the next text.
References
User Journey Test Guide - Dominik Szahidewicz
User Journey Tests - Martin Fowler
Business Facing Test - Martin Fowler
Top comments (0)