Project 24_ Software Testing

docx

School

University of Delaware *

*We aren’t endorsed by this school

Course

465

Subject

Information Systems

Date

Apr 3, 2024

Type

docx

Pages

Uploaded by estara89

TEST PLAN: PROJECT GPS Document Change History Version Number Date Contributor Description V1.0 9/7/2021 Esther Ahn This is a draft test plan to ensure the application security of the GPS application Table of Contents INTRODUCTION 3 1.1 O BJECTIVES 3 1.2 T EAM M EMBERS 1.3 A CCOUNTS AND A CCESS 3 2 SCOPE 3 3 ASSUMPTIONS / RISKS 4

3.1 A SSUMPTIONS 4 3.2 R ISKS 4 4 METHODOLOGY 5 4.1 T EST A PPROACH 4.2 T EST R EPORTS 5 4.3 H ARDWARE AND S OFTWARE T OOLS 5 5 MILESTONES / DELIVERABLES 6 6.1 T EST S CHEDULE 6 6.2 D ELIVERABLES 6 Introduction The Test Plan has been created to communicate the test approach of Project GPS to team members. It includes the objectives, accounts and access, scope, risks, methodology, test environment, schedule, and deliverables. This document will clearly identify what the test deliverables will be and what is deemed in and out of scope. 1.1 Objectives The primary objective of Project GPS is to test application security for the application that tracks movement of all company trucks to meet all security requirements needed for deployment. A key feature of application security will be implementing Identity Access Management (IAM) to authenticate internal users as the application is only hosted internally. The application will be ready for live deployment at the end of the test cycles and the final test report has been approved. 1.2 Team Members Resource Name Role Responsibilities Natasha Staples Cyber Security Manager -Review test plan, test case, test cycle -Ensure the application meets security requirements and compliance with security regulations -Implement OWASP, CWE, CIS control guidelines for software testing and developing -Set up rules and manage penetration testing team -Review results from penetration testing team and forward to appropriate team for remediation -Communicate reviewed findings with Project Manager to resolve any security issues or bugs -Final review and approval of application security -Sign off on final test report -Coordinate live deployment of application with deployment team Esther Ahn Project Manager -Create test plan, test case, test cycle -Communicate with Cyber Security Manager to get security assessment reports -Manage the software development team and software testing team -Ensure that any necessary application remediations are

completed on time -Report to Cyber Security Manager on a regular basis to keep track of Project GPS progress Team Member 1, Team Member 2, Team Member 3 Penetration Testing Team -Conduct penetration testing and analysis -Conduct security audits -Write security assessment reports -Communicate with Project Manager and Cyber Security Manager on findings -Collaborate with software development and software testing team Team Member 4, Team Member 5, Team Member 6 Development Team -Remediate any security flaws, vulnerabilities, bugs found in application code -Document all remediations and updates to coding in final report Team Member 7, Team Member 8, Team Member 9 Software Testing Team -Conduct code-based testing and static testing -Test application functionality -Analyze test results and document results in report -Log issues or bugs in JIRA to communicate with development team Company employees that will eventually use the GPS application End Users -Conduct User Acceptance Testing -Log issues or bugs in JIRA to communicate with appropriate teams 1.3 Accounts and Access Account Type Name Usage Project GPS administrative account access Natasha Staples, Esther Ahn - Create, modify, and delete user accounts and passwords - Access Project GPS Test Environment - Read, write, execute on Project GPS Test Environment - Install new software Project GPS access All Project GPS teams except end users - Access Project GPS Test Environment - Read, write, execute on Project GPS Test Environment End User End Users, Admin - Read and execute only (use the GPS application) 2 Scope The In-Scope test plan will include the following : ● Conduct automated and manual application security testing of the GPS application. ● Conduct acceptance testing by end users to identify and resolve security risks or issues. ● Identify and resolve security flaws, vulnerabilities, and exploits of the GPS application. ● Document, communicate, and report security issues and risks. ● Database security scanning and testing. ● Ensure that the GPS application comply with US security regulations and standards. The Out-of-Scope test plan will include the following:

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

