4-TuneGURU Test Plan

8/12/2019 4-TuneGURU Test Plan

1/28

A Software mentor for musicians

Tune URU .

Test Plan Document

CS 440Software Engineering (Fall 2012)

Team 7

Girish Jambagi

Preetham Nagaraj

Steve Nekoliczak

Tony Dakhoul

11/26/2012


2/28

Contents

A Software mentor for musicians ................................................................................... ..............................0

Tune GURU ....................................................................................................................................................0

. .............................................................................................................................................................0

1. Introduction............................................................................................................................................3

2. Relationship to other documents ......................................... ............................................... .....................33. System Overview......................................... ................................................ ......................................... ...4

3.1 Testing Process............................................................................... ................................................ .....4

4. Features to be tested/not to be tested ................................................ ................................................ .....5

4.1 Features to be tested ................................... ................................................. ............................................5

4.2 Items that will not be tested ....................................................................... .............................................. .6

5. Pass/Fail criteria .......................................... ................................................ ......................................... ...6

5.1 Component Pass/Fail criteria ................................ ............................................... ......................................6

GUI test: ...................................................................................... .......................................... .................6

Basic function test ....................................................................................... ......................................... ...6

Add a student ............................................................................ ............................................... ..............6

Update/delete student ........................................ ............................................... .....................................7

Add a course ........................................ ................................................ ........................................ ...........7

Update/delete Course ......................................... ............................................... .....................................7

5.2 Integration Pass/Fail criteria ................................ ................................................ ......................................7

5.3 System Pass/Fail criteria ................................ .............................................. ..............................................76. Approach ............................................... ............................................... ........................................ ..........8

6.2 Integration Testing .......................................... ............................................... .....................................9

6.3 System Testing ........................................ ................................................ ......................................... .10

6.3.1 Function Validation Testing ........................................................... ....................................... .................10

6.3.2 Performance testing .............................................................. ........................................ .......................10

7. Suspension and Resumption ........................................ ............................................... ...........................11

7.1 Build Acceptance Test (BAT) ............................................. ............................................... ...................11

7.2 System Design Changes................................................................ ................................................ ......11

8. Testing materials (Hardware/software requirements) ........... ...................................... ............................11

9. Test Cases ............................................ ................................................. ....................................... .........12

10. Testing Schedule................................................ ............................................... .................................23

11. Test Incident Report ........................................ ............................................... ...................................24
http://d/UIC-CS/CS440%20-%20Software%20Engineering%20I/TuneGURU%20Test%20Plan.docx%23_Toc341653458http://d/UIC-CS/CS440%20-%20Software%20Engineering%20I/TuneGURU%20Test%20Plan.docx%23_Toc341653459http://d/UIC-CS/CS440%20-%20Software%20Engineering%20I/TuneGURU%20Test%20Plan.docx%23_Toc341653459http://d/UIC-CS/CS440%20-%20Software%20Engineering%20I/TuneGURU%20Test%20Plan.docx%23_Toc341653460http://d/UIC-CS/CS440%20-%20Software%20Engineering%20I/TuneGURU%20Test%20Plan.docx%23_Toc341653460http://d/UIC-CS/CS440%20-%20Software%20Engineering%20I/TuneGURU%20Test%20Plan.docx%23_Toc341653459http://d/UIC-CS/CS440%20-%20Software%20Engineering%20I/TuneGURU%20Test%20Plan.docx%23_Toc341653458


3/28

Summary .................................................................................................................................................24

Incident Description .................................................................................................................................24

Impact .....................................................................................................................................................25

Test incident report identifier......................................... ............................................... ...........................25

Summary .................................................................................................................................................25

Incident description..................................................................................................................................25Impact .....................................................................................................................................................25

12. Test Summary Report .............................................. ................................................ ..........................26


4/28

1.Introduction

This document is a high-level overview defining our testing strategy for the Tune Guru application. Its

objective is to communicate project-wide quality standards and procedures. It portrays a snapshot of the

project as of the end of the planning phase. This document will address the different standards that will apply

to the unit, integration and system testing of the specified application. We will utilize testing criteria unde

the white box, black box, and system-testing paradigm. This paradigm will include, but is not limited to, the

testing criteria, methods, and test cases of the overall design.

Test Objective:

The test objectives are:

The objective our test plan is to find and report as many bugs as possible to improve the integrity of our

program. Although exhaustive testing is not possible, we will exercise a broad range of tests to achieve

our goal. Our user interface to utilize these functions is designed to be user -friendly and provide easy

manipulation of the components. The application will only be used as a demonstration tool, but we

would like to ensure that it could be run from a variety of platforms with little impact on performance or

usability.

To determine design inconsistencies and usability problem areas within the user interface and content

areas. Potential sources of error may include:o Navigation errors failure to locate functions, excessive keystrokes to complete a

