RISK

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

http://sif.uin-suska.ac.id http://fst.uin-suska.ac.id/ http://www.uin-suska.ac.id/

 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%.
✖ 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.
 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
 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.
 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.
 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.
 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
 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.
 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 3. Transfer

Take steps in Convince some

advance to reduce other member of
the likelihood (and the team or
possibly the 2. project 4. Ignore
impact) of the Contingency stakeholder to
risk. reduce the Do nothing
Have a plan in likelihood or about the risk,
place to reduce accept the which is usually
the impact impact of the a smart option
should the risk risk. only when
become an there's little that
outcome. can be done or
when the
likelihood and
impact are low.
 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.
 Reference
Graham. et al. Foundations of Software Testing
The End of Slide
thank you