Quaste TCS Tool Specification

This specification is a DRAFT still in discussion.

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

Reference Document	Check	Location (URL)
Prerequisites	[passed/failed]	n/a
Product Requirement, RFE, Issue ID (required)	[available/not available]	<PLEASE ENTER LOCATION HERE>
Accessibility Check (required)		See accessibility section for check list
Test case specification (required)	[available/not available]	<PLEASE ENTER LOCATION HERE>
IDL Specification	[available/not available]	<PLEASE ENTER LOCATION HERE>
Software Specification Rules	n/a	n/a
Other, e.g. references to related specs, Product Concept Document		<PLEASE ENTER LOCATION HERE>

Contacts

Role	Name	E-Mail Address
Developer	Helge Delfs	hde@openoffice.org
Quality Assurance	Éric Savary	es@openoffice.org
Documentation	Helge Delfs Éric Savary	hde@openoffice.org es@openoffice.org
User Experience	Éric Savary	es@openoffice.org

Acronyms and Abbreviations

Acronym / Abbreviation	Definition
TCS	Test Case Specification
QUASTe	Quality Assurance Statuspage

Detailed Specification

<START TYPING HERE> 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>