function, failure to follow recommended screen flow.

o Presentation errorsfailure to locate and properly act upon desired information in

screens, selection errors due to labeling ambiguities.

o Control usage problemsimproper toolbar or entry field usage.

Exercise the application or web site under controlled test conditions with representative users. Data willbe used to access whether usability goals regarding an effective, efficient, and well -received use

interface have been achieved.

Establish baseline user performance and user-satisfaction levels of the user interface for future testing

evaluations.

2.Relationship to other documents

Testing of application Tune Guru is defined based on previous documents of this project.

Black box tests relating to use cases are developed from the use case diagram(s) in the RAD(requirements analysis document).

Black box tests derived from functional requirements are developed from the requirements lists in the

RAD.

Performance tests derived from nonfunctional requirements are developed from the nonfunctiona

requirements in the RAD.

Structured (unit/white box) tests are generated from the OOD (Object Design Document). The specifictests are developed from the OOD component diagram of each of the components.

Integration tests are developed from the SDD (System/Architecture Design Document). The integration

tests generally come from the overall package diagram describing the architecture of the system. The

architecture is also used to help in determining the integration test approach. The test environment

(hardware/software) is also derived from the SDD.


5/28

A visualization of the relationships to the other documents can be seen in the diagram below.

3.System Overview

Tune Guru is tested for various assertions against many expected outputs. The subsystems and components

that are put to test are to be assured of the required functionality and performance. The testing is done at

different levels of abstraction and may be briefed up as follows:

The system is tested based on the services provided by each subsystem. Each subsystem has layered decomposition and each layer is tested separately.

The dependencies between the objects or components of each layer are also tested.

To test the above subsystems/components, we have followed various testing strategies and techniques to

suit to our testing requirements and those will be explained in detail in the following sections.

3.1 Testing Process

This section describes the initial plan or the overview of the whole to be undertaken for testing. It represents

the planning, the plan for execution and also plan for the deliverables.

The following represents the overall flow of the testing process:

1. Identify the requirements to be tested. All test cases shall be derived using the current Program

Specification.

2. Identify which particular test(s) will be used to test each module.

3. Review the test data and test cases to ensure that the unit has been thoroughly verified and that the

test data and test cases are adequate to verify proper operation of the unit.

4. Identify the expected results for each test.

5. Document the test case configuration, test data, and expected results.

Project PlanRequirements

Analysis

System

ArchitectureDesign

Object Design

Test Plan / Test Cases

-schedule, resources1

1 -Structure/Unit Tests

1

-Component Diagrams

1

-Black Box Tests 1

-Use Cases, Requirements

1

-Integration Tests

1

-Class/Package Diagrams

1


6/28

6. Perform the test(s).

7. Document the test data, test cases, and test configuration used during the testing process.

8. Successful unit testing is required before the unit is eligible for component integration/system testing.

The Figure 1 explains the process of Test plan. i.e. the test plan evolution and what are strategies tha

shall be followed.

Figure 1: Test Process Flow

The diagram above outlines the Test Process approach that will be followed.

a. Organize Test Plan: It involved creating a System Test Plan, Schedule & Test Approach, and assigningresponsibilities.

b. Design/Build System Test: It involved identifying Test Cycles, Test Cases, Entrance & Exit Criteria,

Expected Results, etc. In general, test conditions/expected results will be identified. We will thenidentify Test Cases and the Data required. The Test conditions are derived from the Program

Specifications Document.

c. Build Test Environment: This included accomplishing/building hardware, software and data set-ups that

are required for testing.

d. Execute System Tests: The tests identified in the Design/Build Test Procedures will be executed. A

results will be documented.

4.Features to be tested/not to be tested

This section, focusing on the functional aspects of testing, identifies all features and combinations of features to

be tested. It also describes all those features that are not to be tested and the reasons for not testing them.

4.1 Features to be tested

Components developed in house

The components developed by our team will be tested unless otherwise noted below in section 4.2.

Components developed by outsource vendors

Components outsourced to be developed specifically for this project where this test team has primary

responsibility to test and validate those components will be tested.

Components outsourced to be developed specifically for this project where the outsourced vendor isresponsible for development as well as testing will not be tested as components by the component

testers. Rather, the test results from the vendor will be reviewed by the test leads, and if they pass

review, the component will be tested in-house starting with integration test.

a. Organi ze Test

Plan

b. Design SystemTest

c. Build Test

environment

d. Execute

System tests


7/28

4.2 Items that will not be tested

Third party and Off-The-Shelf components

It is assumed that third party components were evaluated and the pros and cons properly weighedbefore choosing that component with our software. The interfaces to those components will be

tested, but not the functionality or performance those components.

This includes any third party websites and GPS devices or software.

Infrastructure components

