CSE565 Software Verification & Validation Project #3 Part 1 Risk Based Testing -Solved  

. You are required to come up with a testing schedule that identifies the order for the completion of testing tasks before the application is deployed. There are various tasks that need to be completed.  To help develop a risk based strategy for the testing tasks, please consider the following:

 
• A quarter of the application was built upon legacy code that has not been documented or tested very well. Sometimes, there are software compatibility issues with the rest of the software. This code tends to crash much of the time. Unfortunately, if there is an error, it will bring down the application for multiple days, rendering the site useless. The process of testing and fixing the error would take a long time because of the lack of documentation.

•Another portion of the application for the podcasts section was outsourced to a smaller development company that typically does a good job with their development. They document their code well and always ensure the application can be available even if there are small issues. Since this is a smaller portion of the application that fewer users use, there would be very minimal damage if the section was not working for some time, and it would not affect usability. There is also a very low likelihood that the page would stop working because it has been tested well.

• Another portion of the application  is new code which was built by the developers in your organization. They all have at least a couple years of development experience, and have properly documented any changes and additions they have made. This makes it very easy for the testers to develop tests. If parts of this code have defects, there is a high chance that other portions of the application could not be used, which would heavily affect usability and availability of the application. Since the developers are very experienced and have worked on similar code before, there is a very low likelihood of having a significant number of errors.

•  Another portion of the application is the APIs.  The likelihood that an API can go down is very high, so it is vital that the application is able to handle this issue. The developers have designed the application to have the ability where if one of the APIs goes down, the application would instead take the local data it has stored for the API to keep the application running. The only downside would be that performance would be slower and users would not get the latest information. The consequences are not as severe as if the legacy code was down, but are more severe than if the podcast section was down.

 With this knowledge, it is up to you to develop a risk based testing plan.  

 As a recommendation regarding the amount of testing to perform: 

•       minimal testing is needed if the risk exposure is low.   

•       average testing is needed if the risk exposure medium. 

•       maximum testing is needed if risk exposure is high. 

Risk exposure = P(adverse event occurring) * consequences.  

 The following chart outlines a suggested risk exposure based on the probability and consequences. 
Probability \ Consequences 
Marginal 
Critical 
Catastrophic 
Low 
Low 
Medium 
Medium 
Medium 
Low 
Medium 
High 
High 
Low 
Medium 
High 
 
In this project, there are two tasks: 

1.    Prioritize testing order based on risk exposure for the 4 tasks below. Rank them based on the table and provide a brief explanation for your rankings. 

a)    Test legacy code 

b)    Test outsourced code 

c)    Test APIs  

d)    Test new code 

2.    Rate the intensity of testing needed from 3 categories (minimal, average, maximum)