My Google Fu is failing me today...
I want to expand the number browsers I support for my application. The amount of time it takes to test my existing functionality and on multiple browsers has become a limiting factor for expansion.
Is there a more pragmatic what to test layout and functionality across the various mobile and traditional web browsers?
Welcome to the world of development :)
IOW, no - you need to test each release for compatibility across all the devices that you want to support.
Related
I'm new to Roku development (in R&D phase actually). I read that we can't test Roku app on simulator and need real device. If we develop an application, how will we test it?
I checked Roku developer site and different links on internet, but could not find anything that answers my questions
As per my info, Roku sells 5 devices so:
Can we do one app that supports all 5 devices?
Do we need assets in multiple resolutions?
Do I need to buy all devices?
Can we do one app that supports all 5 devices?
Yes. Roku is trying hard to keep their platform coherent, though there are performance issues between the OpenGL and non-OpenGL devices. The "legacy" models (<2222) are no more supported, the firmware is kept current for the others.
Do we need assets in multiple resolutions?
Theoretically yes, practically - not really. You can make-do with assets in only one resolution, if you RTFM and pre-plan carefully. You'll need 3 sizes of app icon, no sweat. For the real UI though, you can either do HD (720) or FHD (1080) and leave it scale accordingly - the thing is TV is very forgiving to scaling graphics because of 10ft watching distance (60" 1080p screen is "Retina" beyond 8ft). Can largely snub SD.
Do I need to buy all devices?
No. And there are much more than 5 devices that are in use - see https://forums.roku.com/viewtopic.php?f=34&t=86471&start=15#p536994 for some statistics (RokuCo does not publish statistics, so that's about the best info available). If you buy only 2 devices, i'll say get
a #42xx (Roku 3 or current Roku 2) as reference model with OpenGL
a #27xx (Roku 1 or SE) or #5xxx RokuTV as reference for "slower", non-OGLES
As 3rd model i'll say the "new HDMI stick" #3600. You can get that one as the only device, its performance is somewhere between (1) and (2) above... but i don't think developing with only 1 device is a good idea.
One thing you may not have noticed is that there are also these "Roku TV" things under Hisense/TCL/Sharp/Insignia brands, models #5xxx. These are proper TVs with proper Roku smarts - meaning can run your Roku app. And one can be had for as little as... (skimming BestBuy web) $130-150 for 24-32" screen.
And i haven't even mentioned the 4k/HDR craze here, nor the new 37xx/46xx models that will be out for the holiday season (i only expect minor, evolutionary changes there).
Disclosure: I am a Roku employee.
That's correct, you'll need an actual Roku device to test your application. You can buy them used on eBay for very cheap ($20-35), or you can buy a brand new unit from our website for $50. The latest Roku Streaming Stick (Model #3600X) is my personal favorite option, and a great value.
You don't need to buy all devices, although we do recommend having many models so that you can QA test across devices. However, one popular development approach is to build your channel on a lower-end model, which theoretically will assure it works on higher-end models as well. This will also mean you have to spend less on your purchase.
Download our Precertification Checklist and open the third sheet, which includes a list of all our model numbers and corresponding code names. I'd recommend building on a "Giga" or a "Paolo."
Think of this cost as an R&D expense. Plus you'll get to enjoy the device on your free time as well!
As for your other questions:
Yes, you will only build one app that will work on all different devices. We do recommend taking the time to make sure your app is optimized across all devices, including older devices with less processing power. Our Performance Guide is a great starting point for this.
The other option is to check if the first number of the device model is less than “3” (which indicates it's a lower-end device) and add conditionals off that, such as removing animations.
You can find two examples of this on our RokuDev GitHub page:
Hero-Grid-Channel —> Components —> LoadingIndicator —> LoadingIndicator.brs —> Line 244
Multi-Live-Channel —> Source —> Main.brs —> Line 21
Yes, you do need different assets based on resolutions. Take a look at this document: https://github.com/rokudev/docs/blob/master/design/channel-artwork.md
I am making a SRS and as per the research that I have done on Non Functional Requirements "Browser compatibility" testing comes in NFR . Please explain why we take "Browser compatibility" in NFR
You can read this link you can under stand, For functional testing we test each and every functionality(how the product should behave),..in non functional testing(HOW THE APPLICATION IS WORKING) we test load,stress...so its comes under NFR.
http://www.softwaretestinghelp.com/best-cross-browser-testing-tools-to-ease-your-browser-compatibility-testing-efforts/
http://www.guru99.com/compatibility-testing.html
Initial phase of compatibility testing is to define the set of environments or platforms the application is expected to work on.
Tester should have enough knowledge on the platforms / software / hardware to understand the expected application behavior under different configurations.
Environment needs to be set-up for testing with different platforms, devices, networks to check whether your application runs well under different configurations.
Report the bugs .Fix the defects. Re-test to confirm defect fixing.
Functional requirement is about how the product should behave. it is about what is the expected output for a given set of initial conditions and actions. And we functional requirement takes on business view on it. If you are building a software to run a dental office, functional requirements are going to be about adding a patient, taking appointments etc.
Non-functional Requirements on the other end is not going to be about the "business behaviour" but more about the platform on which the software will run, the ergonomic of the product or the performance (although for performance, it can become sort of "functional" if the soft is useless above a certain response time)
Back to Browser compatibility, this is not about the behaviour of the product. For our dental office example, the dentist does not really care if it will run correctly on Chrome or Firefox. That is not what he is looking for to run his business. Nevertheless, if your implementation or test conclude that the soft runs ok only on Chrome, then you will have to advice use this browser. But this has nothing to do with the functions of the products.
http://www.1stwebdesigner.com/design/tools-browser-compatibility-check/
Compatibility testing, part of software non-functional tests, is testing conducted on the application to evaluate the application's compatibility with the computing environment. Computing environment may contain some or all of the below mentioned elements:
Computing capacity of Hardware Platform (IBM 360, HP 9000, etc.)..
Bandwidth handling capacity of networking hardware
Compatibility of peripherals (Printer, DVD drive, etc.)
Operating systems (Linux, Windows, Mac etc.)
Database (Oracle, SQL Server, MySQL, etc.)
Other System Software (Web server, networking/ messaging tool, etc.)
Browser compatibility (Chrome, Firefox, Netscape, Internet Explorer, Safari, etc.)
I today had basic question in my mind ,what is the difference between
testing functionality in browser and same in mobile. say testing
m.gmail.com in browser and same directly in mobile using selenium.Is
there any difference other than the fitting into screen etc.
If you have a different server to handle mobile requests, you might have different implementation of the features, thus, you need to test both platforms.
The content might also be delivered according to the mobile browser used (Safari on the iPhone is much more feature-rich than the default N95 browser, for example).
Let’s look at some of the major differences.
Limited Real Estate
The most obvious difference is screen size. Responsive design is relatively easy to code for desktop and laptop browsers – most of which come with predefined ratios anyway.
By contrast, mobile devices are much smaller. Aligning images and text becomes a real challenge – especially when you factor in features like portrait orientation (i.e. the ability to rotate a mobile device and have the image flip accordingly).
Worse still, there is so much more variation – even when dealing with the same manufacturer.
For example, the iPhone 5 has a 4” display, whereas the iPhone 6 is 4.7” on the diagonal. When you add in the iPhone 6 Plus (5.5”), iPad Mini (7.9”), and iPad standard (9.7”), it becomes harder and harder to code and test mobile applications that look “good” on all screens.
Storage and RAM
Screens are not the only spatial constraint mobile software testers face. You also must factor in the limited storage and processing power of today’s mobile devices. Even high capacity phones can quickly fill up as users download apps and multimedia.
In the browser world, such constraints are moot. Desktop storage is essentially unlimited (measured in terabytes). And cloud-based storage is easy to increase, even if this requires charging higher prices to end-users.
Internet Access
With the exception of a few off-line browser applications (e.g. Gmail), Web-based software always requires an Internet connection.
Mobile apps may or may not need online access (although those that don’t often take up more space – see point #2 above). When Internet is needed, however, mobile software testers must factor in 3G and 4G – in addition to normal Wi-Fi.
Does anybody have experience using 20/50/100 RCs connected to a single Selenium Hub? I'm thinking of a centralized hub that multiple team could use together.
I heard that after 20 RCs, performance goes down significantly.
My tests use 104 RCs which are connected to a single Hub. Hub is able to handle all the RCs and the system is stable. One thing that you should note is, how you pass the commands to the Hub.This determines how much RCs Hub is going to utilize. What we do in our grid is, we run multiple builds at the same time - all pointing to the same Hub. This would mean Hub is always kept busy.
I'm not sure where the "20" value is coming from. I run with significantly more than that to power Mogotest and we run many more test sessions across various sites than most users of grid. Granted older versions had some thread problems, but 1.0.8 should be pretty solid and the 2.0 releases have not exhibited any problems.
FWIW, I maintain the grid project and backport any known fix for any known load issues. I also know of several others running large-scale grid installations without incident.
It boils down to how robust your h/w is. Though I can't say exact statistics yet suggest to keep it with in 20
Well there is not but yes very much close to 20 for good performance.
I am developing a website exclusively for mobile browsers.
What guidelines should I follow to optimize the site for mobile development?
My main concerns:
Most mobile devices have propriety browsers. How can the app be tested on those different browsers (testing on an actual device is not possible due to security restrictions)?
How to optimize the site for different screen sizes?
How to make the app touch friendly?
How to detect orientation of devices (in devices that come with an accelerometer)?
How to check that the device is not a desktop/laptop?
Things that I have used when designing mobile websites.
Find out the range of devices that you are planning to support. Some questions that you can ask are
Are u going to support only smartphones
What platforms are u planning to support ( iPhone, Android, Symbian ? )
A lot of you questions can be answered by the kind of Analytics that you are able to gather. If you have very less statistics then you can follow this strategy to start with.
Separate out the target range of devices into
simple ( basic phones with minimum browsing capabilities. ) - Design a very simple plain vanilla site for them.
medium ( older generation smartphones with browsers with poor javascript support ) - Design a site that has slightly better features.
Highend smartphones ( iPhone, Android, WebOS ) - Provide jazzy features that these phones support.
Use a device detection library like WURFL / .Mobi for device detection and WALL for dynamic rendering of content.
You can use .Mobi to detect an HTML5 compliant mobile browser. That way, you can take advantage of HTML5 capabilities in the devices that support it.
For testing you can follow this approach
test on browsers - Firefox / Safari / Opera have plugins to alter USER_AGENT and can simulate mobile testing.
Test on simulators - All the device platforms provide free to download emulators
If needed try device emulation products like device anywhere / perfecto.
I hope I was able to clarify atleast some of you questions. :)
The definitive guide has to be the W3C Mobile Web Best Practices: http://www.w3.org/TR/mobile-bp/ Don't let the length of it put you off - I find it much easier to read than other W3C specs. The key section is the Best Practice Statements, divided into bite-size chunks, often with an example. There's also a recent and extensive mobile web optimization guide here: http://dev.opera.com/articles/view/the-mobile-web-optimization-guide/ (disclaimer: I work for Opera)
Q1 Most mobile devices have propriety browsers. How can the app be tested on those different browsers (testing on an actual device is not possible due to security restrictions)?
The answer depends on how many devices you want to test and support.
iPhone: device and simulator are available.
Android: devices and emulator are available
Other mobile phones?
check http://www.deviceanywhere.com
Of course, you need to pay service fee. But i think its reasonable.
Q2 How to optimize the site for different screen sizes?
iphone4
WVGA854
WVGA800
VGA
HVGA
QVGA
QCIF+
Making contents for all different size is difficult. So have to make a choice about screen size and supported models.
Q3 How to make the app touch friendly?
It is your design issue.
Q4 How to detect orientation of devices (in devices that come with an accelerometer)?
Android and iOS has special message about such event. You have to follow such message.
Of course, you need both landscape and portlait layout.
Q5 How to check that the device is not a desktop/laptop?
You can use User-Agent header or IP address. But IP address is not good method.