FinalTest Plan for

New Password Reset ProcessMarymount University

11/1/2014

James GallahanI have not given nor received help on this assignment.

Table of Contents

Test Scope 1Test Objectives 1Process Overview 2Testing Process 2Testing Strategy 3Entry and Exit Criteria 5

Black Box Testing Phase 5Entry Criteria 6Exit Criteria 6

White Box Testing Phase 7Entry Criteria 7Exit Criteria 7

Bug Tracking/Bug Process 8Expectations 8Roles 9Bug Report Form 10

Roles and Responsibilities 11Development Team 11Testing Team 11

Test Schedule 12Deliverables 13

Test Scope

The purpose of this document is to explain the Test Plan that is to be used by

Marymount University’s ITS Support Team for their New Password Reset Process.

Its objective is to ensure that the new password reset process is efficient and safe.

Four different tests will be conducted, these include, functional, usability, system

and security. The ANSI/IEEE Standard 829 will be followed throughout various

parts of this document.

Test Objective

The objective of this test plan is to discover and report as many bugs or flaws

in the program as possible. It is through this test plan that the efficiency and safety

of the program will be insured. A broad range of tests will be used to insure this.

Marymount University’s New Password Reset program will be tested. The design is

intuitive and very basic to use. There are six major functions that the process needs

to complete. These include, ensuring that the new password is more than 8

characters, includes an uppercase letter, a number and a special character,

validating that the user ID is a current student, require the student to answer a

question from a pool of 5 previously answered questions, require the student to

change their password each semester (must be different than previous passwords),

include a CAPCHA to insure it is not a bot, and finally, provide a link from the MU

Portal. It is imperative that the program is completed prior to the start of the Spring

2015 semester.

1

Process Overview

The following shows the overall flow of the testing process:

1. State the given requirements that need to be tested.

2. Identify which tests will be used to test each specific part.

3. Ensure that the test data and test cases are adequate to verify the proper

operation of the program.

4. Create a hypothesis for the expected results.

5. Perform the tests.

6. Document the test data, test cases and test configuration used during the

testing process.

7. If the testing is unsuccessful, then a Bug Report Form will be created. This

document will include, a description of the test case, the problem that

occurred, a possible cause of this problem, and a sequence of events that lead

to the problem.

8. If the testing is successful, the team can move on to integration testing.

Testing Process

Figure 1: Testing Process

The following diagram explains the Testing Process that will be followed:

3

a. Organize Project involves creating a Test Plan, the Test Approach

b/c. Design & Build System Test involve explaining the Test Cycles, Test Cases, Test

Conditions, the Test Environment, the Entrance & Exit Criteria and Expected

Results.

d. Design Build Test Procedure involves creating procedures for errors and status

reports.

e. Execute System Test involves executing those things defined in parts b,c and d.

This will all be documented along with any Bug Reports that need to be filled out.

f. Signoff will occur when all pre-defined exit criteria has been met.

Testing Strategy

This section outlines the types of tests that will be conducted on the New

Password Reset Process. These tests include functional, usability, stress and

security. The Test Design Document explains how the testing will be documented.

Figure 2: Test Case Template

3

a. Organize Project

b. Design System

Testd. Design

Build Test Proc.

f. Signoffc. Design

Build System

Test

e. Execute System

Test

Tested By:Test TypeTest Case NumberTest Case NameTest Case Description

Item(s) to be tested

1

2

Specifications

InputExpected

Output/Result

Procedural Steps

1

2

3

4

5

6

7

4

Functional - Black Box Testing

Black Box Testing can be useful to the development team as it allows the

team to test the inputs and outputs as if they were the real world end-user. In this

phase, every possible input will be entered to ensure that it acts as it is stated. This

form of testing is important, as the output generated is the same that the real world

end-user would see. Equivalency Partitioning, Boundary Value Analysis and Error

Guessing metrics will be used on this program.

Three Criteria

The Equivalency Partition Method will have generated Test Cases based on

the results.

o This will include inputting an empty value into the text box, and

inputting values that do not include an uppercase letter, a number and

a special character.

Boundary Value Analysis will include inserting 9, 8, 1 and 0 characters,

letters or numbers.

Boundary Value Analysis will have generated Test Cases based on the values

that exceed or are less than the specified boundary values.

Error Guessing will include inserting random variables and making guesses

about possible errors with program.

5

Usability Testing

Usability Testing determines how easily the end user will be able to use the

program. The main important factor in this is the GUI. The developers and end-users

may both have different ideas about what is good and bad design wise. Everything

should be easily accessible and simple to use from the start. If the end-user has to

search for something or take the time to figure out how something works, they will

most likely not use it.

Stress Testing

Stress Testing consists subjecting the program to high amounts of traffic or

to complete tasks that require intense processing. Since it is a web application is it

important to conduct this form of testing. There may be a particular time when

there are many users trying to access it at one time. One of the most common tests

that is conducted includes sending many requests at one time, acting as if there are

many users trying to access it.

Security Testing

Security Testing consists of trying to circumvent the program’s security

measures. This is especially important for this program, as it is a new password

reset program. For that reason, there must be high levels of security in place to

make sure a mal-user does not try to hack into another students account. It can be a

difficult form of testing as the developer needs to have a knowledge of common

security problems, how to fix problems when found and how to generate test cases

