Difference between revisions of "Quaste TCS Tool Specification"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Detailed Specification)
(General Design and Content)
Line 111: Line 111:
 
** '''Name''' (text field | mandatory): the name of the TCS <span style="background: yellow">(can include quite every characters, spaces special characters)</span>
 
** '''Name''' (text field | mandatory): the name of the TCS <span style="background: yellow">(can include quite every characters, spaces special characters)</span>
 
** '''Next''' <span style="background: yellow">(Button/hyperlink?)</span>: saves the creation of the previous fields into the database and leads to the next steps.
 
** '''Next''' <span style="background: yellow">(Button/hyperlink?)</span>: saves the creation of the previous fields into the database and leads to the next steps.
 +
  
 
* In a seconds step, further fields are added below the previous ones and complete the general properties of the TCS:
 
* In a seconds step, further fields are added below the previous ones and complete the general properties of the TCS:
** Cause (Listbox | mandatory): This field indicate what motivated the creation of the TCS. The listbox content 4 entries:
+
** '''Cause''' (Listbox | mandatory): This field indicate what motivated the creation of the TCS. The listbox content 4 entries:
*** Select Cause:
+
*** '''Select Cause''' (default): has no effect but to make the choice mandatory.
*** Specification:
+
*** '''Specification''': has to be selected if a written specification exists. This is the normal case.
*** Own initiative:
+
*** '''Issue''': has to be selected if no specification but one ore more issue ID(s) exist(s).<br>Ex.: the TCS is written to avoid a regression of a fixed bug or<br> 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.
 +
 
 +
<div style="font-size: 80%; background-color: LightGoldenRodYellow; align:block; border:thin solid orange; padding: 4px; width: 500px;height: auto;position:relative; top: -120px; left:600px;">
 +
* '''Note''': in most cases both specification AND issue ID - which is mandatory to motivate a specification - exist. The user might then want to document both items. Though the form is presented as a an alternative (''either specification OR issue ID''), it is possible to fill in both items by switching afterward between Specification and Issue ID and vice versa. This method might sound awkward but it was the only way to assure that 1 of those cause is filled (mandatory) without making both mandatory at the same time.
 +
 
 +
</div>
  
 
=== List Test Case Specification ===
 
=== List Test Case Specification ===

Revision as of 15:30, 14 October 2009

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

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] containing 3 controls:
    • Version (listbox | mandatory): defines when the enhancement/feature has been first implemented.
    • Name (text field | mandatory): the name of the TCS (can include quite every characters, spaces special characters)
    • Next (Button/hyperlink?): saves the creation of the previous fields into the database and leads to the next steps.


  • In a seconds step, further fields are added below the previous ones and complete the general properties of the TCS:
    • Cause (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.
  • Note: in most cases both specification AND issue ID - which is mandatory to motivate a specification - exist. The user might then want to document both items. Though the form is presented as a an alternative (either specification OR issue ID), it is possible to fill in both items by switching afterward between Specification and Issue ID and vice versa. This method might sound awkward but it was the only way to assure that 1 of those cause is filled (mandatory) without making both mandatory at the same time.

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>

Personal tools