Confirmed users
452
edits
QA/Content Handling: Difference between revisions
→Risk analysis
| Line 176: | Line 176: | ||
Track the dates and build number where feature was merged to Release/Beta | Track the dates and build number where feature was merged to Release/Beta | ||
== | == Testing risks and mitigation == | ||
=== TESTING RISK === | |||
Risks can be organized into these categories. | |||
* '''Test planning and scheduling''' : It may occur when there is no separate test plan, but rather highly incomplete and superficial summaries in other planning documents. Also, test plans are often ignored once we are written. Regarding the schedule, the schedule of testing is often inadequate for the amount of testing that should be performed in TDC, especially when testing is primarily manual. | |||
* '''Stakeholder involvement''' : The wrong mindset would introduce wrong thought of testing, having wrong testing expectations, and having stakeholders who are inadequate committed to and supporting of the testing effort. Therefore, we must align expectations with reality between stakeholders before we kick off testing. | |||
* '''Process integration''' : It often occurs when testing and engineering processes are poorly integrated. We sometimes take a "one-size-fits-all" approach taken to testing, regardless of the specific needs of the project. | |||
* '''Test communication risk''' : This problems often occurs when test documents are not maintained or inadequate communication. | |||
=== RISK MITIGATION === | |||
QA team would like to use following flow to address risk. | |||
* '''Risk Identification''': Risks can be identified using a number of resources. E.g., project objectives, risk lists of past projects, prior knowledge, understanding of system architecture or design, prior bug reports, and complaints. For example, if certain areas of the system are unstable and those areas are being developed further in the current project, it should be listed as a risk. It is good to document the identified risks in detail so that it stays in project memory and can be clearly communicated to project stakeholders. | |||
* '''Risk Prioritization''' : If a risk is fully understood, it is easy for us to prioritize a risk by two measures. (1) Risk Impact and (2) Risk Probability are applied to each risk. Risk Impact is estimated in tangible terms or on a scale (e.g., 10 to 1 or High to Low). Risk Probability is estimated somewhere between 0 (no probability of occurrence) and 1 (certain to occur) or on a scale (10 to 1 or High to Low). For each risk, the product of Risk Impact and Risk Probability gives the Risk Magnitude. Sorting the Risk Magnitude in descending order gives a list in which the risks at the top are the more serious risks and need to be managed closely. | |||
* '''Risk Treatment''' : Each risk in the risk list is subject to one or more of the following Risk Treatments. | |||
*# <small>Risk Avoidance : For example, if there is a risk related to a new feature, it is possible to postpone this feature to a later release.</small> | |||
*# <small>Risk Transfer : For example, if the risk is insufficient security testing of a feature, it may be possible to borrow the other expertise (Engineer) to perform the security testing.</small> | |||
*# <small>Risk Mitigation : The objective of Risk Mitigation is to reduce the Risk Impact or Risk Probability or both. For example, if the QA team is new and does not have prior system knowledge, a risk mitigation treatment may be to have a knowledgeable team member join the team to train others on-the-fly.</small> | |||
*# <small>Risk Acceptance : This happens when there is no viable mitigation available due to reasons such as resources. For example, if all testers are at the same place, risk acceptance means no another QA resource. When holiday comes, some tests will be stopped and it may be a concern in the project.</small> | |||
= References = | = References = | ||
* List and links for specs | * List and links for specs | ||