ELDERS Test Plan, Matson-1

ELDERS Test Plan, Matson-1

CS 411W Lab III

Prototype Test Plan/Procedure

For

ELDERS

Prepared by: Robert Matson, Purple Group

Date: 04/29/13

Table of Contents

1Objectives

2References

3Test Plan

3.1Testing Approach

3.2Identification of Tests...... 3

3.3Test Schedule...... 7

3.4Fault Reporting and Data Recording...... 8

3.5Resource Requirements...... 8

3.6Test Environment

3.7Test Responsibilities...... 8

4Test Procedures

4.1Test Case Names and Identifiers

5Traceability to Requirements...... 39

List of Tables

Table 1. ELDERSprototype identification of test cases...... 3

Table 2. ELDERS prototype test schedule...... 7

Table 3. Traceability matrix for the ELDERS prototype...... 39

1

ELDERS Test Plan, Matson-1

1Objectives

ELDERS is a language revitalizing project to help keep endangered languages from dying out.To make sure the ELDERS project is working functionally, we set up test cases to ensure every possible test will result in a working output. This documentation will show what the test cases have been tested for the prototype. We want to have no issues or errors happening when any user is on it.

(this space intentionally left blank)

2References

Matson, Robert. (2013). Lab I – ELDERS Product Description. Norfolk, VA: Author.

Matson, Robert. (2013). Lab II – Prototype Product Specification for ELDERS. Norfolk, VA: Author.

(this space intentionally left blank)

3Test Plan

The following sections of the test plan will discuss the types of tests to be performed, the testing schedule, reporting procedures, resource requirements, the testing environment, and team member responsibilities.

3.1Testing Approach

Performance of the ELDERS prototype will be verified through a variety of different tests. An example is being able to edit your registered user profile.

3.2Identification of Tests

As shown below, the group has split up the test cases. Each category ID has been grouped by a specific description. The test case ID corresponds to the category ID number. The test cases have different descriptions matching with objective of the test case number.

Category ID / Description / Test Case ID / Test Case Description / Objective
1 / Access Control / 1.1 / View access tiers and tier permissions / Show that access tiers and permissions are implemented.
1.2 / Request higher tier status / Show a user may request a higher tier status.
1.3 / Create new access tier / Demonstrate process of creating a new access tier.
1.4 / Change default account tier / Verify that the default tier may be changed.
1.5 / Edit account tiers / Show that the permissions for an access tier may be edited.
1.6 / Verify Access checks / Show that all access checks are in place.
2 / User Accounts / 2.1 / Create new user / Prove that an account can be created.
2.2 / Alert user if username already exists / Show that username redundancy is prevented
2.3 / Verify password requirements / Verify that the password restrictions are in place.
2.4 / Login as existing account / Demonstrate that registered users are able to log in.
2.5 / Login with incorrect information / Show that invalid logins call an error.
2.6 / Reset account password / Verify that a password may be reset.
2.7 / Change notification settings / Demonstrate that a user may change their notification preferences.
3 / Voting / 3.1 / Council to vote on suggested word(s) / To expand the Nottoway Language
3.2 / Restrict only one vote per council member / Ensure that the Council can only make one vote on a suggested word.
3.3 / User change vote / Change vote due to common error.
3.4 / Words that have reached threshold mark as approved / When the majority of votes are in the words favor.
3.5 / Able to add new word to dictionary / Expand the dictionary upon “approved” words.
4 / Searching / 4.1 / Search Nottoway words in English / To test whether searching by English returns the correct information.
4.2 / Alert of failed search / To notify the user that the word searched is not in the database.
4.3 / Suggest and show suggestions of failed search / To suggest alternatives for a returned fail search
4.4 / Edit words that are suggested / To give Council an opportunity to change suggested words
4.5 / Search Nottoway words in Nottoway / To test whether searching by Nottoway returns the correct information.
4.6 / Alert of failed search / To test whether users receive a notification when they search for a Nottoway word that doesn’t exist.
4.7 / Nottoway filtered by letter / To test that the word filter functions correctly.
5 / History / 5.1 / History of the Nottoway viewable / To test that the Nottoway history is displayed.
6 / Suggestions / 6.1 / Suggested words by users / To test a list of suggested words by users
6.2 / Prompt to suggest word if no suggested word exists / To notify the suggested word if the word does not exist
6.3 / User input of suggested word / To test that a suggested word can be inputted
6.4 / User submission of suggested word / To test that a suggest word can be submitted
7 / Administration / 7.1 / Edit website settings / To test that the settings on the website have been changed by the administrator
7.2 / Edit website permissions / To test the website's permission level
8 / Forum / 8.1 / Access Forum / To test that the Forum is displayed.
8.1 / Create access controlled sub forums / To test that a user’s forum account is the same as their ELDERS account.
9 / Database / 9.1 / View the Nottoway database / Viewing the database proves that it exists.
9.2 / Backup the database / Prove that the DB is being backed up.
9.3 / Create a MySQL user / Users must exist in order to access the DB.
9.4 / Assign users sufficient database privileges / Make sure that user’s privileges are set.
9.5 / View the ALPHABET table schema / Make sure that the ALPHABET table has the expected columns.
9.6 / View the HISTORICAL_DICTIONARY table schema / Make sure that the table has the right columns.
9.7 / View the EXPANDED_DICTIONARY table schema / Make sure that the table has the right columns.
9.8 / View the NUM_VOTES table schema / Make sure that the table has the right columns.
9.9 / Prove password encryption / Make sure that the passwords are encrypted in the DB.
10 / Language / 10.1 / Access syllabary chart / To test that the Syllabary is displayed.
10.2 / Browse grammar / Verify the user can access the Nottoway grammar.
11 / Versatility / 11.1 / Can be viewed on mobile devices / Confirming the ability for ELDERS to be viewed on a mobile device.
11.2 / Can be functional for all major web browsers / Confirming that ELDERS can be used correctly through different web browsers that are commonly used.
12 / Maintenance / 12.1 / Check for software update / Show that there is a means to update software used by ELDERS

