Processes

Objective Goal Roadblocks
Regression Testing (1) Identify all user-definable data elements that affect billing.
  • Building the initial baseline will take time
Regression Testing (2) Identify all the features that can be incorporated into a rate plan.
  • We don’t know what we might be missing
Regression Testing (3) Identify what other elements such as system date can affect billing.
  • Building the initial baseline will take time
Test Readiness Criteria Have code that is ready to test.  
Style Guide for Documentation Submit all QCPs in a consistent format.
  • Time to train.
  • Judging whether a QCP “passes
Environments (1) Have a standard configuration for Reflections-X
  • Environment is diverse.
  • Keeping the configuration from being changed
Environments (2) Have a standard UNIX directory structure in the test environment.
  • Difficult to audit
Environments (3) Have a standard Unix environment in the test environment
  • .rc file can be overridden
Complexity Ratings (1) Have a complexity rating for each executable Battlemap does not cover all languages.
Complexity Ratings (2) Have a complexity rating for each form Manual process – establishing a baseline will be time consuming

Process Objectives, Process and Metrics.

Regression Testing (1)

  • Objective: Identify all user-definable data elements that affect billing.
  • Process:
    • Establish a baseline using ACE Insight.
    • Interview the lead developer for each project.
    • Attempt to make data elements part of the project documentation.
  • Metrics: Percentage of data elements identified.

Regression Testing (2)

  • Objective: Identify all the features that can be incorporated into a rate plan.
  • Process:
    • Study existing rate plans.
    • Brainstorm with marketing people.
  • Metrics: Number of rate plan elements identified.

Regression Testing (3)

  • Objective: Identify what else besides data elements (such as system date) affects billing.
  • Process: Interview lead developers.
  • Metrics: Number of elements identified.

Test Readiness Criteria

  • Objective: Have code that is “ready to test.”
  • Process: Develop a checklist of items that must be completed before we accept the code.
  • Metrics: Number of projects handed over with proper items completed and documented.

Style Guide for Documentation

  • Objective: Submit all QCPs in a consistent format
  • Process:
    • Develop a style guide.
    • Train the staff.
    • Develop a word template and make it available.
  • Metrics: Number of documents submitted in accordance with the style guide.

Environments (1)

  • Objective: Have a consistent terminal setup to emulate what the call center uses.
  • Process:
    • Document the set up.
    • Train the staff how to set up.
    • Have the configuration file available on floppy or shared drive.
  • Metrics: Terminals set up properly durning test.

Environments (2)

  • Objective: Have a standard Unix directory structure in the test environment.
  • Process: Use a shell script to create and audit directory structures in the test environment.
  • Metrics: Correct directory structure in the test environment.

Environments (3)

  • Objective: Have a standard Unix environment in the test environment.
  • Process:
    • Create an .rc file
    • Have users source this file before conducting tests.
  • Metrics: Correct environment during tests.

Complexity Ratings (1)

  • Objective: Have a complexity rating for each executable.
  • Process: Use Battlemap to assign a complexity rating.
  • Metrics: Number of compatible programs scanned by Battlemap

Complexity Ratings (2)

  • Objective: Have a complexity rating for each form.
  • Process: Use the Lorenz-Bohls computation for each form
  • Metrics: Number of forms evaluated.

Back to Strategic Plan