The major pain-point with manual cross-browser testing is that testers might need to spend a significant amount of time testing different web pages, cross-browser testing web apps across different breakpoints on a growing list of ‘complex’ combinations. Hence, it is recommended that one round of manual cross-browser testing is performed in the Staging environment before the changes are pushed to the Production environment. Since the development branch would involve changes from multiple developers, you can expect another round of cross-browser testing on these changes, before they make way to the ‘prod/production server’. Though you might be following a ‘model for software development’, there are many activities that become unplanned/ad-hoc and manual cross-browser testing is often considered one of them. The Turnaround Time (TAT) for the resolution of bugs could vary based on the synergy between teams. TAT could increase if the teams indulge in blame games and this behavior can result in an overall delay. You cannot change human tendencies, but you can definitely ensure that processes are kept in place to improve the speed at which tests are performed without compromising the Turnaround Time.
Here are 34 ways to save time on manual cross browser testing.
- Code Linters
- Cross-Browser Testing after a significant development milestone
- CSS Prefixes
- Parallel Testing
- CSS Profiling
- Perform Cross browser testing on the Cloud
- Test, Test and Test at each stage
- Create a detailed test-plan
- Unit Testing
- Test Scripts
- Use Web Analytics To Figure Out The Most Preferred Browser
- Create a Cross Browser Compatibility Matrix
- Focus on tasks that yield more output
- Reusing components
- Testing using a ‘Humane Approach’
- Look for professional testers
- Crowdsourced Testing
- Fallback Mechanism for your users
- Use Breakpoints at relevant places
- Using a test harness
- Study the browser landscape for the target markets
- Utilize Simulators & Emulators
- Deploy the Continuous integration model
- Testing against a specification
- Work hand-in-hand with the testers
- Keep interactions as simple as possible
- Use a Framework (wherever possible)
- Simplicity in Design
- Consistency in content
- Capturing Screenshots With Automation
- Comparing Screenshots With Automation
- In-House testing
- Focus on Accessibility Testing
- Early focus on features related to Localization & User-experience
- CSS – CSS Lint, Stylelint
- HTML – W3C Markup Validation Service, HTML Lint, HTML Tidy
Along with the online option, you can also install plugins/add-ons of these linters to your code editors. Using an add-on option ensures that the linting is done in the premise of the development environment.
2. Cross-Browser Testing after a significant development milestone
3. CSS Prefixes
CSS Vendor Prefixes or CSS Prefixes are mechanisms through which browser vendors add new CSS features before these features become mainstream on all the browsers. If you want that your source code is supported on the latest browsers & older versions of those browsers, your CSS code should incorporate both, prefixed as well as unprefixed code. Using a tool like CSS Flexbox, you can generate new layout features. You have to provide the required prefixes and old syntax to the CSS Flexbox so that your code executes on browser versions where those prefixes are mandatory.
If you are adding the required vendor prefixes manually, there is a high possibility of manual error being introduced in the process. The best way to avoid such errors is by using tools/libraries that can add CSS prefixes automatically (wherever necessary). Some of the popular pre-processor libraries or tools are:
4. Parallel Testing
Irrespective of whether the testing strategy involves automated tests, it is a known fact that parallel module development/parallel testing will always be faster when compared to serial development/serial testing.
You can achieve parallel testing by developing test scripts that would allow cross browser testing of the source code across different browsers, operating systems, and devices. You can develop effective test scripts that can mimic human approach using Selenium WebDriver. We would have it covered in subsequent points.
5. CSS Profiling
We earlier discussed CSS Linting and why exactly you should use a Linting tool. Though Linting can help you identify mistakes in your CSS code, you should also use tools that do CSS Profiling. As a developer, you could be adding code to a CSS module that has a lot of legacy code. Larger the code size, the more difficult it becomes to identify the necessity of legacy code. The ideal way of handling this is by using !important CSS property which ensures that a rule would be applied irrespective of the location of a rule in the document.
There are a number of tools available for profiling the CSS code, but CSS Parker is the most widely used tool since it gives a lot of statistics about your CSS code.
6. Perform Cross Browser Testing on the Cloud
Setting up a testing infrastructure that can accommodate the combination of devices, browsers, and operating systems can be a costly affair and it might not be scalable as well. For example, if you have to test the website functionalities on different flavors of Android – Oreo, Pie, Nougat, etc.; you would need devices with these Android versions and you would also need to invest in procuring devices from different smartphone vendors. Hence, this approach is highly infeasible & non-scalable. An ideal approach would be to have the functionalities tested on Cloud testing services like LambdaTest, so that you can concentrate on the testing without being worried about the infrastructure. You can also write automated test scripts using Selenium by downloading the corresponding WebDriver for Selenium.
7. Test, Test And Test At Each Stage
Periodic Testing ensures that bugs are encountered at later stages of the development cycle. As a developer, you should test your functionalities against different combinations. Even though you are not comfortable testing your module, you should bring that mindset change and incorporate testing as a part of your routine.
If you are working on a complex functionality, you can divide your test plan into different stages so that there is no dependency. You can also make use of tools like CodePen – a social development platform for front-end developers. It can be used for prototyping your test cases.
8. Create A Detailed Test Plan
You would be cross browser testing your source code against various combinations of devices, Operating systems, browser types, screen sizes, etc. Hence the nature of issue you encounter on one version of Browser type (e.g. Chrome 59) can be significantly different from the ones you face on a different version of same Browser type (e.g. Chrome 60). Things can get complicated when you have the same browser type on different operating systems and devices. Hence, an ad hoc approach to testing might not be sufficient in this case.
You should come up with a detailed test plan so that the important functionalities of your code are tested on different combinations. You can formulate a test plan based on each device group so that you can easily segregate issues encountered on each device.
9. Unit Testing
It is said the development & testing should go hand-in-hand so that bugs are unearthed at an early stage of product development.
10. Test Scripts
Unit Tests are performed at a ‘unit level’, whereas Regression Tests are performed keeping in mind the end-to-end functionality of the product. Regression tests are ideally done to ensure that the new code changes have no side effects on the existing functionalities.
11. Use Web Analytics To Figure Out The Most Preferred Browser
Based on the initial market research and the customer market-segment, your management, as well as the development team, would have information about the expected user-segmentation. They would also have information about the browsers on which more testing should be performed (since the majority user base using your product could be using that browser). You can also use web analytics tools to pinpoint the browsers that are responsible for the majority of your traffic.
As a developer, you would want your code to work seamlessly across all browsers; but you cannot dedicate equal time to each browser (during development & testing). Hence, you come up with a detailed plan on how to test the functionalities on browsers that would be used by your customer segment.
12. Create a Cross Browser Compatibility Matrix
Once you are done with analysis of the browsers responsible for bringing traffic for your website then it is time to prioritize those browsers by classifying them as explained below:
- Fully supported and mostly loved browser.
- Fully supported and not so favourite browser
- Partially supported but loved browser.
- Partially supported and not a favourite browser.
- Unsupported but a favourite browser.
- Unsupported and non-favourite browser.
Cross browser compatibility matrix will help you realize the browsers that should never miss out while performing cross browser testing. It will also help you reduce the testing effort by giving you the clarity about the browsers that aren’t providing results, as good as you expected them to be. With cross browser compatibility matrix you can plan a more effective cross browser testing strategy.