DEV Community: Mirza Sisictester

Test Execution Time – why is it important and how can we speed it up?

Mirza Sisictester — Mon, 08 May 2023 07:02:46 +0000

As the complexity of our system under test increases, it will likely mean the number of our tests will keep growing exponentially. Large test suites mean longer test execution times. We can come into situations where we have many tests (especially for regression) and it can take many hours for all those tests to run. Not to mention the time and resources it takes to analyze the test results, investigate the failing tests, debug and fix the flaky ones, etc. So without further ado let’s see what we can do to make our automated tests execute faster.

Combine API tests with UI tests

Sometimes we will have to deal with tests that can’t be executed without certain preconditions. At times we might need a specific set of test data before we can test what we need to test. For such situations, if we have access to an API it can make our lives a bit easier. APIs aren’t just better for automating business logic, they are also great for test preparation. The reasoning is the same as with authenticating via API, instead of the UI. We can cut some corners and save a lot of time, improving our test execution times considerably. This is especially true for preconditions which are frequently used in different many tests. A lot of tools have support for this, some even have native, out-of-the-box support for making API calls from your UI testing framework. Furthermore, API tests can help us avoid malicious code, and execute tests faster, they are less dependent on any technology stack, as we are relying mainly on the universal HTTP protocol. And the benefit that is the most important to the business, API tests are a lot cheaper compared to UI tests.

Run your Playwright automated testing scripts instantly on 50+ browser and OS combinations using the LambdaTest cloud. Read more.

Favor smaller tests whenever possible

Small tests are sometimes referred to as Atomic Tests — each test is very small without having a dependency on other tests. A test that fails or passes independently of other tests makes it more reliable, faster to execute, and much easier to debug when it fails. Also, adding new tests is much easier when those tests are smaller. Granted, it’s not always possible to have very short tests — sometimes we need to emulate a real-world user journey, but as a general rule, we should favor many smaller tests over a few very lengthy detailed tests.

Only automate dynamic UI sections if it can’t be avoided

Sometimes it’s better not to automate certain elements of a web page or an app. Automating elements with a lot of animation, or highly interactive elements, can be very demanding. This usually involves adding a lot of waits in your tests — and such tests are difficult to maintain. Dynamic elements should be tested manually, as automating them can be very flaky and demanding.

For example, let’s imagine a relatable CSS animation. When a user adds an item to the shopping cart, the cart icon might move and update to show the number of items in the cart. Now let’s imagine, that we have a very slow network, we would need to tell out the test to wait until the animation occurs, and until the updated element is visible. The result is that this test can fail for a wide number of reasons, making it hard to debug, and also, such a test would be pretty slow to execute. So in the end, think about the economics of automating a dynamic element and determine if it’s worth the investment — usually, it’s not.

Make sure to mock 3rd party dependencies

When our app needs to connect to 3rd party systems, that adds another layer of complexity to our tests. We come into situations where we end up testing code that we are not responsible for. It is considered a given that we assume that the 3rd party code we are using has already been tested. This is especially important to pay attention to when dealing with sensitive data, like when using payment plugins. In such cases, the security of the integration is of utmost importance. These external dependencies should either be mocked (use a dummy version to simulate the real 3rd party extension) or bypassed on an API level. Especially avoid testing someone else’s UI, and use their API for that instead if you must. For mocking purposes, you can use public mocking libraries to generate credible-looking test data. If you are unfamiliar with mocking, you can always reach out to your developers for help. Developers are accustomed to using many mocking libraries, which they use mostly for unit testing — to test small chunks of the code in isolation. In the end, mocking dependencies allows us to focus on testing what’s crucial for our stakeholders and not spend time on too many details.

Use direct URLs instead of button clicks

We need to think about what is happening behind the scenes when we are automating a user journey. Sometimes translating manual test cases into automated tests is not the best way and most optimal way to go. Let us go with a simple navigation example: if we have a navigation menu, we do not automate clicking on it. It is faster to navigate directly to the URL to which that menu item was originally linked. This has the positive effect of making our test a bit less prone to flakiness, be it a false positive or a false negative test execution result. By avoiding clicking on the nav button, we reduce the number of actions, and page load times improve.

