The days of not being able to find a high quality Test Automation course for free are in the past – in no small part, we’re proud to say, due to Test Automation University (TAU). Today you can find free courses on web, mobile, API, and codeless test automation frameworks. Courses cover tools like Selenium, Cypress and Jenkins, and languages like Java, JavaScript, Python, Ruby, Swift and more – with new course releases every month.

TAU offers more than a dozen learning paths to guide you in your journey, and all courses are taught by leading testing experts.

Celebrate with 100,000 of Your Best Testing Friends

Join the party! Over 100,000 students have joined TAU already, and to celebrate we’re throwing a homecoming bash. Come join us on December 1^st  and 2^nd for a two day virtual conference with expert-led sessions and workshops, plus a live DJ, talent show and more ?.

Top 10 Free Test Automation Courses Taken by Test Engineers

Tens of thousands of free courses have been completed at TAU this year by leading test engineers. Here are the top testing courses for 2021:

1. Setting a Foundation for Successful Test Automation

   The Setting a Foundation for Successful Test Automation course, taught by Angie Jones, was the most popular course for 2020 and held that position through 2021 as well. As opposed to diving into code and automation tools, this course explores the initial considerations for starting a new test automation initiative and focuses on making sure you set up a culture for success. With the majority of test automation projects doomed for failure, this course is a much-needed resource to help change that. This course is highly recommended for anyone (managers, developers, testers, product owners) who will be involved in a test automation initiative.

2. Web Element Locator Strategies

   The second most popular course of the 2021 was Andy Knight’s Web Element Locator Strategies course which has seen a jump from 4th place in 2020. This course gives a fantastic and in-depth overview of the Document Object Model (DOM) – detailing how to explore the HTML that makes up a web page to find reliable locators for test automation. Andy covers the primary locator strategies as well as provides a thorough look into CSS selectors and XPath.

3. Java Programming

   Falling down 1 spot from 2020 is Angie Jones’ Java Programming course. This course is perfect for those who are new to programming and want to learn the language. The material is not specific to test automation, but instead teaches Java in general so that you become a true Java programmer and can use this skill for any related programming role, including an automation engineer. Students particularly love that this course is filled with lots of examples to demonstrate the concepts in practice, and even includes optional exercises for you to try your own!

4. Introduction to JavaScript ?

   New to the top 10 list is Mark Thompson’s Introduction to JavaScript. This course debuted on Test Automation University in the Fall of 2020 and has certainly made a splash, rising up to the #4 spot of the year. With JavaScript automation tools commanding more and more of the market share, it’s no surprise that automation engineers are eager to pick up this skill.

5. IntelliJ for Test Automation Engineers

   Corina Pip’s IntelliJ course climbs one spot in popularity this year. The course covers the various capabilities of IntelliJ and how to efficiently use this editor for Java test automation projects. Even experienced automators may learn a trick or two!

6. Exploring Service APIs through Test Automation

   Appearing again on the top 10 list is Amber Race’s introduction to API testing course! Amber provides real-world techniques to tame your tangled and messy APIs. Learn about the P.O.I.S.E.D. testing heuristic which is a great approach to thorough test coverage of your API.

7. Selenium WebDriver with Java

   The Selenium WebDriver course by Angie Jones remains in the top 10 but has taken a fall from the third most popular course of 2020. This free Selenium tutorial provides a very comprehensive guide on how to automate testing with WebDriver in Java, complete with optional independent exercises to allow you to practice what you’ve learned.

8. Introduction to Cypress ?

   New to the top 10 list is the free Cypress tutorial taught by Gil Tayar. While not new to the Test Automation curriculum, this course has garnered quite a bit of interest lately as Cypress’ popularity has exploded.

9. Cucumber with Java ?

   While Giridhar Rajkumar’s Cucumber with Java course was added last year, it gained a lot of popularity in 2021. This course is perfect for those who are practicing BDD and want to validate their specifications via automated testing.

10. Continuous Integration with Jenkins ?

Another new entry for 2021 is Aparna Gopalakrishnan’s CI course with Jenkins. This course was a late addition to TAU in 2020 and apparently was right on time! As automation engineers embrace CI/CD, this course gets them up and running!

Our Observations

We last compiled our list of top testing courses from 2020, and there have been a few changes! 

• JavaScript rising : “Introduction to JavaScript” has risen to become one of the most popular courses after debuting late last year, settling in at #4. Clearly, there is strong demand for JavaScript knowledge in the testing community with tools like Cypress growing in popularity. We definitely recommend that you add this one to your 2022 learning goals to keep up with the market trends.
• Java still dominant but arguably declining ?: Last year, the #2 and #3 courses we saw were “Java Programming” and “Selenium WebDriver with Java,” respectively. Both are still on the list, but now at #3 and #7. On the other hand, “IntelliJ for Test Automation Engineers” climbed one spot this year, and “Cucumber with Java” is a new entrant on the top ten list. So Java still has a dominant 40% of the top 10 courses this year. We’re eager to see if the JavaScript programming course will surpass the Java programming course in 2022. Also, while not making the top 10 list, the Python Programming course came in at #11 and missed the list by a mere 12 students.
• Selenium vs Cypress ?: This is a big question that we’ve been talking a lot about. While Selenium Java still has a strong position in our top 10, this year “Introduction to Cypress” debuts on the list just one spot behind it, and by less than 100 students!
• API testing is still in demand: The “Exploring Service APIs through Test Automation” course was released in January of 2019 and remains in the top 10 courses year after year – proving that API test automation skills are highly sought after.

2022 and Beyond

As you’re planning your education initiatives for 2022, keep these amazing, freely available resources in mind. In addition to these 10, there are many more courses available and new ones being released every month. To be notified of new course releases, register at Test Automation University!

The post Top 10 Most Popular Free Test Automation Courses of 2021 appeared first on Automated Visual Testing | Applitools.

Update 10/14: Selenium 4 has been officially released! Check out our post covering everything new in the latest release right here.

A release candidate for Selenium 4 is finally here! That means we’re getting really close to the official version ?. This is a really great time to familiarize yourself with the latest Selenium features that are coming in the new release.

I’ve compiled a list of resources to help you do so. Check it out below ?.

What’s New in Selenium 4

For a quick summary of the latest Selenium 4 updates, Manoj Kumar & Anand Bagmar have you covered! Check out What’s New in Selenium 4.

Test Driving Selenium 4 with Angie Jones

If you’d like to see Selenium 4 features in action, I made this video demonstrating real examples. Check out this video of Selenium 4 features.

Selenium 4 FAQs

There were lots of questions from the audience when I recorded that video ?. Check out this followup blog post to read the answers to the most frequently asked questions about Selenium 4 features.

How to Install Selenium 4

OK, now that you know what’s new, are you ready to try it out for yourself? Great! Shama Ugale covers how to install Selenium 4 in this tutorial.

Migrating to Selenium 4: Here’s What Has Changed

Or if you just need to migrate from an Selenium 3 to version 4, Shama Ugale details the notable changes and deprecations you should be aware of. Check it out to see how to migrate to Selenium 4 safely.

Selenium 4 Relative Locators

Good, you’re up and running! One of the interesting new features of Selenium 4 that I really want you to try is Relative Locators. Selenium 4 Relative Locators seem pretty straightforward but I’ve covered some things to be aware of, and also how this is working under the covers.

Selenium 4: Chrome DevTools Protocol [What’s New]

And the biggest draw for Selenium 4 is arguably its programmatic access to the Chrome Devtools Protocol (CDP)! This is some super power stuff. Shama Ugale outlines some of the cool things you can now do right from within your tests using Selenium 4 and Chrome DevTools Protocol.

Selenium 4: Mocking Geolocation

I also have a livestream video where I used Selenium 4’s CDP API to mock a location in the browser! Pretty handy if you need to do any location-based testing.

Selenium Chrome DevTools Protocol (CDP) API: How Does It Work?

And then if you’re fascinated with all of this and want to really geek out, I talk about the architecture of the Selenium Chrome DevTools Protocol API, how it all works, and which method calls to use when (executeCdpCommand vs send).

Have fun and let me know what you think!

The post Selenium 4 Release Candidate is Here! appeared first on Automated Visual Testing | Applitools.

Once upon a time there were several software development teams that worked on a fairly mature product. Because the product was so mature, there were thousands of automated tests – a mix of unit and web UI tests – that covered the entire product. Any time they wanted to release a new version of the product, which was only a few times a year, they’d run the full suite of automated tests and several of the web UI tests would fail. This was because those tests were only executed during the specified regression testing period, and of course a lot had changed within the product over the course of several months.

The company wanted to be more competitive and release more often, so the various development teams began looking into continuous integration (CI) where the automated tests would run as part of every code check-in. But…there were thousands of tests. And although there were so many tests, the teams were really careful about choosing which tests to automate, so they were fairly confident that all of their tests provided value. So, they ran all of them – as part of every single build.

It didn’t take long for the team to complain about how much time it took the builds to execute. And rightfully so, as one of the benefits they were hoping to realize from CI was fast feedback. They were sold a promise that they’d be able to check in their code and within only a few minutes they’d receive feedback as to whether their check-in contained breaking changes. However, each build took hours to complete. And once the build was finally done, they’d also need to spend additional time investigating any test failures. This became especially annoying when the failures were in areas of the application that different teams worked on. This didn’t seem like the glorious Continuous Integration that they heard such great things about.

Divide and Conquer

Having a comprehensive test suite is good for covering the entire product, however, it posed quite the challenge for continuous integration builds. The engineers looked at how they themselves were divided up into smaller agile teams and decided to break their test suite up to better reflect this division.

Each area of the product was known as a work zone, and if anyone was working on a particular part of the application, that was considered an active work zone. Areas that were not under actively development, were considered dormant work zones.

The builds were broken up for the respective work zones. Each build would share common tests such as build verification tests and smoke tests, but the other tests in a given build would be only the ones related to that work zone. For example, the Registration feature of the application was considered a work zone, and therefore there was a build that would only run the tests that were related to Registration. This provided nicely scoped builds with relevant tests and reduced execution time.

In additional to the various work zone builds, there was still the main build with all of the tests, but this build was not used for continuous integration. Instead, this build would run periodically throughout the day. This provided information about how changes may have impacted dormant work zones which did not have active builds running.

Assigning tests to work zones

All web UI tests lived in a common repository, regardless of the specific functional area. This allowed tests to share common utilities. The teams decided to keep this approach and use tagging to indicate which functional area(s) a given test covered. For example, for a test that verified a product listing, this test would be tagged for the “Shopping” work zone. And for a test that adds a product to a cart, this one spanned multiple work zones and was therefore tagged as “Shopping” and “Cart”. Tests that were tagged for multiple work zones would run as part of multiple builds.

To tag the tests, the teams used their test runner such as TestNG or JUnit and made use of the annotation feature of these runners.

@Test(groups={WorkArea.SHOPPING, WorkArea.CART})
public void testAddProductToCart()
{
    ...
}

Test runners also typically allow a means to configure which tests run. The team decided not to create these configuration files within the code repository because it did not allow for quick changes, as they’d need to check the change in, have it reviewed, etc. So, instead the configuration was done at the CI job level.

mvn test -Dgroups=cart

With this, if someone was checking in a feature that touched multiple work zones, they could quickly configure the build to pull in tests from all relevant zones. Also, it allowed for teams to change their build’s needs as their sprints changed. For example, the Shopping area may be an active work zone one sprint but a dormant work zone in the next. So, while the builds were focused on a specific work zone, they really were more aligned with the sprint team and their current needs at any given time.

Limitations

While this approach eliminated the complaints of the build being too slow or containing unrelated test failures, there were still limitations.

Bugs can be missed

By reducing the scope of the build, the team was not testing everything. This means that unintentional bugs in other work zones could creep in with a check in. However, to mitigate this risk, remember, the teams kept the main build which ran all tests several times a day. Initially they set this to run only once a day but found that wasn’t often enough. So, they increased this to run every 6 hours. If this build failed, it would be from a check-in made within the last 6 hours which helped narrow down the problem area.

Also, this system relied heavily on the tests being tagged properly. If someone forgot to tag a test or mis-tagged it, that would not be run as part of the appropriate work zone build. Usually these were caught by the main build and this gave an opportunity to fix the tagging.

Tests must be reliable

The web UI tests were not originally part of continuous integration. Instead they were run periodically throughout the year (during the dedicated regression testing time) on someone’s local machine. That person would then investigate the failures and could easily dismiss flaky tests that failed with unjust cause, unbeknownst to the rest of the team.

However, this sort of immaturity is unacceptable when a test needs to run as part of continuous integration. It has to be reliable. So before this new CI process could work flawlessly, the team had to invest time into enhancing the quality of their tests so that they only failed when they were supposed to.

Not every test failure is a show-stopper

The teams went through the very important process of identifying the most valuable tests to automate. Which would make you think that if any of them fail, the integration should be canceled. This sounds right in theory, but was different in practice.

Sometimes tests would fail, the team would investigate, then determine they still wanted to integrate the feature. So, they opened a bug, disabled the test, and integrated the feature.

Is this wrong? Why have the test if you’re going to still integrate in the event of a failure?

