It took quite some time for me to realize that this is perhaps the most interesting type of testing
Hello, everyone!
Looking back on my past, I realize that there have been different periods in my professional life. I never really thought about how these periods reflected on my attitude towards testing and E2E testing in particular. It’s time to change that.
In this article, I want to analyze how my attitude towards E2E testing has evolved and what events caused certain changes.
Stage 1. Introduction
I started as a manual tester and remained one for several years.
But sooner or later, there comes a time to move on and explore something new. It doesn’t mean that I stopped enjoying testing or stopped seeing prospects in this profession. On the other hand, routine manual testing processes became tiresome, and there was a trend towards test automation. Many tasks required a lot of time for rechecking. In other words, everything pointed towards getting involved in programming and moving towards automation.
I remember how I got introduced to my first project of automated tests. It wasn’t complicated, and it was utilizing fairly basic concepts. I believe nowadays, one can acquire all this knowledge through an automated testing course or by digging a bit into the internet.
Getting acquainted with code didn’t seem like magic; rather, it felt like a task worth diving into to hone my object-oriented programming skills. Nevertheless, it was an exciting feeling, and I eagerly watched how my first tests have been passing.
During this project, we shifted the implementation paradigm from Page Actions to Page Objects and started using a Cucumber-like framework for closer integration with the business. Our team was focused on delivering a quality product, leading to a maximum efficiency focus on processes.
The company’s culture reiterated every day that involving the business in testing is a good practice. I saw many confirmations of this: the entire team’s engagement with the product, early feedback from automated tests when delivering new code changes, a deep understanding of the product and its features. To this day, I consider that team to have given me a strong foundation, both technically and process-wise, and they were the best I’ve ever worked with.
Stage 2. Development
Time doesn’t stand still. Technologies move forward, and so did I when I decided to move away from testing a monolith and look towards microservices architecture.
As you can understand, the approach to testing such a product significantly differs from testing a monolith at all levels. The process of shifting thinking, I wouldn’t say, took much time, but it brought new knowledge and principles to testing organization. What is considered a must-have today (for example, preparing test data through API) was new to me back then, and I encountered such a test organization for the first time. A natural question for me was “Why weren’t we using this before?” (there is actually an answer to this question, but it’s not the focus of this article). Some data couldn’t be generated based on the API; we had to figure out how to use a mock server to emulate such cases and verify the required functionality.
There was also a separate discussion about the test set for automation — what cases to cover at the unit test level, what at the integration level, and which scenarios to write in E2E format; how to assess test coverage at the business level, technical level etc.
In summary of this stage of work, it was an era of new interesting tasks and a more conscious approach to E2E tests.
Stage 3. Stagnation
At some point, the excitement of applying new approaches wore off, and I began to feel like I was stuck in a place. This was a relatively long period during which I changed several projects. The essence of the projects remained the same — first, you write Page Objects (in different project structures and architectures, it seemed like monotonous routine), then you apply some best practices that you’ve encountered before. In the end, the test projects seemed essentially the same; the only difference seemed to be where Page Objects were stored and how you used them.
I became very disappointed in E2E testing. I tried to find information on how to further develop as an automated test engineer, but all articles and courses seemed to revolve around the same basics that I was already familiar with.
The worst happened — I stopped seeing perspectives. It was at this time that I became interested in other areas (again, new to me) — testing mobile applications, developing backend and frontend applications, delving deeper into API testing from a project architecture perspective.
As it turned out later, this stage was not in vain. My experience in application development and broadening my horizons added to my understanding of testing strategies. I looked at test suite composition, their effectiveness in the software development process in a different way, but let’s call it a day and talk about that separately.
Fortunately, everything eventually comes to an end, and this stage was no exception.
Stage 4. Second Breath
One day, another enterprise project came to me, requiring the organization of the test automation process. “Here we go again” - I thought…
We started working, and everything developed in a standard way — again, the same Page Objects, organizing approaches. However, as we digged into the product nuances, new details emerged, adding new dimensions. For example, depending on the starting point and user type, we could follow the process in two different ways (hello, strategy pattern), or depending on the testing environment, we had to load pages for specific devices/browser resolutions at runtime. These are quite basic examples, but they are pretty common in most projects we, QAs, could work on.
At some point, I realized that the unique architecture I built for testing was not an exception or a result of my “unusual” approach but rather the consequences of distinct business traits — domain model, interaction with the environment, team communications, application concepts, etc.
Reviewing my past experience, I understood that each project was unique. In reality, the essence of E2E test code lies not in standard things taught by Selenium or automation courses but in business features and team architecture, the people we interact with, and the products, services we build.
What next?
Now I can definitely say that E2E tests are the most interesting aspect of an automation engineer’s work because they encompass different areas of interaction (UI, API, sometimes services and databases), require knowledge from related fields (such as software development, design patterns, business domain model), and teamwork (who would have thought 🙂).
To recap all of the above I can say that:
Like any process, test automation has a lifecycle that we all have to go through. It sounds grand, but I think it’s true. If you have examples of a different experience, write in the comments; it would be interesting to know if I’m wrong when projecting my experience onto everyone
To write E2E tests effectively, a considerable amount of knowledge is required, including from software development
E2E tests currently seem like a very interesting task, involving not only interaction with the UI but also with backend applications and the most of design patterns utilization
The stagnation period can be used to broaden your horizons and acquire new knowledge
If you like this article, feel free to join my Telegram channel, there I publish more thoughts about software testing and development.
See you next time, and thanks for listening 🙂
And, of course, don’t stop to automate!
Top comments (0)