It’s crucial to debug websites for Safari before pushing them live. In this article, we look at how to debug websites using dev tools in Safari.

Prefer API authentication over UI login

Having dedicated tests with login forms can be pretty costly, and a big bottleneck. Many testers have probably seen methods that call a UI login test a precondition for many other tests. This is a huge time waster and an unnecessary overhead. So, if you have an API you should use that instead. Authentication over API is way faster than UI-based login and it is a lot more reusable. The best thing is that this kind of API test is one of the simplest ones — you would usually need an email/username, password, and maybe a cookie consent. Make your POST request and bam! You are fully authenticated in a fraction of the time it would take to do the same by clicking on the UI. Just make sure that you are not doing this blindly, first ensure that you have a thorough understanding of the login options, to get an idea of all the parameters that you can send to the backend via an API call.

Avoid automation cookie consent banners

Cookie consent banners are the bane of any automation engineer’s existence. Automation is often redundant and they should be bypassed — as they need to be tested separately, from more of a legal-acceptance point of view. Also, another thing is that they can really easily be bypassed, giving us a significant speed boost to our test execution time. Most of the time you can easily get rid of these consent banners by using the developer tools from the browser. All we need to do is to give the required value and place the cookie before our page loads. That will allow us to not even see the cookie consent popup when we load up our test.

Run your tests in parallel

Eventually, the number of tests you need to execute will grow over time, making sequential execution very time-consuming. Just imagine (this is especially applicable to UI tests) having hundreds, or thousands of tests — each one running only once the previous test has been executed! Running those tests in parallel will enable you to run multiple tests at the same time. You can run your tests in parallel on multiple machines, like virtual ones, to significantly reduce the test execution time.

Another, even more convenient, approach that you can try is using a cloud service, such as HyperExecute for your tests. This way you save additional time by not having to the setup test environment and provide resources on your own. Such an approach will need to fall under the testing budget you have allocated, as these are mostly commercial-based services. When running tests in parallel we should have in mind that we should avoid hard-coding any values, and instead make sure that our test data is well organized. If we play things “right” and use smart parallelization within our test automation strategy we will gain many benefits. Our tests will be faster, more economical to run, have better coverage, integrate better into the pipeline (our CI/CD process), enable us to have better testing practices, and give us the opportunity to move into a direction of continuous testing.

Inspect web elements to help developers and testers to debug UI flaws or make modifications in HTML or CSS files. Learn how to inspect on MacBook.

Wrap-up

So, let us briefly sum up what can we do to improve our test execution:

Combine API tests with UI tests — we do this to gain faster execution, write less automation code, and have cheaper execution as well.
Favor smaller tests whenever possible — smaller tests are easier to debug and maintain, have a single point of failure, and should pass or fail independently of other tests.
Only automate dynamic UI sections if it can’t be avoided — avoid automating highly dynamic content, as it is very demanding, instead check them manually.
*Make sure to mock 3rd party dependencies *— do not invest in testing other people’s code, mock 3rd party dependencies to save time and to make your tests more stable.
Use direct URLs instead of button clicks — opening a URL directly instead of clicking on the button will save us time, also, it will make the test simpler. Our tests will be less flaky and faster to execute and the pages will load faster with fewer waits.
*Prefer API authentication over UI login *— authenticating via API is way faster and far more reusable than using a UI test as some kind of shared step, which other tests are dependent on. Tests should fail or pass separately.
*Avoid automation cookie consent banners *— these banners are more and more present and dealing with them directly from the UI can be very time-consuming, especially in the long run. We should access the cookie directly without clicking on buttons, and our page will thank us for being able to load faster!
Run your tests in parallel — parallel execution of our tests allows us to execute more tests in less time, compared to executing our tests in a sequence. We can utilize virtualization and cloud technologies to make our parallelization efforts even more effective.

There are a number of other smaller things we can do to make our tests execute faster. If we are using tools like Selenium, we can speed up our tests by removing redundant Selenium commands, we should minimize the number used to get a speed benefit. Another thing is to favor explicit over implicit waits, explicit waits are a bit more demanding to implement but it’s worth the extra effort.

