Privacy/Reviews/CaseConductor

Document Overview

Feature/Product:	Case Conductor
Projected Feature Freeze Date:	3/31/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:

• Web App
• BrowserID (external component)
• File Store / Attachments (external component)

Web App

This component manages:

• Products & Versions
• Environments
• Test Runs, Suites & Cases
• Test Results
• Authentication

The tables below simply summarize the data encountered by this component.

Stored Data:

What	Where
Products - String definitions of products such as Firefox or Thunderbird. Products under test. This is the top level item to which other items are bound. For instance, Test Cases will be specific to a Product.	database
Product Versions - Products can have several versions. These are string or numerical versions. Environments that need testing are specified against the Product Version, because they may be different for different versions. There is one version of each test case for each Product Version for the same reason.	database
Environments - These are categorized things like the category "language" may have "english, spanish, italian" as well as the category of "OS" may have "OS X, Windows 7, Linux, etc." Environments can be any set of strings that need test coverage for the Product Version.	database
Test Runs - A collection of test cases, specific to a Product Version, that need testing. Once "activated" a tester can begin providing results for each environment of each test case.	database
Test Suites - Collections of test cases that can be added to Test Runs for execution.	database
Test Cases - Specify a set of actions that must be executed. A case is often executed for several different environments.	database
Users - Users of the system that can have roles such as Admin (can change anything), Test Mangager (can edit and create tests), Test Creator (can create new tests, but not edit existing ones), and Tester (can only execute and provide results for tests)	database
Attachment URLs - Files attached to test cases to help with the test. Such as a video file used to test WEBM video.	database

Communication with File-Store / Attachments Attachments are files stored in a file store. In our deployment, it's just the local file system. Full documentation on the Django file store API can be found here: Django File Store API

Direction	Message	Data	Notes
In:	url(name)	hyperlink pointing to the file in question	attachments are referenced by hyperlinks. when the user clicks a link for this file, it opens the hyperlink in the browser.
Out:	get_available_name(name)	text	an available name in the file store to save this file
Out:	save(name, content)	text, binary	the name of the file, and the binary content of that file

Communication with BrowserID Documentation on using BrowserID with a web app can be found here: BrowserID Dev Guide

Direction	Message	Data	Notes
In:	assertion	string	this is a signed claim that proves the user is who they say they are
Out:	https://browserid.org/verify	assertion	an encoded assertion
Out:	https://browserid.org/verify	audience	the host and port of this web app

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