Parental Access School System Test Plan

Introduction

Project Overview

Objectives

Scope

Project Schedule

Risk, Assumptions and Dependencies

Risks

Limitations

Dependencies

Resources

Reference Documents

Test Platform

Hardware

Software

Testing Tools (if applicable)

Acceptance Criteria

Interface Quality & Usability Requirement

Functional Requirements

Integration Requirement

Overall Software Quality Requirements

Test Management and Procedures

Modular Testing (Test Cycle 1)

Testing Process

Suspension and Resumption Criteria

Pass/Fail Criteria

Exit Criteria

User Acceptance Testing

Testing Process

Pass/Fail Criteria

Exit Criteria

Introduction

This Test Plan has been prepared to convey the test approach of Parental access school system to Kualitatem team members. It is intended that the QA Team of Kualitatem will utilize this document to execute all tasks in testing life cycle of Parental access school system.

This document includes the Objectives, scope, Schedule, Risks, Assumptions, Resources, Test Management and Procedures.

Project Overview

Parental Access School System gives parents access to real-time information including attendance, grades and assignments etc for their students. With Parental Access School System, everyone stays connected: Students stay on top of assignments, parents are able to participate in their child's progress, and teachers can instantly share information from their grade book with parents. Families with multiple students can also set up their accounts to view all of their students at one time, with one login.

General features of the application are as follows

• The Application will feature four types of users, Master admin login, School admin login, Staff Admin Login & Parent Login

• Master admin can perform the following activities,

1. Register school, parents ,students, Staff Admins
2. Map students to parents, Map school with parents/teachers/students & amp teachers with parents
3. Send Message to Parents & Schools
4. Create and manage News, Polls, Blogs, Gallery, Events, Disciplinary Category, Discussions, Masters of the site and Banners of the Site.
5. View Reports based on possible filtrations.

• The Functional working of sections for school admin will be same as Master admin but for his school only. School admin can change his logo and color theme of his portal.
• Similarly, Functional working of sections for staff admin will be same as Master admin but for his school and Assigned modules only.
• The Functional working of sections for parent admin will be same as Master admin but for his child only, and he can only view the information, communicate with teachers via messages , reply to polls.

Objectives

Primary Objective

A primary Objective of testing parental access school system is to assure that the application meets full requirements, including non-functional and quality requirements and fulfills the use case scenario and keep up the nature of the item.

Secondary Objective

Secondary Objective of Testing parental access school system will be to: distinguish and uncover all issues and related risks, impart all known issues to the venture group, and guarantee that all issues are addressed in a suitable manner before release.

This test plan supports the following objectives.

• Define Scope
• Define Project Schedule
• Define Risk, Assumptions and Dependencies
• Define Resources
• Define Acceptance Criteria
• Define Test Management and Procedures

Scope

The overall purpose of testing the “Parental Access School System” is to ensure that the application meets all of its business, technical and functional requirements.

Modules/Features to be tested include following,

• Master Admin Panel and its associated functionalities
• School Admin Panel and its associated functionalities
• Staff Admin Panel and its associated functionalities
• Parent Login Panel and its associated functionalities

It’s Mandatory to cover following devices and functional testing while testing the requested application,

• Functional testing on one windows browser
• CB testing on 3 windows browsers
• Need to execute test scenarios on 3 apple devices
• Need to execute test scenarios on 3 android devices

Stated below are the Testing activities which will be performed:

• Functional testing
• Interface & Usability Testing
• Regression Testing
• Negative Testing
• Security testing

Project Schedule

Risk, Assumptions and Dependencies

Risks

Below are the risks that can affect the test plan:

• Any enhancement/addition of functionality during testing cycle will increase the risk of un-stability in application.
• Stopper bugs fixation at the end of testing cycle will increase the risk of ripples in rest of the application.
• Changes to the functionality may negate the tests already written and we may lose test cases already written

Limitations

Below are the limitations that can affect the test plan:

• Application will be tested against the requirement and documents shared.
• Incomplete or ambiguous requirements may lead to incorrect testing.

Dependencies

Testing of master admin, school admin, staff admin and parent login will be performed when their credentials will be shared with QA.

Resources

Reference Documents

