Tag Archives: testing

Wanted: testers for WP YouTube Lyte (the one with the new YT API)

As I wrote a couple of weeks ago, YouTube is shutting down their old v2 API, forcing WP YouTube Lyte to swith to v3. The main change; users will have to get an API key from Google and provide that in the Lyte settings page.

Initial development & testing has been done (this blog switched already) and I now need some brave souls to test this. You can download the “beta” from https://downloads.wordpress.org/plugin/wp-youtube-lyte.zip and report back here or on the wordpress.org support forum about how that did or did not work for you.

Looking forward to having to fix some nasty bugs until everything will finally be in it’s right place once again ;-)

Osunlade ft Erro Everything In Its Right Place

Watch this video on YouTube.

Browser release schedule heaven and hell

“What browser should this be tested in?” Remember 2003, when that question was rarely asked because there was virtually only Internet Explorer? Or 2006, when you could get away with just IE6 and Firefox 1.5? 5 years later the browser landscape has become a lot more complex. You’ve don’t only have to consider Internet Explorer, Firefox, Chrome, Safari and maybe even Opera and mobile, there’s browser versions to worry about as well!

On one hand there’s Internet Explorer, with no less then 4 versions in the wild (cfr. chart on the left, data source: statcounter.com). According to MS’s own IE6countdown, IE6 is down to 1.9% market sharee in Belgium (but 10.7% worldwide), so we might as well forget about that dinosaur, except maybe if you’re in a b2b-context? But that still leaves you with IE7, IE8 and IE9. Check your visitor stats, because your mileage may vary, but you’ll probably want to focus on IE8 (the “stable” version) and IE9 (the “new stable”).

Google Chrome is the example of a radically different approach. There’s a new version approximately every 6 weeks, with users upgrading to the latest stable version automatically. The impact of such a rapid release schedule can seen in the chart on the left (data source: statcounter.com).

The advantage of this approach for web-developers is clear: you don’t have to worry about older versions any more. But on the other hand; you do have to worry about newer versions (at least a bit), because by the time you finished development of your application, Google Chrome (and Firefox, which recently joined the rapid release frenzy) will be one or even two version further along and customers will have upgraded automatically.  In general this won’t be a problem, but maybe you should test your app in the stable and beta versions of your supported browsers during development and consider investing some time in regular testing on the stable versions after your move to production, to avoid that a HTML rendering or JavaScript engine regression or a slightly altered CSS interpretation messes up your online presence?

Anyway, there’s no silver bullet, so what is your approach?