Test Plan and Cases (TPC) s7

Acceptance Test Plan and Cases Version 3.0 Version no x.xx

Acceptance Test Plan and Cases (ATPC)

LEMA Pilot School Integrated Scheduling System

Team Number 12

Version History

Table of Contents

Test Plan and Cases (TPC) i

Version History iii

Table of Contents iv

Table of Tables v

Table of Figures vi

1. Introduction 7

2. Test Strategy and Preparation 8

2.1 Hardware preparation 8

2.2 Software preparation 8

2.3 Other pre-test preparations Error! Bookmark not defined.

2.4 Requirements Traceability 8

3. Test Identification 9

3.1 Test Identifier 10

3.2 Test Identifier Error! Bookmark not defined.

4. Resources and schedule 16

4.1 Resources 16

4.2 Staffing and Training Needs 17

4.3 Schedule 17

17

ATPC_RDCP_F12b_T12 Version Date: 02/06/12

Test Plan and Cases (TPC) Table of Contents

Table of Tables

Table 1: Requirements Traceability Matrix 8

Table 2: TC-01-01 Student current progress page 10

Table 3: TC-01-02 Student grade history entry Error! Bookmark not defined.

Table 4: Testing Schedule 17

17

ATPC_RDCP_F12b_T12 Version Date: 02/06/12

Test Plan and Cases (TPC) Table of Contents

Table of Figures

Figure 1: <Figure Title> Error! Bookmark not defined.

17

ATPC_RDCP_F12b_T12 Version Date: 02/06/12

Acceptance Test Plan and Cases Version 3.0 Version no x.xx

1.  Introduction

The purpose of the Acceptance Test Plan is to verify that the system delivered to the customer satisfies all of the win conditions identified by the stakeholders.

A successful run of the ATP will validate the system for delivery to the customer.

Win conditions will be matched with test cases and test cases will be developed in such a way that a passing test will verify that the win conditions associated with that test case have been met. Every win condition will be associated with at least one test case.

Unit testing will be preformed of the individual pieces of the system while system level testing will be done to validate the higher level win conditions. Integration testing will be done as pieces of the system are added to the project though this testing will not be included as part of the acceptance test plan as this testing does not validate win conditions.

2.  Test Strategy and Preparation

The project’s test strategy is using Boundary value testing using exit and entry criteria for continuous Unit and Integration Testing. These will be prioritized by using the Value based Test Prioritization. For test preparation – we need a similar environment like the development environment - at least for the Unit and Integration and Functionality testing. For the final go-live testing any machines at the client’s end will be used.

Also since we will be following an agile incremental development and more so a test based development approach – at least for all the critical test cases, we will be using the unit tests to validate our agile continuous integration.

2.1  Hardware preparation

There is no special hardware preparation needed for testing

2.2  Software preparation

The main Software that will require testing will be FET i.e. our scheduling system. Also the client will be required to use Firefox 7.1 or higher version web browser. We will be making use of MySql as a database.

2.3  Other pre-test preparations

There are no other test-preparations required.

2.4  Requirements Traceability

Table 1: Requirements Traceability Matrix

3.  Test Identification

3.1  Test Identifier

TC-01 Automated Schedule Generation – Data Validation Testing

All the data entered by the APSCS into the system – Course details, the data we get from the other system and the ones selected by the students and the counselors must always be validated. We must at all times have correct entries in our database so that we can go ahead with automated schedule generation.

3.1.1  Test Level

This is a software item level test – is a User Interface input test.

3.1.2  Test Class

This is an erroneous test. Around boundary conditions it should fail when we go beyond and succeed when we are within the boundary.

3.1.3  Test Completion Criteria

·  All data entered is valid and does not violate any Database or code constraint.

·  The automatic Schedule Generation steps can proceed with Class Section splitting

3.1.4  Test Cases

Table 2: TC-01-01 Student current progress page

3.2  Test Identifier

TC-02 Student Course Registration Testing

The students must be able to see a default list of courses (some are mandatory and some are optional) as soon as they access the course registration page. Also the page allows them to exactly select the number of courses they can take and not lower or higher than that.

3.2.1  Test Level

This is a software item level test – is a User Interface input test and a Database integrity test.

3.2.2  Test Class

This is an erroneous test. Around boundary conditions it should fail when we go beyond and succeed when we are within the boundary.

3.2.3  Test Completion Criteria

·  All data entered is valid and does not violate any Database or code constraint.

·  The students are enlisted for registration into the selected courses

3.2.4  Test Cases

Table 3: TC-01-01 Student current progress page

3.3  Test Identifier

TC-03 Segmentation of Classes

Depending on the number of students enrolled by the counselors in every course, and the go ahead by the APSCS to start the first step of the automated scheduling – classes are segmented correctly into sections depending on the minimum and maximum number of students constraints.

3.3.1  Test Level

This is a software item level test – is a Database – stored procedure test.

3.3.2  Test Class

This is an erroneous test. Around boundary conditions it should fail when we go beyond and succeed when we are within the boundary.

3.3.3  Test Completion Criteria

·  Every course is successfully split into one or more sections and this information is now available for the APSCS to input teachers for each course.

3.3.4  Test Cases

Table 4: TC-01-01 Student current progress page

3.4  Test Identifier

TC-04 Student Progress Tracking Tests

The students are able to view their progress with respect to the various universities – as to where they stand and how many more units they need to complete the university/college requirments.

3.4.1  Test Level

This is a software item level test – is a User Interface output test with Web Service (REST) testing across the two systems..

3.4.2  Test Class

This is a UI view test where the UI displays the progress of the students.

3.4.3  Test Completion Criteria

·  The students are able to view their progress successfully and the data viewed is in fact correct and reflects the student’s current status.

3.4.4  Test Cases

Table 5: TC-01-01 Student current progress page

3.5  Test Identifier

TC-05 Database Management – Export of CSV files testing

The COTS in use – FET needs data that is valid from the database in the form of CSV files that must be exported out. There are three types of expected data – Teachers, Courses and Activities i.e. Teacher Course Mapping. Thus this export must be tested.

3.5.1  Test Level

This is a software item level test – is a Data coherence test.

3.5.2  Test Class

This is a validation test that all data exported actually is correct.

3.5.3  Test Completion Criteria

·  The CSV files have all the details that are mapped correctly from the database and there are no missing entries.

3.5.4  Test Cases

Table 6: TC-01-01 Student current progress page

3.6  Test Identifier

TC-06 Integration with the Family Accountability System – via REST services

We need to integrate the two systems together as we share database entities such as Student and Teacher information (resides in their system), Course Information (residing on our system) and Student Grade history information (on their system again).