Table of Contents

1. Introduction

2. Resource Requirements

3. Features To Be Tested / Test Approach

4. Features Not To Be Tested

5. Test Deliverables

6. Dependencies/Risks

7. Entrance/Exit Criteria

1. Introduction

Description of this Document
This document is a Test Plan for the Major Requirements Tracking System, produced by Marcus Hartzler and Matt Kraly. It describes the testing strategy and approach to testing QA will use to validate the quality of this product prior to release. It also contains various resources required for the successful completion of this project.

The focus of the Major Requirements Tracking System is to support those new features that will allow easier development, deployment and maintenance of solutions built upon the Major Requirements Tracking System. Those features include:

1. Ability to create a student account and log in, select a major, display all classes required for that major and mark courses as taken.

2. Ability to write in when a course is to be completed.

3. Ability for students to save any changes they make.

4/5. Ability for faculty to create accounts and view students who have them selected/Ability for students to select from registered faculty who can see there information.

6. Ability for a faculty account to add new/edit course information.

7. Ability for a faculty account to edit major requirements information.

8. Ability to send a confirmation e-mail to new users and make them enter a confirmation code to activate their account. As well has have a process to remove an unactivated account after 2 weeks.

Related Documents

http://149.143.223.225/twiki/pub/Main/MajorRequirementsTrackingSystem/Requirementsspecification2012-Complete.doc

Architecture

Schedule and Milestones

Major Tracking System Features



2. Resource Requirements

Hardware

In order to use the Major Requirements Tracking System, the following hardware is required:

  • Any device that has web browsing capabilities.
  • I/O devices for text, screen rendering, and point/click. (Keyboard, mouse, touch screen, monitor etc.)
In order to host the Major Requirements Tracking System, the following hardware is required:

  • A web-server connected to the Internet.
Software

The following software is required to use the Major Requirements Tracking System:

  • A web browser. (Ideal browsers include Firefox, Safari, and Google Chrome.)
The following software is required to host the Major Requirements Tracking System:
  • A MySQL web server
  • An Apache web server with PHP5
  • bash shell script
  • mailx
Test Tools

Apart from manual tests, the following tools will be used:

  • Mozilla Firefox
Staffing

  • Co Program Manager, Developer, and Tester: Marcus Hartzler
  • Co Program Manager, Developer, and Tester: Matt Kraly
Responsibilities

Marcus Hartzler's responsibilities (front end):

  • Make sure that all of the client-side features are working properly. This includes any kind of data-input, input checking before data is sent to the server, website navigation, website stylesheets, client-side code, etc.
Matt Kraly's responsibilities (back end):

  • Make sure that all of the server-side features are working properly. This includes any kind of SQL queries made, any PHP scripts, any emails sent from the server, etc.
Training

To perform the tests listed above, the training is required in the following areas:

  • HTML
  • PHP
  • Javascript
  • Jquery
  • SQL
  • CSS
3. Features To Be Tested / Test Approach

Ability to create an account.

  • Can be tested by anyone at this point, has been tested by us multiple times.
Display all classes required for that major and mark courses as taken
  • Can be tested simply by looking at the website.
Ability to write in when a course is to be completed.
  • Again, can be tested simply by looking at the website
Ability for students to save any changes they make.
  • Can be tested by creating an account, making changes and clicking the save button, then returning later to see if those changes have remained.
Ability for students to select from registered faculty who can see there information.
  • Can be tested by creating faculty accounts and student accounts and noting that the faculty accounts can be added by the students
Ability for faculty to view students who have them selected.
  • Can be tested by creating faculty accounts and noting that they are able to view students who have added them.
Ability for a faculty account to add new/edit course information.
  • Can be tested by editing or adding course information and making sure the changes are saved.
Ability for a faculty account to edit major requirements information.
  • Can be tested by editing major requirements information and making sure the changes are saved.
Ability to send a confirmation e-mail to new users and make them enter a confirmation code to activate their account. As well has have a process to remove an unactivated account after 2 weeks.
  • Can be tested by creating a new account and ensuring the confirmation e-mail is sent and that the activation link actually activates their account.
Media Verification

There is no media necessary for this system other than a web browser.

4. Features Not To Be Tested

It will not be tested extensively with IE.

It will not be tested on mobile devices.

5. Dependencies/Risks

Dependencies

The system is dependent upon the CS server being up and running in order to develop, and also to host the system.

The developers are dependent upon having PC's which they can develop with.

Risks

  1. Data Loss during editing.
  2. Legitimate faculty accounts.
  3. Course and Major information validity.
  4. Students being able to easily see what requirements they have/haven't met.
Major Tracking System Risks


6. Final Test Approach

Our final test approach will be to send out an e-mail to all of the CS Majors asking them to create accounts and test out and evaluate our system based on the following questions:

1. Is this tool helpful to you?

2. Can you see this tool being helpful to others?

3. Was there anything you didn't understand?

4. Was there anything you think could be made easier?

5. Did you find the layout to be neat and efficient?

6. Do you think others would be able to understand this tool?

7. Did it seem as though anything wasn't working correctly?

Doing this will help us evaluate our system based on the software qualities we have talked about in class such as Usability, Learnability, Reliability & Dependability (if many students are trying it), Understandability, Portability, Efficiency, Complexity, Adaptability.

Topic revision: r7 - 2012-05-01 - MarcusHartzler
 
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback