Responsive UI’s are the basic requirement for any web application, the whole user experience aspect is driven through responsive UI. Selection gets huge with multiple devices and the number of browser combination. Foldable smartphones are not making it any easy, the challenge only gets bigger.
At the moment most of the responsive testing is performed manually by the team, however there are few emerging tools to support the visual regression. They are not quite there yet. When it comes to responsive testing its good to consider few points before jumping to action.
#1 Business Decisions
Not all applications are meant to work across all devices or browsers. Enterprise solutions, Creative applications which deal with high density images, Safety critical solutions etc. are always recommended to be interacted with desktop/laptop browser unless these applications are specifically built as apps.
Applications from domains like gaming, betting, e-commerce , trading , healthcare, banking etc are in high demand to be accessible from any device. On a generic note most of the B2B applications are not flexible over devices or browsers. Where as in B2C applications the customer base is wide spread, it demands high flexibility in accessing the application from any device or browser. Imagine an e-commerce website forcing you to use specific browser for best experience( i probably wouldn’t invest my time shopping there).
Meanwhile, if you are in start up environment or if the business is undergoing a digital transformation. Having a clear vision of what browsers or device support the team will be providing saves lot of time. However, this decision should be driven by the business. Set the expectations clear to the development team/s. The UI/UX colleagues will work in the designs as per the expectation and the development teams can develop and test accordingly.
#2 Customer usage statistics
Businesses driving responsive UI as frontline activity, have higher pressure of keeping up the best in class action across devices and browsers. Delivery cycles gets heated up as the features delivered grows. Test team will be under constant duress for test coverage.
Such team should always lean on analytics tools to gather the information to take right decisions. All tests need not be performed on all viewports, check the customer usage statistics. It is even better if the business is able to track the customer usage of each feature. It gets easier to make informed decisions regarding the browser and device spread.
#3 Automation trap
Test teams lean back on functional automation to arrest the regression effort it’s a great strategy. However, functional automation run across different browser makes least impact in terms of responsive testing. Business functions will behave same across browsers, what gets affected on browser or device change is only how the UI is rendered.
Visual Regression tests are the right set of tests to be performed for the responsive checks. Avoid executing functional tests on multiple browsers, rather segregate the tests according to the test goals.
Having said that, interoperability tests should still be performed on various combinations of frontend and backend versions.
#4 Planned Checks
The test strategy should speak the flexibility in test planning. The tests planned for every sprint is solely dependant on the stories/features the team is planning to deliver. Responsive tests need not be performed every sprint, if there is no new code introduced. Application should pretty much behave the same. Reduce the unnecessary test time spent on unmodified code.
Leave a Reply