Difference between revisions of "Quaste TCS Tool Specification"

Revision as of 18:03, 14 October 2009

Abstract

There is a need of a web-based tool for writing TCSs (Test Case Specifications) and manage them over QUASTe.
Such a tool already exists (SUN internally) but its version 1.0 has many usability drawbacks and missing features.

The new version of the TCS tool should be easy to use but fulfill expectations and needs of the TCS writers.

In terms of UI design, we rejected as far as possible the former use of "wizards" - which don't give the user a global overview of his current work - and the pop-ups which even break the work flow.

We adopted a "tabbed" design which offers all the features on 1 page.

When final, the TCS tool will consist of two hyperlinks in QUASTe: "List Test Case Specifications" and "Create Test Case Specification".

References

Contacts

Acronyms and Abbreviations

Detailed Specification

The needs: easily create and find TCS.

• TCS Creation:
  A TCS is first created by defining its general properties, then filled with life by adding test cases to it and finally displayed in a preview summarizing all this information:
  • Properties: Define the general properties of a TCS (which OOo version, application, how often should the TCS be run).
  • Test Cases: Manage (add, edit, delete) Test Cases contained in the TCS
  • Preview: Output a print- and web-friendly page of the whole TCS.
• Find a TCS:
  • a list of all existing TCS filtered by fixed criteria.

Create Test Case Specification

General Design and Content

Following the 3 mentioned categories (properties, test cases and preview), the creation/edition of a TCS is displayed into 3 tabs corresponding to those categories.

A first step, when clicking on "Create Test Case Specification", shows a single Tab [Properties].

The [Properties] tab.

This tab contains 3 controls:

• Version [currentlty called "Product"] (listbox | mandatory): defines when the enhancement/feature has been first implemented.
• Title (text field | mandatory): the name of the TCS [can include quite every characters, spaces special characters]
• [N]ext [Button/hyperlink?]: saves the creation of the previous fields into the database and leads to the next steps.
  The access key for this button is Alt+N as noted "[N]" in the caption.

In a seconds step, 3 fields are added below the previous ones and complete the general properties of the TCS:

• Application (listbox | mandatory): The user selects the OOo component the TCS will be part of.
  The entries correspond to the 10 automated OOo applications.
  [Thinking about a 11th entry called "Other" to include 1 time use non yet defined applications...].
• Category (listbox | mandatory): The user selects how often the TCS should be run accross the milestones. The five automation categories plus a "never run" category.
• Cause [better wording: "Origin", "Motivation"] (Listbox | mandatory): This field indicate what motivated the creation of the TCS. The listbox content 4 entries:
  • Select Cause (default): has no effect but to make the choice mandatory.
  • Specification: has to be selected if a written specification exists. This is the normal case.
  • Issue: has to be selected if no specification but one ore more issue ID(s) exist(s).
    Ex.: the TCS is written to avoid a regression of a fixed bug or
    a small enhancement has been implemented which didn't require a specification.

• • Own initiative: has to be selected if the motivation of the TCS is neither due to an specification nor an issue.
    
    Depending on the selected cause, a form corresponding to this cause appears below those fields:
  • If Specification is selected:
    • Specification [better wording: "URL"] (text field | mandatory): The URL pointing to the specification.
    • Description [better wording: "Summary". The description has to be short!](text field | mandatory): A short summary which will be displayed in the list TCS list view.
    • Preconditions (multiline text field | optional): specific conditions needed to run the test (special settings in OOo, platform dependency, external tools, extensions...).
    • CWS Name (text field | optional): if one ore more CWS exist at the time the TCS is beeing written.
    • [S]ave [Button/hyperlink?]: Will be use to save the defined properties.
      The access key for this button is Alt+S as noted "[S]" in the caption.
  • If Issue is selected:
    • Issue ID (text field | mandatory): one or more issue ID.
      The other fields are the same as for Specification...
  • If Own initiative is selected:
    The same common fields as for Specification and Issue ID (Description, Preconditions and CWS name).

A click on [S]ave, saves the defined properties, reloads the page and displays 2 further tabs: [Test Cases] and [Preview].

The [Test Cases] tab

The [Preview] tab

List Test Case Specification

Help | User Interface Element Templates | Example Spec

Accessibility

Accessibility is the responsibility of the I-Team, beginning with UX, DEV and QA, to ensure that the following requirements are fulfilled:

1. Is the feature fully keyboard accessible?
   (Ex: "I can go everywhere and use every function using the keyboard only"
   <START TYPING HERE>
2. Have I specified visual alternatives for the case that the specified feature includes audio as output?
   <START TYPING HERE>
3. Are text alternatives for all icons and graphics available?
   <Start typing here>
4. Don't provide important information in colors alone
   (Ex: marking important information hard coded in red)
   <START TYPING HERE>
5. Does the specified feature respect system settings for font, size, and color for all windows and user interface elements?
   <START TYPING HERE>
6. Have I ensured that flash rates do not exceed 2 hertz for blinking text, objects, or other elements? In any case, try to avoid flashing UI elements
   <START TYPING HERE>
7. Ensure that assistive technology (AT) (like ZoomText or Orca) is able to read everything.
   <START TYPING HERE>

QUESTIONS?

If you need help while designing, implementing or testing the accessibility of the UI, ask/visit:

1. The accessibility check list at the OpenOffice.org Wiki
2. accessibility@ui.openoffice.org (The accessibility mailing lists, preferred)
3. For specific implementation details, architecture: mt@openoffice.org (Malte Timmermann)
4. For specific UX and testing questions: es@openoffice.org (Éric Savary)

Migration

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>

Configuration

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.>

Help | Configuration Table Template

File Format

<START TYPING HERE --- If this part is irrelevant state a reason for its absence.> Help

Help | File Format Table Template

Open Issues

<State a bulleted list of issues Issue here> Bold text