ACCEPTANCE TEST PLAN. Docket Course Scheduling. For. Version 1.0 February 5, 2013

Transcription

1 ACCEPTANCE TEST PLAN For Docket Course Scheduling Version 1.0 February 5, 2013 Developed by Robert Brown Nathal Fonseka Max Haley Michael Kovalichik Joseph Nelson Basil Nyachogo Raymond Selfridge Prepared for Dario Salvucci Computer Science Department Drexel University

2 Version History Version Author Date Comments 1.5 Joseph Nelson 4/20/13 Revisions 1.0 Nate Fonseka 2/5/13 Final Submission 0.5 Mike Kovalchik 1/25/13 Revised Draft 0.2 Mike Kovalchik 1/18/13 Rough Draft of Tests 0.1 Nate Fonseka 12/8/12 Introduction / Scaffolding 0.0 Rob Brown 12/5/12 Template Table of Contents 1. Introduction Purpose Scope References Definitions and Acronyms Definitions Acronyms and Abbreviations Document Structure Test Approach and Constraints Introduction Test Objectives Test Structure Test Assumptions and Exclusions Assumptions Exclusions Entry and Exit Criteria Entry Criteria Exit Criteria Testing Participants Roles and Responsibilities Page 2 of 17

3 5.2 Training Requirements Reporting Requirements Test Cases Introduction Test Case Specifications Requirements Traceability Page 3 of 17

4 1. Introduction 1.1 Purpose Academic departments annually struggle with the task of scheduling courses and placing teachers. Docket is a web-based decision support system designed to facilitate the course scheduling process through department collaboration. By providing course constraints to the system, Docket attempts to satisfy these constraints and provides an interface to view, filter, and manipulate course schedules. In addition, Docket allows departments to subscribe to schedules from other departments and get up-to-date information on how these schedules change over time. The Drexel University Computer Science department hopes to use Docket for scheduling their next academic year. 1.2 Scope This document provides the plan for the testing activities required for the Acceptance Test Plan of Docket. Docket is a course scheduling tool created for the purpose of scheduling courses for a university level environment. The software system is described in greater detail in the Software Requirements Specifcation for Docket. 1.3 References 1. Software Requirements Specification for Docket 1.4 Definitions and Acronyms Definitions Term Application Programming Interface Definition A specific protocol used as an interface between software components Page 4 of 17

5 Back End Department Front End HyperText Markup Language HyperText Transfer Protocol Java Servlet Java Servlet Container JavaScript Object Notation Representational State Transfer Ruby on Rails Simple Mail Transfer Protocol Uniform Resource Identifier User User Account extensible Markup Language The services, hardware, and software the Front End interfaces with to provide scheduling services An organization within a college or university using Docket for their scheduling services The user interface to Docket A markup language used to communicate content and layout to a web browser The standard communications protocol used to send HTML content over a network A class of Java server applications which respond to requests from clients and serve responses. Commonly used to host web services An application server which hosts Java Servlets and provides the external interfaces required by the Java Servlet specification to the hosted servlets. A human-readable text based data interchange format An architecture which uses standard HTTP verbs to communicate between a client and server A web application framework written for the Ruby programming language A standardized format for sending over a network A string of characters used to identify a resource. Often used to interact with resources over a network such as the World Wide Web An individual who interacts with the Docket scheduling system A collection of information about a user which Docket uses to authenticate and authorize a user's actions within the system A human- and machine-readable markup language for encoding information Acronyms and Abbreviations Acronym API CAS Definition Application Programming Interface Central Authentication Service Page 5 of 17

6 HTML HTTP JSON Rails REST SMTP SRS UI / UX URI XML HyperText Markup Language HyperText Transfer Protocol JavaScript Object Notation Ruby on Rails Representational State Transfer Simple Mail Transfer Protocol Software Requirements and Specification User Interface / User Experience Uniform Resource Identifier extensible Markup Language 1.4 Document Structure This document is divided into sections to better facilitate understanding of the test plan that is being described. Section 2 describes the approach taken in the acceptance test plan process. Section 3 describes the assumptions made and constraints considered while developing this test plan. Section 4 outlines the criteria which have to be satisfied for this test plan to be considered satisfied. Section 5 describes the roles and responsibilities of the individuals participating in the acceptance testing. Lastly section 6 describes all of the test cases that are part of this acceptance test plan and section 6.3 contains a traceability matrix with links to the test cases which cover the listed functional requirements. 2. Test Approach and Constraints 2.1 Introduction This section outlines the approach, techniques, and testing tools which are used during this acceptance test plan for Docket and any constraints which have been considered. Page 6 of 17

