Test Plan

PROJECT SECME

Test Plan

EEL5881 SOFTWARE ENGINEERING FALL 2002

Modification history:

Version	Date	Who	Comment
V0.0	08/15/00	G. H. Walton	Template
V1.0	09/29/02	Carthik A. Sharma	Initial Version
V2.0	09/30/02	Santhosh Kumar J.Grandai	Modified as per team review

Team Name: TEAM SECME

Team Members:

Carthik Anand Sharma appcash@yahoo.com www.oocities.org/secmep/carthik.htm
Juan Carlos Vivanco juan@cs.ucf.edu www.oocities.org/secmep/juan.htm
Majid Khan majid_kk@hotmail.com www.oocities.org/secmep/majid.htm
Santhosh Kumar J.Grandai santhu79@hotmail.com www.oocities.org/secmep/santhosh.htm

Contents of this Document

Introduction:

Overall Objective for Software Test Activity

Reference Documents

SECTION 1: Introduction

The software test should ascertain the dependability of the system and ensure that the software is robust enough to handle all the different types of data that could be input by the users and also to ensure that no loss or corruption of data occurs. In view of the security envisaged for the system, the software should prevent the use of the resources without proper authentication. The most important function of the testing process would be to ascertain that the system will not require the full time attention of a software engineer once it is up and running. The data that the system works on includes disparate elements such as dates, integers, and names. The testing will seek to ensure that proper mechanisms exist for checking the validity of data, and that the system meets all the client requirements.

Reference Documents:

SECTION 2: Description of Test Environment

The Test Environment consists of the debugging tools available in the software development environment. The tests will be executed on Pentium – based personal computers running Windows 2000 and Windows NT systems. The systems on which the testing will be done will have the Microsoft Internet Explorer Version 5.0

The testing will be carried out by the software development team. The development team consists of 4 members, the testing will be carried out such that the product modules are tested by the individuals who developed it, and then the individuals in the team who did not have a role in the development of that particular module or feature. The client will also be involved in the testing of the system in the implementation and integration stages. Tests regarding the ease of use and the interface will have a significant input from the client’s side.

The Tests will be carried out in the same environment as that is which the product will operate, as well as on the development tools. During the initial phases, the testing will be carried out using the development tools, and once the software development process is in the implementation and integration phase, the testing will be done in the operating environment

SECTION 3: Stopping Criteria

During testing a defect log will be maintained. The developer will fix the problems in the code and the logic immediately, and once a particular functional unit of the project has been developed it will be tested extensively to see if it completely satisfies the requirements for that module. The defect log will be updated, and the defects will be rectified before testing on the particular unit stops. The unit will then be thoroughly tested again during the integration phase to check for interoperability and compatibility. There will be a meeting of the whole team once in two days, when the detected defects and problems will be discussed. All team members will have the liberty to suggest remedies, and/or alternatives. With regard to testing the approach will be that of a democratic team, with all team members assuming equal responsibilities to find and fix errors.

The software will be deemed fit to deliver only after such time that the software has successfully been tested for all the test conditions, as also for reliable operation with all possible data, as identified in the test cases. All known errors should be fixed before delivery. However the interface of the system needs to be extensively tested by the end users at MECSP for functional ease. All required modifications will be made to the interface before the product is deemed fit for operation.

SECTION 4: Description of Individual Test Cases

Test Case 1 :

· Test Objective : This test seeks to ascertain whether the system allows access to the form only for those users who have a valid User ID and Password.

· Test Description : The Log-In mechanism will be tested with inputs consisting of a set of user ids and passwords that have been identified as being such, and with some random User Ids and passwords. The User ID and password is not case sensitive, and so the test case includes User Id and password inputs in both cases.

Test Inputs:

User ID – jasmith and Password – fall2002 are a valid set of inputs.

a. User ID – jasmith

Password – fall2002

b. User ID – JASmith

Password – fall2002

c. User ID – JASMITH

Password – FALL2002

d. User ID – jasmith

Password – fall2002

e. User ID – JASMI

Password –FALL2001

· Test Conditions : See Test Environment.

· Expected Results : The system is expected to validate the user in case of inputs a,b,c,d and deny access in case of input e.

Test Case 2 :

· Test Objective : This test scenario seeks to ascertain whether the system enforces the deadline for registration.

· Test Description : The registration deadline will be set to the day before the test is carried out, and an attempt will be made to log in as an authenticated user, and to modify the existing record for a particular school. This will be the test school, with the user id “test” and password “test”.

· Test Conditions : See Test Environment

· Expected Results : The system should prompt the user saying that the registration deadline is over, and not provide the form for registration.

Test Case 3 :

· Test Objective : This test seeks to check the functionality of the school coordinators to post queries, messages for the MESCP users.

· Test Description : This test will be carried out by clicking the “post query/message” link. The entry will consist of a string of characters consisting alphabets, numbers and special characters, including the %, & and * characters. Specifically, the posted query will be “ abcDeFgh _ % & * $ # 123 876 ^”

· Test Conditions : See Test Environment.

· Expected Result : The system should send a mail to the email account created for testing purposes with the exact message typed in by the tester.

Test Case 4:

· Test Objective : This test seeks to check the functionality of email being sent to all school coordinators when a new event is placed by the MECSP user.

· Test Description : This test will be carried out by clicking the “compose” link. In the “TO:” box all the email address of the school coordinators will be pulled up automatically, the MECSP Organizer can remove the unwanted email addresses. The MECSP organizer can type in needed information and click the “SEND” button.