The team decided that the information was still valuable to them. Knowing this gave them information about the risks they were taking, and they could discuss as a team if they were willing to take the risk of introducing this new feature knowing that it breaks an existing feature. In some cases, it was worth it, and they opened bugs to eventually address those failures.

That’s the role of tests: to provide the team with fast feedback so that they can make informed decisions.

Happily Ever After

Preparing for continuous integration certainly took a fair amount of investment. The team learned a valuable lesson: you don’t just jump into CI. A proper testing strategy is needed to ensure you’re able to realize the benefits of CI, namely fast and reliable feedback. After experiencing bumps and bruises along the way, the team finally figured out a system that worked for them.

The post Test Management within Continuous Integration Pipelines appeared first on Automated Visual Testing | Applitools.

I stirred up a bit of controversy on Twitter by asking for unpopular opinions on software testing, and unsurprisingly, the community had some pretty hot takes! While I asked this some time ago, it appears that these takes are just as relevant today.

Trish Koo says “You don’t have to argue with people all the time to be a good tester”.

As testers, we are often thought of as the bearer of bad news and have accepted this as part of the job. We often find ourselves fighting for features and fixes in the name of customer advocacy. It doesn’t have to be this way. The best testers are the ones that people want to invite to the meetings. The best testers realize that their job is so much more than simply finding and logging bugs, as pointed out by Jason Phebus.

In fact, the best testers have not only found a way to become a part of the team, but have gotten their teams to realize that testing is a team sport.

Speaking of team sport, this one is from a developer who says “If you don’t start with tests, the design is probably garbage. I can’t think of any APIs I am responsible for and satisfied with that didn’t start with docs and tests”. This developer gets it! He understands his responsibility for quality even as a developer.

But I also often encourage testers not to leave the testing solely to developers during the design phase. As Jason Phebus said in the earlier tweet, logging bugs after the fact is the least interesting thing about testing. Get involved in your design meetings and help the team spot flaws in their approaches before a single line of code is written. Now, that’s powerful!

Let’s head on over to test automation…

Paul Grizzaffi says “A failing automation script does not necessarily mean that the script is wrong, horror of horrors, the script may be accurate”.

If you immediately question your test script when it fails, it could be a sign that you are not confident in this test. A lot of times people are not confident in the tests because they barely understand what it is that they’ve coded. As the director of Test Automation University, I have a lot of people ask me about learning Selenium or Appium, or some other automation tool. I get it, you need to learn the tool to be able to do the job. But can I tell you that you’re shortchanging yourself? Automation development is so much more than a tool. Learn the craft, learn the strategies, really learn to code! That way, when things fail, you know how to properly analyze what’s going on.

Just think about how much more value you can add if you’re truly code literate, as pointed out by Amber Race.

Even if you’re only able to read it, you now can understand much more about how your application works and sniff out poor coding practices that can lead to bugs.

And if you are writing code, you don’t have to stop just at automating tests. You can contribute so much more to automating processes, increasing test automatibility within the product itself, and even fixing bugs that are found.

You may be thinking “well Angie, if I’m doing all of that then I’m doing the job of a developer”. Yep, you absolutely are.

As Justin Ison so accurately says, quality managers expect you to test the entire site, write detailed bug reports, learn to program, automate all test cases, and setup CI/CD for half the salary of the developers creating the bugs!

So, to all of the quality managers and executives reading this, listen to David Burns and pay your testers the same salary as your developers, if not more!

Because “a tester’s mindset is the most powerful thing in computing”, says Orandi Harris. Know this, believe it, and act accordingly.

The post Unpopular Opinions: Software Testing Edition appeared first on Automated Visual Testing | Applitools.

A code review is a quality assurance activity to ensure that check-ins are reviewed by someone other than the author. If not pair-programming when writing the code, mature development shops often practice this activity as it’s an excellent way to catch errors early in the process.

I often state that test code should be treated with the same care as feature code, and therefore it should undergo code reviews as well. Test code can be reviewed by other automation engineers or developers who are familiar with the project and code base.

But what exactly should you look for when reviewing test code? Here are 8 specific things I pay close attention to when conducting code reviews for tests.

1. Does the test verify what’s needed?

When verifying something manually, there are a lot of subconscious validations that are being made. So if anything was incorrect, we’d likely notice. Our tests are not as good at this. In fact, they will only fail if the conditions that we explicitly specify are not met.

For example, let’s say we have a test to increase the quantity of one of the products within an online shopping cart. And here’s the test that you need to review:

@Test
public void testIncreaseQuantity() {
    cart.addProduct("Be A Good Person");

    String product = "Air Fryer Squad";
    cart.addProduct(product);
    cart.increaseQuantity(product, 1);
    cart.clickUpdate();
    assertEquals(cart.getQuantity(product), 2);
}

At first glance, this looks fine. The test increased the quantity of one of newly added products by 1 and is verifying that the quantity is now 2. However, let’s look at the UI.

There’s so much here that’s not being verified by this test.

• Where’s the assertion to make sure the product’s price was updated correctly?
• How about the subtotal of the entire cart? This needs to be verified.
• The tax should change based on the total, so when the quantity was increased, the tax should have increased. Where’s the assertion?
• The shipping is a flat rate. When the cart changes, how can you be sure the shipping cost remains the same?
• What about the other item in the cart? Was it inadvertently affected when we changed the quantity of Air Fryer Squad shirt? Who knows…there are no assertions for this.

As you can see, the one action of increasing the quantity affects many different aspects of the shopping cart – and this is often the case with software features. So when reviewing test code, make sure the test is including assertions for all that is needed. Pro tip: visual testing with Applitools will catch all of these subconscious assertions without you needing to think of them all; highly recommended! ?

2. Does the test focus on one thing?

Each test should focus on a single thing. This may be a bit confusing because in the test above, I mentioned a bunch of things that should be asserted. However, all of those assertions work together to verify a single thing (increasing a product’s quantity within a shopping cart).

If, however, the test above also verified the company’s logo or some other feature besides the cart, that would be outside of the scope of this test.

3. Can the test run independently?

In addition to focusing on a single thing, each test should be independent, meaning it should not rely on other tests at all. This makes it much easier to track down failures and their root causes, and will also enable the team to run the tests in parallel to speed up execution if needed.

While the author may agree that tests should be isolated, they still sometimes fall into the trap of using related test runs as setup for other tests. For example, if the test is to remove an item from the cart, it’s tempting to run the “add to cart” test first and depend upon it before running the “remove from cart” test. Call this out in reviews! Your recommendation should be that the test create and delete whatever it needs, and if possible to do this outside of the GUI. More on this in #4

4. How is test data being managed?

