These updates will be deployed on Monday Feburary 14th, 2022

Here at Ghost Inspector, we’re continually rolling out changes that we think make our customer’s lives better. Occasionally that means undoing some bit of logic we created or allowed in the past in order to move the product in a direction that makes it more powerful for everyone.

We have a couple of changes coming next month that we think are going to be helpful to our customers, but they do change how some logic currently works. We want to make you aware of those changes and have outlined them below. Additionally, with regard to the variable name and AWS CodePipeline changes below, we’ll be reaching out to customers directly who we believe will be impacted by these changes and helping them to adjust ahead of time.

Variable names that match reserved parameter names

Ghost Inspector variables are a super useful and flexible tool for customizing and storing data on the fly in your tests. In general, we’ve left the naming of variables open-ended and you can use any names that you’d like. If you’ve executed a test or suite using our API before, then you know we offer a number of parameters for customizing things like browser and region (geolocation) on the fly. When one of those reserved parameter names is passed into the API, we also apply it as a setting to the test. For example, passing in a region parameter to a test run will both create the region variable and it will also override the “region” setting of the test run.

This behavior is not currently consistent for variables defined in the organization’s settings, suite’s settings, or within data sources. We’re going to update the system so that it becomes consistent. Currently, if you have a variable named region in your suite settings or within a data source (whether that be a data source stored in the service or a CSV file that you upload), it will only be created as a variable in the test run. It will not override the “region” setting of the test run. We’re updating the system so that the setting override will occur. This will make the logic consistent with the API and open up a really useful option for test settings to be customized in different ways within a data source. For instance, you could have a browser column in your CSV file that specifies which browser version should be used during each test run.

If you are using any of the 3 variable names below, and you do not want the behavior described above, simply rename the variable to something else to avoid the collision.

For instance, instead of using a variable named region, you could use regionName or testRegionIf you are using these variable names and do not make this change by February 14th 2022, your tests could begin running with unintended browsers, geolocations or screen sizes.

AWS CodePipeline geolocation settings

When we launched our AWS CodePipline Integration years ago, we set up the logic to automatically run your tests in the same AWS region (geolocation) as the pipeline that triggered them. This meant that if a pipeline running in Dublin, Ireland (eu-west-1) triggered a suite of Ghost Inspector tests, our system would automatically run them from the same Dublin, Ireland geolocation on our end. Neat!

While this was a nice bit of logic in theory, it now presents a challenge because it overrides the geolocation settings that the user has chosen for their test or suite. This makes it difficult for a user to execute the test or suite outside of the geolocation where the pipeline is being triggered. It requires them to override our region matching logic with a custom override parameter of their own, which isn’t very user friendly. In short, we’ve realized that this default behavior isn’t actually convenient.

As a result, we will be dropping this behavior and simply running the test or suite using the geolocation defined in its settings. The region matching behavior will instead be “opt in” which you can do by adjusting the settings of the test or suite, or by adding the custom geolocation parameter yourself in the pipeline.

Old browser versions

The two browsers that we currently offer for test running, Chrome and Firefox, have had auto-updating capabilities for years now. This means that pretty much every user out there is running the latest, or near latest, version of the browser on their system.

We’ve been maintaining a lengthy backlog of old Chrome and Firefox versions for a number of years now but what we’ve found is that practically none of our customers are using anything beyond a few versions back. This makes perfect sense because you’re ultimately interested in testing from your users’ perspective, and at this point no “real” user is going to be out there navigating your website using Chrome v68 from 2018 unless they’re really jumping through hoops to do so.

With that being the case, we are going to transition to a scheme of maintaining the latest 10 versions of each browser. The ultra-low usage of older browser versions coupled with the resource requirement of maintaining them makes this an obvious choice. We can use those resources to bring you new and better options in the future. If you have tests set to use a browser that is more than 10 versions behind, those settings will be automatically incremented when we roll out new browser versions. The one exception is that we will maintain the “Firefox v60 (Legacy)” option for a short time longer for customers who are still using it for specific purposes.