● All other non-application security tests requested by management. ● New features added to the current GPS application, which require additional security tests and security patches. 3 Assumptions / Risks 3.1 Assumptions The following conditions should be met before starting application testing: 1. The test environment is ready and configured properly. 2. The correct test version is launched on the test environment and all relevant personnel are notified. 3. All features for the application security testing are working. 3.2 Risks The following risks have been identified and the appropriate action identified to mitigate their impact on the project. The impact (or severity) of the risk is based on how the project would be affected if the risk was triggered. The trigger is what milestone or event would cause the risk to become an issue to be dealt with. # Risk Impact Trigger Mitigation Plan 1 Any employees from all locations are able to access the internal network, thus there might be potential risk to an insider attack or information theft. High - to security and IAM Unauthorized access from other employees within the internal network Create and enforce IAM policy for Project GPS team members in the testing environment. For example, use AWS IAM to manage access, and use Attribute Based Access Control (ABAC) to tag employees involved in the project. 2 Potential abuse of administrative rights. High - to security and IAM Databreaches, theft, and privacy concerns Assign administrative rights to project managers only. Make sure to keep track of testing environment logs on a regular basis to monitor account activities. 3 Assumption that software developers and software testing team have knowledge about secure coding and testing. High - to security Unable to meet security requirements Implement OWASP, Common Weakness Enumeration (CWE) and CIS Control guidelines. Create a systematic approach to spread security knowledge and training if necessary among the teams. 4 Scope Creep – management might decide to add new features to the GPS application which can lead to additional tests. High - to schedule and quality Delays in application deployment date Ensure that the Statement of Work (SoW) includes the allocation of additional time and resources required for testing new features and that any changes are approved. 5 Updates to the GPS application High – to Loss of test Backup and save data prior to any

codes might affect the original functionality and negate test cases already written. schedule and functionality cases security patch. Ensure that code can be rolled back to the previous version if the security patch is unsuccessful. 6 Penetration testers might accidentally crash servers, or there might be power outages and natural disasters that can disrupt work. High - to schedule, functionality, and quality Unable to conduct tests for a period of time Backup and upload the current test environment to the company’s AWS cloud platform before conducting any tests. 7 Penetration testers are limited to the scope of application security. There might be more risks after deployment, and there might be new security flaws, vulnerabilities, and exploits. High - to security GPS application could be vulnerable after deployment Ensure that SoW includes continuous penetration testing after deployment and continuous security patches. Ensure that the application is updated to newer versions that improve upon and remediate any flaws or bugs. 8 Weekly delivery is not possible because the developer works off site. Medium - to schedule Product did not get delivered on schedule Hire a US manager to review the work of the developer team in India so that work becomes more efficient and doesn’t get delayed. This will help with any time zone differences that cause work delays. 9 Staff from all teams are not familiar with the software that they are using. Medium - schedule Delays in application deployment date Prioritize and conduct training before the Project GPS begins to get everyone up to speed. Promote a healthy work culture where asking questions is encouraged. Assign a senior, a staff member, and a manager in each scrum team to minimize any knowledge and skill gaps. 4 Methodology 4.1 Test Approach The project is using an agile approach, with monthly iterations, because Project GPS is focused on time and value to ensure that the GPS application meets all security requirements for deployment. At the end of each month, the requirements identified for that iteration will be delivered to the team and will be tested. If there are any security risks and issues identified during the tests, the software developer team will be collaborating with the issue finders to resolve the problems. The first phase of the agile approach will be Model-based security testing, which is grounded on requirements and design models. Threat models can be used to capture security issues and translated into test cases for more security testing.