How tests deal with test data can be the difference between a stable and reliable test suite versus a flaky and untrustworthy one. As each test should be developed to run independently and all tests should be able to run in parallel at the exact same time, each test should be responsible for their own test data. Trying to share data that is being manipulated is the perfect ingredient for an unreliable test. When the tests are running in parallel and have different expectations of the test data’s state, the tests end up failing when there’s no real issue with the application. Recommend to the author that they create whatever data is needed for the test within the test itself. Since adding something to the cart already has a test, the “remove item” test can use code seams such as an API or database call to add the item to the cart.

5. Is there a separation of concerns?

Remember, test code should be treated with the same care as feature code. That means that clean coding practices, such as separation of concerns, should be followed. The test method should only focus on putting the application in a desired state and verifying that state. The implementation of manipulating the application’s state should not be within the test itself.

For example, in this test, notice the call to addToCart(). The implementation of adding a product to a cart is not the responsibility of the test, and therefore it is separated out into another method, and even another class. Same goes for goToCart().

    @Test
    public void testAddToCart() {
        product.addToCart("Be A Good Person");
        page.goToCart();
        eyes.checkWindow();
    }

Likewise, the non-test methods should not make any assertions. Their responsibility is to manipulate the state of the application, and the test’s responsibility is to verify that state. Adding assertions within non-tests decreases the reusability of those methods.

6. Is there anything in the test that should be a utility?

Separating concerns already addresses this in most cases, but double check that the test isn’t implementing something that can be reused by other tests. Sometimes this may be a common series of verification steps that certainly is the test’s responsibility, however, is/will be duplicated across multiple tests.

In these cases, it’s good to recommend that the author move this block of code into a utility method that can be reused by multiple tests.

7. Are the selectors reliable?

For GUI and mobile tests, the author will need to use selectors to locate and interact with the web elements. The first thing to ensure is that these locators are not within the tests themselves. Remember…separation of concerns!

Next, make sure the selectors can stand the test of time. For example, using selectors that depend on the structure of the page (e.g. indices) will only work until the structure of the page is changed.

This is a horrible selector and it’s only a matter of time before the test breaks because of it:

//*[@id="main"]/ul[1]/li[2]/a

If another list item is added before this one, all of a sudden, this selector is no longer good. Encourage the author to use unique IDs to locate any elements they need to interact with, even if that means adding the ID to the element as part of this check-in.

8. Is the wait strategy solid?

Flag any hard-coded waits. Automated tests run faster than customers would actually interact with the product and this could lead to issues with the test, such as trying to interact with or verify something that is not yet in the desired state. To solve for this, the code needs to wait until the application is in the expected state before proceeding.

However, hard-coding a wait is not ideal. It leads to all kinds of problems such as lengthening the duration of execution, or still failing because it didn’t wait long enough.

Instead, recommend that the author use conditional waits that will only pause execution for the least amount of time that is needed.

For example, if testing a POST API request, while the response may have been returned, there could still be some processing on the backend. Attempting to run another request on this newly-created entity before the entity has actually been created would result in a test failure. Instead of waiting a set 3 seconds before proceeding, recommend that the author includes logic that polls every few milliseconds until the test is sure the entity has been created, and then proceed.

You’re ready to review!

Hopefully these tips provide something substantial to look for in reviews of test code. Remember, your test code is what’s used to determine the quality of your feature code, so it’s really important that it’s developed with care. If you’re looking for more tips or advice on how to set yourself up for success in test automation, check out my free course over at Test Automation University, Setting a Foundation for Successful Test Automation.

The post Guide to Conducting Test Automation Code Reviews appeared first on Automated Visual Testing | Applitools.

Selenium 4 introduces a new powerful API which grants access to Chrome DevTools directly from your automated tests! This is done via the Chrome DevTools Protocol (or CDP for short) which is essentially a set of tools that enables you to access and control Chromium-based browsers.

You may know Chrome DevTools as the place where you inspect elements to find their locators. But there are lots of other domains here as well such as Network, Performance, and Security. There’s also a bunch of commands and sensors available.

Selenium 4’s new Chromium DevTools API is essentially a wrapper around the raw CDP commands, and access to these commands from our tests opens a world of possibilities!

For example, we can mock the geolocation of our browser to do testing in areas where we aren’t actually physically located. We can simulate things like network speed and device mode. We can intercept network requests and mock responses. And we can capture console logs and performance metrics. Essentially anything that can be done from the Chrome DevTools window can now be done from our automated tests!

Shama Ugale has provided Selenium 4 CDP examples complete with code snippets! And in this post, I’ll provide the architecture to help you better understand how to use CDP in your tests.

ChromiumDriver

ChromiumDriver is a new driver that can be used to interact with Chromium-based browsers such as Google Chrome and Microsoft Edge. The browser-specific drivers ChromeDriver and EdgeDriver still exist in Selenium 4, but now they inherit from ChromiumDriver instead of the RemoteWebDriver class (which ChromiumDriver now extends).

From ChromiumDriver (or any of its children classes), you can now access the getDevTools() method which returns a DevTools object.

DevTools devTools = driver.getDevTools();

DevTools Object

The DevTools object has methods to manage CDP sessions, add and remove listeners, and most notably send CDP commands. The send() method accepts a Command, which are the Selenium-provided wrappers for CDP commands.

The wrapper classes represent the 45 CDP Domains and can all be found in the org.openqa.selenium.devtools.vXX package, where the vXX represents the browser version you’re running against.

For example, I’m currently using Chrome 88, so I must ensure I have the corresponding devtools dependency:

        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-devtools-v88</artifactId>
            <version>4.0.0-beta-1</version>
        </dependency>

Here are the CDP Domains. Each of these have a corresponding wrapper class in Selenium 4.

By clicking on any of the CDP Domain links above, you’ll see the available commands. Each of these commands are methods within the Selenium domain wrapper classes. This makes it relatively straightforward to invoke a CDP command using the send() method.

For example, the signature for the send() method is

devTools.send(Command<X> command)

And if we wanted to invoke a command, we could do so by passing in the {Domain}.{command} to the send() method. Let’s say we wanted to clear the browser cache. The Network domain has a clearBrowserCache command, so this is what we’d use in Selenium as well.

devTools.send(Network.clearBrowserCache());

executeCdpCommand

Selenium 4 also provides the executeCdpCommand() method. I’m already seeing people jump straight to this method as opposed to the send() method, as the name is very enticing. The executeCdpCommand() method is available directly from ChromiumDriver (and its descendent classes). The purpose of this method is to allow you to invoke any raw CDP commands. As the devtools package has all of the ready-made wrappers available, the send() method should be your first choice to invoke CDP commands. The executeCdpCommand() method should be used when you want to bypass Selenium’s implementation and call the CDP commands directly. The use of executeCdpCommand() requires a bit more work, as you’ll need to paste in the exact Domain.command as well as a Map of all of the command’s parameters.

