It is hard fact that we are living in multi-screens and multi-devices era of the web and mobile applications. Unlike earlier desktop only designing, we have to design UIs for cross-platforms and cross-browsers. Designing itself is not tough as we know how to go responsive well now. The real issues arise when we are going to test our website or mobile application for a release.
Today, I shall restrict up to website designing and testing leaving mobile application for next time so my target is responsive web design. Few years back, we have to consider testing our website on five to six browsers on the desktops including Windows and Mac PCs. Unfortunately, today we have to test on nearly 15 browsers and numbers of mobile devices including tablets along with smartphones of various sizes.
Testing Tough & Costly
Therefore, testing is not only time-consuming, but also costly affairs for small start-ups or even seasoned freelancers. Hardware fragmentation is at its peak and we have numbers of mobile devices to test the responsive website. It is true that we can’t cover entire our audience with profound testing as possessing numerous devices is a nightmare even a big web development company.
Think of Smart Testing
In short, you have to forget the complete testing on all the devices your target audience is using. Instead, if you have a solid testing strategy, you can cover majority of population of your targeted audience. In other words, you should be smart enough in testing and cover sizable audience with least investment of time and most importantly money on purchasing real testing devices.
Based on such similarities and peculiarities of browsers as well as devices, we can group them in a logical manners and can give them priorities according to our website and our targeted audiences. Unfortunately, each website is unique and have unique audience as no business is same in the market, we have to carve browser groups each time for each new project. Based on my experiences, I can say that it is not much difficult to get mastery over time.
As per my strategy, I sometime test only 50% browsers and release the website. Afterwards, I test rest of browsers and fix the long tails without delaying my release data further. Another strategy is I never leave brand new version of website that is releasing first time without testing on all of my browser groups, say four groups.
Of course, I do test only primary and secondary browser groups when I am a bit in hurry and website is for redesigning. However, accomplish rest of browsers in one or more steps at later dates. This way I apply the rules of ‘smoke testing’ by fragmenting my testing schedule. However, smoke testing offers you only some flexibility and relaxations, but never let you escape from complete testing on your all browser groups.
I especially, apply smoke testing on the PSD to Joomla conversion projects where we have to deal with mainly B2B clients and they are in hurry to produce results of their end clients. I hope we will discuss on testing and creating browser groups in next part as we have space constraints in this post.