Photo: Castel Sant'Angelo and the Bridge of Angels at midnight, Rome, Italy, July 2016.
Introduction:
Micro-service Reference Architecture Diagram:
System Design Diagram:
Sua Sponte Cyber Security Solutions Test Plan: 1. Overview
2. Testing Summary:
3. Test Focus Areas:
4. Unit Test Objectives:
5. Functional Test Objectives:
6. Regression Test Objective:
7. Verification & Validation Test Objectives:
8. Mitigation Objectives:
9. Testing:
10. Test Strategy:
11. Test Environment Plan:
Introduction:
All software developers have a responsibility to ensure that their products are secure. The process to ensure secure software begins at the very beginning of the design and development processes. It does not end throughout the process, nor does it end after the product goes live. The investment a company must make in ensuring the security of its software is not to be overlooked. These costs were once seen as too burdensome for the software development companies to invest in. The customers were responsible for seeking out additional security software to secure the operational software. More companies are opting to invest more money up front for software that has been designed and developed to be more secure. This way the customer does not need to invest as heavily on the back-end to secure a less expensive and less secure software.
Ethically it is important for the software developer to be honest and upfront about the security mechanisms built into their software systems. Potential customers will understand the initial upfront higher costs to purchase the software if the developer is able to justify the costs as saving money in the long run due to a more secure software program. All software designers and developers have a responsibility to ensure that they are not exposing their users and customers to vulnerabilities.
Ethically it is important for the software developer to be honest and upfront about the security mechanisms built into their software systems. Potential customers will understand the initial upfront higher costs to purchase the software if the developer is able to justify the costs as saving money in the long run due to a more secure software program. All software designers and developers have a responsibility to ensure that they are not exposing their users and customers to vulnerabilities.
Micro-service Reference Architecture Diagram:
(Dambal, 2010); (Microsoft, 2018)
Public Nodes: The Public Nodes are able to be reached via the public-facing load balancers. The API gateway is found on these nodes. (Microsoft, 2018)
Backend Nodes: The Backend Nodes run the services that the clients reach via the API gateway. The Backend Nodes do not get Internet traffic directly. Each Backend Node will each have their own hardware profile, and could have more than one pool of VMs. (Microsoft, 2018)
VM Cluster Management: The VM Cluster Management runs the master nodes. (Microsoft, 2018)
Networking: The Public Nodes, Backend Nodes, and the VM Cluster Management are in separate subnets within the same VM. (Microsoft, 2018)
Load Balancers: The external facing load balancer sits in front of the Public Nodes. The Load Balancer role is to distribute internet requests to the Public Nodes. Another load balancer is in front of the VM Cluster Management to allow secure shell (SSH) traffic to the VM Cluster Management. (Microsoft, 2018)
Public Nodes: The Public Nodes are able to be reached via the public-facing load balancers. The API gateway is found on these nodes. (Microsoft, 2018)
Backend Nodes: The Backend Nodes run the services that the clients reach via the API gateway. The Backend Nodes do not get Internet traffic directly. Each Backend Node will each have their own hardware profile, and could have more than one pool of VMs. (Microsoft, 2018)
VM Cluster Management: The VM Cluster Management runs the master nodes. (Microsoft, 2018)
Networking: The Public Nodes, Backend Nodes, and the VM Cluster Management are in separate subnets within the same VM. (Microsoft, 2018)
Load Balancers: The external facing load balancer sits in front of the Public Nodes. The Load Balancer role is to distribute internet requests to the Public Nodes. Another load balancer is in front of the VM Cluster Management to allow secure shell (SSH) traffic to the VM Cluster Management. (Microsoft, 2018)
System Design Diagram:
(Dambal, 2010); (Microsoft, 2018)
Sua Sponte Cyber Security Solutions Test Plan: 1. Overview
1.1. Purpose
The purpose of this document is to define the scope, focus areas, and objectives of the Sua Sponte Cyber Security Test Plan. The Sua Sponte Cyber Security Test Plan shall include unit tests, functional tests, regression tests, verification, validation, and mitigation plans. For unit tests each set of functions that implement the functional requirements, a unit test shall ensure the function is properly implemented. For functional tests shall provide description of what functional testing shall be performed for the software application. For regression tests, it shall be explained how to ensure changes by a developer to a portion of the code will not introduce errors elsewhere. Descriptions of the processes for verification and validation of the software application shall be provided. An explanation for mitigation strategies addressing vulnerabilities or software errors not identified using the testing mechanisms shall be implemented as part of the Sua Sponte Cyber Security Test Plan.
1.1. Scope
This document details the testing that will be performed by the project team for the Sua Sponte Cyber Security Test Plant. It defines the overall testing requirements and provides an integrated view of the project test activities. Its purpose is to identify what shall be tested, how the testing shall be performed, and identify what resources shall be required.
The purpose of this document is to define the scope, focus areas, and objectives of the Sua Sponte Cyber Security Test Plan. The Sua Sponte Cyber Security Test Plan shall include unit tests, functional tests, regression tests, verification, validation, and mitigation plans. For unit tests each set of functions that implement the functional requirements, a unit test shall ensure the function is properly implemented. For functional tests shall provide description of what functional testing shall be performed for the software application. For regression tests, it shall be explained how to ensure changes by a developer to a portion of the code will not introduce errors elsewhere. Descriptions of the processes for verification and validation of the software application shall be provided. An explanation for mitigation strategies addressing vulnerabilities or software errors not identified using the testing mechanisms shall be implemented as part of the Sua Sponte Cyber Security Test Plan.
1.1. Scope
This document details the testing that will be performed by the project team for the Sua Sponte Cyber Security Test Plant. It defines the overall testing requirements and provides an integrated view of the project test activities. Its purpose is to identify what shall be tested, how the testing shall be performed, and identify what resources shall be required.
2. Testing Summary:
2.1. Scope of Testing
2.1.1. In scope
The project team shall take a multipronged approach in conducting testing. The project team shall be responsible for the Unit Testing, Functional Testing, Regression Testing, the Verification and Validation, as well as the Mitigation of errors. These tests shall test to ensure that the business requirements, data requirements, and the timing requirements are met. The project team shall also be responsible to validate that the specifications capture the customer’s needs, and verifying that the software meets the specifications. Finally, the project team shall mitigate all errors discovered during the testing phases.
2.1.2. Out of scope
The project team shall not test the usability of the application. Usability testing shall be conducted by the users of the application. It is also not the responsibility of the project team to perform integration testing. Integration testing shall be conducted by the vendor.
2.1.1. In scope
The project team shall take a multipronged approach in conducting testing. The project team shall be responsible for the Unit Testing, Functional Testing, Regression Testing, the Verification and Validation, as well as the Mitigation of errors. These tests shall test to ensure that the business requirements, data requirements, and the timing requirements are met. The project team shall also be responsible to validate that the specifications capture the customer’s needs, and verifying that the software meets the specifications. Finally, the project team shall mitigate all errors discovered during the testing phases.
2.1.2. Out of scope
The project team shall not test the usability of the application. Usability testing shall be conducted by the users of the application. It is also not the responsibility of the project team to perform integration testing. Integration testing shall be conducted by the vendor.
3. Test Focus Areas:
3.1. Platform Testing
- For Unit Testing several automated tools shall be used, to include:
- Junit: It is a free to use testing tool used for Java programming language
- NUnit: It is a widely used unit-testing framework use for all .net languages
- PHPUnit: It is a unit testing tool for PHP programmer
- The Functional Testing tools that shall be used include:
- QTP: This is a user-friendly functional test tool by HP
- JUnit: It is used mainly for Java applications
- The Regression Testing Tools that shall be used include:
- QTP: It is an automated software designed to automate functional and regression test cases.
- RFT: The Rational Functional Tester is a Java tool used to automate the test cases of software applications.
- The Verification and Validation Testing:
- System Test
- Beta Test
4. Unit Test Objectives:
Ref |
Function |
Test Objective |
Evaluation Criteria |
X-Ref |
P |
1.1 - 1.6 |
Business Requirements |
To ensure that all of the business requirements are accomplished. The War-fighter should be able conduct all actions associated with Requests for Information, view financial records, input and update data, and generate reports on Army operations. |
War-fighters are able to submit Requests for Info War-fighters are able to cancel Requests for Info War-fighters are able to access financial records War-fighters are able to view old Requests for Info War-fighters are able to input or update data Are able to generate reports on army operations |
2.1 – 2.9 |
High |
1.7 - 1.9 |
Data Requirements |
To ensure that the data requirements are accomplished. The War-fighter shall be able to access and edit the War-fighters records, operational intelligence information, and financial information. |
War-fighters records ( name,
permanent address, DoD ID number, social security number, etc, but no health
information) are able to be accessed and edited Operational intelligence information (reports, maps, intelligence records, etc.) is able to be accessed edited Financial Information (payroll, pending debts, etc.) is able to be accessed and edited |
2.1 – 2.3; 2.10 – 2.12 |
High |
1.10 - 1.12 |
Timing Requirements |
To ensure that the timing requirements are accomplished. The application shall have no more than 1 second response time, conduct automatic updates every 6 months, and data shall have the ability to be archived indefinitely. |
Latency: No more than 1 second response time on any task of the interface Frequency: Upgrade 6 months Duration: Data shall be archived indefinitely |
2.1 - 2.3; 2.13 – 2.15 |
High |
5. Functional Test Objectives:
Ref |
Function |
Test Objective |
Evaluation Criteria |
X-Ref |
P |
2.1 – 2.3 |
Mainline |
To test the main functions of an application:
|
|
1.1 – 1.12 |
High |
2.4 |
Submit Requests for Info |
War-fighter is able to submit Requests for Info |
|
1.1 – 1.6 |
High |
2.5 |
Cancel Requests for Info |
War-fighter is able to cancel Requests for Info |
|
1.1 – 1.6 |
High |
2.6 |
Access financial records |
War-fighter is able to access financial records |
|
1.1 – 1.6 |
High |
2.7 |
View old Requests for Info |
War-fighter is able to view past Request for Info |
|
1.1 – 1.6 |
High |
2.8 |
Input or update data |
War-fighter is able to input and update data |
|
1.1 – 1.6 |
High |
2.9 |
Generate reports on army operations |
War-fighter is able to view reports on army operations |
|
1.1 – 1.6 |
High |
2.10 |
Access and edit records |
War-fighter is able to access and edit records (name, permanent address, DoD ID number, social security number, etc, but no health information) |
|
1.7 - 1.9 |
High |
2.11 |
Access and edit Operational intelligence information |
War-fighter is able to access and edit Operational intelligence information (reports, maps, intelligence records, etc.) |
|
1.7 - 1.9 |
High |
2.12 |
Access and edit Financial Information |
War-fighter is able to access and edit financial records |
|
1.7 - 1.9 |
High |
2.13 |
Latency |
No more than 1 second response time on any task of the interface |
|
1.10 - 1.12 |
High |
2.14 |
Frequency |
Upgrade every 6 months |
|
1.10 - 1.12 |
High |
2.15 |
Duration |
Data shall be archived indefinitely |
|
1.10 - 1.12 |
High |
6. Regression Test Objective:
Ref |
Function |
Test Objective |
Evaluation Criteria |
X-Ref |
P |
3.1 – 3.3 |
Mainline |
To test the main functions of an application:
|
|
1.1 – 1.12; 2.1 – 2.3 |
High |
3.4 |
Submit Requests for Info |
War-fighter is able to submit Requests for Info |
|
1.1 – 1.6; 2.4 |
High |
3.5 |
Cancel Requests for Info |
War-fighter is able to cancel Requests for Info |
|
1.1 – 1.6; 2.5 |
High |
3.6 |
Access financial records |
War-fighter is able to access financial records |
|
1.1 – 1.6; 2.6 |
High |
3.7 |
View old Requests for Info |
War-fighter is able to view past Request for Info |
|
1.1 – 1.6; 2.7 |
High |
3.8 |
Input or update data |
War-fighter is able to input and update data |
|
1.1 – 1.6; 2.8 |
High |
3.9 |
Generate reports on army operations |
War-fighter is able to view reports on army operations |
|
1.1 – 1.6; 2.9 |
High |
3.10 |
Access and edit records |
War-fighter is able to access and edit records (name, permanent address, DoD ID number, social security number, etc, but no health information) |
|
1.7 - 1.9; 2.10 |
High |
3.11 |
Access and edit Operational intelligence information |
War-fighter is able to access and edit Operational intelligence information (reports, maps, intelligence records, etc.) |
|
1.7 - 1.9; 2.11 |
High |
3.12 |
Access and edit Financial Information |
War-fighter is able to access and edit financial records |
|
1.7 - 1.9; 2.12 |
High |
3.13 |
Latency |
No more than 1 second response time on any task of the interface |
|
1.10 - 1.12; 2.13 |
High |
3.14 |
Frequency |
Upgrade every 6 months |
|
1.10 - 1.12; 2.14 |
High |
3.15 |
Duration |
Data shall be archived indefinitely |
|
1.10 - 1.12; 2.15 |
High |
7. Verification & Validation Test Objectives:
Ref |
Function |
Test Objective |
Evaluation Criteria |
X-Ref |
P |
4.1-4.3 |
Mainline |
Verify and Validate the main functions of an application:
|
|
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15 |
High |
4.4- 4.6 |
System |
Verify and Validate the main functions of an application:
|
|
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15 |
High |
4.7 - 4.9 |
Beta Test |
Verify and Validate the main functions of an application:
|
|
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15 |
Medium |
8. Mitigation Objectives:
Ref |
Function |
Test Objective |
Evaluation Criteria |
X-Ref |
P |
5.1 - 5.3 |
Mainline |
To mitigate all errors with the main functions of an application:
|
|
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15; 4.1 – 4.9 |
Medium |
9. Testing:
1.1. Unit Testing
Unit testing is verifying the correctness of an isolated section of a code. It is done during the development, or coding, of an application. The intent is to isolate each part of a program and verify that each part is correct. (Guru99, 2018)
Using the automated approach, codes shall be isolated to test them more rigorously. The user shall copy and paste the function into its own environment. In isolating the code, unnecessary dependencies between the code being tested and other units are revealed. These unnecessary dependencies shall then be eliminated. (Guru99, 2018)
The following unit testing best practices shall be followed:
For Unit Testing several automated tools shall be used, to include:
1.2. Functional Testing
Functional testing verifies each function of the software application is operating in conformance with the requirement specification. All functionality of the system is tested. The results are then compared with the expected results. Functionality testing shall be conducted using automation. (Guru99, 2018)
The following steps for a functional test shall be conducted:
The Functional Testing tools that shall be used include:
1.3. Regression Testing
Software maintenance is an activity which includes enhancements, error corrections, optimization and deletion of existing features. These modifications may cause the system to work incorrectly. Therefore, Regression Testing becomes necessary. (Guru99, 2018)
Regression testing is a type of software testing that confirms a recent program or code change has not adversely affected existing features. Regression testing is full or partial selection of already executed test cases which get re-executed to ensure functionality works fine. In other words, it checks that old code still works when the new code is implemented. (Guru99, 0218)
Regression testing shall be conducted based on the prioritization of test cases. The prioritization of test cases shall be done based upon the business impact, and the critical and frequently used functionalities. This will greatly reduce the regression test suite. (Guru99, 2018)
The following regression test cases shall conducted based upon the following priority:
To ensure that proper regression testing management is being conducted, the following rules must be followed by managers:
The Regression Testing Tools that shall be used include:
1.4. Verification & Validation Testing
Verification is concerned with whether the system is well-engineered, and error-free. While Validation is concerned with checking that the system will meet the customer’s actual needs. Verification will help determine whether the software is of high quality, but it will not ensure that the system is useful. Validation is the process of checking whether the specification captures the customer’s needs, while verification is the process of checking that the software meets the specifications. (Serendipity, 2018)
The Processes that shall be followed to verify and validate the software application is indicated by each of the bullet points below:
The Verification and Validation Testing:
1.5. Mitigation
Measuring risk in current software systems can be seen as these types: “(a) internal risks that are within the control of the project manager and (b) external risks that are beyond the control of project manager. Risk management is carried out to:
It is important to keep one up to date on the internal risks. This is the type of risk that can be within the control of the project manager. In managing the risk it becomes important follow certain processes and standards. These standards should be followed by the project manager as well as by each member of a team. A few of these standards include:
The strong aspect of measuring risk is the current software systems is the processes associated with risk management. “A project manager has to deal with risks arising from three possible cases: (1) Known knowns, (2) Known unknowns, (3) Unknown Unknowns.” (Test Institute, 2018) Once the project manager is able to address each of the three possible cases they must then quantify the risks. “This includes: (1) Giving a precise description of risk event that can occur in the project, (2) Defining risk probability that would explain what are the chances for that risk to occur, (3) Defining how much loss particular risks can cause, and (4) Defining the liability potential of risk.” (Test Institute, 2018) The project manager must then ensure that the following processes are followed: “(1) Software Risk Identification, (2) Software Risk Analysis, (3) Software Risk Planning, and (4) Software Risk Monitoring.” (Test Institute, 2018)
The main weakness in the risk management of software is that the best practices are very general. This is done because of the fast pace of technology advancement as well as the ever evolving threats. As a result, any specific solution that is given is nothing more than a temporary solution. Once a patch is implemented the attackers will find a new way in which conduct their attacks. This requires the cyber security professionals to be proficient in the latest technologies as well as have a creative mind to come up with new effective solutions in an ever changing environment.
Unit testing is verifying the correctness of an isolated section of a code. It is done during the development, or coding, of an application. The intent is to isolate each part of a program and verify that each part is correct. (Guru99, 2018)
Using the automated approach, codes shall be isolated to test them more rigorously. The user shall copy and paste the function into its own environment. In isolating the code, unnecessary dependencies between the code being tested and other units are revealed. These unnecessary dependencies shall then be eliminated. (Guru99, 2018)
The following unit testing best practices shall be followed:
- Unit Test cases should be independent. In case of any enhancements or change in requirements, unit test cases should not be affected.
- Test only one code at a time.
- Follow clear and consistent naming conventions for unit tests
- In case of a change in code in any module, ensure there is a corresponding unit Test Case for the module, and the module passes the tests before changing the implementation
- Bugs identified during unit testing must be fixed before proceeding to the next phase in SDLC
- Adopt a "test as your code" approach.
For Unit Testing several automated tools shall be used, to include:
- Junit: It is a free to use testing tool used for the Java programming language. Junit shall be used to test all the business, data, and timing requirements that use the Java programming language.
- NUnit: It is a widely used unit-testing framework use for all .net languages. NUnit shall be used to test all the business, data, and timing requirements that use .net languages.
- PHPUnit: It is a unit testing tool for PHP programmer. PHPUnit shall be used to test all the business, data, and timing requirements that do not use either Java r .net programming languages.
1.2. Functional Testing
Functional testing verifies each function of the software application is operating in conformance with the requirement specification. All functionality of the system is tested. The results are then compared with the expected results. Functionality testing shall be conducted using automation. (Guru99, 2018)
The following steps for a functional test shall be conducted:
- Identify test data
- Compute the expected outcomes with the selected test input values
- Execute test cases
- Compare actual and expected test results
The Functional Testing tools that shall be used include:
- QTP: This is a user-friendly functional test tool by HP. QTP shall be used as the functional test tool on all the functions associated with the business, data, and timing requirements. This functional testing tool was chosen as it is very user-friendly.
- JUnit: It is used mainly for Java applications. The JUnit shall be used as the functional test tool for all Java language functions associated with the business, data, and timing requirements.
1.3. Regression Testing
Software maintenance is an activity which includes enhancements, error corrections, optimization and deletion of existing features. These modifications may cause the system to work incorrectly. Therefore, Regression Testing becomes necessary. (Guru99, 2018)
Regression testing is a type of software testing that confirms a recent program or code change has not adversely affected existing features. Regression testing is full or partial selection of already executed test cases which get re-executed to ensure functionality works fine. In other words, it checks that old code still works when the new code is implemented. (Guru99, 0218)
Regression testing shall be conducted based on the prioritization of test cases. The prioritization of test cases shall be done based upon the business impact, and the critical and frequently used functionalities. This will greatly reduce the regression test suite. (Guru99, 2018)
The following regression test cases shall conducted based upon the following priority:
- Test cases which have frequent defects
- Functionalities which are more visible to the users
- Test cases which verify core features of the product
- Test cases of Functionalities which has undergone more and recent changes
- All Integration Test Cases
- All Complex Test Cases
- Boundary value test cases
- Sample of Successful test cases
- Sample of Failure test cases
To ensure that proper regression testing management is being conducted, the following rules must be followed by managers:
- Code being regression tested should be under a configuration management tool
- During the regression test phase, no changes shall be allowed to code. Regression test code shall be kept immune to developer changes.
- The database used for regression testing shall be isolated. No database changes shall be allowed
The Regression Testing Tools that shall be used include:
- QTP: It is an automated software designed to automate functional and regression test cases. QTP shall be used as the regression testing tool for all functions associated with the business, data, and timing requirements. The QTP testing tools may also be used during the functional testing phase as well as the regression phase.
- RFT: The Rational Functional Tester is a Java tool used to automate the test cases of software applications. RFT shall be used to test all Java Language functions associated with the business, data, and timing requirements during the regression testing phase.
1.4. Verification & Validation Testing
Verification is concerned with whether the system is well-engineered, and error-free. While Validation is concerned with checking that the system will meet the customer’s actual needs. Verification will help determine whether the software is of high quality, but it will not ensure that the system is useful. Validation is the process of checking whether the specification captures the customer’s needs, while verification is the process of checking that the software meets the specifications. (Serendipity, 2018)
The Processes that shall be followed to verify and validate the software application is indicated by each of the bullet points below:
- Verification of requirement against defined specifications
- Verification of design against defined specifications
- Verification of product code against defined standards
- Verification of terms, conditions, payment, etc., against contracts
- Code reviews – Systematic examination of the product's source code
- Inspections – Peer review of work products and documentation
- Walkthroughs – Inspecting source code by following logical paths through the algorithms or code as determined by input conditions and choices made along the way
- Determining the types and levels of product integrity to be verified and validated
- Developing performance metrics to allow tracking of project completion against defined milestones
- Identifying an integrity schema to measure the project's conformity to requirements
- Planning and scheduling of V&V activities considering the project management plan and schedule
- Consulting with stakeholders to assess their involvement and buy-in regarding system functionality and the system's ability to meet their needs
- Reviewing and providing recommendations to improve both the management and technical aspects of the project including evaluating project progresses, resources, budgets, schedules, and reporting
- Reviewing and analysing project management and software development activities, performance, and operational policies, processes, documentation, and products for accuracy and completeness
- Reviewing product architecture for feasibility, consistency, and adherence to related industry standards
- Reviewing traceability of product functions to original requirements
- Documenting V&V activities and assessment results in the form of task reports, activity summary reports, anomaly reports, test documents, and eventually a final V&V summary report
The Verification and Validation Testing:
- System Testing shall be conducted by the project team in order to verify and validate that all units and functions are working properly in the application.
- Beta Testing shall be conducted by the vendor in order to verify and validate that all of the units and functions are working properly within the application. The Beta Testing shall also be conducted to ensure that the vendor is satisfied that all the business, data, and timing requirements have been met by the application.
1.5. Mitigation
Measuring risk in current software systems can be seen as these types: “(a) internal risks that are within the control of the project manager and (b) external risks that are beyond the control of project manager. Risk management is carried out to:
- Identify the risk
- Reduce the impact of risk
- Reduce the probability or likelihood of risk
- Risk monitoring”
It is important to keep one up to date on the internal risks. This is the type of risk that can be within the control of the project manager. In managing the risk it becomes important follow certain processes and standards. These standards should be followed by the project manager as well as by each member of a team. A few of these standards include:
- Always be forward-thinking about risk management.
- Use checklists, and compare with similar previous projects.
- Prioritize risks, ranking each according to the severity of exposure.
- Develop a top-10 to top-20 risk list for your project.
- Vigorously watch for surfacing risks by meeting with key stakeholders – especially with the marketing team and the customer.
- As practicable, split larger risks into smaller, easily recognizable and readily-manageable risks.
- Strongly encourage stakeholders to think proactively and communicate about risks throughout the entire project.
The strong aspect of measuring risk is the current software systems is the processes associated with risk management. “A project manager has to deal with risks arising from three possible cases: (1) Known knowns, (2) Known unknowns, (3) Unknown Unknowns.” (Test Institute, 2018) Once the project manager is able to address each of the three possible cases they must then quantify the risks. “This includes: (1) Giving a precise description of risk event that can occur in the project, (2) Defining risk probability that would explain what are the chances for that risk to occur, (3) Defining how much loss particular risks can cause, and (4) Defining the liability potential of risk.” (Test Institute, 2018) The project manager must then ensure that the following processes are followed: “(1) Software Risk Identification, (2) Software Risk Analysis, (3) Software Risk Planning, and (4) Software Risk Monitoring.” (Test Institute, 2018)
The main weakness in the risk management of software is that the best practices are very general. This is done because of the fast pace of technology advancement as well as the ever evolving threats. As a result, any specific solution that is given is nothing more than a temporary solution. Once a patch is implemented the attackers will find a new way in which conduct their attacks. This requires the cyber security professionals to be proficient in the latest technologies as well as have a creative mind to come up with new effective solutions in an ever changing environment.
10. Test Strategy:
Test Level |
External Party |
Project Team |
Business |
Unit Testing |
S |
P |
T |
Functional Testing |
S |
P |
T |
Regression Testing |
S |
P |
T |
Verification & Validation Testing |
S |
P |
T |
Mitigation |
T |
P |
S |
10.2. Test Execution Schedule
Test Type |
Objectives |
Priority |
Schedule |
Unit Testing |
The objectives are to verify that the application:
|
High |
10/22/2018 To 10/29/2018 |
Functional Testing |
The objectives are to verify that the application:
|
High |
10/30/2018 To 11/05/2018 |
Regression Testing |
The objectives are to verify that the recent program or code changes have not adversely affected the application. |
High |
11/06/2018 To 11/12/2018 |
Verification & Validation Testing |
The objectives are to verify that the application meets the specifications and to validate if the application meets the customer’s needs. |
Medium |
11/13/2018 To 11/20/2018 |
Mitigation |
The objectives are to identify and correct any errors that may have occurred as a result of the previous testing phases.
|
Medium |
11/21/2018 To 11/28/2018 |
11. Test Environment Plan:
Role |
Staff Member |
Responsibilities |
Release Manager |
Jake Smith |
Responsible for overall establishment, coordination and support of the test environment |
Test Manager |
Mary Rossi |
Responsible for advising release manager of environment requirements for planning, establishment and ongoing |
Project Manager |
Leo Blasius |
Escalation point for environment issues. |