A Test Automation Blog

At some point I messed up my local test automation setup and I thought, maybe I should do the experimental things in a Virtual Machine. So here is a compact manual for a Ubuntu VM. For the VM I'm using the open source software VirtualBox from Oracle. There are plenty of manuals for that around on the internet. So I'm not going to cover how to install Virtual box with Ubuntu.  www.virtualbox.org But what I want to cover in this manual is an editor (Visual Studio Code), Ruby, a set of ruby gems (lapis_lazuli, Watir, Selenium-webdriver) and of course the webdriver itself (Geckodriver). So let's get started. Visual Studio Code installation Download the package from https://code.visualstudio.com/ I downloaded the 32bit debian version from https://code.visualstudio.com/docs/?dv=linux32_deb After that I followed the guide on https://code.visualstudio.com/docs/setup/linux sudo apt install ./<file>.deb Ruby + gems installation In the terminal: su...

I think every test automation engineer will come at a point where you need to look at improving/optimizing your test automation script so it will take less time to run. But doing so is always tricky. Your tests should run as reliable as possible, at some point speed also becomes a factor in the equation. So what can you do, what works and which trade-offs should you avoid? Core reason for your TA suite The most important thing to keep in mind is that you should never give in on the core reason why you implemented test automation. If you only have a set of tests that run locally and the results are for you to interpret anyway, speed might be more important and a test is allowed to fail once in a while. But when your test suite is connected to a CI cycle and the results are automatically interpreted, it is very important to have super reliable tests instead. Obviously you want to have fast and reliable tests all the time. But time can only be spend once and is limited in mos...

Are you on a company network that is using a proxy to connect to the internet? And do you want (or are you planning) to connect your tests to an external selenium-grid. Than stay tuned, before you get lost in a bunch of answers on the internet that don't resolve the issue you're facing. Source:  https://nl.wikipedia.org/wiki/Proxyserver I'm on a new project and looking into Robotframework. But then I bumped into an issue with the POC I had to make which might result in me convincing the company to switch to Ruby. Anyway long story short. They use a proxy and although the internet has all the answers, you do need to know what specific question to ask to get the correct result. And since proxies are not used that much anymore, it's hard to find the skilled people to help you out and push you in the right direction for a solution. The setup To access the internet, I need a configuration on my computer that will tell Windows to connect to a proxy server. I...

As we all know, non-touch devices like a desktops have slightly different input from touch devices like mobile. This also means developers do have the option to build a website that does expect touch input instead of a mouse click. If your test suite does do a `element.click` when touch is expected, the click does not fail (at least not currently), so no error is thrown/shown but your script will fail. In one of my previous blog posts I mentioned a solution with execute_script and touchend . I did find out ( with the help of the watir community on Slack ), this can be resolved easier with Selenium and touch action (only supported on Chrome at the moment of writing). The specs In general spec documents are a bit difficult to interpret because of the lack of a clear example, but it gets easier to understand the structure over time. If you look at the specs of selenium-webdriver  you get an overview of all possibilities. There are a couple of points you could look if you think...

A picture sometimes says more than words. This is also true for test automation. Therefore it could be that you want your framework to make a screenshot when a scenario is failing to make debugging more easy. But how can you make sure your framework does this for you? Since we're using the `lapis_lazuli` gem, this is actually already been taken care off for most scenario's, but if you're using the 'watir' gem, you need to modify your `hooks.rb` file like briefly described on this page . Let's first look at Watir and then move to LapisLazuli to see what advantages and disadvantages are between the two. Watir screenshots Watir by default does not make a screenshot of a failing test, so you need to write some code to make this work. Below a Watir example Keep in mind that this only makes a screenshot at the end of the scenario. Meaning that it can happen that the screenshot is being taken a fraction later and thus missing the real issue. So let's t...

Our test automation suite for a single page application (SPA) called service-hub , takes almost one hour to run all +- 200 scenario's in serie per browser. The amount of scenario's will keep on growing with the expansion of the product. So I needed to start using some clever tricks to speed up the process. One of those tricks is by testing in parallel sessions. This is a very good thing to figure out anyway, but is also taking more resources (and therefore cost more money). Another trick is by using the API for some of the preconditions that take a lot of time. But for that we need a token which is stored in the browsers Session Storage. Scenario example For the service-hub product which I'm testing, it takes precious time to add/remove a material from an activity if I need to do this all via the UI. There are many steps to take to make sure I'm on the correct page, tab, breadcrumb, sub-tab and finally the element and to cover all other scenario's that might...

On most websites and applications you might need to fill in a form of some kind. Some people like to `click` in each field with the mouse, others like to use the `tab` button on the keyboard. But do you need to script both of these scenario's for your automated tests? https://www.service-hub.com/ contact form What to test and why? There are a bunch of additional questions that pop-up in my mind when I ask myself the question: "`Click` or `Tab`, which will be required in our test automation suite?". Because sure, we can automate both scenario's, but why is this needed? Would it be sufficient to automate only one of these? Can we mix them (most fields click and only one tab)? Will automating it save us time/effort?  The answer is simple: "It depends on what you want to test and what the test should be covering".  If you want users to navigate through the website with keyboard tabs, you should test this. If you want users to navigate through...

When building a solution for mobile users there are a bunch of solutions to choose from. Responsive Website, Progressive Web App, Android/iOS WebApp or Android/iOS App. All come with advantages and disadvantages. If you have a website that is responsive it's very easy to turn this into a (webview) WebApp. But do you need to test this? And if so, how do you test this? Android WebApp Let's look at a simple Android WebApp example. We now just turned a simple website into a Android WebApp. You will notice you can navigate through the website and when you use the phone back button, it will first navigate back on the website itself unless your at the initial loaded page, in which case it will close the WebApp. It looks just like the regular website, but can we test it the same way? And/Or can we test the responsive website and assume the webapp works just as fine as the webview app? To test or not to test? If you have a simple website, only testing the responsive website ...

In case you've never head of the phrase "All Roads Lead to Rome", it refers to the fact that many routes can lead to a given result. The same counts for finding elements on your website under test. There are many attributes which can be used to find the element you need. So let's have a look at a bunch of functions/options with the `lapis_lazuli` gem to limit the amount of roads a bit but still keep the test reliable. Side note Let's start with something I mentioned in a previous post , but it's good to keep in mind. The ` lapis_lazuli ` gem is an extension build on top of the ` watir ` gem. Even though I focus on LapisLazuli functions, you can also use the Watir way instead to locate the elements or even combine the two to a certain extend. Documentation All LapisLazuli documentation for locating elements can be found on the testautomation.info website. And also on github , but this is less complete. Since most of the element selection information...

When you just start with test automation, you most likely search and interact with elements within your `*_steps.rb` files (the files that contain the precondition, interaction and validation steps). So most likely across the steps, you have repeatedly located and interacted with the same elements a couple of times. And as long as your test suite is small, adjusting it only takes a small bit of time and it works, so who cares, right?  But now imagine you have a 100 scenario's, 100+ (precondition, interaction and validation) steps. And in a bunch of them you've locate the same element. But because of a change in the website this button cannot be found anymore. Are you going to adjust this in every line in your code to fix? Your answer should be: "NO!". You could use nested steps , but this becomes really confusing really fast and is not a good practice. So let's have a look at a proper solution, the helper files. Structure We basically define four main layers i...