Software Regression Test Plan Outline

profilethoson
cs459_ip4_1.docx

***Some of the Material in this paper has been repurposed from CS CS455-1501-B-01 with Professor Lemaster, and CS346-1501A-01 with Professor Borrego ***

Software Testing CS459-1601B-01

Testing scenarios for gym membership web based software

02-22-2016

Revision History

Revision

Date

Sections Changed

Reason

Description

Author

1.1

02-22-2016

Original Document

Initial Revision

Initial Revision

Table of Contents

Section 1 Software Testing Environment 4

1.1 Overview 4

1.2 Testing Environment 4

1.3 Organizational Assessment 4

1.3.1 Determine Software Capabilities 4

1.3.2 creating an environment supportive of software testing 5

1.3.3 Determining Staff Competency 5

1.3.4 Determining User Satisfaction 5

1.4 Assumptions 5

Section 2 Importance of unit/usability/system test planning process 6

2.5 Test Identification and Test Levels 7

2.5.1 Component Testing 7

2.5.2 Integration Testing 7

2.5.3 Regression Testing 8

2.6 Planned Tests and Test Schedules 8

2.7 Test Report 8

2.8 Requirements Traceability 8

2.9 Summary 9

Section 3 Characteristics of Test Plans 10

Test Planning Approach 11

Outline of The Test Plan 12

Appendix A 13

5.1 RTM 13

References: 15

4

Section 1 Software Testing Environment

Overview

Membership fees for Devil Dogg Crossfit are determined by the number of classes a member attends however there is no application in place which keeps track of this and individuals are essentially put on the “honor system” whereby they are asked to keep track of the number of classes they attend per week. This system is very disorganized, creates a great deal of confusion, and makes it very difficult to keep track of the members of the gym which in turn makes it very difficult to determine the actual financial health of the gym. To resolve these issues Devil Dogg Database application will be developed and tested during this project lifecycle. The application is a web based software application that allows a gym going customer to determine their membership type, the cost of that membership, and the features the membership provides is required for the Devil Dogg Crossfit company.

Testing Environment

The application will be compatible Windows 7 through Windows 8.1. The compatibility of the application with other OS platform will require specific testing The two tier Thin-client model will be the chosen architecture to host the application. In this model the client is only used to provide an interface to connect to the server. All of the resources and applications reside with the server, and the server is also responsible for data management on the network.

Organizational Assessment

Determine Software Capabilities

The application has a Customer User and an Administrator Account with the functional requirements for the Customer User and owner user being as follows:

· The Customer User shall be able to create unique identifier account along with a password to secure the account.

· The Customer User shall be able to login to the account once it is created.

· The Customer User shall be able to determine their membership type.

· The Customer User shall be able to determine the cost associated with that membership.

· The Customer User shall be able to track the benefits available versus benefits used.

· The Customer User shall be able to read, update, and delete their account when desired.

· The Administrator Account shall be able to determine the number of paying members at the gym.

· The Administrator Account shall be able to determine the membership type associated with each individual user.

· The Administrator Account shall be able to determine the cost of membership for each individual member.

· The Administrator Account shall be able to determine the benefits utilized for each individual member.

· The Administrator Account shall be able to determine the total sum of membership fees per month.

· The Administrator Account shall be able to read, update, and delete member accounts when desired.

creating an environment supportive of software testing

To create an environment supportive of software we will perform the following steps:

1. Determine the software testing model most appropriate for our organization and adopt that model.

2. Determine our current competencies, level of user satisfaction, and software testing capabilities.

3. Develop and implement a plan to improve our current level of user satisfaction, competencies, and software testing abilities.

Determining Staff Competency

When following the steps to create an environment supportive of software testing the current capabilities and competencies will be assessed. This assessment will enable the development of a baseline of our staff competency. The plan we develop will in turn move the baseline in a positive direction allowing the company to compete on a world class level.

Determining User Satisfaction