That’s everything! Please feel free to reach out to us if you have any questions or concerns about these upcoming changes.

Upcoming Feature Changes — Q1 2022

These updates will be deployed on Monday Feburary 14th, 2022 Here at Ghost Inspector, we’re continually rolling out changes that we think make our customer’s lives better. Occasionally that means undoing some bit of logic we created or allowed in the past in order to move the product in a direction that makes it more […]

Test Management with QADeputy & Ghost Inspector

Test Management with QADeputy & Ghost Inspector

Quality assurance is a broad initiative. Ghost Inspector strives to be an all-in-one tool when it comes to browser automation. However, QA teams often use a range of products to cover all their testing needs, like API testing and load testing. This can lead to testing-related data being scattered in various places. QADeputy is a service that […]

Browser & System Updates — July 2019

Browser & System Updates

These updates will be deployed at 10:00am Pacific Time on Tuesday July 16th, 2019 Here at Ghost Inspector, we’re continually rolling out new browser versions and automation logic updates. However, this month we’ve got a number of big changes launching at once and I wanted to discuss each in a little more detail. Here’s a […]

Headless Browsers and Testing at Scale

Headless Browsers and Testing at Scale

The Ghost Inspector team got together for our annual company offsite in Austin, TX this year. We always plan our offsite around presenting at an industry-related event. This year we were thrilled to present to the Austin Automation Professionals Meetup on the topic of headless browsers and testing at scale. A big thank you to Handsome for hosting the […]

CSS Selector Strategies for Automated Browser Testing

CSS Selector Strategies for Automated Browser Testing

“Change breaks the brittle.” — Jan Houtema I love this quote, though I’m not quite sure if “Jan Houtema” is a real person. It may be a Paul Graham pseudonym… But in any case, yes, change breaks brittle things and one of the challenges of automated browser testing is to mitigate that effect as much as […]

Where Does End-to-End Testing Fit into a Comprehensive Testing Approach?

Where Does End-to-End Testing Fit into a Comprehensive Testing Approac

Every type of automated testing has a maintenance tax. Everything from simple unit tests up through end-to-end tests that are performed on the GUI of your application. Of course this tax rate varies depending on the complexity of the test. For unit tests (which typically deal with a small, isolated piece of functionality), the tax […]

Simulate Drag and Drop with JavaScript and CasperJS

Simulate Drag and Drop with JavaScript and CasperJS

We use a number of browser automation tools here at Ghost Inspector including CasperJS — which is a handy wrapper for controlling operations in PhantomJS and SlimerJS headless browsers. Today I’m going to present some JavaScript code that can be used for simulating drag-and-drop events in a browser. This can be used as standalone code, or you can call it through […]

Selenium Import is Here!

Selenium automated testing with Ghost Inspector

Yes, you read that correctly! Selenium is a popular, open source browser automation tool set — and for a while now, Ghost Inspector has allowed you to export your tests in Selenium’s HTML format. Now, Ghost inspector allows you to import tests in that very same format. The benefits of this new functionality are two fold: One, […]

Automated Browser Testing During Continuous Integration with CircleCI and ngrok

Automated Browser Testing During Continuous Integration with CircleCI and ngrok

Note: this article relates to CircleCI 1.0 configuration which is scheduled to be sunset on August 31, 2018. Documentation for integrating with CircleCI 2.0 can be can be found in our Integrations documentation. One question we receive a lot is how to run your Ghost Inspector automated browser tests on your application during the continuous integration process. We’ve put together a […]

5 Best Practices for Automated Browser Testing

Automated Browser Testing During Continuous Integration with CircleCI and ngrok

Automated testing entails much more than simply creating tests and enabling them. A “set it and forget it” approach won’t get you very far with automated tests — particularly automated browser tests, which interact with the ever changing frontend of your application or website. The true workload ultimately comes with the maintenance and evolution of […]