From the UI side of things, there are also small tweaks we can do, such as avoiding the use of Xpath, when possible, and using tags and data attributes to manipulate elements directly. Running our tests in a headless browser mode allows up to run UI tests directly from memory, without interacting with the browser’s GUI, most modern testing tools have built-in support for headless mode. Also, we need to pick times when our tests are being run, and at what frequency; a smaller set of sanity tests can be scheduled to run several times a day whereas a bigger test set should be triggered less frequently.

We should also invest time in exploring different tools to find the ones best for our context. Our tests should also be deterministic, meaning that they should be resilient and not fail due to environmental and data issues. Another good practice is to do a database and test environment clean-up, so we start with a clean slate when we run our tests. Make sure your tests are documented (it doesn’t have to be overly detailed, as long as it provides value), and favor lower-level tests over more complex ones.

Hopefully, these tips will be helpful, Happy testing!

Make e2e Testing Easier With the Right Tools

Mirza Sisictester — Wed, 19 Oct 2022 13:13:05 +0000

End-to-end (e2e further in the text) testing is immensely important since there are issues that can only be discovered while testing the system as a whole, testing it from one end to another.

That also adds a greater level of complexity to e2e tests, making them longer, slower to execute, and with more points of potential failure, compared to lower-level tests with a smaller scope, especially when compared to tiny and blazing fast unit tests. Since e2e tests bring a lot of value, we don’t want to neglect them. We also want to make our lives easier when doing e2e testing, which we can do with the right tools. Apart from automating our e2e tests, we can speed up our e2e tests if when they are not automated. Let us dig deeper into what exactly we can do to make e2e testing easier and faster to execute.

How to Make e2e Testing Easier and Faster to Execute

Analyze the value e2e tests will bring

While having the previously mentioned in mind (e2e are expensive and slower than other tests) we should take heed to prioritize which part of our application under test needs to be covered with e2e tests, and which parts can be covered at lower test levels. When balancing the costs and the potential return on the investment, we should have the customer in mind — doing extensive e2e testing of the FAQ section will not be as valuable as covering the whole checkout, or the entire registration journey with e2e tests. Having the most important customer journeys monitored and covered with e2e tests will add a significant level of security — an alarm that will go off when something in this journey fails. This is why these kinds of tests need to be run on a regular basis, such as a part of a nightly build, for example. Also, when deciding which journeys to automate, you should talk to the stakeholder and your team members, especially with the subject matter experts (or the domain experts) and with technical team members, such as other automation engineers and the developers, to reach informed decisions regarding the e2e coverage.

Avoid duplication — test whatever is possible at lower levels

You don’t really need two e2e tests checking parts of the same flow — this should be avoided, if it’s at all possible. It is much cheaper to check all the business logic at the unit level and to cover more complex business rules with API automated checks — which are way faster than checking the same functionality using the UI. Keep a low number of e2e UI tests, check only what gives a lot of value to the customer.

Utilize cloud infrastructure to reduce costs and increase speed

The pros of using cloud infrastructure, over on-prem, are the ease of configuration and the availability of resources ( almost infinite). Additionally, the prices of cloud services have been dropping, as there are more competing players in the cloud arena. For this, you can utilize a cloud-based test orchestration platform like LambdaTest’s HyperExecute. You can also use cloud containers to manage and organize your tests better and make executing times faster as well! There is also an on-prem enterprise option for this feature, as some organizations cannot use the cloud due to legal restrictions.

Use tools like LambdaTest to cover multiple browsers

The need to cover multiple browsers or mobile platforms can make your testing efforts very time-consuming. Just imagine, you have a fairly complex web app that needs to be tested on all the modern browsers to make sure all the important features work. Such sort of testing should be made faster with the use of proper tools. These tools can be particularly helpful if you need to support multiple versions of different browsers, and operating systems and to check against multiple different screen resolution sizes for this u need to perform online browser testing.

It can be very beneficial to be able to test on real physical hardware, without having to buy a whole bunch of dedicated testing devices — you would practically just rent the usage of these for a certain period of time. Another important feature to look for is if the cross-browser testing tools have native integrations with the developer tools, in the supported browsers, so you can debug and test more thoroughly. Other uses for such tools are the ability to test on the local host, if you have an app in local development, or to test geolocations with a different IP address. Also, make use of browser extensions for cross-browser testing tools.