Figure1ELDERS Identification of cases

3.3 Test Schedule

The test schedule can be viewed below. The first five minutes, missing from the table, will be used to briefly introduce the Nottoway. It will also describe how our prototype has fulfilled the tribe’s needs.

Table 2 ELDERS Prototype Test Schedule

3.4 Fault Reporting and Data Recording

A team member will have the role as a test recorder. This member keeps track on which test case needs to be done. That member will record what test case passes or fails. Each fail will require a fault report on what test case went wrong while keeping the data of the failed output.

3.5Resource Requirements

The use of a virtual machine is required. We want to be able to access into the backend of the prototype. The frontend needs access to a pc or laptop with a working network connection. The user will then be able to see and test the ELDERS prototype.

3.6Test Environment

The test will be done inside a room with access to a wired or wireless network connection. The room needs a working projector to be able to display a large screen of the presentation of the prototype. A computer or laptop will be connected to it so the tester can display the prototype. Two presenters will be at the front discussing and explaining what is happening on the displayed prototype. The tester will write down details throughout the inputs and outputs during the presentation.

3.7Test Responsibilities

In the ELDERS prototype presentation, there will be two presenters, two test users, a database monitor, and a test recorder. The primary speakers will be Tatiana Livingston and George Calhoun, who will work together in presenting the prototype. One of the two presenters will take the other’s job if he/she is unable to attend. They will also provide an introduction and narrative of each test case. Ben Cortina and Josh Fetherolf will be test users as well as operating the computer. Taking turns, each test user will execute the test case, explain what they are doing as well as show the expected results. Terry Stilwell will be the database monitor, responsible for displaying and explaining changes to the database when applicable. Robert Matson is the test recorder. He will keep the testing on track and will record what has been done and the result. He will also record what needs to be done should any errors occur.

(this space intentionally left blank)

4Test Procedures

Detailed test procedures have been created by ELDERS. This will ensure that the test cases will meet the requirements needed for the prototype.

4.1Test Case Names and Identifiers

The ELDERS group met all the requirements needed for the specific test cases. The test cases have initialized steps, inputs, procedures, and expected results.

Test Category: 1 / Description: View access tiers and tier permissions
Test Case: 1.1 / Case Name: Access tier viewing / Version: 1.0 / Written By: Ben Cortina
Requirements Fulfilled: 3.1.1.1 / Purpose: Show that access tiers and permissions are implemented.
Setup Conditions:

• Logged in as user with permission to view access tiers

Test Case Activity / Pass/Fail / Comments / Expected Result
1Access administration page
2Access access tiers
3Click on a access tier to view permissions / Access tiers are displayed. Permissions for each tier are visible.
Test Category: 1 / Description: Request higher tier status
Test Case: 1.2 / Case Name: Requesting tier status / Version: 1.0 / Written By: Ben Cortina
Requirements Fulfilled: 3.1.1.1.2 / Purpose: Show a user may request a higher tier status.
Setup Conditions:

• Logged in as existing user

Test Case Activity / Pass/Fail / Comments / Expected Result
1Request higher tier status
2Log in as user with permissions to set access tiers
3VIew pending tier promotion requests.
4Note the request is listed / Access tier request is noted.
Test Category: 1 / Description: Create new access tier and prove its creation
Test Case: 1.3 / Case Name: Create new access tier / Version: 1.0 / Written By: Ben Cortina
Requirements Fulfilled: 3.1.1.2.1, 3.1.1.2.3, 3.1.1.2 / Purpose: Demonstrate process of creating a new access tier.
Setup Conditions:

• Logged in as user with permissions to create access tiers

Test Case Activity / Pass/Fail / Comments / Expected Result
1Access administration page
2Access access tiers
3Create new tier
4Set existing user to newly created tier / Access tier is created and user is assigned to the new tier.
Test Category: 1 / Description: Change the default account tier
Test Case: 1.4 / Case Name: Change default account tier / Version: 1.0 / Written By: Ben Cortina
Requirements Fulfilled: 3.1.1.1.1, 3.1.1.2.2, 3.1.1.2 / Purpose: Verify that the default tier may be changed.
Setup Conditions:

• Logged in as user with permissions change access tiers settings

Test Case Activity / Pass/Fail / Comments / Expected Result
1Access administration page
2Access access tiers
3Change default access tier.
4Create a new account.
5Show that new account is in the new default tier / User account should be in the default tier.
Test Category: 1 / Description: Change a access tier’s permissions
Test Case: 1.5 / Case Name: Edit account tiers / Version: 1.0 / Written By: Ben Cortina
Requirements Fulfilled: 3.1.1.2, 3.1.1.2.4, 3.1.1.2.5, 3.1.1.2.5.* / Purpose: Show that the permissions for an access tier may be edited.
Setup Conditions:

• Logged in as user with permission to edit access tiers

Test Case Activity / Pass/Fail / Comments / Expected Result
1Access administration page
2Access access tiers.
3Click on a access tier to edit permissions
4Show every permission from 3.1.1.2.5 is listed
5Edit at least one permission.
6Prove that the permission is changed for an account in that access tier / Permission change is reflected in accounts from that tier.
Test Category: 1 / Description: Verify Access checks
Test Case: 1.6 / Case Name: Access Checks / Version: 1 / Written By: Ben Cortina
Requirements Fulfilled: 3.3.2.2 / Purpose: Show that all access checks are in place.
Setup Conditions:
●Component source code accessible
●Logged in as user with permission to edit access tiers
Test Case Activity / Pass/Fail / Comments / Expected Result
For each permission,
1Access the user tiers.
2Show that the permission is assignable
3In the relevant source code, show the section that prevents access
Once,
4Attempt to access with an account that does not have the permission / The access is prevented for the tested feature and every feature uses a similar system to block access.
Test Category: 2 / Description: The method of creating an account
Test Case: 2.1 / Case Name: Account Creation / Version: 1.0 / Written By: George Calhoun
Requirements Fulfilled: 3.1.1.3, 3.1.1.3.1, 3.1.1.3.3, 3.1.1.3.4 / Purpose: Prove that an account can be created.
Setup Conditions:

• At website home page