The actual database software utilized is assumed to work as designed and will not be directly tested

for functionality. Performance tests will be done during system test with respect to GUI response time

that will involve the database. However, no testing will be done directly against the database.

The internet/WIFI backbone will be utilized during testing, however, no tests will be written executed

to directly test the communications backbone.

5.Pass/Fail criteria

This section specifies generic pass/fail criteria for the tests covered in this plan. They are supplemented by

pass/fail criteria in the test design specification. Note that fail in the IEEE standard terminology means

successful test in our terminology.

5.1 Component Pass/Fail criteria

Tests executed on components only pass when they satisfy the signatures, constraints, and interfaces

dictated by the Object Design Specification for that component. This includes positive tests, negative and stress

tests, and boundary tests. If a test exhibits a product failure to meet the objectives of the object design

specification, it will fail and a defect/issue will be recorded for further consideration.

GUI test:

Pass criteria: Students, Instructors could use this GUI to interface with the backend database without anydifficulties

Result: pass

Database testPass criteria: Results of all basic and advanced operations are normal.

Result: pass

Basic function test

Add a studentPass criteria:

Each student should have following attributes: Student ID(unique), Name, Address and Phone number.Result: pass

The retrieved Student information by viewing Student detail should contain the four attributes.

Result: pass


8/28

Update/delete student

Pass criteria:

The record would be selected using the student ID

Result: pass

Updates can be made on full. Items only: Name, Address, Phone number

Result: pass

The record can be deleted if there are no Courses selected by user.Result: Partially pass. When no course issued by user, he can be deleted. But when there are courses

Issued by this user, he was also deleted. It is wrong.

The updated values would be reflected if the same Student's ID is called for.

Result: pass

If Student were deleted, it would not appear in further search queries.Result: pass

Add a course

Pass criteria:

Each Course shall have following attributes: Title, Instructor name, Duration, Time-table.

Result: pass

The retrieved Course information should contain the four attributes.

Result: pass

Update/delete CoursePass criteria:

The Course item can be retrieved using the Title Name

Result: did not pass. Cannot retrieve using the Title name

The data items which can be updated are: Title, Instructor name

Result: pass

The Course can be deleted only if no user has issued it.Result: partially pass. When no user has issued it, pass. When there are user having issued it, did not pass

The updated values would be reflected if the same Title name is called for

Result: pass If Course were deleted, it would not appear in further search queries.

Result: pass

5.2 Integration Pass/Fail criteria

Tests executed on integrated components only pass when they satisfy the signatures, constraints, and

interfaces dictated by both the object design specification and the system architecture specification. This

includes positive tests, negative and stress tests, boundary conditions, and tests that explicitly manipulate the

interface environment (such as the physical connection to the database server).

If a test exhibits a product failure to meet the objectives of both the object design specification and the

system architecture specification, it will fail and a defect/issue will be recorded.

5.3 System Pass/Fail criteria

Tests executed against the system use the functional requirements, non-functional requirements, and use

cases as the oracle to determine pass or fail.


9/28


10/28

For the Playback class, the opposite test cases need to be done. A note will be given as input for Playback to

play, and it will play the correct frequency. To keep the played notes in a range humans can comfortably listen

to, the input notes will be restricted to C3 through B3.

Equivalence Class Value for Note Input Test Type

0 Hz (Silence) Invalid Input Boundary

130.81 Hz C3 Equivalence

138.59 Hz C#3 Equivalence

146.83 Hz D3 Equivalence

155.56 Hz D#3 Equivalence

164.81 Hz E3 Equivalence

174.61 Hz F3 Equivalence

185 Hz F#3 Equivalence

196 Hz G3 Equivalence

207.65 Hz G#3 Equivalence

220 Hz A3 Equivalence

233.88 Hz A#3 Equivalence

246.94 Hz B3 Equivalence

6.2 Integration Testing

Though the system may be divided into modules such as User Interface (UI), the application and the

database module, we consider a different approach. We test the services provided by each objects in themodule. This becomes Service based testing. Under this, we have three modules:

Module 1The Audio interface Module

The interface here does not refer to the user Interface but, the interface of the audio recording system with the

whole system. The Audio recording functionality is tested by testing each method in the Record and Playback

objects. Test cases are developed for each method and test is performed on them. The results are accounted

and factors for integration are considered.

Module 2The Student interface Module

The interface here refers to the functionalities that are to be provided to the student by the system and not

necessarily GUI. The Student object has various methods that give services to the student. Test cases are

developed to test the functionality of these methods and are documented. Factors for further integration are

considered.

Module 3The Instructor interface Module

The interface here refers to the functionalities that are to be provided to the instructor by the system and not

necessarily GUI. The Instructor object has various methods that give services to the instructor. Test cases are


11/28

Component Tests

