Litmus: Difference between revisions
Jump to navigation
Jump to search
Zachlipton (talk | contribs) No edit summary |
Zachlipton (talk | contribs) No edit summary |
||
| Line 10: | Line 10: | ||
* [[Litmus:Web Services]] | * [[Litmus:Web Services]] | ||
** [[Litmus:Test Result Format DTD|Test Result Format (DTD)]] | ** [[Litmus:Test Result Format DTD|Test Result Format (DTD)]] | ||
** [[Litmus:bsmedbergWebServices|bsmedberg's notes on Litmus Web Services]] | |||
* [[Litmus:Test Suite|Verifying Your Litmus Install]] | * [[Litmus:Test Suite|Verifying Your Litmus Install]] | ||
* [[Litmus:CVS|How to check out Litmus from mozilla.org CVS]] | * [[Litmus:CVS|How to check out Litmus from mozilla.org CVS]] | ||
Revision as of 18:00, 13 June 2006
Litmus is the new integrated testcase management and QA tool that is designed to improve workflow, visibility, and turnaround time in the Mozilla QA process. It is first and foremost designed as a replacement for Testrunner, but will also have additional functionality.
Litmus Documentation and Notes
- Litmus Roadmap
- Litmus To-Do List
- Litmus Developers' Notes
- Litmus Requirements
- Litmus Design
- Litmus:Web Services
- Verifying Your Litmus Install
- How to check out Litmus from mozilla.org CVS
- Adding Testcases to Litmus
- Future Directions for Litmus
- View a list of recent checkins to Litmus in CVS (Bonsai)
- Notes from the Litmus BOF session held at the Mozilla 2005 offsite
Goals for Litmus
Litmus will:
- make it easier for casual testers to assist with testing Mozilla products;
- serve as a repository for test cases, with all the inherent management abilities that implies;
- serve as a repository for test results, carrying over the best features of Testrunner, e.g. test lists, division of labor, etc.;
- provide a query interface for viewing, reporting on, and comparing test results;
- expose a web services interface for the mechanical batch submission of testing results.
Litmus will not:
- be released as a standalone product such as, e.g., Bugzilla, at least not in the 1.0 timeframe. We are trying not to paint ourselves into a corner where this is concerned, but many of the decisions and tradeoffs we're making are necessarily Mozilla-centric at this point. Still, the code is in CVS if you want to try your luck or help out.
- manage the automation of testing requests as a centralized test scheduler or daemon. The majority of testing we do, and all of the community testing that we know of, is still done by hand. This doesn't preclude such functionality in the future, but we need to figure out the intricacies of how to automate a larger proportion of our daily testing before it makes sense to spend too much time on scheduling those automated tests. Existing automation frameworks will be able to submit results via web services.