gnuherds-app-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: browsers' support -- proposed test policy


From: Davi Leal
Subject: Re: browsers' support -- proposed test policy
Date: Fri, 12 Oct 2007 12:12:53 +0200
User-agent: KMail/1.9.5

Victor Engmark wrote:
> > We should have a testing team :-( to consider all the browsers...
>
> A testing team is important for any large project, especially one
> which will be used by a lot of people with diverse clients.
>
> Usability testing without a budget
>http://www.456bereastreet.com/archive/200505/usability_testing_without_a_budget/

> Easy accessibility testing in Firefox
>   http://www.webaim.org/articles/evaluatingwithfirefox/

> Unit testing for JavaScript
>   http://www.jsunit.net/

> Unit testing for web sites in general
>   http://jwebunit.sourceforge.net/


I am not sure, just guessing:


 * Testing webapp frontend (HTML + CSS) will be complex just due to
   the diversity of browsers and devices.

   If we had used JavaScript it would had been a lot lot more complex.


 * Testing the webapp backend (PHP + data base) is a lot of work
   due to there are a lot of cases to test.

   Developing "Unit testing" to be used against the webapp backend
   is a lot of work too, but I have heard that it makes up for the
   effort as time goes on and you use such unit testing again and
   again after you code some fix or add some new feature.

      However, IMHO it is a lot of work to develop unit testing now that
      the webapp is known to be more or less stable. Maybe later, when
      we more to the FSF hosting?


> > As we are still in beta stage, I propose to add a link at the bottom
> > of the page like:
> >
> > "Are you experiencing a problem displaying this page with your browser?"
>
> Good idea! Just make sure you add some anti-spam feature to it. My personal
> favorite is using a text field with an ID like "spamtrap" and the label "
> Don't fill in this field", and then hiding it with CSS. Accessible &
> working

My vote is not to spend our short time adding such line, forms, etc., 
overloading the webapp with maybe an unused feature.

Note that such thing would be removed when the project pass the beta phase. 
So, why such effort? Nobody will use such report feature along the beta 
phase.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]