You can write as many cases as you want, but it won’t be enough to replicate the live production environment. It’s not easy to reproduce customer data or predict their behavior. Not to forget, your staging environment may not be exposed to as much live-traffic as your production environment. Similarly, if your staging environment is not an exact clone of your production(which is true for most cases!!), then there is a good possibility that you may miss a cross browser incompatible CSS property while going live, or worse, a bunch of them.
Which is why cross browser testing in production becomes indispensable for every release cycle. However, to test your web-application over hundreds of browsers + operating systems if not monotonous would certainly be exhausting. A lot of times, you may even end-up performing browser compatibility testing at the 11th hour due to an overnight hotfix for an outage urgency and lack of time, consequently, you may end up doing just smoke testing instead of regression. Well, if that is the case, you can pretty much expect a browser bug coming your way.
Let’s take a real-time scenario to understand this better. Your DevOps team has prepared the pipeline to deploy the latest code changes into your web application. And it’s up to you to test them in multiple staging environments before it finally goes live in the production environment. While in staging you test it across all the major browsers, let’s say all the latest versions of Google Chrome, Mozilla Firefox and others rolled out across the last year. You do a quick smoke test, and everything seems to work fine. Your web application goes live and you just sit back and relax thinking that everything is done and dusted. And thus the days go by!
Do you see what’s going wrong in the above case? You guessed it right! You clearly missed old versions of the browsers, now all of your users in the old version might be going nuts. They’re leaving your web application, the number of outage tickets soars high.
To tackle this issue, you need to make sure you have the Selenium test automation suite ready to be executed on our online Selenium Grid with zero downtime. Using an online Selenium Grid to perform automated browser testing in production can help you clear a major hurdle of time-spent over the maintenance of your in-house Selenium Grid, individually testing functionalities of your web application across different operating systems/devices/browsers. This helps you to ensure that you validate your product’s cross browser compatibility in the production.
Long story short, you can’t afford to neglect Selenium test automation in production.