Integration Tests

Functional Tests

Performance Tests

Use Case Validation Tests

Component

Test Phase

Integration

Test Phase

System

Test Phase

* *

1 *

1 *

1

*

1

*

developed to test the functionality of these methods and are documented. Factors for further integration are

considered.

After the successful completion of testing of the above modules, the modules are integrated together to

perform integration testing. This involves checking the interfacing problem within different modules,

communication issues or any kind of errors that may occur as a result of integration.

6.3 System Testing

The goals of system testing are to detect faults that can only be exposed by testing the entire integrated

system or some major part of it. Generally, system testing is mainly concerned with areas such as performance

security, validation, load/stress, and configuration sensitivity. But in our case well focus only on function

validation and performance. And in both cases we will use the black-box method of testing.

6.3.1 Function Validation Testing

The integrated Tune Guru application will be tested based on the requirements to ensure that we built

the right application. In doing this test, we will try to find the errors in the inputs and outputs, that is, we wil

test each function to ensure that it properly implements the Tune Guru functionalities, and that the resulting

system meets all the requirements.In addition, we will test:

The interfaces to ensure they are functioning as desired (i.e. check if each interface is behaving as

expected, specifically verifying the appropriate action is associated with each mouse_click event).

The interaction between the GUI and the backend repository. In this case the data will be inserted and

check if they are processed in the backend and give the expected output.

6.3.2 Performance testingThis test will be conducted to evaluate the fulfillment of a system with specified performance

requirements. It will be done using black-box testing method. And this will be performed by:

Giving boundary value conditions as inputs and testing the resulting output.

Checking the performance and resource usage during peak system usage. Giving erroneous/invalid input and checking the performance.

Checking for performance in case of continuous and discrete usage of the system.

Test Case alignment with test phases


12/28

7.Suspension and Resumption

This section specifies the criteria for suspending the testing on the test items associated with the plan. It

also specifies the test activities that must be repeated when testing is resumed.

7.1 Build Acceptance Test (BAT) When a build is deemed ready to test by development, a build acceptance test will be run on the

build. The BAT will consist of a broad but shallow set of tests to determine the overall stability ofthe build and decide if it is worth testing.

If the BAT fails on a particular build, testing will suspend until another build is created with any

BAT failure issues fixed, verified by running the BAT again. Testing will resume on a build that

passes the BAT.

Different build acceptance tests will be developed and used for the different test phases.

Component BATs will be small and localized for each of the components. Integration BATs will

vary based on the level of integration testing being performed. The System Test BAT will contain

a set of tests that will utilize each of the components of the system.

7.2 System Design Changes

If at any point in time issues are submitted that require a design change to the system, all testing will besuspended. After the changes to the requirements, system architecture, and object design are made, a review

and updates will be performed of the test specifications to ensure they properly align with the revised system

changes. After updates are made, testing will resume. Tests in the vicinity of the change must all be rerun. A

20% regression of other tests must also be performed to ensure the changes did not adversely affect other parts

of the system.

8.Testing materials (Hardware/software requirements)Hardware required:

A microphone, a playback device (e.g. speakers, headphones), and a sound card are required for testing.

Both the microphone and playback device need to have a standard 3.5mm jack that plugs into a computer's

sound card. The microphone must be a passive microphone, which does not require external power. The

sound card needs to support AC97. Since this audio codec standard is well established, most computers' on-

board sound cards will suffice.

Software required:

Three libraries are required for testing. The FMOD library will be used for the Record class. The MIDI library

will be used for the Playback class. The ODBC library will be used for the Database class.


13/28

9. Test CasesStartup

Test case specification identifier Test_Startup

Test itemsOn Startup

Input specifications

User s tarts tuneGURU

User enters correct credentials User enters incorrect credentials

Output specifications

System starts up and displays login screen

System logs user in as student or teacher based on givencorrect credentials

System informs user that the credentials entered are incorrect

Environmental needsNone

Special procedural requirementsNone

Intercase dependenciesNone

Exit

Test case specification identifier Test_Exit

Test items On Exit

Input specifications User logs out of tuneGURU

User exits tuneGURU application before logging out

User exits tuneGuru application after logging out


System logs user out of tuneGURU

System logs user out of tuneGURU and then exits theapplication

System exits the application

Environmental needs None

Special procedural requirements None

Intercase dependencies None

Register to classTest case specification identifier Test_Register_to_class

Test items Student class-Register_to_Class method


Student enters valid credentials to login

Student enters invalid credentials to login

Student chooses a course section that is open

Student chooses a course section that is closed

Student adds a course by filling in valid details

Student adds a course by filling some fields with invalid details

Output specifications Student login is successful. Student enters his profile


14/28

Student login unsuccessful. Login is blocked after 3consecutive wrong attempts.

