Detailed Design Document
CPSC 451 Supplier Group #1

Department of Computer Science
University of Calgary
27 February 1997

Page maintainer: Terrence Asgar-Deen
terrence@cpsc.ucalgary.ca
  • Terrence Asgar-Deen
  • Patrick Chan
  • Thomas Hui
  • Carsten Jaeger
  • Matthew Johnson
  • Brian Low
  • Hoang Nguyen
  • Kevin Pattison
  • Csaba Suveges
  • Jeremy Tang
  • Leena Thakkar
  • Al-Amin Vira
  • Lin Zhang
    •

    Testing Plan

    While developing the Sales Routing System, dHACs Software will be undertaking extensive testing to ensure a top quality system is delivered. This section describes the testing plans that will be followed, the rationale behind the plan and the results expected.

    dHACs has been meticulous in preparing the test plans. A team, led by a Quality Assurance Leader (QAL), has been created to map out the overall strategy, how the major functions would be addressed and how comprehensive detail testing will be accomplished. This team will also be responsible for conducting the tests proposed according to the planned schedule.

    To ensure that the dHACs team delivers the final product on time and within budget, testing tasks will be assigned to various team members by the QAL. Test results will be reported back to the QAL by individual testers using an Email form. The QAL will compile results, relay requests for changes, bug fixes and other corrections to the design team leader and ensure that testing schedules and methodologies are being adhered to.

    The QAL will follow a monitoring procedure to ensure that team members have an opportunity to use various testing techniques including walkthroughs, input/output testing and logic testing. Since the system is being developed using Microsoft Access, many of the traditional tests that would be conducted using other tools will not be required for every field in the Sales Routing System. For example, if a text item is entered into a numeric field, MS Access will trap this and alert the user accordingly. Once it is proven that this works as expected by Access, it can be assumed with relative certainty that other such errors will be detected.

    In the overall design document, a number of testing techniques had been mentioned. The ones most appropriate to this environment are related to black box testing. The white box testing techniques are not relevant to the solution being proposed since it is not planned to test the underlying integrity of the MS Access product itself. If the solution being proposed were to be written in C++ or Smalltalk instead, there would be more justification for using these techniques.

    Summary of Testing Assignments

    The following testing schedules are planned:

    Unit Testing ongoing to submission deadline of Mar 17
    Integration ongoing to submission deadline of Mar 24
    Functional ongoing to submission deadline of Mar 31
    Performance ongoing to submission deadline of Mar 31
    Acceptance Mar 31 to Apr 4

    Note dHACs will be asking for one or two representatives from Peachy Business Forms to work with during for the Acceptance Testing Phase. It is anticipated that this will require approximately 4 hours of work.

    Detailed Testing Assignments

    Unit Testing will be assigned in the following manner:

    Integration Testing Assignments

    Matthew Johnson

    As various unit tests are completed and signed off, Matt will start bringing them into the Integration Test. Any problems will be documented and passed to the QAL for subsequent action (most likely passing to the Design/Coding Team for correction). If a change occurs to the design/code as a result of this problem being corrected, it will be resubmitted for testing and subsequent re-integration.

    Integration Testing Plan

    In order to successfully complete integration testing, the following stages will be employed:

    Stage 1 Initially, an administrator user will be created to facilitate all testing. Following this, the various user modules (add, delete, modify, view, list) will be tested. Once this is performed, several users will be added to the database to test further modules.
    Stage 2 Once these users are added, the system login facilities will be thoroughly tested using the newly added users. At this point, the user functions and the system login functions should be working correctly.

    Before any other functions are tested, the change password functions will be tested to ensure optimal password security for the system.

    Stage 3 Following testing of the user functions, the various customer-related functions will then be integrated into the system. This is done after user function testing since this will also enable the route list to be set up for each user. The customer functions to be tested at this stage are add, modify, delete, view and list. The modify route list for the salesperson will be tested here as well.

    Once testing is completed, several customers will be added to the database with differing territories. This will also enable tests of the automatic salesperson assignment feature (automatically assigns the customer to whichever salesperson happens to be servicing that territory).

    Stage 4 This stage will involve the integration and testing of the product functions (add, delete, modify, view, list). Several sample products will be added to the database to enable the order functions to be tested.
    Stage 5 Following the creation of several sample products, the ordering functions (add, modify, delete, view, list) will be integrated into the system and tested. Also, modules that could not be completely tested because of a dependency on an order database are tested here (for example, the Delete Customer module). Once testing is completed, several sample orders will be created in the order database for further testing .
    Stage 6 At this point, the entire system is integrated and we proceed to System Testing. This will involve re-testing all the modules that were tested in prior stages to ensure that the addition of new modules did not have an adverse effect on previously correct modules. This will be the most rigorous part of the testing. An entire hypothetical database will be created and all functions will be tested using this database. This will simulate the actual system procedures that will be used by the customers themselves.

    Detailed Tests for Individual Modules (Unit Testing)

    The details of conducting individual module testing has been carefully planned by the dHACs Testing Team. Processes related to logging onto the system are tested first to ensure only valid users gain access and are correctly identified. Secondly, processes related to customers are tested so that sample data can be put into the database, viewed and modified. Thirdly, processes related to Peachy Business Forms products are tested. Fourthly, processes related to orders placed by Peachy Business Forms employees are tested followed by any miscellaneous processes not yet covered. Once these tests have been successfully completed, integration testing can proceed.

    Notes

    Logging Onto the System

    Goal ensure proper functioning of the login procedure and to ensure security protocols are satisfied.
    Test Method Manual login attempts using valid and invalid combinations of usernames and passwords.
    Test Cases Expected results/success criteria:
    1. Login as a valid administrator with User gains access to system valid password. User gains acess to system with administrative security access.
    2. Login as a valid salesperson with User gains access to system valid password. User gains acess to system with limited (salesperson) security access.
    3. Login with an invalid username. No access granted. Message "Access Denied" displayed.
    4. Login with valid username but invalid No access granted. password. Message "Access Denied" displayed.

    Customer Modules

    List Customers

    Goal To successfully list customers according to list criteria as specified by user.
    Test Method Attempt to list customers using the following three criteria: -all customers -user's customers -daily route
    Test Cases Expected results/success criteria:
    1. List with "all customers" criteria. List all active customers stored in the system (alphabetically).
    2. List with "user's customers" criteria. List all active customers assigned to the user (alphabetically).
    3. List with "view daily routes". List all active customers on the criteria daily routes for the next seven days.

    Add New Customer

    Goal To successfully add a new customer to the customer database.
    Test Method Attempt to add new customers that are not in the database. Attempt to add new customers that already exist in the database.
    Test Cases Expected results/success criteria:
    1. Add a valid customer that is not already Customer is successfully added present. to customer database.
    2. Add a customer with invalid/missing data Error message indicating which fields. field needs to be corrected. Prompt for re-entry of data in appropriate field.
    3. Add an already existing customer Error message indicating that (company name already exists on system). customer already exists in the database.

    Modify Customer

    Goal To modify a customer that exists in the customer database.
    Test Method Modify all fields for a customer in the database.
    Test Cases Expected results/success criteria:
    1. Modify with all fields valid. Customer successfully modified.
    2. Modify with one or more fields invalid. Error message indicating which field needs to be corrected. Prompt for re-entry of data in appropriate field

    Delete Customer (Administrator ONLY)

    Goal To successfully delete a customer existing in the database (flag the customer as inactive).
    Test Method Delete various customers in the database.
    Test Cases Expected results/success criteria
    1. Delete customer without pending orders. Customer successfully deleted.
    2. Delete customer with pending orders. Error message indicated that orders are pending. Prompt with warning to delete pending orders.

    View Customer

    Goal To view all data fields pertaining to a particular customer.
    Test Method View various customers in the database.
    Test Cases Expected results/success criteria:
    1. View an arbitrary customer. Customer data fields displayed correctly.

    Modify Route List

    Goal To modify the route list of the user (if the user is a salesperson). To modify the route list of any user (if the user is an administrator).
    Test Method Modify various route lists both as an administrator and as a salesperson.
    Test Cases Expected results/success criteria:
    1. User modifies their own route list. Route list successfully modified.
    2. Administrator modifies another user's Route list successfully modified. route list.

    Product Modules

    Add New Product (Administrator ONLY)

    Goal To successfully add a new product to the product database.
    Test Method Attempt to add new products that are not in the database. Attempt to add new products that already exist in the database.
    Test Cases Expected results/success criteria:
    1. Add a valid product that is not already Product is successfully added present. to product database.
    2. Add a product with invalid/missing data Error message indicating which fields. field needs to be corrected. Prompt for re-entry of data in appropriate field.
    3. Add an already existing product Error message indicating that (product and motif already exist on system). product already exists in the database.

    Modify Product (Administrator ONLY)

    Goal To modify a product that exists in the product database.
    Test Method Modify all fields for a product in the database.
    Test Cases Expected results/success criteria:
    1. Modify with all fields valid. Product successfully modified.
    2. Modify with one or more fields invalid. Error message indicating which field needs to be corrected. Prompt for re-entry of data in appropriate field.

    Delete Product (Administrator ONLY)

    Goal To successfully delete a product existing in the database (flag the product as inactive).
    Test Method Delete various products in the database.
    Test Cases Expected results/success criteria:
    1. Delete product in database. Product successfully deleted.

    View Product

    Goal To view all data fields pertaining to a particular product.
    Test Method View various products in the database.
    Test Cases Expected results/success criteria:
    1. View an arbitrary product. Product data fields displayed correctly.

    List Products

    Goal To successfully list all products contained in the database.
    Test Method Attempt to list all products by various sorting criteria.
    Test Cases Expected results/success criteria:
    1. List all products with sorting order List all products in database sorted specified. by user-specified criterion.

    Administrative Modules

    Add New User (Administrator ONLY)

    Goal successfully add a new user to the user database.
    Test Method Attempt to add new users that are not in the database. Attempt to add new users that already exist in the database.
    Test Cases Expected results/success criteria:
    1. Add a valid user that is not already User is successfully added present. to user database.
    2. Add a user with invalid/missing data Error message indicating which fields. field needs to be corrected. Prompt for re-entry of data in appropriate field.
    3. Add an already existing user Error message indicating that (username already exists on system). user already exists in the database.

    Modify User (Administrator ONLY)

    Goal To modify a user that exists in the user database.
    Test Method Modify all fields for a user in the database.
    Test Cases Expected results/success criteria:
    1. Modify with all fields valid. User successfully modified.
    2. Modify with one or more fields invalid. Error message indicating which field needs to be corrected. Prompt for re-entry of data in appropriate field.

    Delete User (Administrator ONLY)

    Goal To successfully delete a user existing in the database (flag the user as inactive).
    Test Method Delete various users in the database.
    Test Cases Expected results/success criteria:
    1. Delete user in database. User successfully deleted.

    View User (Administrator ONLY)

    Goal To view all data fields pertaining to a particular user.
    Test Method View various users in the database.
    Test Cases Expected results/success criteria:
    1. View an arbitrary user. User data fields displayed correctly.

    List Users (Administrator ONLY)

    Goal To successfully list all users contained in the database.
    Test Method Attempt to list all users by various sorting criteria.
    Test Cases Expected results/success criteria:
    1. List all users with sorting order List all users in database sorted specified. by user-specified criterion.

    Change User Password (Special)

    Goal To successfully change a password.
    Test Method Attempt to change passwords as administrator and salesperson (both user's own password and other users' passwords).
    Test Cases Expected results/success criteria:
    1. An administrator changes a valid user's Password changed password to a new valid password.
    2. An administrator changes a valid user's Error message indicating password to an invalid password. Invalid password. Prompt for re-entry.
    3. An administrator changes an non- Error message indicating existing user's password. invalid user.
    4. A user changes his/her old password Password changed. to a new valid password.
    5. A user changes his/her old password Error message indicating to an invalid password. Invalid password. Prompt for re-entry.
    6. A salesperson changes another Error message indicating user's password. Unauthorized access. Password unchanged.

    Order Modules

    Add New Order

    Goal To successfully add a new order to the order database.
    Test Method Attempt to add new orders that are not in the database. Attempt to add new orders that already exist in the database.
    Test Cases Expected results/success criteria:
    1. Add a valid order that is not already Order is successfully added present. to order database.
    2. Add a order with invalid/missing data Error message indicating which fields. field needs to be corrected. Prompt for re-entry of data in appropriate field.
    3. Add an already existing order Error message indicating that (order and motif already exist on system). order already exists in the database.

    Modify Order

    Goal To modify a order that exists in the order database.
    Test Method Modify all fields for a order in the database.
    Test Cases Expected results/success criteria:
    1. Modify with all fields valid. Order successfully modified.
    2. Modify with one or more fields invalid. Error message indicating which field needs to be corrected. Prompt for re-entry of data in appropriate field.

    Delete Order

    Goal To successfully delete a order existing in the database (only if the order has been fulfilled).
    Test Method Delete various orders in the database.
    Test Cases Expected results/success criteria:
    1. Delete order in database. Order successfully deleted.

    View Order

    Goal To view all data fields pertaining to a particular order.
    Test Method View various orders in the database.
    Test Cases Expected results/success criteria:
    1. View an arbitrary order. Order data fields displayed correctly.

    List Orders

    Goal To successfully list all orders contained in the database.
    Test Method Attempt to list all orders by various sorting criteria.
    Test Cases Expected results/success criteria:
    1. List all orders with sorting order List all orders in database sorted specified. by user-specified criterion.

    Test Evaluation Form

    The following form will be used in all testing correspondence within the team:

    TEST PERFORMANCE SHEET

    Name of Tester  
    Date of Test  
    Stage of Integration (0 if unit testing)  
    Module(s) Tested  
    Test cases/scenarios performed  
    Results of Test  
    Errors noted  
    Recommendations for corrective action  
    Comments  

    This form will be e-mailed to the Quality Assurance Leader by each member involved in the testing of the system. Any corrective actions/comments will be forwarded to the Coding Team by the QAL.