Test Plan

COP4331 Fall 2014

Modification history:

Team Name: Group 6

Team Members:

• Melissa Holguin - email - web page
• Lance Lebanoff - email - web page
• Logan Lebanoff - email- web page
• Matthew Smith - email - web page
• Ryan Villaflores - email - web page
• Kyle Urquhart - email - web page
• Team Page

Contents of this Document

1. Introduction:

Overall Objective for Software Test Activity

Reference Documents

2. Description of Test Environment
3. Overall Stopping Criteria
4. Description of Individual Test Cases

SECTION 1: Introduction

• Overall Objective for Software Test Activity:
• The software test activity will identify errors in the Android application and provide useful information for debugging purposes.
• The software test should thoroughly find any bugs within the system that cause the application to crash or produce incorrect results. Unit testing should be performed for each building block of the software to ensure each function is working properly and independently of other functions. Acceptance testing should also be performed in compliance with requirements set by the client.

Reference Documents:

• Concept of Operations
• Project Management Plan
• SRS
• Test Plan

SECTION 2: Description of Test Environment

The test environment will run on Android smartphones. Tests will be run on multiple models of Android phones to ensure usability on differing screens sizes and OS versions. The developers will perform initial tests on the most basic versions of the application. The client is expected to assist in acceptance testing to guarantee that the software is following the requirements. Beta testers may be utilized to test for usability in regards to the interface. The Android test environment should be similar to the actual software environment.

SECTION 3: Stopping Criteria

• Testing will continue even if problems are found in the system, unless a major problem causes further testing to be impractical or impossible. Each error will be recorded with specific details on how to replicate the error. When testing is complete, the records will be sent back to the respective developers to fix the bugs.
• If no errors are found during testing, more test cases will be created to ensure the software is consistent.
• The software will be deemed ready to deliver when there are no known errors. If a deadline is approaching, then this will be at the discretion of the developers whether to settle with cosmetic errors and workarounds.

SECTION 4: Description of Individual Test Cases

Describe EACH individual test to be run: (so if you plan to run 20 test cases, you would answer the following questions for each of them. Either a tabular format or a bulleted format is acceptable.)

• Test 1:
  • Test Objective: Test adding extra notes in a measure.
  • Test Description: The system should prevent a measure from having too many beats in it.
  • Test Data:
    1. Place 1 whole note and try adding any other note.
    2. Place 2 half notes and try adding any other note.
    3. Place 4 quarter notes and try adding any other note.
    4. Place 8 eighth notes and try adding any other note.
    5. Place 1 half note and try adding a whole note.
    6. Place 3 quarter notes and try adding a half note and so on.
  • Test Conditions: The test will be done in both 4/4 time and 3/4 time. The test will be done in both treble clef and bass clef.
  • Expected Results: The system should warn the user that there are too many beats in this measure and cancel the addition of the note.
  
  
• Test 2:
  • Test Objective: Test recognition of pitch
  • Test Description: The system should recognize the pitch of a note being placed in the staff and add the resulting note to the song.
  • Test Data: Every possible pitch on the staff will be tested and checked if the correct pitch was added to the song.
  • Test Conditions: The test will be done in both treble clef and bass clef. The test will also be done for whole notes, half notes, quarter notes, and eighth notes.
  • Expected Results: The system should add a note with the correct pitch to the song.
  
  
• Test 3:
  • Test Objective: Test pitch recognition for accidentals.
  • Test Description: When a user adds a sharp, flat, or natural to a note, the system should change the corresponding note to the new pitch.
  • Test Data: Add a sharp, flat, and natural to each possible pitch.
  • Test Conditions: The test will be done in both treble clef and bass clef. The test will be done for every possible pitch on the staff. The test will be done for every note length.
  • Expected Results: The accidental should be successfully added to the note on the visible staff, and the corresponding note in the system should change to the new pitch.If the note has an accidental already, it should replace the existing accidental. If the note is a B or E, then the system should prevent sharps from being added. If the note is a C or F, then the system should prevent flats from being added.
  
  
• Test 4:
  • Test Objective: Test insertion of a note to the middle of a measure.
  • Test Description: When a user inserts a note into the middle of a measure, the note should be placed in between two notes.
  • Test Data:
    1. Place a half note before a half note.
    2. Place a quarter note into every spot in between other quarter notes.
    3. Place an eighth note into every spot in between other eighth notes.
    4. Place a half note before 3 quarter notes.
    5. Place a whole note before a half note.
  • Test Conditions: The test will be done in both 4/4 time and 3/4 time. The test will be done in both treble clef and bass clef.
  • Expected Results: The note should be placed in between the two notes, and the corresponding note should be added to the song. The notes after the new note should also change their effective time in the song. If the measure has too many beats, the system should warn the user and cancel the insertion of the note.
  
  
• Test 5:
  • Test Objective: Test key signatures.
  • Test Description: When a user selects a key signature for the song, the system should add that key signature to every staff in the song.
  • Test Data: Every possible key signature of both sharps and flats will be tested. Create a new song with a key signature.
  • Test Conditions: The test will be done in both 4/4 time and 3/4 time. The test will be done in both treble clef and bass clef.
  • Expected Results: Every staff of the song should have the key signature. Each new staff that is added should have the key signature.
  
  
• Test 6:
  • Test Objective: Test music play through.
  • Test Description: When a user plays the song, the pitches and rhythms should be correct for each note.
  • Test Data:
    1. Create a measure of 4 quarter notes and play the song.
    2. Create a measure of 8 eighth notes and play the song.
    3. Create a measure of 2 half notes and play the song.
    4. Create a measure of 1 whole note and play the song.
    5. Create a songs with various notes and rhythms and play the song.
  • Test Conditions: The test will be done in both 4/4 time and 3/4 time. The test will be done in both treble clef and bass clef. The test will be done with various combinations of notes and rhythms.
  • Expected Results: The system should correctly play what is on the sheet music.
  
  
• Test 7:
  • Test Objective: Test exportation of sheet music.
  • Test Description: When a user exports to PDF, the resulting file should look exactly like the music created by the user in the app.
  • Test Data: Create songs with various combinations of notes and rhythms and export to PDF.
  • Test Conditions: The test will be done in both 4/4 time and 3/4 time. The test will be done in both treble clef and bass clef.
  • Expected Results: The system should successfully create a PDF file that looks like the sheet music that was created with the app.
  
  
• Test 8:
  • Test Objective: Test musical forms.
  • Test Description: When a user selects a musical form, the correct example song should appear.
  • Test Data: Select each musical form and check the resulting example song.
  • Test Conditions: See Test Environment.
  • Expected Results: The example song should be the correct song for the chosen musical form.
  
  
• Test 9:
  • Test Objective: Test Facebook share.
  • Test Description: When a user shares their music to Facebook, a dialog box should appear and successfully post a status.
  • Test Data: Create songs with various notes and rhythms and click the Share with Facebook button.
  • Test Conditions: The test will be done in both 4/4 time and 3/4 time. The test will be done in both treble clef and bass clef. The test will be done for multiple Facebook accounts.
  • Expected Results: A dialog box should appear asking for Facebook information. After entering the information, a new status should be created with a link to the PDF of the sheet music.

This page last modified by Melissa Holguin (mellorine@knights.ucf.edu) on 9/18/2014