Risk and testing - Graham et al Foundation of Software Testing http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/ http://www.uin-suska.ac.id/

1. RISK AND TESTING
Emi Rahmi
Program Studi S1 Sistem Informasi
Fakultas Sains dan Teknologi
Universitas Islam Negeri Sultan Syarif Kasim Riau

2. Risks and Levels of Risk
Risk is a word we all use loosely, but what
exactly is risk?
Simply put, it's the possibility of a negative or
undesirable outcome. In the future, a risk has
some likelihood between 0% and 100%; it is a
possibility, not a certainty. In the past, however,
either the risk has materialized and become an
outcome or issue or it has not; the likelihood of a
risk in the past is either 0% or 100%.

3. ✖ The likelihood of a risk becoming an
outcome is one factor to consider when
thinking about the level of risk associated
with its possible negative consequences.
The more likely the outcome is, the worse
the risk. However, likelihood is not the only
consideration.
✖ The potential consequences or impact is an
important consideration affecting the level
of risk, too.

4. We can classify risks into :
o project risks -> factors relating to the way the
work is carried out, i.e. the test project
o product risks -> factors relating to what is
produced by the work, i.e. the thing we are
testing

5. Product risks
✖ Unsatisfactory software might omit some key function
that the customers specified, the users required or the
stakeholders were promised.
✖ Unsatisfactory software might be unreliable and
frequently fail to behave normally.
✖ Unsatisfactory software might fail in ways that cause
financial or other damage to a user or the company
that user works for.
✖ Unsatisfactory software might have problems related
to a particular quality characteristic, which might not
be functionality, but rather security, reliability,
usability, maintainability or performance.

6. Risk- based testing uses risk to prioritize and
emphasize the appropriate tests during test
execution, but it's about more than that.
Risk-based testing starts early in the project,
identifying risks to system quality and using that
knowledge of risk to guide testing planning,
specification, preparation and execution.

7. Risk-based testing involves both mitigation testing to
provide opportunities to reduce the likelihood of
defects, especially high impact defects and
contingency testing to identify work arounds to make
the defects that do get past us less painful.
Risk-based testing also involves measuring how well
we are doing at finding and removing defects in
critical areas.

8. Risk-based testing starts with product risk
analysis. One technique for risk analysis is a
close reading of the requirements
specification, design specifications, user
documentation and other items. Another
technique is brainstorming with many of the
project stakeholders. Another is a sequence of
one-on-one or small-group sessions with the
business and technology experts in the
company

9. Project risks
However, testing is an activity like the rest of the
project and thus it is subject to risks that
endanger the project. To deal with the project
risks that apply to testing, we can use the same
concepts we apply to identifying, prioritizing and
managing product risks.

10. Checklists and examples can help you identify test project risks
[Black, 2004].
For any risk, product or project, you have four typical options:
1. Mitigate
Take steps in
advance to reduce
the likelihood
(and possibly the
impact) of the
risk.
2. Contingency
Have a plan in
place to reduce
the impact
should the risk
become an
outcome.
4. Ignore
Do nothing
about the risk,
which is usually
a smart option
only when
there's little that
can be done or
when the
likelihood and
impact are low.
3. Transfer
Convince some
other member of
the team or
project
stakeholder to
reduce the
likelihood or
accept the
impact of the
risk.

11. Here are some typical risks along with some options for managing them.
✖ Logistics or product quality problems that block tests: These can be mitigated through
careful planning, good defect triage and management, and robust test design.
✖ Test items that won't install in the test environment: These can be mitigated through
smoke (or acceptance) testing prior to starting test phases or as part of a nightly build
or continuous integration. Having a defined uninstall process is a good contingency
plan.
✖ Excessive change to the product that invalidates test results or requires updates to test
cases, expected results and environments: These can be mitigated through good
change-control processes, robust test design and light weight test documentation.
When severe incidents occur, transference of the risk by escalation to management is
often in order.
✖ Insufficient or unrealistic test environments that yield misleading results: One option
is to transfer the risks to management by explaining the limits on test results
obtained in limited environments. Mitigation sometimes complete alleviation can be
achieved by outsourcing tests such as performance tests that are particularly sensitive
to proper test environments.

12. Reference
Graham. et al. Foundations of Software Testing

13. The End of Slide
thank you