blog

Let's talk about cross-platform testing

Standard platform, operating system and browser recommendations (October 18)

This entry is part 16 of 16 in the series Standard Platform, Operating System and Browser Recommendations

Introduction

The following post updates our recommendations for platforms, operating systems and browsers to use when testing commercial web sites targeting consumers in Europe.

Our recommendations are based on usage figures widely available on the Internet, our experience and our analysis of client needs. Since browser versions change frequently, we review and update these recommendations regularly.

Continue Reading »

Standard platform, operating system and browser recommendations (July 18)

This entry is part 15 of 16 in the series Standard Platform, Operating System and Browser Recommendations

Introduction

The following post updates our recommendations for platforms, operating systems and browsers to use when testing commercial web sites targeting consumers in Europe.

Our recommendations are based on usage figures widely available on the Internet, our experience and our analysis of client needs. Since browser versions change frequently, we review and update these recommendations regularly.

Continue Reading »

Standard platform, operating system and browser recommendations (April 18)

This entry is part 14 of 16 in the series Standard Platform, Operating System and Browser Recommendations

Introduction

The following post updates our recommendations for platforms, operating systems and browsers to use when testing commercial web sites targeting consumers in Europe.

Our recommendations are based on usage figures widely available on the Internet, our experience and our analysis of client needs. Since browser versions change frequently, we review and update these recommendations regularly.

Continue Reading »

The 3 most common mistakes writing Gherkin features

In the past I’ve worked on many projects where they either used Gherkin to describe functionality or to be used for test automation. The following recommendations are useful for both usages.

common gherkin mistakes

1. Writing scripts in first person instead of third person

When starting with Gherkin, people quickly feel like they should describe the actions they are performing when going trough a functionality.

Wrong

Given I am logged in
When I delete a post on the blog
Then I should see a successful deleted message

The problem with the case above is that it’s not clear who this “I” person is. Is it an administrator, a moderator or a member? This is quite important information when reading Gherkin, so you can understand it quicker. This post goes more in-depth about why third person is better.

Right

Given the administrator is logged in
When the user deletes a post on the blog
Then a successful deleted message should display

2. Describing every action instead of a functionality

When writing Gherkin, it’s often seen as if you have to describe every action to get to the next step: Every click, every text input, web-page. But Gherkin is meant to describe a specific flow you’re going trough.

Wrong

Given the user is on "http://training-page.testautomation.info/"
When the user fills in "test" for username
And the user fills in "test" for password
And the user clicks on the login button
And the user clicks on the logout button
Then the user should be on the login page
And the avatar should not display in the right top

Right

Given the test user is logged in on the training page
When the user logs out
Then the login page should display as expected

When this scenario is used in functional testing, someone reading it will understand what is suppose to happen.

For test automation all the different clicks can be solved on a code level. Also, with the more functional description, it’s easier to group the code and repeat yourself less.

3. Using absolute values instead of configurable values

When writing Gherkin scripts, it’s always quick and easy to simply use the absolute values that you want to use. For example a username and password, or the values used in a registration form.

It’s best practise to move your absolute values to a configuration file, so you can set user information in a central place.

Wrong

Given the user navigates to "http://training-page.testautomation.info/"
When the user fills in "test" for "#login-username"
And the user fills in "test" for "#login-password"
And the user clicks on button "submit"
Then the page should display in logged in state

Right

Given "test-user" navigates to page "landing-page"
When the user logs in
Then the page should display in logged in state

So in this case the URL is moved into a configuration value called “landing-page” and the user credentials in “test-user”. If at any point in the future one of these values change, you’ll only have to change one configuration value with it.

Final word

When writing Gherkin scenario’s, ask yourself the following:

  • What is the goal of my scenario?
  • Is my scenario descriptive?
  • Can I use less steps to describe it?

Thanks for reading! – Gijs Pauldies, Test Automation Engineer

Standard platform, operating system and browser recommendations (December 17)

