Page History

...

1. What and how "things" can affect our project?
   1. Risk Identification
      1. identification of risks to product (e.g. software/hardware) features; this is normally performed by the team and discussed together
      2. risks are identified before implementation starts and are reviewed throughout the development life cycle; new risks can be identified during implementation
   2. Risk Analysis
      1. risks are discussed together in the team (may involve customer)
      2. risks impact and probability are calculated, and thus the related risk level
2. How will we handle it, in the most effective way (i.e. the one that can return most value)?
   1. Risk Evaluation and Treatment
      1. Test Planning
         
         1. using the input from Risk Analysis, the test manager can...
            1. define test strategy (e.g. level of testing to perform, techniques to use, environments to choose)
            2. estimate testing effort
            3. define/estimate schedule (target dates, number of testing iterations)
      2. Test Design
         1. specification of the Tests taking the identified risks as input; tests are designed to mitigate the risk (i.e. diminish their probability)
         2. make use of more extensive data with data-driven testing and automated testing/checking, if needed
      3. Test Execution
         1. perform testing by descending order of risk level (i.e. execute Tests related with higher risks first); experienced testers, with high degree of domain knowledge may provide more valuable feedback 
         2. thoroughly test risky items, using scripted and exploratory approaches
   2. Risk Monitoring and Reviewing
      1. look at items where you assessed the risk and evaluate if you need to take additional measures/treatments ("Are those items having failed tests? Were bugs founds? Are those bugs relevant? Did we find any new risk while testing?")

RBT in Waterfall

In projects following waterfall, or one of the waterfall variants, in their SDLC, RBT can fit as follows (high-level overview).

...

As your development project goes through different stages sequentially, problems found at a later stage of the pipeline can can lead to rolling back to a previous phase; thus, it can go from Test Execution back to Test Planning... or from the "Testing" high-level phase back to "Implementation"... or even from "Implementation" back to "Design" and "Requirement Analysis.

RBT in Agile

In projects adopting Agile principles and values software is delivered incrementaly and frequently, being highly focused on customer needs and feedback. In Agile changes are welcome and not really tied to "long phases". Both Agile Software Development and RBT have the customer and its most important needs/concerns at the center. 

...