Privacy/Reviews/CaseConductor
Document Overview
| Feature/Product: | Case Conductor |
| Projected Feature Freeze Date: | 3/30/2012 |
| Product Champions: | Cameron Dawson, Rebecca Billings, Carl Meyer |
| Privacy Champions: | (the privacy Friend you're working with) |
| Security Contact: | Adam Muntner |
| Document State: | [NEW] |
Timeline:
| Architectural Overview: | (date TBD) |
| Recommendation Meeting: | (date TBD) |
| Review Complete ETA: | tbd |
Architecture
In this section, the product's architecture is described. Any individual components or actors are identified, their "knowledge" or what data they store is identified, and data flow between components and external entities is described.
The main objective of this feature/product is: This is a test case management system. It is Free and open-source. This is our upcoming replacement for Litmus. The system is designed to provide test case management, and status on test execution. Test managers can write tests for testers to execute, and they can see the results of the tests in real-time.
We will host an instance of this product as our own test case management system. However, the source is checked into github here and other organizations will deploy their own instances.
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.
One result of this change, is that the product is no longer a joint project with uTest, however they own the name "Case Conductor." So we will be changing the name. The branding search is underway.
Documentation: http://readthedocs.org/docs/case-conductor/en/latest/index.html
Project Plan:Pivotal Tracker
Components
Describe any major components in the system and how they interact. Also include any third-party APIs (those Mozilla does not control) and what type of data is sent or received via those APIs.
Deployment Considerations: readthedocs
The main components of the product are:
- Test Management
- Running tests
- Viewing Results
- Authentication
- Attachments
This product also supports:
- BrowserID
- Open Web App
Test Management
This component manages:
- Products
- Product Versions
- Environments
- Test Runs
- Test Suites
- Test Cases
This also interacts with the authentication to manage Users.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| Products | database |
| Product Versions | database |
| Environments | database |
| Test Runs | database |
| Test Suites | database |
| Test Cases | database |
Communication with Attachments Communication with most components is just done by writing data to the database, where the other component will pick it up. The only exception is Attachments.
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | hyperlinks | attachments are referenced by hyperlinks | |
| Out: | upload | attachments are uploaded and saved on a file store (like Amazon S3, etc) |
Running Tests
This component allows the user to execute active test runs. As they mark tests passed or failed, those results are persisted and visible in the View Results component.
When a bug is encountered, the user can store a link to an external report of the bug (Bugzilla, etc) though no real integration is done with bug tracking systems at this time.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| Test Case Results | database |
| Environments | database |
| Bug links | database |
Communication with Attachments
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | hyperlinks | attachments are referenced by hyperlinks | |
| Out: | file data | attachments are uploaded and saved on a file store (like Amazon S3, etc) |
Viewing Results
This component allows the user to view the results of test runs. Pass / fail status is displayed in the context of the entire run, or for each testcase therein. A test case can be executed for several environment combinations, so it's possible a test case will show 3 passing and 2 failed for different environments. The user can then drill down into the test case and see all the results for that case for each environment.
This component is read-only.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| Test runs | database |
| Test cases | database |
| Environments | database |
| Bugs | database |
| Attachments | database |
Communication with Attachments
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | hyperlinks | attachments are referenced by hyperlinks | |
| Out: | file data | attachments are uploaded and saved on a file store (like Amazon S3, etc) |
Authentication
This component manages:
- Users
- Email addresses
Email is used for user registration and password change only. There are no reports emailed by the system at this time.
We will be supporting BrowserID / Persona as well.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| username | database |
| database | |
| password | database |
Communication with BrowserID on browser
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | message 1 | auth key | |
| Out: | message 2 | auth key |
Attachments
This component allows the user to execute active test runs. As they mark tests passed or failed, those results are persisted and visible in the View Results component.
When a bug is encountered, the user can store a link to an external report of the bug (Bugzilla, etc) though no real integration is done with bug tracking systems at this time.
The tables below simply summarize the data encountered by this component.
Stored Data:
| What | Where |
|---|---|
| any file | file store |
Communication with Component Y
| Direction | Message | Data | Notes |
|---|---|---|---|
| In: | read in files to be stored | ||
| Out: | read out stored files for download or viewing |
User Data Risk Minimization
In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
Alignment with Privacy Operating Principles
In this section, the privacy champion will identify how the feature lines up with Mozilla's privacy operating principles.
See Also: Privacy/Roadmap_2011#Operating_Principles:
Principle: Transparency / No Surprises
(How the feature addresses this)
Recommendations: (what can be improved)
Principle: Real Choice
Recommendations:
Principle: Sensible Defaults
Recommendations:
Principle: Limited Data
Recommendations:
Follow-up Tasks and tracking
| What | Who | Bug | Details |
|---|---|---|---|
| [NEW] Initial Overview Discussion | ? | Meeting time TBD |