Student is redirect to course registration page.

Student is notified that the current section for the course is fulland is not redirected to course registration page.

Student is registered for the class and the number of seatsavailable is decremented by 1.

Student attempt to register to the class is unsuccessful.System prompts student to fill valid details.

Environmental needs none

Special procedural requirements Student shall look up and manage his/her own schedule.

Inter case dependencies None.

Manage Class

Test case specification identifier Test_Manage_class

Test itemsInstructor class-Manage_Class method

Input specifications Instructor clicks on Manage class tab

Output specifications None


Special procedural requirements none

Inter case dependencies

Aggregation of test cases:

Test_Create_class Test_Add_student

Test_Drop_student

Create classTest case specification identifier Test_Create_class

Test items Instructor class-Create_Class method


Instructor enters a valid course code and course name

Instructor enters a course code that is already created

Instructor enters the duration in positive time value within therange of 30min to 150min

Instructor enters the duration as a time value outside the range

of 30min to 150min Instructor selects a schedule that is available

Instructor selects a schedule that is not available

Instructor enters the strength of the class within the range 20to 60

Instructor enters the strength of the class outside the range 20to 60

Instructor chooses an available classroom

Instructor chooses an unavailable classroom


15/28


A new cours e with given course code and name is created

System displays error message Course already exists.Cannot create new course with this course code

The duration of an instruction session is allotted to the course

System displays error message Invalid duration. Please entera value between 30min to 150min

A particular schedule for a week is allotted to the course

System displays error message Schedule not available.Please select an available schedule

The strength of the class is fixed to the entered number System displays error message Invalid class s trength. Please

enter a strength between 20 and 60

The classroom chosen is allocated to the respective courseand the class creation is complete.

System displays error message Classroom unavailable.Please select a room that is listed as available.


Special procedural requirements Instructor decides various parameters himself/herself.

Inter case dependencies None

Add StudentTest case specification identifier Test_AddStudent

Test items Instructor class - AddStudent method


Instructor adds a student within the class strength

Instructor adds a student after the max_count in class strengthis reached


Student is successfully added to the course

System displays an error message Cannot add student. Class

strength has reached the maximum limit


Special procedural requirementsInstructor decides various criterions before selecting a student byhimself/herself.


Drop StudentTest case specification identifier Test_DropStudent

Test items Instructor class - DropStudent method


Instructor drops a student when the class strength is within thevalid range

Instructor drops a s tudent after the min_count in class strengthis reached

Output specifications Student is successfully dropped from the course

System displays an error message Cannot drop the student.


16/28

Class strength has reached the minimum limit


Special procedural requirementsInstructor decides various criterions before dropping a s tudent byhimself/herself.


Evaluate ExamTest case specification identifier Test_EvaluateExam

Test items Instructor class - EvaluateExam method


Instructor selects a students exam that is yet to be evaluated

Instructor selects a students exam whose evaluation is inprogress

Instructor selects a students exam that is al ready evaluatedbut not submitted

Instructor selects a students exam that is evaluated andsubmitted

Instructor gives the grades in the range of predefined gradingscale

Instructor gives the grades not in the range of predefinedgrading scale.


A students exam is chosen for evaluation is opened in anevaluation interface

A students exam is chosen for further evaluation withdocumentation and saved data about the part of evaluationcompleted till date

A students exam is chosen that is already evaluated for thefinal review of the instructor before submission to the system

A students exam is chosen that is evaluated and submitted,but again letting an option for the instructor to re-evaluate

Grading is accepted and posted successfully

Environmental needs None

Special procedural requirementsInstructor decides various criterions before evaluating an exam byhimself/herself.


CreateExercise

Test case specification identifier Test_CreateExercise

Test items Instructor class - CreateExercise method


Instructor will give the set of valid exercise depending on thechapters covered.

Set of valid exercises are given with valid weight age points.

Instructor Gives Out of Syllabus Exercise.

Output specifications Exercise will be stored and will send a notification mail toStudent who are taking or subscribed to that class.


17/28

Tutoring server will return an error with not included in coursesyllabus.

Tutoring server will return an error with MAX exceeded weightage points.

Environmental needs Tutoring server as Test driver and Database as a Test Stub

Special procedural requirements Teacher can create an exercise in flexible time duration

Inter case dependencies Depends on the database and web connectivity

CreateExamTest case specification identifier Test_CreateExam

Test items Instructor class - CreateExam method


Instructor will give the set of exercise depending on thechapters covered with points possible.

Instructor Gives Out of Syllabus Exercise.

Point possible for Exam.

Duration of Exam.


Exam will be stored and will send a notification mail to Studentwho are taking or subscribed to that class.

Tutoring server will return an error with not included in coursesyllabus if exercise in Exam is out of course provided.

Tutoring server will return an error with Exceeded point for theExam if point exceeds Max_oints for Exam

Tutoring server will return an error with Exceeded duration forthe Exam if duration exceeds Duration for Exam

Exam is s tored securelyin Database i f successfullysubmitted.


Special procedural requirements Teacher can create an Exam in flexible time duration


Issue ExamTest case specification identifier Test_IssueExam

Test items Instructor class - Issue_Exam method


Instructor will issue Exam details.

Point possible for Exam.

Duration of Exam. Timing of Exam


Exam will be stored and will send a notification mail to Studentwho are taking or subscribed to that class.

Tutoring server will return an error with not included in coursesyllabus if exercise in Exam is out of course provided.

Tutoring server will return an error with Exceeded point for theExam if point exceeds Max_Points for Exam

Tutoring server will return an error with Exceeded duration for


18/28

the Exam if duration exceeds Duration for Exam

Tutoring server will return an error with Exceeded duration forthe Exam if timings conflicts with other Exam.


Special procedural requirements Teacher can create an Exam in flexible time duration


Take Exam

Test case specification identifierTest_TakeExam

Test itemsStudent class - TakeExam


Student clicks Take Exam

Student selects exam to take

Student completes exam

Student runs out of time Student exits exam before completion

Student exits program before completion

Student chooses to retake exam with tries left

Student chooses to retake exam with no tries left


System displays all possible exams that can be taken

System brings up the exam and starts the timer

System displays score and asks i f the user would like to retakethe exam (assuming he has tries left)

System informs the user that time has run out and displaysscore, then asks if the user would like to retake the exam(assuming he has tries left)

System saves users position in exam for duration of exam.When time is up, the users score is tabulated and the userhas one less try to retake the exam.

System reduces users number of tries by one but does notcalculate score

System brings up the exam again and starts the timer

System informs the user that there are no more tries remaining




ViewExerciseResultsTest case specification identifier Test_ViewExerciseResults

Test items Student class - ViewExerciseResults method

Input specifications Student enters the details of the exercise for which he /she


19/28

want to see exercise results.

Output specifications Tutoring server will return page with exercise results.

Environmental needs None.

Special procedural requirements None.


ViewAggegatedResultsTest case specification identifier Test_ViewAggregatedResults

Test items Student class - ViewAggregatedResults method

Input specifications Student enters the details of the exercises for which he /she

want to see exercise results.

Output specifications Tutoring server will return page with exercise results.

Environmental needs None.



Get Feedback

Test case specification identifier Test_GetFeedback

Test itemsStudent class - GetFeedback


Student clicks Get Feedback

Student clicks Exercise Feedback

Student clicks Exam Feedback

Student clicks Exit


System asks the user what type of feedback should be viewed

System displays users exercise feedback

System displays users exam feedback

System takes user back to the main menu





20/28

LookUp Term

Test case specification identifierTest_LookupTerm

Test itemsStudent class - LookupTerm


Student inputs a term located in the database

Student inputs a term not located in the database

Student inputs a term larger than 128 characters

Student doesnt input anything


System outputs the term and definition along with other info

System informs user that the term is unavailable

System informs the user that all search queries need to be 128characters or less

System informs the user that there was nothing inputted tosearch for



Intercase dependencies None

Take Interval Exercise

Test case specification identifier Test_TakeIntervalExercise

Test items Student class - TakeIntervalExercise method


Student clicks New Interval.

Student clicks Sing Interval.

Student sings a note into the recording device and Recorddetects the student singing the correct note.

Student sings a note into the recording device and Recorddetects the student singing an incorrect note.

Student sings a note into the recording device and Recorddetects no singing from the student.


Playback plays a random note when New Interval button isclicked.

Record starts a 3 second recording device recording whenSing Note is clicked. The New Interval button must beclicked before this.

If Student sings the correct note, Student is given the point andis notified that he sang the correct note.

If Student sings an incorrect note, Student is given no pointsand is notified that he sang an incorrect note.

If Record detects no note sung, the student is notified. Studentis then asked to check their recording device settings. Studentis given another chance to sing the interval after checking theirsettings.

Environmental needs

Record class needs to have a frequency and notedetection to detect the student's voice through Student'srecording device.

Playback class needs to be able to play MIDI notesthrough Student's playback device.


21/28



Arpeggio Exercise

Test case specification identifier Test_TakeArpeggioExercise

Test items Student class - TakeArpeggioExercise method


Student clicks New Arpeggio.

Student clicks Sing Arpeggio.

Student sings the notes into the recording device and Recorddetects the student singing the correct notes.

Student sings the notes into the recording device and Recorddetects the student singing at least one incorrect note.

Student sings the notes into the recording device and Recorddetects no singing from the student for at least one note.


