DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Languages
  4. 34 Ways to Save Time on Manual Cross-Browser Testing

34 Ways to Save Time on Manual Cross-Browser Testing

In this article, we discuss the many methods web devs should be aware of for testing their applications for cross-browser compatibility, such as linting and unit testing.

Harshit Paul user avatar by
Harshit Paul
·
Aug. 29, 22 · Analysis
Like (11)
Save
Tweet
Share
12.55K Views

Join the DZone community and get the full member experience.

Join For Free

One of the major hurdles that web and app developers face is testing their website/app across different browsers. This is also called "Cross-Browser Testing."

There are so many browsers and browser versions (Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera, Yandex, etc.), numerous ways in which your website/app can be accessed (via desktop, smartphones, tablets, etc.) and numerous operating systems (Windows, macOS, Linux, Android, iOS, etc.) that might be used to access your website. Ensuring that your website’s UI/UX and its functionalities work without any flaws on the combination of ‘Browsers + Browser Version + Operating Systems + Device Profiles’ would involve numerous man-hours for development, testing, and maintenance. Though testing might include automated cross-browser testing, you would always prefer to have a round of manual cross-browser testing before the final release.

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, and 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 their 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.

Let’s have a look at some of the mechanisms/processes which you can use to improve manual cross-browser testing.

1. Code Linters

Irrespective of the development language being used, it is important you lint your source code with static analysis tools. You may not be in a position to identify coding errors by just glancing through your code; hence it becomes necessary that you execute your source code against static code analyzers, also called Linters. Linters help in saving the manual effort for validating the cross browser compatibility of HTML, CSS, and JavaScript, plus you have the flexibility to either use online tools or linters installed on your local machine. Before using online linting tools, it is advisable that you discuss this with your manager since you would be uploading the code on the server (where the online linter will statically analyze the source code).

Some of the popular Linters for CSS, JavaScript, and HTML are:

  • CSS – CSS Lint, Stylelint
  • JavaScript – JSHint, ESHint
  • 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 development environment.

2. Cross-Browser Testing After a Significant Development Milestone

Take a hypothetical situation – You have a module that comprises 50+ CSS, JavaScript, and HTML files and have come across a cross-browser compatibility issue with the module. Would identifying an issue in such an environment be different than finding an issue in the same module where you have changed 100+ LOC (Lines of Code)? Any developer would vouch for the second option since you are aware that the change (of 100+ LOC) has caused the break in the functionality. Once you added the code changes, you should test the changes on browsers that your ‘intended customers’ might be using. Based on your internal research, you can test on the latest browser versions or test it on a version that is used by your target customer segment.

Once you have fixed a lot of bugs, you should follow one complete round of cross-browser testing. Though, this approach depends a lot on the timeline of client deliverables and the nature of the product; having cross-browser testing at an early phase of product development can reap rich dividends at later stages of testing and development.

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 and 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 into 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:

  • Sass – http://bourbon.io/
  • LESS – http://lesselements.com/
  • PostCSS – http://postcss.org/
  • Autoprefixer – https://github.com/postcss/autoprefixer

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 the 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 the !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 lot of statistics about your CSS code. More details about the Parker tool can be found here.

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 flavours 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 and 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 found wherever they enter into the SDLC. 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 testing 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 a browser (e.g. Chrome 59) can be significantly different from the ones you face on a different versions of the same Browser (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

The term ‘unit testing’ needs no introduction. It is used to test the changes that have been made by the developer at a ‘unit level.’ Irrespective of the programming language being used, unit testing is used to verify code changes at a unit level. In order to bring that culture of ‘thorough testing,’ the focus should be on Test Driven Development (TDD). By incorporating the TDD approach, developers and designers can come up with beautifully crafted code. It also involves a mindset change. JavaScript has an exhaustive set of libraries that can aid unit testing, the popular ones are listed below:

  • Mocha – https://mochajs.org/
  • Jasmine – http://jasmine.github.io/

It is said that development and testing should go hand-in-hand so that bugs are unearthed in the early stages of product development.

10. Test Scripts

Unit Tests are performed at a unit level, whereas regression tests are performed while 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.

There might be some cases where there is a visual element involved in the functionality, e.g. a button click using JavaScript. There could also be cases where there is no update on the interface, e.g. updating some field in the database once a button is clicked. Hence, it is recommended that test scripts are developed and maintained on a timely basis and test scripts should be grouped per their priority.

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 and testing). Hence, you'll need a detailed plan on how to test the functionalities of browsers that will be used by your customers.

12. Create a Cross-Browser Compatibility Matrix

Once you are done with the analysis of the browsers responsible for bringing traffic to your website, then it is time to prioritize those browsers by classifying them as explained below:

  • Fully supported and loved browser.

  • Fully supported and not so loved browser.

  • Partially supported but loved browser.

  • Partially supported and not so loved browser.

  • Unsupported but loved browser.

  • Unsupported and non-loved browser.

