Confirmed users
508
edits
Privacy/Reviews/CaseConductor: Difference between revisions
Jump to navigation
Jump to search
→Architecture
| Line 33: | Line 33: | ||
We will host an instance of this product as our own test case management system. However, the source is checked into [https://github.com/mozilla/caseconductor github here] and other organizations will deploy their own instances. | We will host an instance of this product as our own test case management system. However, the source is checked into [https://github.com/mozilla/caseconductor github here] and other organizations will deploy their own instances. | ||
'''Use Cases:''' There are 4 main roles and use-cases: | |||
* Testers | |||
** Testers can only execute tests. In this case, usually community members will be given a URL to an existing Test Run. They nav to that, specify the environment they're using (such as Windows 7) and begin executing test cases. They mark them Pass / Fail / or Invalid (if the case is unclear to the point they can't tell if it passes or fails). | |||
* Test Creators | |||
** These folks can do everything that Testers do, but they also can create new tests. These are "semi-deputized" members of the community. They will create new tests, and a Test Manager or Admin will activate them, if they pass muster. | |||
* Test Managers | |||
** These are usually in-house QA or Product owners, or fully deputized Community members. These users can specify new Products, and Product Versions that should be tested. They can create new Test Cases and Suites of Test Cases and activate them so they can be run. They can also create Test Runs (collections of Test Suites that can be executed). Once this use activates the Test Run, then all the users above can execute the test cases and provide results. | |||
* Admins | |||
** These users can do everything from above, and can also manipulate user accounts. | |||
Results: | |||
All users can login and see results of executed test cases. They can see what passed, what didn't and what cases were not clear. | |||
'''History''': Originally this product was designed to be in two parts. A "Platform" written in Java providing REST endpoint APIs and a "User Interface" written in Django. Despite some people's investment in this relationship with uTest and the separation of the two parts, eventually it was determined that this architecture was untenable. At this point (Nov 2011) we decided to re-architect as pure Django. | '''History''': Originally this product was designed to be in two parts. A "Platform" written in Java providing REST endpoint APIs and a "User Interface" written in Django. Despite some people's investment in this relationship with uTest and the separation of the two parts, eventually it was determined that this architecture was untenable. At this point (Nov 2011) we decided to re-architect as pure Django. | ||