Playback plays a random note and displays a chord namewhen New Arpeggio button is clicked. The played note is theroot note of the displayed chord.

Record starts a recording device recording when SingArpeggio is clicked. The New Arpeggio button must beclicked before this. A one s econd recording is allocated foreach note in the arpeggio. The Sing Arpeggio button must beclicked only once per New Arpeggio cl ick.

If Student sings the correct notes, Student is given the pointand is notified that he sang the correct notes.

If Student sings an incorrect note, Student is given pointsequal to the number of correct notes sung in the arpeggio.Student is notified that he sang an incorrect note andspecifically which notes.

If Record detects no notes sung for at least one of the notes inthe arpeggio, the student is notified. Student is then asked tocheck their recording device settings. The current question isrestarted, and Student is given another chance to sing thearpeggio after checking their settings.

Environmental needs






22/28

Melody Exercise

Test case specification identifier Test_TakeMelodyExercise

Test items Student class - TakeMelodyExercise method


Student clicks New Melody.

Student clicks Sing Melody.

Student sings the notes into the recording device and Record

detects the student singing the correct note. Student sings the notes into the recording device and Record

detects the student singing at least one incorrect note.

Student sings the notes into the recording device and Recorddetects no singing from the student for at least one note.


Playback plays the first note in the melody and displays thebeats per minute (BPM) of the melody when New Melodybutton is clicked.

Record starts a recording device recording when SingMelody is clicked. The New Melody button must be clickedbefore this. The Sing Melody button must be clicked onlyonce per New Melody click. Student is given a one measurelead-in, and then the melody starts with a BPM audiometronome (played through Student's playback device with

Playback). The melody's current note is indicated by an arrowabove the music staff. The duration of the recording isdetermined by the length of the melody taking into account theBPM. Record detects correct notes based on the currentposition (the arrow) of the melody and what Student wassinging at that time.

If Student sings the correct notes, Student is given the pointand is notified that he sang the correct notes.

If Student sings an incorrect note, Student is given pointsequal to the number of correct notes sung in the melody.Student is notified that he sang an incorrect note andspecifically which notes.

If Record detects no notes sung for at least one of the notes inthe melody, the student is notified. Student is then asked to

check their recording device settings. The current question isrestarted, and Student is given another chance to sing themelody after checking their settings.

Environmental needs






23/28

Rhythm Exercise

Test case specification identifier Test_TakeRhythmExercise

Test items Student class - TakeRhythmExercise method


Student clicks New Rhythm.

Student clicks Tap Rhythm.

Student taps the rhythm correctly with their m ouse.

Student taps the rhythm incorrectly with their mouse.


Displays the beats per minute (BPM) of the rhythm when NewRhythm button is clicked.

A metronome plays a tick sound at the specified BPM for aone measure lead-in and for the rest of the melody when TapRhythm is clicked. The metronome ticks are played throughStudent's playback device with Playback. The New Rhythmbutton must be clicked before clicking Tap Rhythm. The TapRhythm button must be clicked only once per New Melodyclick. The rhythm's current note is indicated by an arrow abovethe music staff. The duration of the recording is determined bythe length of the rhythm taking into account the BPM. Correctmouse clicks are detected based on the current position (thearrow) of the rhythm.

If Student taps the correct rhythm, Student is given the pointand is notified that he correctly tapped the rhythm.

If Student taps at least one note at the wrong time, Student isgiven points equal to the number of correct taps hit in therhythm. Student is notified that he sang incorrectly tapped anote and specifically which notes.

Environmental needs Playback class needs to be able to play MIDI notes

through Student's playback device for the metronometicks.



Database Testing:Application involves transactions which are performed both at UI and Database level,

Data loading

Database Migration

Testing DB Schema and Data types

Rules Testing

Testing Stored Procedures and Functions

Testing Triggers

Data Integrity
http://www.softwaretestinghelp.com/category/database-testing/http://www.softwaretestinghelp.com/category/database-testing/


24/28

10. Testing Schedule

The section contains the overall project schedule. It discusses the phases and key milestones as they relate to

quality assurance. It discusses the testing goals and standards that wed like to achieve for each phase of testing

that will be deployed, e.g., Usability Testing, Code Complete Acceptance, Beta Testing, Integrati on Testing,

Regression Testing, System Testing.

The key dates for overall TuneGuru development and Testing are outlined below. For details on the schedule,

refer to the TuneGuru Project Schedule (this document). For details on general Engineering QA deliverables,

refer to the test plan document.

Testing

Activities End Date

Notes Deliverables/Roles

Planning

Phase

10/02/12 Project Plan, Program function

specifications.

High-level test planning activities, which

include preliminary development of

Master QA Plan document, QA

schedule.

Design Phase 10/16/12 The deliverables for this phase are

Program source code and System

design and object design

documents.

Development and Test engineers

