Automated testing – keeping the smoke inDevelopment
Websites and web-based applications are key to almost all businesses. The constant stream of updates for security, new patches and the addition of new functionality can put a significant load on limited personnel to ensure these resources are always available and working correctly for clients and staff.
The solution is to have a set of automated tests that can quickly verify key areas of functionality.
These are some of the tools we use at Breadcrumb to help keep some of our clients up and running using automated testing.
It is ideal to make sure that we have at least a test environment available that is a recent copy of the production one. This way we can make sure that we minimise the chance of any business interruption. It also is a great place to look at potential changes before sending them live.
Kinds of tests
Just like automated tests for non-web based applications, it’s almost impossible to test every feature, function, and scenario for your websites or applications. We concentrate on two different test types.
1. Smoke tests
Here we’ll concentrate on just critical business functionality. Is the home page there? How about our products? We may even want to purchase a small value item to check that our web store is working properly. For the curious, the term ‘smoke test’ comes from the hardware side of computing, and electronics repair. If your newly fixed/created equipment is plugged in and turned on, you check that you don’t see smoke (or flames). See also Magic Smoke.
2. Functional tests
Here we’ll build up a more comprehensive list of tests for as much of the functional areas of our site or application as we have time to create. This is a lot easier if we have requirements, user stories or other artifacts to help us. Ideally we’ve been able to build these during the development of the site in the first place.
Over time we may well add new tests as functionality changes, or we encounter issues we would like to incorporate in our test cycle to make sure it doesn’t re-occur (often called regression tests).
Browserstack is a great way to help with the problem of testing on the multiple device and browser combinations available. If you have specific in-house device standards, you can make sure you’re covered. The use of simple-to-configure proxies allows the testing of web-based content that is only available on an intranet. Browserstack even has a good selection of real devices you can use remotely, allowing you to check that the site looks good on the CEO’s new iPhone XS before go-live.
Selenium is a library that supports code connecting to a local (or remote like Browserstack) browser and automating behaviour. It supports code written in several languages; in our case we use C# so we can also incorporate other tests that connect directly to Microsoft Office 365 or Azure infrastructure. There is a wealth of information available in the documentation on both the Selenium and Browserstack sites that can help you along your journey.
While it’s certainly possible to run your tests from a laptop, it’s preferable to have a stable location to run daily tests. Breadcrumb employs an automated build and release pipeline in Azure DevOps to build the code and automatically deploy it to an Azure VM.
Azure App Services are also a good possibility here, but don’t offer the same flexibility with other installed utilities and services if that’s a requirement.