The second phase is code-based testing and static analysis on the GPS application’s code base. A formal list of testing guidelines from OWASP and CWE will be implemented. The software testing team will then use tools like Klocwork to find code-based defects, vulnerabilities, or security issues according to the guidelines. The third phase is Penetration testing and dynamic analysis. The penetration testing team will conduct both white and black-box testing to gain a complete understanding of the GPS application security. End users should also be involved in conducting user acceptance tests. The fourth phase is Security regression testing to re-run the test case to make sure that security issues, vulnerabilities, and flaws are fixed. This will ensure that software bugs are fixed and nothing new comes up. Ultimately, the GPS application’s security requirements are met, and the functionality should not be affected. 4.2 Test Reports The managers are responsible for writing and disseminating the following reports to the Cyber Security Manager or Project Manager as required. A bi-weekly or monthly status report will be provided by the respective managers. This report will summarize weekly testing activities, security issues and risks, vulnerabilities, bugs, test case coverage, and other relevant metrics. When each agile phase testing is completed, the Project Manager will distribute a phase completion report to the Cyber Security Manager for review and sign off. The document contains the following metrics: - Total Test Cases, Number Executed, Number Passes / Fails, Number Yet to Execute - Number of Bugs Found to Date, Number Resolved, and Number still Open - Breakdown of Bugs by Severity / Priority Matrix - Discussion of Unresolved Risks - Discussion of Schedule Progress (are we where we are supposed to be?) The final test report will be issued to the Cyber Security Manager to certify that testing is completed, and there will be a security assessment of the application’s readiness for deployment. If the application meets the security requirements for deployment, the Cyber Security Manager will sign off on the final report and approve the application for deployment. Finally, this will be communicated and coordinated with the software deployment team. 4.3 Hardware and Software Tools Tool Usage Name Software: Source-Code Analyzers - Static application security testing (SAST) tool - Audit tool for security compliance with US standards - Detect bugs Klocwork

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

- Analyze source code in real time - Simplifies peer code reviews - Optimize software architecture - Containerized build support for machine provisioning and cloud computing systems such as AWS Web application scanner - Penetration testing tool - Evaluate security of web-based applications - Web Vulnerability Scanner Burp Suite, Zap Database security scanner - Scan database for security vulnerabilities and configuration flaws, including patch levels Scuba Database discovery tool - Performs active and passive scans of a network to identify SQL server instances SQLRECON Network discovery and security auditing tool - Discover hosts and services on a computer network Nmap Issue and project tracking software - Bug and issue logging - Agile project management - Test case management - Workflow mapping Jira Software Bug tracking tool - Bug logging tool that is easy for end users to report bugs BugHerd Operating System: Penetration testing tool - Contains all the penetration testing tools that Project GPS requires. Kali Linux, Dirbuster Hardware: Workstations, work mobile devices - For Project GPS employees to perform application security tests on the GPS application - To allow end users to use the GPS application and perform end user testing Windows Laptops, iPhone Devices 5 Milestones / Deliverables 5.1 Test Schedule Task Name Start Finish Effort Comments Test Planning 9/1/21 9/3/21 3d Review Requirements documents 9/3/21 9/4/21 2d Create initial test estimates 9/4/21 9/5/21 2d Implement CWE, OWASP, and CIS Control guidelines for testing reference 9/6/21 9/9/21 4d Staff and train new test resources 9/10/21 9/24/21 15d First deployment to cloud platform as 9/27/21 9/28/21 2d

test environment Make backup copy of test environment 9/28/21 9/28/21 1d Model-based security testing – Iteration 1 9/29/21 10/6/21 8d Prepare Iteration 1 status report 10/6/21 10/21/21 7d Code-based testing and static analysis - Iteration 2 10/22/21 11/1/21 11d Prepare Iteration 2 status report 11/1/21 11/5/21 5d Penetration testing and dynamic analysis – Iteration 3 11/8/21 11/17/21 10d Prepare Iteration 3 status report 11/17/21 11/24/21 8d Security regression testing - Iteration 4 11/25/21 12/13/21 20d Prepare Iteration 4 status report 12/13/21 12/20/21 8d User Acceptance Testing 12/21/21 1/7/22 18d Resolution of final defects and final build testing 1/10/22 1/21/22 12d Prepare and send final testing report 1/24/22 1/28/22 5d Management sign off and approve GPS application for deployment 1/28/22 2/4/22 6d Release to deployment 2/7/22 2/9/22 3d 5.2 Deliverables Deliverable For Date / Milestone Test Plan Project GPS members 9/5/21 Test Case Project GPS members 12/20/21 Test Cycle Project GPS member 1/12/22 OWASP, CWE, CIS Control Guidelines Software Testing Team, Penetration Testing Team 9/9/21 Test Status Reports Managers 10/21/21, 11/5/21, 11/24/21, 12/20/21 Test Completion Report Cyber Security Manager 1/28/22 Final Test Report Cyber Security Manager 2/4/22

Project 24_ Software Testing

Related Documents