participate actively in feature design by

inspecting and reviewing the

requirements and design documents.

As the design documents are

completed, the test engineers are

encouraged to start working on the Test

Plan document and test design

planning.

Code

Complete

-

Infrastructure

11/31/12 The testing team should perform

unit & integration testing before

checking the code into any build.

Test scenarios, expected results, data

sets, test procedures, scripts and

applicable testing tools.

Code

Complete

-Function

11/31/12 Unit testing and code review of

each function component prior tochecking the code into the test

phase.

The deliverables include system-testing

specification, Unit testing specifications,Integration plan.


25/28

Testing

Activities End Date

Notes Deliverables/Roles

Feature

Complete

12/05/12 Bug fixing and regression testing

around the bug fixes. .

All bugs verified and QA documentation

is finalized. Preliminary Test Summary

Reports.

Regression

Test

12/07/12 GUI interface and Regression

Testing.

Complete regression test execution of

complete system and update Test

Summary Reports for regression.

Ship/Live 12/14/12 Product is out. Any unfinished Testing documents

should be complete.

11. Test Incident Report

In this testing process we followed following format test Incident report.

Test Incident Report IdentifierSome type of unique company generated number to identify this incident report, its level and the level

of software that it is related to. The number may also identify what level of testing the incident occurred at. This

is to assist in coordinating software and test versions within configuration management and to assist in the

elimination of incidents through process improvement.

SummaryThis is a summation/description of the actual incident. Provide enough details to enable others to understand

how the incident was discovered and any relevant supporting information such as:

References to: Test Procedure used to discover the incident

Test Case Specifications that will provide the information to repeat the incident

Test logs showing the actual execution of the test cases and procedures

Any other supporting materials, trace logs, memory dumps/maps etc.

Incident DescriptionProvide as much details on the incident as possible. Especially if there are no other references to describe the

incident. Include all relevant information that has not already been included in the incident summary

information or any additional supporting information including:

Inputs

Expected Results

Actual Results

Anomalies

Date and Time

Procedure Step

Attempts to Repeat

Testers

Observers


26/28

ImpactDescribe the actual/potential damage caused by the incident. This can include either the Severity of the incident

and the Priority to fix the incident or both. Severity and Priority need to be defined in the standards documents

so as to ensure consistent use and interpretation, for example:

SeverityThe potential impact to the system

o Mission Critical - Application will not function or system fails

o

Major - Severe problems but possible to work aroundo MinorDoes not impact the functionality or usability of the process but is not according to

requirements/design specifications

PriorityThe order in which the incidents are to be addressed

o ImmediateMust be fixed as soon as possible

o DelayedSystem is usable but incident must be fixed prior to next level of test or shipment

o DeferredDefect can be left in if necessary doe to time or costs

Test incident report identifierIdentifier for this document is TG-001.

SummaryThe development environment planned to use and which seemed very nice, also seems to be very slow and very

unreliable in real use.

Incident descriptionInputs Voice through audio recorder(mic)

Excepted results Everything works properly.

Actual results Slow Recording, Display graph on front end.

Anomalies Recording Noises around the record environment.

Date and time 2012-11-26 18:30:26

Procedure step N/AEnvironment PC, Win07

Attempts to repeatJust use the same procedure.

Testers Steve

Observers Preetham

ImpactSeverity normal. Bug is now fixed.


27/28

12. Test Summary Report

Test Case Summary Results

Summary Assessment Total Number Test Cases % of Total Planned Comments

Test Cases Planned 21 100%

Test Cases Run 2 9.5%Test Cases Reviewed 19 90.47%

Test Cases Passed 19 90.47%

Test Cases Failed 0 0

Test Cases To Be Run 0 0

Test Cases Held 2 9.5%

% of total planned can be calculated as follows:

Total Number Test Cases Run divided by Total Number Test Cases Planned) multiplied by 100

Test Incident Summary Results:

Impact/Severi

ty Level

Total

Reported

Total #

Resolved

% Total

Resolved

Total #

Unresolved

% Total

Unresolved

As discussed

in section 11

total number

of Test

Incident

Reports (TIRs)

associated

with this

impact/

severity level

total number

of resolved

TIRs

associated

with this

impact/

severity level

Total #

Resolved TIRs

for this

impact/

severity level

divided by

total TIRs)

multiplied by

100

total number

of unresolved

TIRs for this

impact/

severity level

Total #

Unresolved

TIRs for this

impact/

severity level

divided by

total TIRs)

multiplied by

100

Combined

Totals

total number

of TIRs

total number

of resolved

TIRs

percent of

resolved TIRs

to total TIRs

total number

of unresolved

TIRs

percent of

unresolved

TIRs to total

TIRs


28/28

Updated Gantt Chart:

Documents

4-TuneGURU Test Plan