Litmus: Difference between revisions
Jump to navigation
Jump to search
ChrisCooper (talk | contribs) |
ChrisCooper (talk | contribs) |
||
| Line 20: | Line 20: | ||
== Goals for Litmus == | == Goals for Litmus == | ||
Litmus will: | 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 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.; | * 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; | * 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: | Litmus will not: | ||
* be released as a standalone product such as, e.g., Bugzilla, at least not in the [[Litmus:Roadmap|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 [http://lxr.mozilla.org/mozilla/source/webtools/litmus/ code is in CVS] if you want to try your luck or help out. | * be released as a standalone product such as, e.g., Bugzilla, at least not in the [[Litmus:Roadmap|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 [http://lxr.mozilla.org/mozilla/source/webtools/litmus/ 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. | |||
== Further Reading == | == Further Reading == | ||
* [[Mozilla_QA|Mozilla QA]] | * [[Mozilla_QA|Mozilla QA]] | ||
Revision as of 18:03, 18 April 2006
Litmus is the new integrated testcase management and QA tool that is designed to improve workflow 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
- Litmus Test Suite
- How to check out Litmus from mozilla.org CVS
- Adding Testcases to 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.