Posted by Robin Monks on March 12, 2008 at 9:16pm
<p>By: Robin Monks</p>
<h1>Introduction</h1>
<p>Drupal is community. It’s a community of visionaries that make Drupal what it is, we all want to see Drupal be more powerful, more flexible, and just plain better than the competition!</p>
<p>That said we need to be aware that the more popular our product gets, the more we need to test for various scenarios; and not just from the developers point of view, but from the users. This is where Quality Assurance comes into play. QA can help give Drupal core that extra level of stability and sanity, and the good news is we’ve already taken the first steps.</p>
<h2>Non-Interactive Functionality Testing (Unit Tests) [Already Happening]</h2>
<p>· <a href="http://drupal.org/project/simpletest">http://drupal.org/project/simpletest</a></p>
<p>· <a href="http://drupal.org/project/Drupaltestbed">http://drupal.org/project/Drupaltestbed</a></p>
<p>· <a href="http://drupal.org/project/project_issue_file_test">http://drupal.org/project/project_issue_file_test</a> (aka. PIFT)</p>
<p>Non-interactive testing via projects such as <a href="http://testing.drupal.org">http://testing.drupal.org</a> will go a long ways toward eliminating the need for developers to manually test each submitted patch for syntax quality and general “does it run?”-ability. It will be sure to allow patches to be processed much faster.</p>
<h2>Smoke Testing [Concept]</h2>
<p>We need a list of common tasks that volunteers can perform on various host and browser environments to test for broken or unexpected functionality. I plan to make some further guidelines, and perhaps some tools, for this shortly.</p>
<h2>User Interface Quality [Partially Complete]</h2>
<p>The g.d.o <a href="http://groups.drupal.org/usability">Usability Group</a> has made great progress to this goal, here is some of their fine work:</p>
<p>· <a href="http://groups.drupal.org/node/8428">Views 2.0 UI guide</a></p>
<p>· <a href="http://drupal.org/about/authoring">Handbook style guide</a></p>
<p>· <a href="http://drupal.org/documentation-writers-guide">Documentation writer’s guide</a></p>
<p>Here are some things I’d like to see added:</p>
<p>· Style guide for help text and prompts in Drupal (eg, the confusing password strength “error” during install)</p>
<p>· Module and form description style guide</p>
<p>· A general UI element style guide a la Gnome</p>
<h3>Disability Usability</h3>
<p>We need to ensure all Drupal features can be access by those with screen readers, or with color blindness.</p>
<h2>Full Standard Compliance [Partially Complete]</h2>
<p>We need to monitor to ensure that current Drupal features (HTML, JS, CSS) meet existing standards; we also need to make sure as we enter the world of the semantic web, where data is free-for-all, that we also stick to know standards and conventions so as to allow the presented data to be as interoperable as possible.</p>
<h2>Community-powered Quality Events [Concept]</h2>
<p>Bug-a-tons, bugdays; prizes for those who process the most bugs, etc. These could all be means to get more people involved in the issue queues, and to enhance the overall quality of Drupal.</p>
<h2>Central Source of Information [Concept]</h2>
<p>There needs to be a central location where everyone interested in Drupal quality can find out information, and participate. The great thing about quality testing is those involved don’t necessarily have to be developers. It’s a great way to get more people involved in the Drupal development process!</p>
<p>I think the g.d.o “Quality Assurance” group has the potential to be that place. I’ll be making myself active in that group and will help co-ordinate changes to implement the items in this “rough guide” I’ve outlined. None of it should be considered “official”, but I believe it will serve as a great guide for future QA efforts.</p>
Comments
Usability Suite
If everything works out as planned I will be working on a usability suite that sounds like it will fit into the plan. Bevan and I talked and he wrote up his ideas.
That sounds excellent, it
That sounds excellent, it will help a lot in the UI Quality section
Robin
--changed position--
--changed position--
bug-a-thons
I'd like to see some 'review sprints' during this release cycle - dealing with existing patches and trying to get them RTBC (or needs work/won't fix for good reasons). Currently there's less people reviewing patches than providing them ,and a big drive to get more people involved with that would help a lot. Between that and automated testing I'm hoping our current 150-250 patches needing review could go down to about 30-50 at any one time, and stay there due to faster turnover and more eyes on any one individual issue.
With the usability testing suite it'd be good to work towards a way of getting brand new Drupal users involved in this early on - people who've just arrived at the site, just signed up for a d.o. account etc. - ideally we'd end up with a constant stream of new people to look at interfaces (and proposed interface changes) for the first time, as part of the patch review process.
Tutorial about application of patches and review standards
I would like to help with the review and I feel that many of the new people to Drupal could find that a useful way to learn and participate.
Is there a Tutorial or instructions on "how-to" perform the patches and then document the review or is this just something that one either knows or does not?
There's a fair amount of
There's a fair amount of information at http://drupal.org/patch - which covers everything from creating patches, to testing, to the review process.
As well as that, you should turn on the 'contributor links' block in your drupal.org user profile - this gives you direct links to the Drupal 7 issue queues.
If you're not sure where to start (there's about 160 patches needing review at the moment), you'll find lots and lots of very enthusiastic help on the #drupal irc channel - there's almost always someone on there who'll walk you through their current favourite patch. http://drupal.org/node/108355