On 9/7/07, Angela Byron <drupal-devel@webchick.net> wrote:
Yay!
- Use it purely as a means of cataloguing all of the bugs that have broken core in one way or another. Before a release, we "spot check" a few of these trouble areas and make sure they're good to go.
- Before any release, we split up the various sections among individuals, so that each person can take a component (node system, user system, etc.) and make sure all of the tests there pass. This way we have no more of this "one person trying to test all of core by herself" business again. ;)
- We can also use this as a check-list for our library of SimpleTest automated tests (or Selenium or whatever). While it takes awhile to write all of these, once they were written "in theory" no human would ever need to test those aspects again.
Even more yay! Maybe you want to come and see this session: http://barcelona2007.drupalcon.org/node/621 "Creating a Drupal Specific QA Team" One of the things I'd like to do is create a system somewhat like Litmus - http://litmus.mozilla.org/ Litmus allows community testers to spend a very little amount of time testing the software, recording their results, and then aggregating them to make sure they are useful. It's pretty neat. Another fun tool would be the magic automated simpletester/Selenium machine we keep getting closer to implementing. This is another topic I'd love to cover in that QA brainstorming session in Barcelona. Anyway, just saying thanks for this work and (not so subtly) advertising my sessions here ;) Greg PS The other sessions I'm doing are: "Token Module: How I Learned To Use the Token API and Stop Re-Implementing Dynamic String Replacement" - http://barcelona2007.drupalcon.org/node/416 AND (Dis)Organizing a Drupal Local User Group: lessons learned - http://barcelona2007.drupalcon.org/node/433 -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg