In order to find a balance between the cost of testing comparative to cost of failure, it would behoove teams to consider risk analysis. All the factors that may influence the expensive risks of testing or a lack thereof would be best countered by project-specific risk analysis.
The prompt brings up that more testing generates higher prices, but if we cut back on testing activities, the product will have more undetected faults and errors. This leads to either direct defect costs, indirect defect costs, and costs for defect correction; thus, we must understand the potential defect cost due to a lack of testing according to Spillner et al. (2014). Preventing software bug costs can be done through testing earlier as possible after the creation of them, the longer they remain the more costly they become. The test manager should plan verification and test activities to estimate and better handle the potential costs of testing, which will provide a better chance of preventing any surprising costs. Overall choosing a good test strategy and approach is the most important thing, especially for the test manager.
Reducing the risk of critical bugs before they escape to production can be done by trying and find bugs while writing the code. As bugs are being created, utilize the tools available to scope them out then and there. Documenting the test strategy and being mindful of it is a great way to ensure the team is thinking about the best way to produce efficient code and the means to test it. You can ground your answer on when to stop testing based on some data sometimes. Spillner et al. (2014) detail that a few organizations bother to collect data that quantifies the relationship between costs and benefits. Although this is not done too often thus leading to intuitive decisions, the point is that you can use data to come to an answer.
2. Lapagedrea Evans (she/her/hers)
Oct 19, 2022 at 10:06 AM
Hi Class,
The entire development process can cost a business a ton of money. Every process has it own expense. Testing is one cost that can go on and on to ensure the product is ready for launch but when do you draw the line for testing. In my opinion, a great start is to come up with an initial budget for testing. A testing strategy. This will underline the testing costs and efforts. Settling on a number of testings can reduce the ongoing repetition of testing. If you look for something you will find it so setting a baseline for the number of testing can really give a sense of control over elongated testing.
Finding a balance between he cost of testing versus the cost of uncovered bugs can be a headache for everyone. This is a job for the testing manager. He or she has the option between two approaches:
1. “Listing all testing task; the letting either the task owner or experts who have estimation experience estimate each task OR
Estimating the test effort based on effort data of former or similar projects, or based on typical values” (Spillner, Linz, Schaefer, 2014, chap. 6.3.3.).
2. Taking the preventative approach will allow for the reduction risks of critical bugs escaping to production when testing is stopped. In the preventative approach, testing will should start early and should continue in each phase of the project (Spillner, Linz, Schaefer, 2014, chap. 6.4.1.).
-Page
3. Jasmin Wind
Oct 19, 2022 at 9:37 PM
Hello Class and Professor Hayden,
It is difficult to find information on incident management without finding articles selling incident management software. The basic steps are the same, whether looking at a sales pitch such as Manage Engine or the required reading. Please refer to the concept map below, but the management of an incident starts when an issue arises. It can also be referred to as the incident occurring. Incident reporting or problem anomaly is when an incident, error, or failure is reported and put into a database. Each system or project should have their own database. The error can be reported by anyone on the development team (Spillner, Linz, & Schaefer, 2014, pp. 193-194). The next step in the process is to log the incident. The test log consists of comprehensive data about tests that have been performed. Some tests that would be included in the log are script routines, procedures done on a low level, and potentially keyword tests as well. The test log will also include the test result. This can be an image file, linked file, or written entries (SmartBear, 2022).
After the incident has been logged, it needs to be categorized. Defect classification takes the incidents and categorizes them into severity. The amount the error or flaw affects the system is what the severity is based on. It can be classified into the categories of fatal, very serious, serious, moderate, and mild. The reading gives a few examples of the classifications. Some potential examples of fatal incidents are when the system crashes with loss of data, or a test object is not compatible in the current form. On the opposite end of the spectrum, a mild incident example could be a spelling error (Spillner, Linz, & Schaefer, 2014, p. 198).
After the error has been categorized, it can be prioritized. A response is sent to let the tester know the issue has been received. The next step is when the error is diagnosed, and this leads to either the issue being fixed or escalated to the tier of support that can fix it. This solution is referred to as resolution and recover in the concept map. It is listed as a short phrase, but this step can take a range of time to fix. It might be an error that can be fixed in a moment, or it could unfortunately take years. Once the issue has been resolved, the tester is requested to confirm the issue has been fixed. The developer cannot decide if the case is closed. If the tester confirms the issue has been solved, then now the case can be closed (Spillner, Linz, & Schaefer, 2014).
In my personal experience, if an incident management system is good, it also offers an option to re-open the case. The customer or tester can say the error has been fixed, but then find it is still occurring. The incident may be the same issue or it might be another error. It is good to have an option to re-open a case if needed.
When looking at the Incident status model, it can be customized for individual projects or software. The main components likely remain the same. It can be used for one developer or an entire team. When the developers are able to fix the flaws, some of these fixes can be deemed enhancements. These improvements can be thought of as functional. The reason that functional improvements, fixes, and enhancements are hard to define between them, is that some of these issues are a matter of opinion on where they fall.
The concept map is based on the concept map from TechTarget (Gillis, 2018). The test log definition is based on an article (SmartBear, 2022). Incident reporting is based on information from the reading (Spillner, Linz, & Schaefer, 2014, pp. 193-194). Incident status information as well as the incident status model from the concept map is based on the reading (Spillner, Linz, & Schaefer, 2014, p. 198).
Here is the concept map.
4. Lapagedrea Evans (she/her/hers)
Oct 19, 2022 at 10:03 AM
Hi Class,
The following shows the details of each incident management within the test cycle.
“Tests logs- Test Analyst, Documenting Incidents, Developer’s Task
Incident reporting- Incident Database, Standardize Reporting Format, Document all info relevant to reproduction & correction
Defect classification- Failure Severity, Fault Priority, Incident analyst for controlling the test process, Incident analyst for improving the test process
Incident status- Only the tester may set the state to “Closed”, Incident status scheme, Test exit criteria, Incident status model, Change control board” (Spillner, Linz, Schaefer, 2014, chap. 6.6.1.-6.6.4).
Describe how they contribute to effective test management.
Each of these contributes to the test management in a huge way. “The goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse impact on business to ensure the best quality of service” (N.a., 2022, para. 3). This how each incident management type contributes to the effectiveness test management.
-Page