Usability testing will allow us to determine if the application is on track to meet the user needs and to validate the system design in its current state. The only way to effectively determine if an application meets the user requirements is to collect empirical through a series of usability tests collected from application users. This will make determining the strengths and weaknesses of the applications easier to identify during the early phases of the project and allow us to consistently created updated and improved prototypes.

Assumptions

There are no assumptions at this time. Conditions which must exist for application testing to be comprehensive and on schedule have not yet been defined therefore no assumptions are currently required.

Section 2 Importance of unit/usability/system test planning process

1

Importance of Unit/Usability/System Test Planning Process

Testing means a great deal to engineers and developers because it can detect system issues early in the development process, and provide a means to mitigate those issues. The earlier a defect is identified, the easier it is to mitigate, and Requirements testing allows for the early identification of defects within the system.

The first step in implementing the testing process is to establish the testing plan and establish the testing criteria. The test plan is the project plan for the testing work to be performed however it does not specify the design or contain test cases or test procedures, they do not address that level of detail. Three of the most important reasons to develop a proper test plan are as follows:

1. Test plans guide project thinking. When writing a test plan the most important features of the design are emphasized.

2. Test plans promote communication. A proper test plan and the test planning process requires input from all members of the project. The test plan should influence the think of the project members and the project members should influence the test plan through communication among peers.

3. Test plans help to identify and manage changes in requirements. As a project evolves the requirements will change and the test plan is modified based upon those changes. Updating the test plan keeps the testing aligned with requirements.

Characteristics of Test Plans

A properly developed test plan should include the approach, scope, schedule, and resources of the test activities. The characteristics of a properly developed test plan are as follows:

1. It should identify the features to be tested, the testing tasks, and the tester assigned to complete these tasks.

2. It should identify the test environment, test design techniques, and degree of tester independence.

3. It should identify the entry and exit criteria, the rationale behind that selection and any risks which may require contingency planning.

Test Planning Approach

The approach taken during application testing will emphasize the following objectives:

1. Start small and continue to focus on resolving small issues which will ultimately allow you to conquer the large issues. Conducting a larger number of tests with a smaller number of users allows you continually focus on those small problems, and that focus will allow you to make steady measurable progress (Gothelf, 2011.

2. Continue testing on a regular schedule (weekly at a minimum) throughout the lifecycle of the application. When testing becomes a routine scheduled part of the development process the development becomes used to evaluating and modifying the product according the qualitative insight gained from the usability testing (Gothelf, 2011). This again keeps the problems small and easy to handle.

3. Show the customer the current state of the application on a regular basis. While the application is in a production environment the customer should have a solid idea the current state of the application, and should be providing feedback on how well they believe the application is meeting their needs. This continual dialog will help to prevent misunderstandings and allow the small issues to be observed and resolved quickly.

4. Share the results of the usability testing with all potential users and request feedback on a regular basis. Though the number of users in a usability test should remain small, all potential users should be able to see and provide feedback on the results allowing designers to effective collect empirical data and provide an application that meets all of the user’s needs.

5. Reply to the provided feedback as quickly as possible. When users provide feedback they should receive a response as quickly as possible letting them know that their opinions are being heard and their feedback acted upon.

1.1 Test Plan Outline

Scope

The overall purpose of testing is to ensure the devildogg database application meets all functional and technical requirements. The overall purpose of this test plan is to describe the strategy and overall test plan for the application. The approach illustrated in this document provides the framework for all application testing. The test plan will be updated as required for each subsequent release of the application, and individual test cases will be written for each version of the application that is released.

Component Testing

Component testing utilizes the provided input by the user to receive the output of the system. The expected output of the system is then compared to the actual output to determine the quality of the output. Because the output is compared to set requirements this is usually a form of black box testing where the tester does not require any knowledge of the system.

Integration Testing

Integration testing allows developers to simulate a real world environment for the application and see how the application reacts to the stresses received. Typically there is external hardware and software specifically designed to provide the application with a simulated environment and working conditions which mimic the real world. The results of a simulation should be believable and repeatable. It is usually best to have an independent auditor perform and verify the simulation testing to ensure accuracy and believability. When Unit Testing is complete Integration testing is then performed. Integration testing validates the functionality of the components of a process when they are integrated into a process.

Regression Testing

Regression testing is a type of software which occurs during the maintenance phase of the project when a change to the software or hardware has been made. The goal of regression testing is to uncover “regressions” in the functional areas of the system. After configuration changes, enhancements or patches have been applied to the system. Regression testing will test the compatibility of changed components or parts with the new system and

Planned Tests and Test Schedules

The testing schedule will be defined using the Microsoft Project software to develop a Gantt chard and will break the project into five phases with each phase comprising approximately one week of man hours per phase. A Gantt chart allows you to see the various activities on a project, the start and end date for those activities, which activities overlap in time with each other, and the length of the project as a whole. The ability to obtain that much information with a single glance allows project manager’s to determine the overall status of the project, and individual details regarding project tasks in a quick and efficient manner. When these charts were originally developed it was a very laborious task done by hand and manually updated by hand as the project progressed. At the time that was a disadvantage of the Gantt chart, however modern software has automated the process of updating a Gantt chart, and made it a very simple task to create and maintain a Gantt chart. The disadvantages of a Gantt chart can be the time and expense to generate reports, the cost of training personnel in using the software associated with it, and security concerns if the details of the Gantt chart is placed online.

Test Report

The test report contents will include a summary of the test activities and the final test results. The results will be communicated to the project stakeholders and approved by the project manager. Specifically, the test report will contain a summary of the test strategy,

Requirements Traceability

A requirements traceability matrix allows us the trace requirements from their original development to their final implementation on a timeline which records their origin and final stage of development. This helps us to ensure the design meets the customer needs and helps us to assess the impact of a requirements change. The following table tracks the requirements, and links the requirements test case number. Those test cases are used to verify the usability of the system and ensure that the customer receives exactly what they asked for.

Summary

No matter the type of test or technique used it is vital that the procedures are planned and traceable, and all of the results are documented for later review. The attributes of a good test include uniqueness, the high probability of finding errors, a medium degree of complexity, and proper suitability for the application being tested. When the verification and validation process is properly utilized the result is the elimination of unexpected errors, and the delivery of a system that meets all requirements.

Section 3 Regression Test Plan Outline

2

Regression Testing

Test Risks / Issues

[Describe the risks associated with product testing or provide a reference to a document location where it is stored. Also outline appropriate mitigation strategies and contingency plans.]

Items to be Tested / Not Tested

[Describe the items/features/functions to be tested that are within the scope of this test plan. Include a description of how they will be tested, when, by whom, and to what quality standards. Also include a description of those items agreed not to be tested.]

Item to Test

Test Description

Test Date

Responsibility

Test Approach(s)

[Describe the overall testing approach to be used to test the project’s product. Provide an outline of any planned tests.]

Test Regulatory / Mandate Criteria

[Describe any regulations or mandates that the system must be tested against.]

Test Pass / Fail Criteria

[Describe the criteria used to determine if a test item has passed or failed its test.]

Test Entry / Exit Criteria

[Describe the entry and exit criteria used to start testing and determine when to stop testing.]

Test Deliverables

[Describe the deliverables that will result from the testing process (documents, reports, charts, etc.).]

Test Suspension / Resumption Criteria

[Describe the suspension criteria that may be used to suspend all or portions of testing. Also describe the resumption criteria that may be used to resume testing.]

Test Environmental / Staffing / Training Needs

[Describe any specific requirements needed for the testing to be performed (hardware/software, staffing, skills training, etc).)]

Test Planning Approach

TBD

Outline of The Test Plan

TBD

Appendix A

3

4

RTM

Req ID

Description

Requirement

Category

Component (HW or SW)

Test Case

Test Procedure

REQ0001

Registration Status View Test

Customer User shall be able to view their registration status with each interaction.

Functional

Software

TC001

TP001

REQ0002

Registration Page Access Test

The system shall only allow unregistered users to access the registration page.

Interface

Software

TC002

TP002

REQ0003

User Input Test

The system shall allow the Customer User to input their name, address, billing information, and preferred method of payment

external interface

Software

TC003

TP003

REQ0004

Account Creation Test

The Customer User shall be able to login to the account once it is created.

Interface

Software

TC004

TP004

REQ0005

Membership Test

The Customer User shall be able to determine their membership type.

Interface

Software

TC005

TP005

REQ0006

Web Page Navigation Test

The system shall direct the Customer User to the to correct web page according to the selection identified in the main menu

User Interface

Software

TC006

TP006

REQ0007

Load Performance Test

The system shall be able to support a minimum of 20 simultaneous users during peak hours.

Performance

Software

TC007

TP007

REQ0008

Software updates Test

The application will support auto updates without user input.

Performance

Software

TC008

TP008

REQ0009

Browser Load Time Test

The load time of the web pages shall take no more than five seconds on a standard DSL speed or higher internet connection.

Performance

Software

TC009

TP009

REQ0010

System maintenance test

The system will allow the Administrator Account to install patches and security updates on a live system without shutting the system down.

Security

Software

TC010

TP010

REQ0011

Membership Fees Test

The Administrator Account shall be able to determine the total sum of membership fees per month.

Functional

Software

TC011

TP011

REQ0012

Utilized Benefits Test

The Administrator Account shall be able to determine the benefits utilized for each individual member.

Functional

Software

TC012

TP012

REQ0013

Membership Cost Test

The Administrator Account shall be able to determine the cost of membership for each individual member.

Functional

Software

TC013

TP013

REQ0014

Membership Type Test

The Administrator Account shall be able to determine the membership type associated with each individual user.

Functional

Software

TC014

TP014

REQ0015

Database Communications Test

The application shall only allow a connection to the SQL database defined within the program.

Security

Software

TC015

TP015

REQ0016

Operating System Compatibility Test

The application shall be compatible with Windows 7 through Windows 8.1 Operating Systems

Performance

Software

TC016

TP016

REQ0017

CRUD Administrator Account Test

The Administrator Account shall be able to read, update, and delete member accounts when desired.

Functional

Software

TC017

TP017

REQ0018

Login Lockout Test

The system shall lockout the Customer User after 5 failed attempts to login.

Security

Software

TC018

TP018

REQ0019

Login Lockout Duration Test

A Customer User which has been locked out shall remain locked out for a period of 24 hours

Security

Software

TC019

TP019

REQ0020

Unique Identifier Test

The system shall require a unique identifier account along with a password to access the application.

Security

Software

TC020

TP020

Legend/Instructions:

Req ID

A unique ID number used to identify the traceability item in the requirements traceability matrix.

Description

This column contains the requirement title or description.

Requirement

 This column contains a description of the requirement.

Category

 This columns contains the requirement type.

Component (HW or SW)

This column is populated with a description of the hardware and software design components.

Test Script or Procedure

This column is populated with the identification of the procedure, script, or test case used.

Test Case Number

This column is populated with the test case number linked to the functional requirement.

Req ID

A unique ID number used to identify the traceability item in the requirements traceability matrix.

Description

This column contains the requirement title or description.

User Document

This column is populated with a description of the procedural document linked to the functional requirement verification method.

***NOTE: Traceability Matrix adapted from CDC_UP_Requirements_Traceability_Matrix_Template.xls by Daniel Vitek MBA, PMP - Consultant to CDC NCPHI, retrieved from http://www.cdc.gov/cdcup/

References:

Perry, W. (2015). Effective methods for Software Testing. Wiley Publishing Inc.

Pandhi, D (2006). How to Create the Best User Experience for Your Application. Retrieved

From https://msdn.microsoft.com/en-us/library/aa468595.aspx

System Usability Scale (SUS). (n.d.). Retrieved from

http://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html

ISQTB (2016). What is the purpose and importance of test plans in software testing? Retrieved

From http://istqbexamcertification.com/what-is-the-purpose-and-importance-of-test-plans/