• PASS_SOWv1.3-2.doc
• Parental Access School System Test Case.xls

Test Platform

The application will be tested using the following hardware and software resources.

Hardware

• 3 Apple devices
• 3 Android devices

Software

• IOS 7
• IOS 8

Testing Tools (if applicable)

Following are the Testing Tools that will be used during the testing:

• JIRA
• Microsoft Excel
• Microsoft Word
• SnagIt

Acceptance Criteria

Testing team will conduct smoke testing to accept the system for detail testing. In case of any showstopper/blocker/issue while acceptance tests, the testing team will inform client. Upon resolving the issues, system will be accepted and detail testing will be started by executing already developed strategy.

Acceptance requirement that the application should meet is divided in to four categories stated below,

Interface Quality & Usability Requirement

Interfaces of the entire application should be stable enough so that QA will proceed towards its functional testing. There should be no redirection error in other words connection from one component to another one should be correct

Functional Requirements

Flornce integration application provided for testing should be functional so that QA may execute it for detail testing. All the widgets in the app should be workable.

Integration Requirement

There should be no issue in interfacing between modules and within sub-systems. No module should be missing or performing in wrong manner. QA will ensure that the system functions together with all the components of its environment as a total system.

Overall Software Quality Requirements

Provided app should be reliable, usable, secure and compatible enough for testing. There should be no major crashing areas.

Test Management and Procedures

Modular Testing (Test Cycle 1)

Testing Process

Modular testing can refer to the testing of modules, that is, it may be the same as unit testing.

Parental Access School System is composed of following modules which are in the testing scope. Therefore currently QA will execute the test cases per module individually to ensure that each module is fully functional as per the requirements.

• Master Admin Panel and its associated functionalities
• School Admin Panel and its associated functionalities
• Staff Admin Panel and its associated functionalities
• Parent Login Panel and its associated functionalities

Suspension and Resumption Criteria

The criteria which is considered for Suspension is stated below,

• Application not assigned to QA at the time indicated in the project schedule.
• Modular testing contains many serious defects which limits the testing activity.
• Adequate resources not available when needed for testing.

If testing is suspended the issue which caused the suspension should be resolved first.

Pass/Fail Criteria

Test executed on the modules only pass when they satisfy the business, technical and functional requirements. This includes functional tests, usability tests, integration tests, security tests, regression test and negative tests.

If a test exhibits a module failure to meet the objects it will then be reported as fail and defect/bug will be reported accordingly.

The Testing Team reports bugs using four levels of severity:

• SEVERITY LEVEL 1 (Crash)

• Loss of Main functionality
• System Crash

• SEVERITY LEVEL 2 (Blocker)

• Any defect that prevents execution of test cases

• Partial loss of access to system
• Performance outside of target service levels
• Unexpected behavior that blocks particular functionality
• Work around exists but is complicated

• SEVERITY LEVEL 3 (Major)

• Field validation
• Minor errors but system still operates
• User friendliness
• Major non-Conformance to GUI standards
• Defect in code, but simple workaround exists

• SEVERITY LEVEL 4 (Minor)

• Cosmetic Defect
• Not affecting the functional operation of system
• Incorrect shade of screen color
• Spelling/grammar errors

Exit Criteria

The exit criterion for the test phase is:

• All planned test cases have been executed.
• Limit of test execution time exceeds.
• Completion of the Final Defect Report

User Acceptance Testing

Testing Process

User Acceptance Testing is directed to guarantee that the application fulfills the needs of the business as indicated in the functional requirements and gives trust in its utilization.

UAT is the final testing performed when system, regression and functional testing is completed. QA will validate the software against all business and functional requirements. QA will also perform additional steps not enlisted in the plan but will remain within the scope.

Pass/Fail Criteria

UAT test will be passed only if the modular testing, functional testing, regression testing, interface & usability testing, negative testing and security testing along with all the test cases have been marked as passed.

Each bug submitted by UAT will be assigned a priority, worked by development, fixed , and re-tested by UAT prior to closure.

Exit Criteria

The exit criterion for the test phase is:

• All planned test cases have been executed.
• All Functionality points identified in the Requirements Specification are present and working.

Confidential Page 19/20/2016