Content Management/Test Plan: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
==Strategy & Plans==
==Strategy & Plans==
Our test strategy involves several components:
To show that our system is bug free and acts according to use cases, we have conducted a variety of test types. Our test strategy involves several components:
*White Box testing: Occurs during development via unit testing.
*Black Box testing: Manual testing of interface and classes it exposes.
**This testing mode also involved positive and negative testing. First, common use cases were attempted, followed by deliberate attempts to break the system.
*Black Box testing: Manual testing of interface.
*Regression Testing: During development, at each update, core functionality relating to the update is checked for bugs and consistency.
**This testing mode also involved positive and negative testing. First, common use case were attempted, followed by deliberate attempts to break the system.
===Schedule===

===Resources===
Our testing resources are the same as our development resources. Our computers serve as the testing computers since the application runs online (differing system configurations won't affect it). We ourselves were the testers. Time spent testing was the minimum to assure a quality product.
===Guidelines===
In addition to correctly performing the test types discussed above, there are a few guidelines for dealing with errors discovered via testing. All bugs are documented via TRAC. At the end of each iteration, bugs must not prohibit the system
s critical components from functioning.
==Quality Goals==
==Quality Goals==
At minimum, our goal was to have the critical use cases for our program working. This means that content should be submittable, viewable, and searchable. In the process of performing these actions, the user should not be presented with any unexpected errors. An unexpected error is one that is caused by a faulty system, rather than an message explaining user error (example: "You didn't fill in a required field")
At minimum, our goal was to have the critical use cases for our program working. This means that content should be submittable, browsable, and searchable. In the process of performing these actions, the user should not be presented with any unexpected errors. An unexpected error is one that is caused by a faulty system, rather than an message explaining user error (example: "You didn't fill in a required field"). Ideally all errors in every part of the system would be caught, but since a) our code is not 100% complete, and b) the infeasibility of testing every single possible path, we can't achieve this.

==Test Case Specifications==

===TC1: Submit Content===
'''Preconditions''': User must be logged in.
'''Sequence of Actions''':
User types title, selects file, types tags, selects language, and selects category.
User presses submit button.
User is prompted to confirm submission.
User presses confirm button.
User is presented with thank you message.

===TC2: Browse Content===
'''Preconditions''': None
'''Sequence of Actions''':
User clicks a category (repeat as needed).
User clicks a content title.
User presented with content information page.


===TC3: Search Content===
==Test Cases==
'''Preconditions''': None
'''Sequence of Actions''':
User types search terms.
User selects desired language.
User presses search button.
User is presented with search results.


==Results==
==Results==

Revision as of 04:32, 19 November 2007

Strategy & Plans

To show that our system is bug free and acts according to use cases, we have conducted a variety of test types. Our test strategy involves several components:

  • Black Box testing: Manual testing of interface and classes it exposes.
    • This testing mode also involved positive and negative testing. First, common use cases were attempted, followed by deliberate attempts to break the system.
  • Regression Testing: During development, at each update, core functionality relating to the update is checked for bugs and consistency.

Schedule

Resources

Our testing resources are the same as our development resources. Our computers serve as the testing computers since the application runs online (differing system configurations won't affect it). We ourselves were the testers. Time spent testing was the minimum to assure a quality product.

Guidelines

In addition to correctly performing the test types discussed above, there are a few guidelines for dealing with errors discovered via testing. All bugs are documented via TRAC. At the end of each iteration, bugs must not prohibit the system s critical components from functioning.

Quality Goals

At minimum, our goal was to have the critical use cases for our program working. This means that content should be submittable, browsable, and searchable. In the process of performing these actions, the user should not be presented with any unexpected errors. An unexpected error is one that is caused by a faulty system, rather than an message explaining user error (example: "You didn't fill in a required field"). Ideally all errors in every part of the system would be caught, but since a) our code is not 100% complete, and b) the infeasibility of testing every single possible path, we can't achieve this.

Test Case Specifications

TC1: Submit Content

Preconditions: User must be logged in. Sequence of Actions: User types title, selects file, types tags, selects language, and selects category. User presses submit button. User is prompted to confirm submission. User presses confirm button. User is presented with thank you message.

TC2: Browse Content

Preconditions: None Sequence of Actions: User clicks a category (repeat as needed). User clicks a content title. User presented with content information page.

TC3: Search Content

Preconditions: None Sequence of Actions: User types search terms. User selects desired language. User presses search button. User is presented with search results.

Results

TEST PLAN

Outline

  • Table of contents
  • Goals for test
  • Basic Testing Strategies
  • list of resources needed
    • pc
    • people
    • time
  • Schedule
  • Test case specification
    • TC1:
      • precondition:
      • sequence of events
      • postcondition
  • Results
    • Example: table
      • test case, tester 1, tester2, test3, tester4, tester5
      • PASS/FAIL
  • Explain reason of failure