7 2.2 Test Objectives The acceptance test plan documents the process which will be used to evaluate the Docket software system and verify whether it meets the specifications listed in the Software Requirements Specification for Docket. 2.3 Test Structure The acceptance test plan consists of a series of Unit, Integration, and System tests to be conducted on Docket which have been selected to adequately cover the client's requirements. It is essential that all the test cases in the acceptance test plan have been performed and their results documented and presented to the client before the system is accepted. 3. Test Assumptions and Exclusions 3.1 Assumptions The acceptance test plan will only cover the following: The functional requirements listed in the Software Requirements Specification The system's usability Consistency of the system's documentation with the implemented system 3.2 Exclusions The acceptance test plan will not cover the following areas: Non-functional requirements of the system Structural integrity of the source code Page 7 of 17

8 Maintainability of the source code 4. Entry and Exit Criteria 4.1 Entry Criteria The following criteria must be met in order for the Acceptance Test Plan to be performed or else the results of the test plan may be inaccurate. The version of Docket being tested matches the version on the first page of this document The testing environment has been verified by the Test Lead 4.2 Exit Criteria The acceptance test plan is considered successful is all of the following criteria are met and a failure otherwise: All test cases testing Priority 1 requirements were successfully passed All test cases testing requirements with a priority other than Priority 1 which failed have been signed off by the Test Lead or a client representative. 5. Testing Participants 5.1 Roles and Responsibilities Test Lead - The individual responsible for ensuring the acceptance test plan is executed as specified by this document. Page 8 of 17

9 Client Representative - A representative or stakeholder from the client organization responsible for verifying that all the requirements for a test case are completed in a satisfactory manner. Tester - An individual or group of individuals responsible for executing the test cases. 5.2 Training Requirements All individuals involved in the acceptance process should be familiar with the Docket User Interface as well as the Software Requirements Specification and any relevant system documentation. 5.3 Reporting Requirements Any failed test case or deviation from expected results must be documented by the Test Lead or Test Participant and submitted to the development group as a problem report or to the client representative for approval to change the test plan to account for this result. 6. Test Cases 6.1 Introduction The test cases presented in this section cover functional requirements and use cases in the software requirements specification. Each test case contains the following information: Name - The name of the test case Preconditions - Conditions necessary to begin the test case Actions - The actions to be performed Page 9 of 17

10 Postconditions - Expected state of the system after the test is executed 6.2 Test Case Specifications T6.2.1 Self-Hosting Service Preconditions The server application has been configured for the test environments database and networking requirements Actions The self-hosting java servlet is executed Postconditions The Docket API is available on the specified interface T6.2.2 Running within a Servlet Container Preconditions The hosting servlet container has been configured for the test environments database and networking requirements Actions The Docket server is deployed into the Java Servlet Container Postconditions The Docket API is available on the specified interface T6.2.3 Running the Docket User Interface Preconditions The Front End rails web application has been configured for the test environment's networking requirements Actions The rails web application is deployed to the testing environment Postconditions The Docket User Interface is available at the specified URI T6.2.4 Logging In as a System Administrator Preconditions The Docket login screen is being Actions The user enters their username and password in the appropriate fields and submits the form Postconditions The user is logged in and the system administration page is Page 10 of 17

11 T6.2.5 Logging In as a Scheduling User Preconditions The Docket login screen is being Actions The user enters their username and password in the appropriate fields and submits the form Postconditions The user is logged in and the main application page is T6.2.6 Failing to Login Preconditions The Docket login screen is being Actions The user enters incorrect username and/or password information in the fields and submits the form Postconditions A message is stating that the login failed and the login page is re T6.2.7 Creating a New Account Preconditions The account registration page is Actions The user enters in their proposed account information and submits the form Postconditions An inactive user account is created and submitted for verification by a system administrator T6.2.8 Deleting a System Administrator Account Preconditions The user is logged in as a System Administrator and the account administration page is Actions The user selects to delete the System Administrator account and confirms their action Postconditions A message is stating that the only System Administrator account cannot be deleted T6.2.9 Deleting a Scheduling User Account Preconditions The user is logged in as a System Administrator and the account administration page is Actions The user selects to delete a Scheduling User account and confirms their action Postconditions A message is stating that the account has been deleted and the user account is removed from the system Page 11 of 17

12 T Verifying a New User Account Submission Preconditions The user is logged in to a user account with the System Administrator role and the account information page is for an inactive account Actions The user clicks the verify button and confirms their request Postconditions The inactive user account is marked as active T Rejecting a New User Account Submission Preconditions The user is logged in to a user account with the System Administrator role and the account information page is for an inactive account Actions The user clicks the reject button and confirms their request Postconditions The inactive user account is deleted from the system T Creating a New Course Preconditions The user is logged in and the course creation page is Actions The user enters the new course's department code, course number, course name, course description, prerequisites and corequisites and then submits the form Postconditions The course is created in the system and a message is to the user indicating as such T Creating a New Instructor Preconditions The user is logged in and the instructor creation page is Actions The user enters the new instructor's name, the number of courses the instructor should teach each term, and the list of courses this instructor is preferred to teach then submits the form Postconditions The instructor is created in the system and a message is to the user indicating as such Page 12 of 17

13 T Creating a New Section Preconditions The user is logged in and the section creation page is Actions The user enters the new section's assigned course, time, term, section number, assigned instructor, location and any corequisite sections then submits the form Postconditions The section is created in the system and a message is to the user indicating as such T Create a Section Conflicting with an Existing Section Preconditions The user is logged in and the section creation page is Actions The user enters a new section whose assigned time and location are the same as an existing section's assigned time and location Postconditions The section is created and a warning is generated stating that there is a scheduling conflict T Creating a Section with an Instructor Conflict Preconditions The user is logged in and the section creation page is Actions The user enters a new section whose assigned instructor and time are the same as an existing section's assigned instructor and time and submits the form Postconditions The section is created and a warning is generated stating that there is a scheduling conflict T Creating a Section with Missing Corequisites Preconditions The user is logged in and the section creation page is Actions The user enters a new section whose assigned course defines corequisites without defining any corequisite sections and submits the form Postconditions The section is created and a warning is generated stating that there are missing corequisites T Scheduling a Section in an External Location Page 13 of 17

14 Preconditions Actions Postconditions The user is logged in using a Scheduling User account and the section creation page is The user enters a new section whose assigned location is not associated with the user account's assigned department and submits the form The section is not created and a message is to the user stating that the location cannot be scheduled by the current user T Creating a New Location Preconditions The user is logged in and the location creation page is Actions The user enters the new location's building code, room number, owned department, and capacity then submits the form Postconditions The location is created in the system and a message is to the user indicating as such T Filtering the Calendar View Preconditions The user is logged in and the calendar view is Actions The user filters the available information using the date, instructor, section, and department filters to display the required information Postconditions The calendar view displays the requested information to the user based on the selected filters T Viewing the Detailed Course View Preconditions The calendar view displays the requested information to the user based on the selected filters Actions The user selects a course or set of courses to display in the detailed course view Postconditions The detailed course view displays the available information to the user based on their selection of courses T Viewing the Detailed Instructor View Page 14 of 17

15 Preconditions Actions Postconditions The user is logged in and the detailed instructor view is The user selects an instructor or set of instructors to display in the detailed instructor view The detailed instructor view displays the available informaiton to the user based on their selection of instructors T Adding a Subscription Preconditions The user is logged in and the subscription page is Actions The user selects a course, instructor, or section to receive notifications about Postconditions The subscription is saved in the system and a message is to the user stating as such T Cancelling a Subscription Preconditions The user is logged in and the subscription page is Actions The user selects an existing subscription to delete and clicks delete Postconditions The subscription is removed the system and a message is to the user stating as such 6.3 Requirements Traceability Requirement R R R R R R R R R4.3.1 R R R4.3.2 R4.3.3 R4.3.4 R4.3.5 Test Cases T6.2.1 T6.2.2 T6.2.3 T6.2.1, T6.2.2 T6.2.1, T6.2.2 T6.2.1, T6.2.2 T6.2.1, T6.2.2, T6.2.3 T6.2.1, T6.2.2 T6.2.4, T6.2.5 T6.2.4 T6.2.5 T6.2.4, T6.2.5 T6.2.8 T6.2.7 Page 15 of 17

16 Page 16 of 17 R4.3.6 T6.2.7 R4.3.7 T R4.3.8 T R4.4.1 T R T R T R T R T R T R T R4.4.2 T R4.5.1 T R T R T R T R4.5.2 T R4.6.1 T R T R T R T R T R4.6.2 T R4.6.3 T R4.7.1 T R T R T R T R T R T R T R T R4.7.2 T6.2.15, T6.2.16, T R T R T R T R4.7.3 T R4.8.1 T R4.8.2 T R T R T R T R4.8.3 T R T R T6.2.21

17 R R R R R R R4.8.4 R R R R R R R R4.9.1 R4.9.2 T T T T T T T T T T T T T T T T Page 17 of 17