Cross-browser compatibility matrixes will help you realize the browsers that should never skip over while performing cross-browser testing. It will also help you reduce the testing effort by giving you some clarity about the browsers that aren’t providing results. With cross-browser compatibility matrixes, you can plan a more effective cross-browser testing strategy.

13. Focus on Tasks That Yield More Results

Browsers are a piece of software and, like any other software, they have bugs. Browser companies periodically fix the bugs and they are pushed to the users via an update. There could be a possibility that the bugs being fixed may not be of high severity or the changes might not have any impact on the functionalities that are being implemented by you.

Since there are many operating systems, you should make a conscious decision as to whether testing should be done on the same browser across different operating systems. If the browser changes across those operating systems are trivial, you can skip the test.

Hence, when performing manual cross-browser testing, you should focus on the tasks that yield better output, rather than focusing on tasks that are repetitive in nature.

14. Reusing Components

 From the beginning of the project, you should keep a track of the tools and components that are used for development and testing so that there is no duplication.

You can also use a tool in order to create a shared repository of elements that are being used by your project.

15. Testing Using a ‘Humane Approach’

Along with unit tests and regression tests, you will need to execute functional tests which more or less mimic the testing from an end user’s perspective. In order to get the best out of these tests, you should come up with an automated approach to testing.

Selenium is a popular software testing framework for web applications and there is extensive support for it. WebDriver and NightWatch are popular JavaScript wrappers around Selenium Webdriver. 

By writing test cases using Selenium, you can automate button clicks, scrolls, the filling-in of text fields, etc. These are some of the real-time scenarios that will occur during the web-development cycle. Another advantage of performing these tests is the ‘interaction’ that is involved with your fellow team members. These tests are not done in a vacuum and, hence, you as a developer get an opportunity to interact with and discuss issues with fellow testers and developers in your team.

16. Look for Professional Testers

White-box testing is a specialized skill and you need to think like a developer to test the product features. Though developers can do unit testing of their modules, they should never perform end-to-end testing since their mindset might be biased and they may not have complete clarity on the test specifications. Hence, any manual cross-browser testing should be done by professional or qualified testers since they can unearth the bugs in your product.

17. Crowdsourced Testing

In case you are unable to find testers internally at your organization, you can make use of crowdsourced testing services. In the case of crowdsourced testing websites, you can choose the testers who suit your criteria. Depending on the nature of the product, you can get an NDA (Non-Disclosure Agreement) signed by the tester so that confidential information about the product is protected.

More and more companies (of a different scale) are making use of crowdsourced testing since it has good cost benefits.

18. Fallback Mechanism for Your Users

As a developer, you might be up-to-date with all the latest technologies, but there is a sizeable number of people who are still hung up on old technologies (or browsers). Based on your product market research and intended target audience, your product should incorporate a fallback mechanism for features that are not supported on old browsers. For example, have a fallback mechanism for video playback in case your web browser does not support Flash.

19. Use Breakpoints at Relevant Places

The definition of a breakpoint depends on whether it is being looked at from a developer’s perspective or from a designer’s perspective. For a developer, a breakpoint is a media-query; whereas, for a designer, a breakpoint is a point when there is a change in the presentation of the content. It is recommended that you follow the mobile-first approach for design, development, content, etc. The whole intent of breakpoints is to have a web page whose content adapts to the screen resolution of the device from where the page is viewed. This is normally accomplished by adding browser widths in media query declarations.

When should you add a breakpoint? You should add a breakpoint when your content is difficult to read, e.g. when the screen is wider. There is no ideal number of breakpoints, but you should use them judiciously in order to adhere to responsive web design principles.

20. Using Test Harness

In the point ‘Reusing components’ above, we discussed the importance of keeping track of the tools and resources that are used for development and testing. You can use that information to create a test harness setup. A test harness is an automated test framework that is used for testing software/code against various kinds of test data. The test is performed under varying conditions, such as variable CPU load. The test results are captured and compared.

A test harness should be designed in a modularized manner so that components are loosely coupled and can be re-used across different teams (and projects). JUnit is one popular unit-testing framework that can be used to create a test harness setup.

21. Study the Browser Landscape for the Target Markets

In our last article, we discussed the importance of testing on browsers that really matter, i.e. browsers that are more prevalent. Hence, before you start designing and coding your website/web app, it is important to have a look at resources like CanIUse which outlines features that are supported on different browsers. For example, you can check whether CSS Grid Layout would work on Safari or not. It is a good starting point to know your target audience and develop features that keep your target audience in mind.

You need to make a call about the supported browsers (and their respective versions) and prioritize the features development and testing according to those findings.

22. Utilize Simulators and Emulators

Your source code could execute perfectly fine when it is tested as an ‘independent module,’ but its thorough test occurs when it is tested as an end product and in varied conditions (e.g. latest browser, unsupported browser, etc.). It requires heavy investment to have a lab that can house all the products on which testing can be performed; hence it is a non-viable option.

This is where cross-browser testing can come to your rescue. Alternatively, you also have the option to use VMs (Virtual Machines) where you can install specific browser versions. From a scalability and reliability point of view, cloud-based testing is a preferable option. This will help you realize how your website will be accessed from numerous devices.

23. Deploy a Continuous Integration Model

Continuous Integration is a dev process where a build is triggered as soon as a developer pushes code. You can also integrate testing in the continuous integration process, in which case the module test and full-functionality test would also be triggered once the build is successful. Such a process ensures that your code works as per the intended functionality in different scenarios.

Many large-scale organizations use Jenkins, a leading open-source automation server that provides a number of plugins for build, deployment, and automation.

24. Testing Against a Specification

What if you could automate layout tests across different browsers as soon as you come up with the layout specs? This is possible by using a framework like the Galen Framework, through which you verify the relative positioning of the elements in a layout.

The Galen Framework is a great resource that comes in handy when you want your website/web app to adhere to the principles of responsive design. By making use of such a framework, you can unearth design issues at a very early stage of product development.

25. Devs Working Hand-In-Hand With Testers

In one of our earlier points, we discussed the importance of having ‘proper communication’ between the developers and the testers. Developers should also be actively involved in the end-to-end testing phase and suggest test cases to their fellow testers (in case they missed some test cases).

Similar to the concept of pair programming, developers can pair with testers (who would be responsible for testing their functionalities) and create an environment that is more conducive to learning.

26. Keep Interactions as Simple as Possible

As an end-user, you want the product that is being developed to be user-friendly and easy to use. Adding too many components to a web page can lead to a confusing design, hence you should add design features that do not add complexity to the product.

There could be scenarios where a race condition is encountered in the source code, i.e. an async operation where the output is largely dependent on the timing of events. Race conditions or deadlock situations are common in web development environments where a number of requests are being processed and concurrency is not being handled in the code. In order to avoid such race conditions, you can make use of the async utility module for JavaScript which is instrumental for coordinating async requests in your website/web app.

27. Use a Testing Framework (Wherever Possible)

As a web developer, you should be aware of the pros and cons of using a CSS framework like Bootstrap. Once you are aware of the framework in detail, you should decide whether utilizing the framework can speed up the cross-browser testing process.

It is recommended that you consult with other teams who have used Bootstrap or other CSS frameworks so that you can incorporate those learnings into your project.

28. Simplicity in Design

In one of our earlier points, we touched upon the importance of keeping interactions simple and adhering to responsive design principles. The same thumb rule also applies to product development. You should keep the ‘design’ simple, yet effective, and ensure that the design does not confuse the end-users. You should always design keeping the end user’s perspective in mind.

29. Consistency in Content

You have probably come across many scenarios where content on a web page looks perfect in portrait mode but looks messed up in landscape mode (or vice-versa). This is called 'content variation' and it is critical to maintaining consistency in the test content.

You can make use of the Faker JavaScript library in order to produce fake data so that you do not have to go through the pain of coming up with (consistent) content for testing the functionalities.

30. Capturing Screenshots With Automation

‘Screen Grab’ functionality can be used for verification of the rendered output, an important part of the Image Regression test. The whole methodology is very simple – a screen grab is taken during the execution of a particular functionality and image diff algorithms are used to verify the difference between the quality of the screen grab and the expected output.

31. Comparing Screenshots With Automation

Now that you have captured bulk screenshots over various configurations, it is time to compare and notice the UI deviations. However, comparing an anchor image with other images by scrolling all the way to the bottom of the page for numerous pages can be a very time-consuming and faulty process. Kudos to cross-browser testing tools that have made the task far easier and quicker. 

32. In-House Testing

In a few earlier sections, we touched upon the importance of having efficient and experienced testers who can unearth bugs. In many scenarios, the turnaround time involved in reporting bugs can increase in case there is a lack of communication between different teams involved in product development and product testing. This may result in project delays as well.

Hence, many organizations (irrespective of their size) are now looking for in-house testing teams so that there is better communication and a smaller turnaround time.

33. Focus on Accessibility Testing

If your product also appeals to people with disabilities, e.g. color blindness, hearing impairments, etc., it is recommended that the test specification covers test cases that cater to ‘accessibility testing’ as well. Testers who would test the product from an ‘accessibility perspective’ should have clear knowledge about the test cases so that even corner test cases can be verified.

34. Early Focus on Features Related to Localization and User-Experience

Manual testing is apt for the verification of features that are tightly coupled with the user experience. The early focus should be laid on user-experience testing and the same should continue over the different phases of product testing. Even though automated testing saves time and effort, it can never be considered a replacement for manual testing.

If your product has localization features, e.g. website content is displayed in the Mandarin language for Chinese customers, it is critical that these features are tested once the product reaches a certain stage of maturity. If those issues are unearthed later, it would become a burden on the product and development teams.

unit test CSS

Published at DZone with permission of Harshit Paul, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Was the Question Again, ChatGPT?
  • Implementing Adaptive Concurrency Limits
  • How to Deploy Machine Learning Models on AWS Lambda Using Docker
  • How To Avoid “Schema Drift”

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: