Software Regression Test Plan Outline
***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
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
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/