How and why to introduce automated tests into development

2023

futured.app

Automated testing provides many advantages:

cost reduction,
reduction of delivery time,
minimising the risk of errors in production, thereby improving the overall quality of the resulting product

In this article, we will take a closer look at our path to automated testing and share some important aspects that could help you to successfully introduce into development.

‍

Why Start with Automated Testing

Regression manual testing can be time-consuming and at the same time less reliable. Why? Because they are done by humans. And people make mistakes.

In contrast, the machine always performs the task the same. In addition, automated testing will allow you to devote more time to scenarios that you would otherwise not have time for.

However, it is important to note that automatic tests are not intended to replace manual tests, but rather complement them.

Both types have their place and time in the development cycle.

Product vs Agency Development

I came to Futured from a company that had its own product and where automation was literally the order of the day. So joining an agency where automation was almost not dealt with was a challenge and a test for me at the same time.

The first step was to open the topic on an internal level and pitch the idea of including automation in the standard development process. We agreed that we wanted to focus on automated testing, so we moved on to tooling and frameworks.

Exploration and analysis

It is often the case that a company that wants to start automating hires a Senior Automation Engineer who is expected to start right away pour a bunch of tests.

I'm not saying that this is necessarily wrong, but often it may not be the right solution because this external person does not have the necessary awareness of the current types of products. For example, he can choose a framework that he is used to and not the one that best suits the needs of the company and other QA Engineers. Nobody probably wants to find out after dozens of hours (at worst, hundreds) that the chosen technology does not suit.

Invest time in analysis, it will pay back to you.

But don't try to find the perfect solution right at the beginning. After some time, look back to see if you chose correctly. You may find that you need to use a different framework or even more frameworks. This was our case: We thought there was no point in looking for a universal framework that could automate both web and mobile applications, and we chose two.

Workshops

If automation is not part of development in a company, QA Engineers probably can't write tests. Therefore, it is important to organize workshops to familiarize future users with the basics of programming, git and especially the framework and best practices for writing tests.

Definitely do not expect that after three workshops you will be able to immediately write tests. It is necessary to give everyone the space to touch the framework and try it in practice. Within these workshops, it is also advisable to discuss the approach and identify areas that can be automated.

Offer to the client

The real challenge for us came when we wanted to sell automation to clients — because implementing automated testing can be seen as an unnecessary cost increase. Therefore, it is important to explain the benefits in development, but most importantly, what benefits the client himself will feel.

Once you mention that writing tests and maintaining them costs quite a bit of time and therefore money, the discussion becomes considerably more complicated.

We followed the path of personal meetings, in which we went through all the benefits with the client in detail and revived the empty headlines with real examples from practice.

In general, we mainly focused on the benefit that the client is most interested in, which is saving money. But how can you save money when automation costs something? In order for the client to be able to imagine it better, we included graphs in the presentation as well. In short, the point is that the longer a project is worked on, the more automation makes sense.

We closed the entire presentation with a live demo. We demonstrated a simple End to End (E2E) test in a development environment. We emphasized that if the test is written correctly, it is also well readable for a non-technical person. Which basically means that tests can also serve as documentation.

Subsequently, we launched the test and I dare to say that only this demonstration demonstrated to the client the power of the tests. Watching their interest was sheer joy.

Implementation and problems

When we were able to sell automation, we could start with the implementation itself.

This requires collaboration between developers and testers. For example, it is desirable that each component that the test needs to work with has a unique and immutable ID. The developer himself must think about this fact and add IDs already during programming.

However, E2E tests (at the user level) are often not enough. Therefore, we also needed to solve the question of so-called unit tests, which are written by the developers themselves and whose purpose is to verify the correct functionality of the subparts, or units of the source code. The importance of these tests is also often neglected.

The further we were, the more things we had to sort out. Will we run the tests on real devices or simulators? Local or remote? Automatically during build, or manually? Where will the tests be stored? And so on.

During implementation, you will always encounter problems and questions that you did not think about during the analysis. This may be due to the complexity of the application or, in short, lack of knowledge. Development in general is about solving problems. The important thing is not to panic, not to stop and instead come up with some solution and have an alternative solution in reserve.

Conclusion

In conclusion, it is necessary to mention that:

Automated tests are not worth implementing everywhere and at all costs.

It is good to think about the value, so that in the end the investment is not higher than the benefit itself. For example, if the product is very small, the time investment can be much higher than the investment in manual testing.

For tech readers, it's probably a little disappointing that I didn't devote more words to the implementation paragraph. But my intention is not to brag about what we use, why and how. As a result, I think it wouldn't do you any good either.

‍

Rather, the aim of this article was to outline what needs to be done when automation is started. And also to demonstrate that every coin has two sides and no solution is universal. It is always necessary to analyze the needs and after some time ask yourself if the chosen method suits us.

‍

The images/visualizations used in the text we borrowed from DigitalMara, NextGen and Cypress. Photos tagged with the letter W were created for Futured profile on the platform Welcome to the Jungle.

‍