Taking screenshots automatically, in different browsers you test on, is yet another handy feature that comes with these kinds of tools. LambdaTest comes with a browser of its own — LT Browser which comes pre-packaged with advanced features like creating custom resolution sizes of your own for testing the responsiveness of your web apps.

Leverage existing tools for visual testing

Visual regression testing can catch a lot of issues that are either very hard to detect using tools like Selenium, or not possible with regular UI functional testing tools. Plenty of customer-impacting issues can be prevented if caught by doing visual testing. This can be done in the cloud as well with LambdaTest’s Smart UI tool.

Issues such as wrong element colors, various size-checks, padding validation, layout issues (such as responsiveness), text-related issues, and element positioning, can be good candidates to check using Pixel-by-Pixel comparison, which can be run across well over 3000 desktop and mobile devices. Automated visual checks should be run in parallel, to speed up your release cycles and to make the test execution a lot faster while cutting down the feedback loops considerably.

Visual regression tests are also great candidates to be included in the CI/CD pipeline. Another useful practice would be to leverage extensions and integrate them into the other tools you’re using.

Check this out: Data Driven Testing- A Comprehensive Guide With Examples and Best Practices

Include e2e tests into your build pipeline early

As soon as you have at least one working e2e test you should include it into your CI/CD pipeline, or make sure to include the test execution as part of your build process if you have scheduled releases.

Integrate reporting tools with your e2e tests

Given the costly nature of the e2e tests, having good and detailed reporting in place is a great way to get additional value from your e2e tests. There are many libraries that allow you to access their reporting capabilities (usually via an API) from your automation framework. Examples would be ReportNG, Allure reports, Report Portal, etc. These libraries can generate a lot of visually appealing reports, like pie charts and status bars for your testing, so you can visualize how many of your tests are passing, failing, being skipped, etc.

For failing tests you can usually drill into the details. But, for the non-testing folks, this info is usually not very interesting. Do remember, it can be very valuable for the testers, maintaining (so they can debug the failing checks and fix them or report bugs) the automation solution, and for the developers as well — if you have them involved in the automation process, which is almost always a good idea to do!

Most modern test management tools also have extensive reporting capabilities for your test execution.

Another great practice is to have the reporting for your automation connected to your most common communication channels, such as having a Slack notification, a Teams message, or similar. It’ll help you be on top of things like — when tests in the build pipeline fail, what is the status of the test execution, etc. In this sense, your e2e tests (especially if you have them configured to be, for example, executed repeatedly — like as a part of a nightly build) can act as an alarm — warning you in time when an important feature stops working or misbehaves. It’s always better to find an issue internally and fix it than to have the customer report it to your support department because it could mean losing that customer, and many others who had the same issue. It is a known fact that due to many competitors in the market today, customers have a lot of options to choose from, meaning that if they have an issue with using your app, a lot of them won’t even tell you about it, they will just move to the competitor. So, always have the customer’s satisfaction as your main priority!

Common approaches to e2e testing

Here are some of the most important things to consider when doing e2e testing.

Make sure that your app is deployed properly and is testable This will speed up testing and prevent some issues from happening, like problems with the test environment. For these things, you can use cloud services to make your life a bit easier.
Make sure that other testing activities are completed — all the features have been already tested in isolation, integration points have been tested and all unit tests are passing. This is done to make sure that the system is working well and all the unique pieces are connected together and interacting as they should. Do e2e testing after all the other stages of testing have already been completed. That means you should wait until all the individual components have been tested.
Keep the end-users experience in mind. Talk to the customer, if possible, and connect with the product owners and technical support people to learn more about how the real users use your app. With such knowledge in mind, your e2e tests will be more valuable and successful.
When it is time for e2e testing, make sure you have a process in place that is accepted by everyone. Avoid significant deviations from the testing process, as these can lead to slower releases, and can cost additional time and money.

Check this out: Ad Hoc Testing- A Comprehensive Guide With Examples and Best Practices

Conclusion

In order to test end to end, it is crucial to follow the agreed-upon set of practices — to make sure that testing is doable and cost-effective.

