I want to tell you about the experience of building test automation from scratch, when there is either no testing at all on the project, or its degree is minimal.
I hope the article will be useful for novice engineers or managers.
When to do autotests?
The short answer is as early as possible.
And the full one will be revealed below. In any case, when the project has been running for 3 years, and everything was checked manually, life becomes very monotonous. And it is problematic to automate a park of 5,000 scenarios in a month or two. As a rule, in such projects, you will have to start working out the scripts again. Because it will be faster. And it’s not a fact that the old ones can be automated without significant changes.
Why?
Because autotests are:
- Accumulate scenarios for regression
- Unbiased
- Fast
Accumulated scripts
The larger the pool of automated scripts, the more likely it is to find a regression, especially if the data changes with each run.
If the autotest was stable for a long time and suddenly crashed on some branch, then: a) the requirements were changed, b) bug, c) infrastructure failed.
Impartiality
If the requirements were changed, the autotest should go for redesign along with reworking the main functionality. That is why testers take part in the approval of technical specifications.
If a test run is automatically linked to a task, then no one can say that it has not been tested. Or vice versa, it can. In general, there are definitely fewer problems.
Speed
If each test meets the boring conditions:
Precondition – Test – Postcondition
It is easy to automate such tests. And then it’s easy to parallelize. Because they get independent.
The number of threads – how many test servers will withstand and not to interfere with others.
The second point is speed itself. In manual mode, clicking on the creation of a product, its search, and purchase in the online store takes 5 minutes. 4 browsers. Total 20 minutes. In just one small scenario.
The autotest for this scenario takes 1.5 minutes. But on 8 browsers. (Latest and penultimate versions of each browser).
Where to begin?
With custom scripts. The value of atomic tests drops all the time, especially on microservices. And in general, in an ideal world, this is the area of responsibility of the programmer. Such errors should be detected during the unit testing phase.
Accordingly, the logic 1 test – 1 user case (business scenario) is closest to reality. There are, of course, difficulties with the preparation of data, for example, in the case of an online store, the card payment process requires the presence of things in the basket, and either data for a new user, or authorization data for an existing one.
Yes, sometimes preconditions take longer than the test, but when reusing scripts, it does not carry any complexity.
Which scripts to automate
Least changeable in the short term.
Or the most commonly used ones. It makes sense to help manual testing generate test data. For example, in the bulletin board, it makes sense to automate the creation of announcements, because further, any scenario requires a generated ad.
Choosing a scenario
Let’s say we have an online store.
There is an admin panel, there is a client and admin front.
There is an API that serves all this.
Where to start automation?
Let’s take a look.
There are clients, there are employees. The client has the first case – viewing and searching for an item, adding it to the cart, and design.
The most common scenario for an employee is adding a product card.
Test Automation Framework
What is the purpose of a Test Automation Framework? What challenges does it solve for the development team?
In agile development, you might not have enough time to automate your new features in time, so you might be creating automated scripts, duplicating a lot of code in many places.
Refactoring code is an inherent part of software development to avoid building up a huge tech debt. This also applies to test automation; by refactoring your automated scripts, you will improve readability and maintenance in the long run.
When creating a Test Automation Framework, we should consider the following main points:
- To be able to create automated tests quickly by using appropriate abstraction layers
- The framework should have meaningful logging and reporting structure
- Should be easily maintainable and extendable
- Should be simple enough for testers to write automated tests
- A retry mechanism to rerun failed tests – this is especially useful for WebDriver UI tests
I would suggest avoiding building selenium framework from scratch, nowadays there are a lot of open-source selenium frameworks, which already have all the necessary features.
Final parting words
My article does not claim to be a universal pill that can be used anytime, anywhere. All projects are very different, all teams are very different – each must build its own best path by itself, often it is the quintessence of different approaches and tools. Even the famous Scrum, how many projects I have seen, each one professes in his own way 🙂 I do not believe in strict instructions at all, I believe that they are needed as guidelines, but you need to act according to the situation.
However, the IT world is developing, and more and more people are coming to it, so I am sure that among those who read this material there will certainly be someone who will be helped by my little instructions to choose the right path.