Test Case Activity / Pass/Fail / Comments / Expected Result
1Click the Create an Account Link
2Fill in Account Details
3Click Register / account is created
Test Category: 2 / Description: The method of creating an account
Test Case: 2.2 / Case Name: Account Creation / Version: 1.0 / Written By: George Calhoun
Requirements Fulfilled: 3.1.1.3.2 / Purpose: Show that username redundancy is prevented
Setup Conditions:
●At website home page
●An already created account
Test Case Activity / Pass/Fail / Comments / Expected Result
1Click the Create an Account Link
2Fill in Account Details with an already used username
3Click Register / receive notification that username is already in use
Test Category: 2 / Description: The method of creating an account
Test Case: 2.3 / Case Name: Account Creation / Version: 1.0 / Written By: George Calhoun
Requirements Fulfilled: 3.1.1.3.3.* / Purpose: Verify that the password restrictions are in place.
Setup Conditions:
At website home page
Test Case Activity / Pass/Fail / Comments / Expected Result
1Click the Create an Account Link
2Fill in Account Details with an improper username
3Click Register / Receive alert that the password does not fulfill the requirements
Test Category: 2 / Description: Making sure registered users are able to log into ELDERS
Test Case: 2.4 / Case Name: log in / Version: 1.0 / Written By: George Calhoun
Requirements Fulfilled: 3.1.1.4, 3.1.1.4.1, 3.1.1.4.2 / Purpose: Demonstrate that registered users are able to log in.
Setup Conditions:
●At website home page
●Account created
Test Case Activity / Pass/Fail / Comments / Expected Result
1Fill out User name
2Fill out password correctly
3click log in / be logged into your account
Test Category: 2 / Description: Making sure only registered users are able to log into ELDERS
Test Case: 2.5 / Case Name: Incorrect log in / Version: 1.0 / Written By: Ben Cortina
Requirements Fulfilled: 3.1.1.5, 3.1.1.5.1, 3.1.1.5.2 / Purpose: Show that invalid logins call an error.
Setup Conditions:
●At website home page
●Account created
Test Case Activity / Pass/Fail / Comments / Expected Result
1Fill out User name
2Fill out password incorrectly
3click log in
4Repeat steps 1-3 with incorrect username / Does not allow the user to sign in and presents them with an error
Test Category: 2 / Description: Regaining access to an account when the password is forgotten
Test Case: 2.6 / Case Name: password reset / Version: 1.0 / Written By: George Calhoun
Requirements Fulfilled: 3.1.1.6.* / Purpose: Verify that a password may be reset.
Setup Conditions:
●At website home page
●Account created
Test Case Activity / Pass/Fail / Comments / Expected Result
1Click forgot password link
2fill out box with an incorrect email address for account
3repeat step 2 with correct email
4use information in email to reset password / Error message after step 2
email sent to the email address after step 3
Test Category: 2 / Description: Changing why and how often you receive notifications
Test Case: 2.7 / Case Name: change notification settings / Version: 1.0 / Written By: George Calhoun
Requirements Fulfilled: 3.1.1.8 / Purpose: Demonstrate that a user may change their notification preferences.
Setup Conditions:
●At website home page
●Account created
●Account logged in
Test Case Activity / Pass/Fail / Comments / Expected Result
1go to account setting
2change notifications / notifications changed.
Test Category: 3 / Description: Voting
Test Case: 3.1 / Case Name: Suggested Word Vote / Version: 1 / Written By: Josh
Requirements Fulfilled: 3.1.2.1 / Purpose: To expand the Nottoway Language
Setup Conditions:

• User logon tab in voting section.

Test Case Activity / Pass/Fail / Comments / Expected Result
1User accesses administration page
2User searches for word
3User prompted of non-existing word
4Selects either search or vote
5User changes their vote / User has the opportunity to expand the Nottoway language by voting.
Test Category: 3 / Description: Voting
Test Case: 3.2 / Case Name: Voting Restrictions to One. / Version: 1 / Written By: Josh
Requirements Fulfilled: 3.1.2.1.1 / Purpose: Ensure that the Council can only make one vote on a suggested word.
Setup Conditions:

• User logon and each vote only is obtained only once.

Test Case Activity / Pass/Fail / Comments / Expected Result
1User access administration page
2User votes on word
3Restricted to one vote per user / A user has one vote.
Test Category: 3 / Description: Voting
Test Case: 3.3 / Case Name: Able to Change Vote. / Version: 1 / Written By: Josh
Requirements Fulfilled: 3.1.2.1.2 / Purpose: Change vote due to common error.
Setup Conditions:

• User logon tab in voting section.

Test Case Activity / Pass/Fail / Comments / Expected Result
1User accesses administration page
2User accesses past votes
3User changes vote / Users are able to change vote at a later time. This updates in the database as still counting only one vote per member.
Test Category: 3 / Description: Voting
Test Case: 3.4 / Case Name: Threshold Stamp of Approval. / Version: 1 / Written By: Josh
Requirements Fulfilled: 3.1.2.1.3* / Purpose: When the majority of votes are in the words favor.
Setup Conditions:

• Database will have a count on each word.

Test Case Activity / Pass/Fail / Comments / Expected Result
1Enough user votes have been received
2Words that have reached threshold of votes are marked as approved / Total number of user votes have reached the majority so the suggested word is now added.