A Test Automation Blog

Some time ago I started to share Android statistics and predictions and I still keep track of these statistics. At my previous employer I also had to report on this, so I created some blogposts on their website instead of here. So I thought it might be interesting to start sharing this information again. I'll share my reasons to support or skip a certain version on the long and short term. Obviously the support you want to give for your app/website is depending on your customers and not per see on these statistics.  https://developer.android.com/about/dashboards/ Data collected during a 7-day period ending on April 16, 2018.  Any versions with less than 0.1% distribution are not shown. Statistics I'm skipping the numbers for Android Jelly Bean and earlier (4.3 and earlier). The reason I left these out is due to the fact that there market share really does not matter anymore. And there are so many lines in these graphs that it is more clear this way. In case your app

Ruby + Cucumber is utilizing the Gherkin language so users can write scenario's and match them to actual scripts. The Cucumber + Gherkin combo is a widely used standaard among test automation engineers, but it has nothing to do with vegitables. So what is it? How to use it? And how to use it properly?/lessons learned. What is Gherkin (and Cucumber)? Let's start with the definition that is mentioned on the Cucumber(software) wikipedia page .  "Gherkin is the language that Cucumber uses to define test cases. It is designed to be non-technical and human readable, and collectively describes use cases relating to a software system." So not only do you write your test cases in a way even a non-technical person can read and understand what the test is actually doing. It can also be used as documentation. An example of how to write test cases using the Gherkin language you see in the picture of this post. This documentation on it's own does not execute anyt

Intro  In one of my previous blog posts, I talked about a high level view of the whole test automation setup . It happens quiet often that people that begin with test automation forget to install the webdriver or are working with an older version of the webdriver. So in this post I wanted to go over this specific part and show some examples when testing local, with selenium-grid or via appium. What are webdrivers? In short I'd say: "Webdrivers are the bridge between your test automation framework and the browser. It can mimic user behavior on the browser so that your test script perform actions like a user would do".  How does it work?  The high level view of the flow is very straight forward. Your test scripts talk to Selenium, Selenium talks to the webdriver of your needs, the specific webdriver talks to the browser. So this means you need all components. The browser, the browser specific webdriver, selenium and a program language that is supported

Intro Not long after I started to build the first set of tests for our single page web application, I noticed the time it took to run the tests started to increase quiet fast. I started to read about parallel testing, selenium-grid, which ruby gem I could use and that was all quiet interesting. Luckely I already wrote my tests to run independantly. For parallel testing you need to keep a couple more things in mind than just write independant tests and starting them, but I'll make a part 2 where I'll cover it more in depth. In this post I'll cover the basics for using PowerShell to trigger tests to run in parallel. Setup As mentioned in previous posts we make use of Visual Studio Online (VSO)as a build server and Azure VM's for our Selenium-grid setup. There are multiple ways to go at this, but we use the grid in the following setup. One hub, multiple nodes. The hub machine also has ruby installed and all needed gems. We use the lapis_lazuli gem for our test

Intro This is the first in a series of PowerShell blogposts. I don't know a lot of PowerShell so I'm going to cover this part very short. What is PowerShell? PowerShell is a very powerful framework you can use to automate tasks. For more info, use Google or check the Wiki:  https://en.wikipedia.org/wiki/PowerShell For my current project we use Azure VM's that we use as selenium-grid (hub and nodes). And Visual Studio Online for kicking off builds. So I started to use a fair share of PowerShell in my test automation process. During the setup I came accross a couple of problems that I want to share with you all which I'll spread across a couple of posts. And we start with Azure VM's that have a fixed resolution of 1024 x 768 and how to overcome this issue/limitation. Azure VM's resolution limitation  Let's start with the problem we faced. Our website under test, requires the test machine to have at least a certain resolution ( Which is > 1024

Recently our website application changed and with that change there was also a check for input fields that were not saved yet (dirtyflag). When you want to close the page while there is an unsaved change on the page, the browser will show you an alert with the options to Leave the page (and loose all changes) or Cancel (and stay on the page). This seems like a small thing to solve. But it seems like it's a bit more difficult to do something with this alert then I initially thought so I'll show you my case and why I needed a small workaround to make sure it was not breaking all my tests. My case I'm testing a one page application, which means I don't deal with a lot of url's. Actually I only have to deal with two url's. The application page https://application.domain.com and the login page https://application.domain.com/login. The disadvantage of a one page application is that you cannot use a url to go to a certain page within the application. You need to

The market share of the MS Edge browser is low. Just look it up on netmarketshare.com . But that doesn't mean it does not need to be tested. Especially since it will replace IE at some point in time. Therefore you also need to think about test automation. I had my fair share of ups and downs when it comes to testing on the Edge browser that I would like to share with you. The short summary is that MS Edge webdriver is not matture enough for test automation. But you can prepare for it. List of issues I faced Setup Ruby version 2.5  lapis_lazuli 2.1.3 Microsoft Edge 16.16299 Issues clicking elements - Check the zoom level First of all make sure the zoom level is at 100% since click events will otherwise fail. Not a big issue, you just need to set/check this once and you're done. More strict than others Context: With lapis_lazuli you can find elements within another element by using the higher element as 'context'. Since lapis_lazuli is basically

Recently I have been focussing on test automation with mobile devices. Specifically Android and iOS (no Windows phone because that platform is as good as dead at the moment). I first wanted to make a complete manual from setting up software and devices/simulators up to a small test script. But due to lack of time I'll focus on specific parts. If you have any questions reguarding the setup, feel free to contact me. So all that said, let's get to the point. The internet is full of blogposts, video's and examples of people testing mobile apps. However I don't test an app, I want to do some web test automation on mobile devices. It took me quiet some time to figure out what exactly I had to use to get it all to work as needed for my project. Setup Mac mini running OSX 10.13.4 High Sierra (Mac machine is needed for iOS simulation) Ruby version 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17] Appium desktop version 1.4.1 (with Appium server 1.7.2) lapis_laz