PUBLIC MARKS with tag QA

t work we have to manage a ton of Django based sites. Just for our World Company sites, we have over 50 different settings files, and this doesn't take into account the sites that we host for other clients. At this size it becomes basically impossible to test each site in a browser when you push things to production. To solve this problem I have written a very basic server description tool. This allows you to describe sites (settings file, python path, url, etc.) and servers.

The technical qualities of a website largely depend on how hard the web development team has worked on it. When qualifying a website on the code level, you need a different set of metrics than you did some years ago. This article is our attempt at specifying what metrics you should use.

The QA style sheet highlights specific HTML problems like use of deprecated elements, inaccessible images, layout tables, empty elements, or styling-related maintenance issues. Theoretically, it is “unobtrusive” in a sense that when everything’s fine it won’t cause any visible changes.

Welcome at the WatiN (pronounced as What-in) website. Inspired by Watir development of WatiN started in December 2005 to make a similar kind of Web Application Testing possible for the .Net languages. Since then WatiN has grown into an easy to use, feature rich and stable framework. WatiN is developed in C# and aims to bring you an easy way to automate your tests with Internet Explorer and FireFox using .Net.

It is very important to report the WTF to the developer who produced the code. Subversions “annotate” or “blame” function provides a means to blame someone for the existence of a specific piece of code. The best way to report this back is through an informative and educational discussion, where everyone could be involved. The factoring should preferably be done by the developer responsible for the code, perhaps with the assistance of the developer who reviewed it. As a result, quality awareness will have improved within the development team.

Test-Driven Development is first and foremost an application design methodology. If you write your unit tests after you write your application code, then you are not driving the design of your application with your unit tests. In other words, Test-After Development ignores the Driven in Test-Driven Development.

The big hole we have is automation. We have already ported the Firefox unittests to Maemo, but there are a lot of bugs to be fixed and a pending integration into the tinderbox automation framework.

Yet, these 16 chars cost around 1200$* in direct labour time and 3 engineers were involved.

We're not planning to cram a bunch of Fixes into Firefox 3 since it's almost ready, and cramming features in at the last minute risks hurting other Web standards support or hurting some of the other things that make Firefox a great browser.

oui. un discours réaliste (bien que nouveau) qui prend en compte tout le contexte. Cela me rappelle une anecdote d'une amie. Au Canada, elle pratiquait le karaté. À la fin de chaque année, elle était préparée pour passer l'examen des ceintures. Au Japon, elle a repris les cours à zéro. Le maître propose enseigne la technique et la philosophie du karaté et les individus ne se présentent à l'examen que quand ils sont prêts. C'est toute la différence entre passer le test Acid 3 avec hack ou pas, et implémenter sérieusement la technologie en étant sur de ce que l'on fait. Et je trouve, dans ce cas ci, la démarche de Mozilla et son changement de discours plutôt bien.

Regarder les communautés évoluer est toujours intéressant. Que ce soit celles du w3c ou ailleurs. Complexe. Y participer, c'est accepté d'avoir les mains sales ou alors on est un sombre ignare idéaliste.