One of the major hurdles that web developers, as well as 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.) which 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, 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 with which you can use ro 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 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 whereever 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 Brrowser (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 the 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 performedwhile 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.

That's all for Part 1! Tune in tomorrow when we'll cover topics such as reusing components and crowdsource testing.