What is the goal behind an e2e test? Try to think like the user, imagine that you are using the app for the very first time, and ask some questions. Is the app easy to navigate and are all the important user options easily available and accessible? Is the journey evident to the user — the features are pretty self-explanatory to use. Can the user get from point a to point b — like completing the registration or the checkout process? Have the acceptance side of testing in mind as well and create your tests according to that.

Try to cover with e2e tests the parts of the app where a lot of issues are expected, and the most important parts for the customer. Try to use the risk-based approach here to determine what to cover. There are decision tables you can use to visually determine how risky a certain feature is.

Do not test for exceptions when doing e2e testing, this can be covered at lower test levels, to save resources and test faster.

Maintain your e2e test set regularly — since e2e tests cover big parts of the app, they are usually longer and more complex than other tests. If one e2e test can be logically divided into two or more tests, then you should do that, since with every new big step in the test (like an entire screen or page in the app) the complexity of the test will increase significantly, and it will be harder to debug it as it will have multiple points of failure — which is one of the biggest pain points of having e2e tests.

Make sure your tests are well organized and use consistent naming — it’s best to make it obvious just by reading the title of the test to understand what it does.

Have pre-defined test setup and teardown — e2e tests will require test data and will usually write to the database as well., Do make sure that you clean up as you might risk having duplicate data, which can result in bugs that could have been avoided. Eg like primary key violations if you try to, say, register a test user with the same email twice.

Plan your e2e tests well, and as early as possible. The e2e tests which you have automated should also be checked manually by a real human, as there are a lot of issues the automation will ignore — it will only check what you tell it.

Also, use your e2e tests to speed up your exploratory testing — if you have an e2e test that fills out a lengthy form you should use it to save time.

Depending on the nature of your project, you might want to treat end-to-end testing as an essential part of the build pipeline. Prepare e2e tests as early as possible, invest time in them, and make sure you have the resources needed to have the ability to e2e test even before the feature goes live in production. Good luck!

Check this out: Agile Testing Tutorial- A Comprehensive Guide With Examples and Best Practices

Let’s Explore how Agile Architecture Spikes are used in Shift-Left BDD

Mirza Sisictester — Tue, 18 Oct 2022 18:17:22 +0000

An Architecture Spike in Agile methodologies usually implies a software development method, which originates in the Extreme Programming offshoot of Agile. It boils down to determining how much effort is needed to solve a particular problem or to discover a workaround for an existing software issue

So let us explore the benefits and see how these spike can help in improving quality and making testing easier — through shifting our attention to the left — challenging the specification at very early phase, asking questions and getting the ground ready for sensible software architecture — which will in turn improve the testability of our application under test.

Check this out: User Acceptance Testing (UAT) Tutorial- A Comprehensive Guide With Examples and Best Practices

More Details about Spikes

There are many benefits of spiking — to get to know the unknown unknowns, discover risks, reduce complexity, provide proof for proving or disaproving a theory. Taking a deep dive into the idea behind the solution can help in getting better at understanding potential architectual solutions and the likelyhood of will it work.

A spike is not there to provide a finished working product, or even an MVP, it’s purpse is mainly to test a theory, so even though this concept is used (in the long run) to produce working software, the code writen for spikes is often disgarded after it has served it’s purpose. Spiking usually is done by ignoring architecture styles (which might seem odd at first as it can help in discovering the righ archictectural approaches for the system we are building), coding style, design patters and general clean coding practices in favor of speed. So even though the spike may not directly produce software that will be delivered to the customer, in the long run it still helps us ship better code in the end.

Spiking is a good tool for handlign risk, by discovering unknown risks, and it provides a great way to learn and reduce complexity. A very common approach is to come up with spikes around a theory and to follow the code by a small number of simple tests. Even though the spikes are often seen as discardable code, we don’t really just throw them aside. While they don’t end up in the actual code which gets delivered, they provide useful insights and can serve as documentation to show how a certain solution was reached.

A Simple Example Let us assumen that we have a new feature we need to develop, we need to allow the users to be able to save a photo in their profile, to do that a developer can make a spike where the following could be done:

Have the JavaScript on the Front-end communicate with the database

a. Setup a database server locally
b. Setup a NodeJS (or another server)
c. Use ODBC (Open Database Connectivity) API to connect to the DB

Test the spike

a. Run a few sample queries
b. Test the CRUD functionality

What is mentioned in this simple example is all we need for a spike, it does not require any detailed documentation. The developer working on a spike will need to do some googling, run a few commands from the terminal, write a few lines of code for each theory. The spike would provide a posible direction for solving the challenge at hand, it can also include links for resources used, install scripts and the actual produced code to be used a blurprint. Trying things out is way more beneficial than simply theretisizing about them. The team was able to recude the risk related to this feature — in this example especially from technical integrations side and even discovered new risks such as accessing the DB using local JS!

Check this out: Exploratory Testing Tutorial- A Comprehensive Guide With Examples and Best Practices

How does this impact testing?

Allowing us to explore, spikes helps with identifying the unknown unkwonwns, so in a sense spikes are a tool for early testing (used often she shifting testing to the left). By getting answers to what works and what will not work, we avoid a lot of potential issues, and delays, by probing the requirements to distill them further. In turn, there are less bugs to report, fix, verify and keep track of. Also, the earlier the testing is done, the more economical and fast it will be.

Can QA use spikes?

There is no real reason why not to, I have seen testers use spikes to try out, and experiment, with different approaches to automating some part of the system under test, do determine the best approach. An architecture spike can help us in trying out different testing tools, such as new frameworks and libraries, give us a first hand experience of how a certain tool would behave with out system, when we try to automate some business rule, for example. Spikes are generally regarded as technical tasks (different than user stories) usually under an epic, that is in early development stages.

Check this out: UI Testing Tutorial: A Comprehensive Guide With Examples and Best Practices

Conclusion

So the wrap this up, spikes in Agile are one of the tools which allows us to do what Agile is intended to do in the first place: short, quick feedback cycles give us answers early in the development process, we focus on doing and trying instead od long overly-detailed planing. That is not to say that code architecture does not matter in Agile (as we know, in Waterfall architecture is very important and usually done in the design phase), in Agile we just use a different approach. Agile practice, such as spikes, allow us to get an idea about architectural solutions that may work, as well as info about the ones that may not work.

Software produced in the above mentioned manner, help us reduce risk in our user stories, enabled the team to discover right solutions using collaboration, constructive discussion, frequent experimentation and compromise. In a informal sense, a lot of people happen to be using spikes without even realizing it! As long as you are trying to identify the unknown unknowns, have short feedback cycles and you’re trying to determine technical and also functional risks, you are doing Agile. Spikes will help us in situation where we are not certain about the requirements and if there are a lot of unknowns and answers that need answers.

Understanding what is required to start with test automation for junior testers

Mirza Sisictester — Mon, 17 Oct 2022 15:08:16 +0000

Software releases have become faster than ever before. They are adding new features, quicker response to defects, especially those found in production, and what not! This has resulted in a massive increase in demand for automation testers and considerable pay gaps between “manual” and “automation” testers. In addition, automated tests help companies save time by doing repetitive testing, such as regression testing.

If you are new to software testing or haven’t had an opportunity to learn test automation, this article is for you. So, without further ado, let us see what we need to learn to get started with test automation!

View test automation as software development

Test automation should be viewed as an integral part of software development, meaning that it implies programming knowledge. This idea was popularized mainly by Agile methodologies, such as XP (Extreme Programming). Automation testing does not only concern unit and integration level automated tests (which are mostly done by the developers) but also API and UI automation as well. There are other schools of thought, such as the whole-team approach to quality, and the modern testing principles, which state that everyone should be involved in testing in their own right. Knowledge of software development helps greatly with test automation, as (apart from coding) many skills are used in automation, just as in “regular” feature development — like using version control, creating builds, using databases, APIs, CI/CD pipelines, and more.

Safari For Windows: Say No To Safari VM! Perform Cross Browser Compatibility Testing On All Safari Browser Versions Across Real Browsers And Operating Systems.

Pick one programming language to get started

If you are just starting with learning how to code, you might be tempted to hop from one language to the next — as trends keep changing. However, to be good at programming, one needs to think like a problem solver rather than memorizing specific syntax. Therefore, you should pick one language while starting and stick with it for a long while until you become very comfortable with it. This is especially true when dealing with high-level languages from the C-family. This is because these languages share many similar concepts and have syntax similarities. So when you are no longer a beginner with the language you initially started with (let’s say it’s Java), learning another language will be pretty simple — just a matter of getting used to syntax differences — like getting to know a new dialect of a language you already speak well!

Learn clean code practices and principles

Some people put way too much burden on themselves by trying to learn too many specific tools, frameworks, and libraries, even when it’s not required for their job because they think that is the only way to keep themselves relevant in the ever-changing job market. This can be very draining and demanding; instead, you should focus on learning and applying practices and principles widely applicable and universal to many situations.

So what can you do:

Keep the automation code simple — always have in mind that the code you write is most likely to be used by others; try to keep it simple and readable, and avoid overengineering whenever you can. Write code that will be easy to refactor and change.
Make sure to use meaningful naming conventions — The name of your automated test should be clear. It should be evident for others to decipher what it does by reading the name. Variable and function names are apparent. Use the DAMP (Descriptive and Meaningful Phrases) principle for this.
Use comments wisely — comments can be helpful, but when commenting on something obvious, such a comment just adds noise and clutter. Also, comments require updating and maintenance, so don’t create extra work for yourself unless needed. Instead, comment where you see that additional explanations are warranted — for example, you are testing a complex enterprise system with many confusing integrations. In addition, you have testers who are new to the project and don’t have the required domain knowledge.
SRP — use the single responsibility principle in your tests whenever possible. This will make debugging failed tests easier and simplify dealing with false-positive/negative. Also, make sure that every class, function, etc., does only one thing — this will make your automation code more maintainable and easier to refactor.
Continuously refactoring is a never-ending process; as your knowledge improves, you will notice places where your code could be improved. Also, changes in technology will require code refactoring, so embrace refactoring as a constant in your career.

Check this out: iOS emulator for pc- How To Use iPhone Simulators On Windows https://www.lambdatest.com/blog/iphone-simulators-on-windows/

Want to make your life of testing easy and fuss-free while debugging? Try LT Debug Chrome extension!

Understand the design pattern useful in automation

Design patterns are beneficial, as they offer many benefits: they are an excellent way to structure your code, they are well known so your code will be readable by others, and a lot more.

One of the most famous ones in test automation is POM (Page Object Model), an OOP approach mainly used in UI automation, where a page on your website corresponds to an object in your code — usually a class.

Next, we have the Factory principle, which involves one superclass with many sub-classes. It is most useful when you do not know beforehand what type of object you need to create. Other commonly used ones are Facade pattern, Singleton, and Fluent interface.

Learn clean code practices and principles

I have found that Robert C. Martin (also known as Uncle Bob) has summed these up quite well. He’s one of the most experienced people in IT today, and his influence is enormous. Check out this Gist on GitHub for more details. For more details view, you can read his book on this topic or refer to the infographic below:

Study basics of how the web works

Here we need to have some fundamental knowledge of web technologies, HTML, CSS, and JavaScript. We should also have a basic understanding of how web browsers work. For example, one needs to understand what happens when they enter a URL and hit enter in the browser. What are the requests being sent when that happens, and what do they mean? What is DNS, and how does it fit in this process? What are IP addresses? What is the HTTP protocol, and why is it essential when we are performing API testing? Also, one should understand how data is being transmitted by getting familiarized with the most common formats such as XML and JSON. Finally, understand the difference between server-side and client-side and how data gets stored in databases — whether it’s a relational DB (table-based, like SQL) or a document-based non-relational, like MongoDB.

Pick one UI automation tool to start with

If you are just starting, the sheer number of tools available today can be overwhelming — it’s both a blessing and a curse that we have so many choices! But, if we look at it positively, sticking to one tool has its advantages. When you learn it well, you will gain an understanding of what other tools with similar purposes have to have in terms of features and what are common cons of a certain kind of a tool. This meta-knowledge will later make it a lot easier to learn new tools with less time and effort!

When using a UI tool, consider how easy it is to use, its support, whether it has an active community, its good tutorials, the market demand for that particular tool, etc. You will often notice that it might be wiser to learn an “old and boring” tool — which has high adoption and is well trusted, rather than the new hot tool that is not being widely used yet. For example, Selenium is widely used (its pros and cons), well documented, and has a vast wealth of online tutorials. Still, Playwright and Cypress (easier to set up than Selenium, suitable for simple websites, but have issues when dealing with redirects, iframes, and changing tabs) seem more attractive but not nearly as widely used — although their adoption is growing steadily — for Cypress in particular, as it came out before Playwright did.

Playwright is an open-source, cross-browser automation framework that provides e2e testing without the need for any third-party tools. Learn what it is, how to install it, and how we can execute tests using Playwright.

Pick one UI automation tool to start with

Check this out: Mobile Emulator Online- Test your mobile websites and smartphone apps using our scalable on cloud mobile emulator.

Learn about HTTP protocol and how to automate API tests

The Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed to communicate between the browser and the server, but it also has other uses. As a tester, you need to understand its basics, such as the HTTP methods (GET, POST, DELETE, PUT, etc.), headers, requests and responses, and most common status codes. Then, learn to use the developer tools (network tab) in the browser to get insights into the HTTP requests being sent and received. Finally, learn some HTTP client tools, such as Postman, and ideally an HTTP client library, like the one from Apache or a tool such as Rest-Assured.

API testing will make your life as a tester easier since it has many advantages over UI automation, such as earlier testing (you can test the business logic before the UI is available). In addition, API tests are faster and easier to develop and maintain; even when automating the UI, the knowledge of API testing will benefit you.

Let’s assume that you have a UI that requires the user to be logged in. A precondition for that test to be executed would be for the user to log in first to be authenticated and authorized to access the requested resource. Since UI tests take more time than lower-level tests, logging the user in via the login form is an unnecessary waste of time. Instead, you could make an HTTP request to get a token for the user and proceed with the test. This way, you’ll achieve the same result but a lot quicker.

Get familiarised with Database essentials.

Learn the basics of SQL (or some non-relation database) to use CRUD (Create, Read, Update, Delete) in your tests. This will enable you, amongst other things, to use the data-driven approach in automation, i.e., get test data from a database, store some records in the DB( if the test requires it), change some data via an automated test, etc. Having access to valid test data, and being able to use it, plays a big part in having reliable tests, as many bugs are data-related.

Pick a test mangment tool for easier reporting

A good test management tool can help even with automated tests. When selecting such a tool, make sure it has its API integrated with a reporting tool. Some of the most popular test management tools are — TestRail, Xray, Zephyr, etc. Another thing to consider is integrations with other tools — for example when you run your tests, can you have the generated report (about passing, failing, and skipped tests) emailed or sent to you via Slack, Teams, and the like.

Always have the manual aspect of testing in mind

Automation and manual testing go hand in hand. To be effective at automation, you also need to be an excellent exploratory tester who knows how to dig deep into the system you are testing to identify the scenarios which are the most beneficial as automation candidates in terms of risk coverage and to recognize if the return in investment when automating them, is worth it. In addition, before automating tests, you need to get familiarized with the system under test to improve your domain knowledge. Pair testing with a domain expert can also help a lot in this regard.

Conclusion

Getting into automation can seem scary and daunting at first, but instead of feeling jittery and trying to learn everything at once, you should segment your learning and attack one topic at a time. Be consistent, curious, and always try to apply what you learn from reading blogs, checking out documentation, and watching tutorials.

Don’t just copy what you see and do the same steps; try to give it your twist; instead of automating the same website the course instructor is using, try a different one. Of course, this will make things a bit harder for you, but it is a good indication that you are learning when things are hard.

Take it slow, be consistent, and have long-term goals. Within 6–12 months of dedicated learning, you can become proficient in automation. After that, it will be enough for you to get hired for a junior role, negotiate a better raise or land a higher paying job.

Lastly, don’t be intimidated by test automation; it is not there to automate you out of your job. Automation is there to serve as a trip wire or an alarm if something breaks and you get notified right away. It is much better than hearing about a defect from a customer. Also, automation will free up some of your time (after the initial effort to develop it and set it up). By automating the repetitive tasks, you will have more time for other aspects of testing where human creativity means a lot. Good luck on your automation journey!