For example, here’s a call to emulate a geolocation using executeCdpCommand(). Notice, I need to manually type in the names for the Domain, command, parameters as well as the parameter values.

driver.executeCdpCommand(
        "Emulation.setGeolocationOverride",
        Map.of(
                "latitude", 30.3079823,
                "longitude", -97.893803,
                "accuracy", 1
        ));

And here’s the more streamlined way of invoking that same CDP command by using the DevTools API that Selenium provides. Here I only need to manually type in the values. Selenium takes care of everything else, so there’s less room for error.

devTools.send(Emulation.setGeolocationOverride(
        Optional.of(35.8235),
        Optional.of(-78.8256),
        Optional.of(100)));

Hopefully this helps you understand CDP better and how you may be able to take your tests to the next level!

The post Selenium Chrome DevTools Protocol (CDP) API: How Does It Work? appeared first on Automated Visual Testing | Applitools.

A common question is “does Applitools visual testing work on mobile apps?”. The answer is a resounding YES! In this post, I’ll automate a couple of scenarios and show you the power of visual testing.

The App

We’re going to work with a Todo App which will allow us to add tasks. A cool feature of this app is the ability to add colors to tasks, which is a great way to designate categories for our various types of tasks.

Scenario #1: Add multiple tasks of different categories

Our first scenario is to add four tasks, one for each of the different colors/categories. So here, we declare the 4 tasks and add them to the app: one for purple, blue, yellow, and pink. Next, we verify that the tasks were indeed added.

However, a key aspect of this scenario is to verify that the tasks were added as the right color. This is a native app, so we can’t make a call to get the CSS value as that is unsupported. And when looking in the Inspector, there was nothing there that identified these tasks by color. Fortunately, visual testing can help us with this!

What is Visual Testing?

Visual testing is an automated technique for verifying the state of your application by using snapshots. This means your tests are not limited to interrogating the DOM to determine status, like what is done with most other automation tools. Instead, with visual testing, a screenshot of your application is taken on every regression run and compared against a baseline image. Therefore, viewing and verifying your application as your users would!

Applitools’ visual testing API is called Eyes. The Eyes API uses AI to compare the images and is much more reliable than all other forms of visual testing, namely the notoriously flaky pixel-to-pixel and DOM-based approaches offered by other vendors.

Adding Visual Testing

The Eyes API can be added to your existing tests so there’s no need to throwout your test suite and start over! Let’s add visual testing to Scenario #1 so that we can make sure the tasks were added with the right colors.

Here we’ve added visual testing with 4 lines of code! ?

On line 21, we’re simply initializing the Eyes API. On line 22 is where we tell Eyes that we would like to begin visually testing.

On line 23 is where the magic happens – we take a screenshot of our app. If this is the first time the test is run, this will become the baseline image. If there is already a baseline image, a new image will be taken and compared to the baseline image to determine if there are any differences. Notice the arguments sent into this call. This is telling Eyes to ignore the status bar region of our app because it is dynamic and will contain a timestamp and notifications. So this part of the app will be ignored every time the test runs!

Finally, on line 24, we’re done so we can close our Eyes. At this point, the screenshots are sent to the Applitools cloud, analyzed, and stored in a nice dashboard. In the event of a failure, your team can easily review the images to determine where the application has changed, and annotate the image with bugs and remarks.

But wait…

We added visual testing to verify the colors of the tasks. But it’s doing so much more. It’s verifying the entire screen (sans the status bar which we explicitly said to ignore). So that means all of our assertions above are already covered by Eyes and we can actually DELETE CODE!!! ? In fact, we’ve deleted almost HALF of the code from this one test alone – with MORE coverage!!! Woohooo ?

Let’s try another more scenario.

Scenario #2: Complete a task from the list

In our next scenario, we need to complete one of the tasks by clicking on it, and then verify that it is crossed off.

Now when it’s time to verify, we run into the same issue we did in Scenario #1. The strikethrough on the completed task is a CSS effect, and cannot be verified using the Inspector. So, let’s use visual testing.

Now we’re covered! Ok, one more scenario…

Scenario #3: Add long tasks

For the last scenario, we want to add long tasks. What is the purpose of this test? It’s to ensure that on this mobile view, the text is displayed properly and doesn’t get cut off or bleed off the edge of the page.

But how can we make sure the text is displayed correctly without using visual testing? We can’t! We can make sure it exists. We can make sure it’s visible. But only visual testing will make sure that it’s showing up just as we intend it to.

Visual Bugs Love Mobile Viewports

Mobile testing is such a challenge. In addition to not being able to access style attributes from the Inspector, the presentation of your apps can vary based on the various viewport sizes. This makes mobile apps ripe for visual bugs! To make matters worse, traditional mobile automation tools only offer so much and are incapable of catching these visual bugs, and heck, even some of the functional ones as we’ve seen in Scenarios 1 and 2. If you’re doing mobile app test automation, you need visual testing! Wait no more; create your forever-free Applitools account and improve your testing today!

The post Visual Testing for Mobile Apps appeared first on Automated Visual Testing | Applitools.

Playwright, Microsoft’s new end-to-end browser automation framework, is making quite the splash! I took Playwright for a spin only a few months ago when it was a JavaScript-only framework, and am pleasantly surprised to learn that language support has expanded to my beloved Java as well as Python and C#! ?

I’ve also started to think about how to compare Playwright vs Selenium.

Playwright vs Selenium

With the additional language support, as well as the ability to execute across modern browser engines Chromium, Firefox, and WebKit – this puts Playwright in the same category as Selenium WebDriver as viable testing solutions for all (not just JS) web testers who need cross-browser testing capabilities for complex applications.

Browsing the Playwright Javadocs was helpful, but I like to evaluate frameworks by actually using them to automate realistic scenarios. So in this post, I’ll share the steps of building a testing project with Playwright which includes Page Objects, and I’ll also compare the Playwright steps to their equivalents in Selenium WebDriver.

How to Install Playwright Java

The first step in getting started with Playwright is adding the dependency to your project. You can get the Playwright client from Maven Repository. I created a new pom.xml file and added the playwright dependency.

When it comes to comparing Selenium vs Playwright, it’s worth noting that like Selenium WebDriver, Playwright is a browser automation tool and not necessarily limited to a testing framework. In fact, neither of them provide any assertion methods. Therefore, you’ll need to add an assertion library as well. For this example, I’ll use TestNG.

How to Launch Browser in Playwright

The Playwright interface allows you to create specific types of Browser objects. The options are Chromium which is what Chrome and Edge are built upon, Firefox, and WebKit (the engine Safari is built upon). With this Browser object, a launch() method is available which will start a browser instance.

