Transcript
Writing automated tests that run perfectly against one environment is challenging in and of itself. But what about when you’re ready to scale your one suite of tests to run in multiple environments, browsers, or devices?
In this chapter, we’ll discuss the considerations for scaling your test automation projects.
# Multiple environments
At some point in your automation journey, you may find the need to run your automated scripts on different environments. However, you may find that different environments have different information – such as the IP address or URL, the login credentials, and the database information.
For this reason, it’s best to extract out these sorts of details within your automation project and make use of artifacts like properties files. Even during your early phases of automating for a single environment. Making these considerations early will prevent you from needing to refactor later. With the use of properties files, you can focus on the content of the test versus coding multiple conditional paths.
Managing test data and all other artifacts needed for test automation also becomes more challenging when running across multiple environments. Fortunately, solutions such as containerization help mitigate some of this burden.
# Cross-browser
Even if executing on the same environment, there may be a need to execute your UI tests across multiple browsers. This is one of the benefits of automating tests – so that your testers do not have to repeat the same tests over and over on various browsers and their versions.
However, managing these browsers becomes a new task for your team. Give this serious consideration and determine if testing on a select few browsers is sufficient. If the risk is too high, consider using cloud solutions that have an array of browsers of all different versions readily available to run against at any given time.
# Multiple devices
In today’s world, users tend to access applications from all types of devices. This is another factor to consider when developing your tests.
Similar considerations to the cross-browser testing need to made for device testing. Will you create and maintain your own device farm or is it more feasible to use a cloud based service for this?
You’ll also need to consider your test code as well. Do your UI-level tests work when your application is in responsive layout? Some of the elements are replaced with mobile-friendly ones. Your test code should be able to handle this.
How about for native mobile applications? Can your automation suite run for both iOS and Android? Do you need to write two different automation projects to support each of these? This poses an interesting problem. There are libraries, such as Appium, that support writing the test automation once and having it run against different mobile operating systems. However, if you anticipate your developers helping with test automation, which language should this be written in? If you have two unique native apps, where your iOS developers are writing in one language and your Android developers are writing in another language, there is no common denominator here.
Also, if your native mobile applications are distinctly different – meaning different features and different navigational paths, how will you conquer this within your test code?
These are critical decisions that need to be made early on so that you don’t go down the path of automating for one of these devices and then being unable to later scale it to run against others.