This entry is part 13 of 16 in the series Standard Platform, Operating System and Browser Recommendations

Introduction

The following post updates our recommendations for platforms, operating systems and browsers to use when testing commercial web sites targeting consumers in Europe.

Our recommendations are based on usage figures widely available on the Internet, our experience, and our analysis of client needs. Since browser versions change frequently, we review and update these recommendations regularly.

Continue Reading »

5 best practices for ecommerce testing during the holiday season

Black Friday and Cyber Monday have just passed for 2017, with online businesses continuing the annual trend of conquering more of the global market. This is a pretty predictable result, and highlights the need for retailers to make sure their ecommerce website is performing at optimal levels during the holiday season.

We’ve tested A LOT of ecommerce webshops over the years, so our team knows what they are talking about it when it comes to best practice. Here are some recommendations I collected from them about how best to prepare for a holiday deployment.

Continue Reading »

The impact of thermal throttling and low-quality texture on VR testing sessions

I have been involved with testing many VR and AR applications, and I can safely say that they all come with their own specific challenges when it comes to the implementation of software testing. To run a testing project in this field successfully and not interfere with development time, it is vital that technical issues that can arise with virtual reality applications are taken into account when planning test sessions. Today I will be discussing two challenges you’re quite likely to come across: thermal throttling and low-quality texture.

Continue Reading »

Which Android versions should I test on?

This entry is part 5 of 6 in the series Android

Android statistics chart

In the last Android statistics blog, I made the prediction that Android 7 would really take a larger market share. Obviously that was to be expected. We have seen Android 7 Nougat grow from 7.1% to 13.5% this month. It is not hard to predict that by November, Android Nougat will have reached a solid third place. What is still surprising to see is the slow decline of Android 4.4, losing only 2.8% in the last three months. Android 4.4 is already almost 4 years old, but still holds the third spot in size. So for testing, Android 4.4 still needs to be considered.

Continue Reading »

Do I really have to test on all those browser configurations? (Part 2)

This is part 2 of this article discussing the reasons why you should test your app or website on multiple browser configurations. Today we continue with browser functionality and the differences between devices.

How your product functions on different browsers

Ideally, the way your product functions would be the same on all browsers and operating systems. However this is often not the case, and is another scenario in testing where the end user experience needs to be taken into account when writing test plans.

The various components that make up a website or application such as HTML, CSS styles, Javascript and page layouts need to be tested across different browsers. The functionality of Javascript and page layouts in particular vary from browser to browser, as they express varying capabilities when implementing different features determined by your developer’s code. Although browser compatibility is becoming standardised, the continued usage of older browsers that are no longer being developed inevitably means that some features of your website will not work properly on every browser. This does not necessarily matter, as long as the core information is available to as many users as possible.

Continue Reading »

Do I really have to test on all those browser configurations? (Part 1)

One of the most common questions that our clients ask us is whether it is necessary to test on a multitude of browser configurations during cross-browser testing. It’s easy to drown in the choices that are available, making cross-browser testing a difficult process to handle internally.

Since the ultimate goal of test planning is to minimise the risk of high impact, high risk bugs interrupting your website or app’s performance, the easiest place to start is with your product itself and how end users interact with it. Considering the following factors will help you to make an informed decision about which browsers are worth concentrating on during your allocated testing time.

In part 1, I’ll discuss market share and geography and user preference.

Continue Reading »

Reputation. Meet spriteCloud

Find out today why startups, SMBs, enterprises, brands, digital agencies, e-commerce, and mobile clients turn to spriteCloud to help improve their customer experiences. And their reputation. With complete range of QA services, we provide a full service that includes test planning, functional testing, test automation, performance testing, consultancy, mobile testing, and security testing. We even have a test lab — open to all our clients to use — with a full range of devices and platforms.

Discover how our process can boost your reputation.

We use cookies to give you the best browsing experience possible. For more information, please read our cookie policy.

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close