By default, Playwright launches the browser in headless mode, which means you won’t actually see the tests execute. If you want to see the browser open, you can disable headless mode by passing in a LaunchOption.

In addition to setting the headless mode, LaunchOptions provide several other methods including ones to set environment variables and open Chromium dev tools.

How to Launch a Website in Playwright

Now that we have a browser, we can load the application under test – Automation Bookstore. To do so, we need a Page object – which is similar to the WebDriver objects in Selenium. To create the Page object, we call browser.newPage() on line 8. This represents a single tab within the browser window. With this object, we can then navigate to our URL (line 9).

How to Create a Page Object in Playwright

We have our application loaded in the browser, and now we’d like to use the Page Object Model design pattern to create a Java class that represents the Search page of our application.

In order to interact with the web elements, the Page Object class will need access to the Playwright Page object we created above. Again, this is comparable to how we pass the Selenium WebDriver object to Page Object classes so that they can perform browser interaction methods.

I created that SearchPage class and the constructor that accepts the Page object.

The first method I’ll add to this class is search() which will take in text and enter it into a text field. The method to do this is fill(), which takes a locator and the text you’d like entered into the field. You can see the call on line 11.

Locators

The element locator for the search field is defined as a String. This is true for all locators used in Playwright; unlike Selenium which uses the By class to allow you to express locators as id, name, XPath, css selector, link text, etc. However, Playwright offers a variety of options to express the locators so all of the ones in Selenium are covered, plus extra flexibility for more expressive locators such as conditions of the elements, chaining, and even access to shadow DOM elements!

Wait Strategies

Playwright has auto-waiting for elements that you are directly interacting with. Selenium WebDriver often gets a bad rap for things that are out of its control, for example the need to wait for a desired state of the application. In my particular application, there is a slight delay between the time I enter the search query and the time that the results are filtered. Since the search results element is a different element than the one I used the automation tool to interact with (search field), I have to account for this wait in my code, and it doesn’t matter if I use Selenium, Cypress, or Playwright – this remains true.

To wait within Playwright, there’s a WaitForSelectorOptions class that allows you to specify the state you’re waiting for. The available states are ATTACHED, DETACHED, HIDDEN, and VISIBLE.

So here, after entering text into the field, I need to ask Playwright to wait until there are hidden books attached to the DOM. This is shown on lines 4-5.

To demonstrate the DETACHED selector option, I’ll also make a clear() method. In this method, I clear the text field by sending an empty String, then wait for the hidden books element to be detached from the DOM.

How to Get Elements in Playwright

Playwright provides the querySelector() mehod which returns a single element as an ElementHandle object. This is equivalent to Selenium’s WebElement object obtained by findElement(). To get multiple elements that match the locator, Playwright provides querySelectorAll() and this will return a list of elements: List<ElementHandle>.

This is demonstrated in our Page Object class as we get the number of visible books.

From an ElementHandle, you can take actions (e.g. click, fill, etc) or get information (getAttribute, isEnabled, isChecked, etc). The two methods that are JavaScripty and maybe not obvious at first glance to Java programmers are: innerText() and innerHTML(). The innerText() method is equivalent to Selenium’s getText() method; and there is no equivalent for innerHTML() in Selenium, but it’s used to get the entire HTML contained between an element’s opening and closing tags.

Here I use the innerText() method to get the titles of the visible books on line 4.

The Tests

Now that all of the heavy lifting has been done in the BaseTests and Page Object classes, the tests look exactly like they would if written in Selenium.

There’s Much More

What I’ve demonstrated here is how to use Playwright for some of the most common everyday tasks, however the API boasts a lot more! It can capture screenshots, mock geolocation, emulate mobile device settings, intercept network calls, and much more. When comparing Playwright vs Selenium, Playwright already contains a lot of the features that make Selenium 4 more modern. While Playwright is still very new, it looks extremely promising and I’m definitely keeping my eye on it.

The post Playing with Playwright – Java API and Playwright vs Selenium appeared first on Automated Visual Testing | Applitools.

It’s been more than two years since we last evaluated Cypress vs Selenium WebDriver, and as we all know, a lot can happen in two years.

Since then, Selenium WebDriver has made impressive improvements as they prepare for the major release of Selenium 4, and Cypress has grown from its infancy phase. Let’s see what’s changed!

Target Audience

In our previous post, we asserted that most of Selenium’s users are testers, while developers seemed to favor Cypress. While this was certainly true in its early days, the popularity of Cypress has increased with testers as well. Cypress has become the most widely used test automation tool amongst our JavaScript users, which comprises mostly of dedicated automation engineers.

My theory for the uptick in the use of Cypress amongst testers is that collaboration is a key factor in tooling. It’s hard enough to get developers to contribute to UI testing, and if Cypress is a way to bridge that gap, then testers are all for it!

Language Support

Since Cypress was designed for frontend developers, it only supports JavaScript – the language of the web. This has not changed since Cypress was released, and it does not seem to be on the product’s roadmap. Consequentially, this puts Cypress at a disadvantage to Selenium which supports JavaScript as well as Java, Python, C#, Ruby, and Kotlin. This gives Selenium a much wider target audience, especially since Java is the most popular programming language for UI testing.

Browser Support

Arguably, the biggest enhancement to Cypress since our last post is its move from Chrome-only to cross browser support!

Cypress’ lack of cross-browser support was a major con for those who needed to test their applications on more than just Chrome. Many Cypress users had to rely on third-party plugins such as Applitools’ Ultrafast Grid to gain test coverage on multiple browsers. However, with version 4 of Cypress, this now opens the possibility of testing on Firefox and Edge as well.

Of course, Selenium WebDriver has always supported Chrome, Firefox, and IE; and has also supported Edge and Safari for years. This gives Selenium an edge in this category for those who need to test on Internet Explorer and Safari (the default browser for iOS devices).

Browser Capabilities

The architecture for Cypress and Selenium varies quite a bit (see our original comparison for the details). Cypress runs tests in-browser while Selenium uses a browser driver. Both of these approaches have their pros and cons.

Cypress tests are faster since there are less processes to call for every browser interaction. However, features such as opening and manipulating multiple tabs and windows is not supported in Cypress. Likewise, Cypress has limited support for working with iframes and requires you to write custom code to be able to do so.

Selenium users do not have to concern themselves with these limitations. Not only are iframes fully supported in WebDriver, but Selenium 4 boasts updated support for multiple windows and tabs.

Server Manipulation

In our previous post, we admired Cypress’ built-in support for mocking and intercepting server requests and responses. At that time, this powerful feature was not available in Selenium. However, Selenium 4 provides a brand new Chrome DevTools Protocol API which enables Selenium tests to not only mock server requests and intercept responses, but to fully leverage all of the possibilities of Chrome DevTools. This is a game-changing feature for Selenium WebDriver!