to prove there are significant issues in the program

6

Entry and Exit Criteria

This section details the criteria of what will happen if testing is temporarily

stopped, how and when it will be resumed, as well as when the testing phase is

complete. Explaining the information in detail will help map out the impact a bug

has on the program. For the purpose of this paper, everything must be completed by

spring semester of 2015. In order for testing to begin all test cases must be created

and all equipment must be prepped and ready. In order for testing to end all four

testing types must be completed accurately and with no error, meaning all criteria

previously mentioned has been met.

Bug Tracking/Bug Process

The testing process should and will find things within the design of the

program that do not meet the specifications. When this happens it will be explicitly

documented so others can reproduce the bugs. An example of the type of form that

relates to this can be found on

Expectations

What version of the software was the bug found on

Has the bug been documented already

What steps lead up to the finding of the bug

Be specific about the bug

Expected results for how the bug will affect the program

7

What kind of impact will this bug have on the program

The following chart explains the severity levels used when describing the impact of

a bug.

Impact Definitions1 – Fatal Full Halt: If the defect prevents QA from further testing.

2 – Serious Partial Halt: This is a bug that users would experience such as: system crash, not requiring an uppercase letter, a number and a special character, significant QA risk, and major UI defects.

3 – Minor Live Release: A bug that must be fixed before the product is officially completed, content and UI and graphic changes required for release.

Roles in Bug Resolution

Author – Person who finds the bug; someone from the QA Team

Resolver – Person who patches the bug; typically Engineer

Verifier – Person who confirms the bug has been fixed; typically QA Engineer

8

Bug Report Form

MU ITS Software Development Problem Report #___________

Program ____________________________ Release _____________________ Version ______________

Type (1-6) ___________ Severity (1-3) ___________ Attachments (Y/N) _________

1 – Coding 1 – Fatal If yes then what is it: ____________________________________

2 – Design Flaw 2 – Serious ____________________________________________________________

3 – Suggestion 3 – Minor ____________________________________________________________

4 – Documentation

5 – Hardware

6 - Software

Summary of bug _________________________________________________________________________________________________

Can you reproduce the bug? (Y/N) __________

How did you reproduce it?

____________________________________________________________________________________________________________________

____________________________________________________________________________________________________________________

____________________________________________________________________________________________________________________

Suggested Fix (Optional)

____________________________________________________________________________________________________________________

____________________________________________________________________________________________________________________

___________________________________________________________

Reported By: __________________________________________ Date: _________________________

Items Below are for Development Team only

Status ________ Priority (1-5) ________

1 – Open 2 – Closed

Resolution (1-9) ________ Resolution Version ________

1 – Pending 4 – Deferred 7 – Withdrawn by reporter

2 – Fixed 5 – As Designed 8 – Need more information

3 – Irreproducible 6 – Can’t be fixed 9 – Disagree with suggestion

Resolved by: _______________________________________________ Date: _________________________

Tested by: _______________________________________________ Date: _________________________

9

Roles and Responsibilities

Management Team

Project Leader/Manager

Ensures everything is delivered on time and in good quality

Ensures that exit criteria have been achieved before signoff

Regularly reviews testing progress

Raises and manages issues and/or risks

Signoff on testing approach, plans and schedule

Software Quality Assurance Project Leader

Ensures that everything is delivered on time and in good quality

Regularly reviews testing progress

Manage issues and/or risks

Provide proper resources

Testing Team

Test Planner

Ensures that everything is delivered on time and in good quality

Produce quality testing conditions

Regularly report progress

Work with higher up to create review and signoff conditions

Manage testing and help with tester issues

10

Tester

Identify test data

Ensure entrance criteria have been achieved before testing

Execute predefined test conditions

Prepare error reports

Ensure system issues are reported immediately

Ensure exit criteria have been achieved before signoff

Test Schedule

This section explains the testing schedule. It details the different phases and

important milestones. Each phase contains specific goals and standards that would

be ideally achieved before deployment.

11

New Password Reset Milestones

End DateNotes

Planning Phase

12/01/14

High level planning should be completed. Deliverables include: Project Plan and Program function specifications.

Design Phase 12/08/14

This depends on other factors. Deliverables include, Program source code and other design related documents.

Code Complete-Infrastructure

12/15/14

All infrastructure development and functions should be complete. The testing team should have preformed unit & integration testing before checking the code into any build.

Code Complete-Function

12/22/14

Unit testing and code review of each function. This must be completed prior to checking the code into the test phase. Deliverables include system-testing specification, Unit testing specifications, Integration plan.

Feature Complete

12/29/14

Feature clean up and verify remaining bug fixes and regression testing are complete.

Regression Test

01/05/15

All code and GUI interface ready for Regression Testing.

Ship/Live 01/12/15

Program live.

12

Deliverables

Test Plan Document – addresses testing objectives, criteria, standards,

schedule and testing tools

o Functional Testing Plan

o Usability Testing Plan

o Stress Testing Plan

o Security Testing Plan

Test Design Document – addresses results, problems, summary and analysis

o Black Box Test report

o Usability Test report

o Stress Test report

o Security Test report

Bug Report

Test Results Document – addresses the end product of all the test

13

References

Murphy, D. (2013). Software Test Plan - Sorted Binary Tree Application.

14