Assume you are working as a project manager for a software testing team in charge of testing a music player application. 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 Low Low Medium Low High Low
Critical Catastrophic Medium Medium Medium High Medium High
In this project, there are two tasks:
1. Prioritizetestingorderbasedonriskexposureforthe4tasksbelow.Rankthembased
on the table and provide a brief explanation for your rankings. a) Test legacy code
b) Test outsourced code c) TestAPIs
d) Testnewcode
2. Ratetheintensityoftestingneededfrom3categories(minimal,average,maximum)
Submission
Submit your answers in a zip file containing your answers online to Coursera in Unit 7.
Assessment
Your assignment will be scored based on the following criterion:
1. PriorityTesting
2. IntensityRanking 3. ContingencyPlan
Project #3 Part 1 is worth 30 points.