Which is Better? Selenium or Cypress?

That depends on your needs.

Cypress integrates quite nicely into a given production codebase making it favorable for developers, which therefore fares better for collaboration between developers and automation engineers/testers. Cypress’ architecture also inherently speeds up test execution.

However, Selenium has far more reach and support for browsers, programming languages, and browser capabilities.

If your application is relatively simple and speed and collaboration are the most important factors, then Cypress is a great choice. However, if your application and user journeys are more complex and require extensive testing across multiple platforms, then Selenium would be a better choice.

I applaud you for reading to the end! Tools have their intended purposes and while multiple tools may seem similar, we shouldn’t be so quick to label one tool as “better” than another. Evaluate any given tool against your requirements to determine which would be the most efficient for your needs.

I’m excited to see the progress in both Selenium WebDriver and Cypress over the last two years. Both are clearly here to stay!

The post Selenium vs Cypress: The Rematch appeared first on Automated Visual Testing | Applitools.

Unless you’ve been living under a rock, surely you’ve heard of Test Automation University (TAU) – the online platform that provides free courses on all things test automation! TAU provides more than 50 courses on web, mobile, API, and codeless test automation frameworks in Java, JavaScript, Python, Ruby, and Swift – with new course releases every few weeks.

With several learning paths to guide you and courses taught by testing experts, TAU has become the premier place to find what you need when you need it.

Here are the top 10 courses that engineers have taken this year:

1. Setting a Foundation for Successful Test Automation

The Setting a Foundation for Successful Test Automation course is taught by Angie Jones and explores the initial considerations for starting a new test automation initiative. What’s unique about this course is that it doesn’t dive into programming or tools. No, instead it focuses on making sure you set up a culture for success. With the majority of test automation projects doomed for failure, this course is a much needed resource to help change that. I highly recommend this course for anyone (managers, developers, testers, product owners) who will be involved in a test automation initiative.

2. Java Programming

The Java Programming course is also taught by Angie Jones and has been an excellent course for those wanting to learn the language. This course is not specific to test automation, but instead teaches Java in general so that you become a true Java programmer and can use this skill for any related programming role, including an automation engineer. The material covered in the course is equivalent to the curriculum of a full semester of Java programming at a university and is filled with lots of examples to demonstrate the concepts in practice, and even includes optional exercises for you to try your own!

3. Selenium WebDriver with Java

Angie Jones also teaches the free Selenium WebDriver tutorial which is a very comprehensive guide on how to automate testing with Selenium. The course is a full tutorial on Selenium WebDriver going from 0 to 100 – introductory to advanced. It also includes optional independent exercises to allow you to practice what you’ve learned.

4. Web Element Locator Strategies

Andy Knight teaches the Web Element Locator Strategies course which gives a fantastic and in-depth overview of the Document Object Model (DOM) – detailing how to explore the HTML that makes up a web page to find reliable locators for test automation. Andy covers the primary locator strategies as well as provides a thorough look into CSS selectors and XPath.

5. Exploring Service APIs through Test Automation

This course by Amber Race is an excellent introduction to API testing! Amber provides real-world techniques to tame your tangled and messy APIs. Learn about the P.O.I.S.E.D. testing heuristic which is a great approach to thorough test coverage of your API.

6. IntelliJ for Test Automation Engineers

In this course, Corina Pip teaches you about the various capabilities of IntelliJ and how to efficiently use this editor for Java test automation projects. Even experienced automators may learn a trick or two!

7. Test Automation in DevOps

World-renowned author and testing legend, Lisa Crispin, teaches the Test Automation in DevOps course. Lisa covers some basic concepts and terminology about DevOps, continuous delivery, and continuous deployment as well as techniques for operability and learning from production use.

8. The Whole Team Approach to Continuous Testing

Principal Agile Tester, Lisi Hocke, covers how to tackle test automation when there are no automation experts on the team. She reveals the secrets of pairing, mobbing, and collaborating with developers and others on the team to make continuous testing a reality!

9. Introduction to TestNG

TestNG is a test framework which allows you to execute tests. In this 9-chapter course taught by Rex Jones II, you’ll learn about assertions, annotations, attributes, data-driven testing, and cross-browser testing.

10. Codeless Test Automation with Selenium IDE

Selenium IDE has gotten a complete makeover and Dave Haeffner, one of the Selenium IDE contributors, teaches a course covering the new features of the revamped tool, such as decision structures, loops, test case reuse, debugging, CI, and plugins!

2021 and Beyond

As you’re planning your education initiatives for 2021, keep these amazing, freely available resources in mind. In addition to these 10, there are many more free courses available and new ones being released every few weeks. To be notified of new course releases, register at Test Automation U!

The post Top 10 Most Popular Free Test Automation Courses of 2020 appeared first on Automated Visual Testing | Applitools.

I often get questions from those starting new test automation projects querying which programming language they should choose. I never have a cut and dry answer to this because it depends on a few factors such as which language the product features are being developed in, who will be writing the tests and which language are they most comfortable in, and how much support and tooling is available for a given language.

In this post, I’ll share which programming languages are most used for test automation as it gives some insight into industry usage. However, do not take this to mean “best programming language”, as the best language is the one that is best for your context.

The Data

You may be wondering where the data is from. Good question! More than half of the top companies in software, financial services, and healthcare verticals use Applitools for their web and mobile test automation needs. From the millions of tests that run in our cloud every week, I’ve analyzed which languages the tests were written in and aggregated the results at the team level (not the test level).

The Results

1. Java
   Java remains the most popular programming language for test automation. Java held its lead with 43% of our users opting to write their tests in this language. In last year’s review, Java was used by 44% of our customers, so a slight decline but nevertheless this language managed to keep the crown in 2020.
2. JavaScript
   Coming in as the 2nd most popular programming language for test automation is JavaScript with 35% of our users writing their tests in this language. This is a huge increase from last year where only 15% of our users tested in JS! According to StackOverflow, JavaScript is the most popular technology used by professional developers, so I expect to see an increased usage of JS for testing in the years to come.
3. C#
   With Java and JavaScript accounting for 78% of usage combined, there’s not much market share left for the other languages. So, we see quite the jump with the 3rd place language, C#, being used by 8.8% of our users. This is rather interesting because last year’s results showed 13% of our customers using C#, which means almost a third of these users have likely opted for a different language this year.
4. Python
   Right behind C# is Python, with 8% of our customers using Python as their language of choice for test automation. This is exactly the same percentage of usage we saw last year. What’s most surprising about this stat is that Python is gaining popularity year after year with professional developers and has become the fastest-growing major programming language – even edging out Java for the first time this year! Perhaps we’ll eventually see this trend in software testing as well.
5. Ruby
   Only 4.2% of our customers use Ruby for test automation. This is a stunning 40% decrease from Ruby test automation usage last year. StackOverflow shows Ruby’s popularity down to 8.9% with professional developers and it appears Ruby is even less popular in the testing space.

Remember…

While the data here doesn’t necessarily indicate which is the best programming language for test automation, it does highlight which ones are most used for testing amongst the hundreds of companies and open source projects surveyed.

The post 2020’s Most Popular Programming Languages for UI Test Automation appeared first on Automated Visual Testing | Applitools.

Those looking to break into the test automation field have difficulty doing so because of lack of experience. One way to gain experience is, of course, to study and practice on your own. But how do you demonstrate your newfound knowledge to employers?

Other professionals, such as front-end developers, create portfolios to highlight their skills, and you can do the same as automation engineers!

Here are 10 projects for your test automation portfolio that will help you stand out among the competition.

1. Web browser automation

Web automation is by far the most common and sought-after form of test automation. If you’re looking to break into test automation, this is an absolute must-have for your portfolio.

Be sure to go beyond a basic login flow. Instead, show full scenarios that require your code to interact with multiple pages.

This project should demonstrate your ability to find element locators and interact with various types of elements such as dropdown menus, checkboxes, text fields, buttons, links, alerts, file upload widgets, and frames.

Also, be sure you’re writing clean test code and utilizing design patterns such as the Page Object Model or the Screenplay Pattern.

Sites to practice against:

• The-internet (Heroku)
• ToolsQA
• Formy
• ParaBank (login is john/demo)
• OpenCart

2. Mobile automation

The demand for mobile test automation engineers has increased over the years as the popularity of mobile apps has soared. Having experience here can certainly work in your favor.

Your portfolio should demonstrate automated testing against both iOS and Android apps. Using Appium to create one project that works for both iOS and Android would be great. Using tools such as Apple’s XCUITest or Google’s Espresso is good as well. But if you go this route, I recommend doing at least two projects (one of each), since each supports only one mobile operating system.

No matter which framework you use, you’ll want to demonstrate the same element interactions as you did in your web automation project, but also mobile-specific gestures such as swiping and pinching.

Apps to practice with; download any of these to use in your project:

• Android apps (you’ll need to fill out the CAPTCHA form before you can access the apps)
• iOS apps

3. Visual automation

After making your web and mobile projects, fork them and add visual testing capabilities to them. You’ll quickly see just how much your tests are missing because they weren’t enabled to verify the appearance of your app.

Visual testing is a skill being listed on a number of job postings, and having this skill will really help you shine against the competition.

4. API automation

With the rise of microservices, IoT applications, and public-facing APIs, the demand for automation engineers who know how to test APIs has become substantial. So definitely add an API testing project to your portfolio. (Here’s a free class on how to test APIs to get you started.)

Within this project, be sure to demonstrate a variety of API methods, with GET and POST as a minimum. Use APIs that require parameters or request bodies, and also return complex responses with multiple objects and arrays.

For bonus points, use advanced verification techniques such as deserialization or approval testing. Also, demonstrating how to mock API responses would be a nice bonus.

APIs to practice against:

• Swagger Petstore
• ParaBank
• Restful booker
• Zippopotam.us

5. BDD specification automation

Many teams are practicing behavior-driven development (BDD) and automating tests based on the specifications produced. You’ll want to demonstrate your experience with this and how you can jump in and hit the ground running.

For this portfolio project, be sure to not only show the mapping between feature files and step definitions, but also demonstrate how to share state between steps via dependency injection.

Also, be extremely careful when writing your feature files. Long, verbose feature files will hurt your portfolio more than help. Make the effort to write good, concise Gherkin.

6. Data-driven automation

Your practice projects may use only a small amount of test data, so it’s easy to store that data inside the source code. However, on production development teams, you’ll have hundreds or even thousands of automated tests. To keep up with all this data, many teams adopt a data-driven testing approach.

I recommend adding this to at least one of your projects to demonstrate your ability to programmatically read data from an external source, such as a spreadsheet file.

7. Database usage

Speaking of being able to access data from external sources, it’s a good idea to add a project that interacts with a database. I recommend writing queries within your code to both read and write from a database, and use this within the context of a test.

For example, you can read from the database to gather the expected results of a search query. Or you can write to a database to place your application in a prerequisite state before proceeding to test.

8. Multiple languages and libraries

Writing all of your portfolio projects in one programming language is okay; however, automation engineers often need to dabble in multiple languages.

To make yourself more marketable, try using a different language for a few of your projects.

Also switch it up a bit and try a few other automation libraries as well as assertion libraries. For example, maybe do a project with Selenium WebDriver in Java and JUnit, and another project with Cypress in JavaScript and Mocha.

I know this sounds daunting, but you’ll find that some of the architecture and design patterns in test automation are universal. This exercise will really solidify your understanding of automation principles in general.

9. Accessibility automation

Automating accessibility testing has always been needed but recently has become extremely important for companies. There have been legal battles where companies have been sued because their websites were not accessible to those with disabilities.

Demonstrating that you are able to do test automation for accessibility will give you a great advantage when applying for jobs.

You can use the same sites/apps you used for your web and mobile projects to demonstrate accessibility testing.

10. Performance testing

Last but not least, you should consider adding a performance testing project to your portfolio.

Nonfunctional testing such as performance is a niche skill that many automation engineers do not have. Adding this to your portfolio will help you be perceived as a unicorn who really stands out from the crowd.

Presenting the Portfolio

GitHub

Be sure to put all of your projects on GitHub so employers can easily access and review your code. However, be careful to hide secret keys. This will give you bonus points, since it shows another level of maturity.

Website

Create a website that highlights each of your portfolio projects. You don’t have to build the website yourself; you can use common CMS systems such as WordPress to allow you to quickly get your portfolio up and visible.

Each project highlight should include a paragraph or bullet points explaining what you’ve done in the project and the tools and programming language used.

Resume

Include a link to your portfolio on your resume, and feel free to list your portfolio projects under the “Experience” section of your resume.

While this is not traditional work experience, it shows that you are self-driven, passionate, and competent to break into the test automation field.

Interview

During your interviews, be sure to mention all of the projects you have worked on. Draw from your experiences with building the projects to be able to answer the questions. Also brush up on other concepts around testing and development that may come up during the interview.

Good luck!

The original version of this post can be found at TechBeacon.com.

Header Photo by Shahadat Rahman on Unsplash

The post 10 Portfolio Projects for Aspiring Automation Engineers appeared first on Automated Visual Testing | Applitools.