Murphy's Laws for Software
Testing Laws
1. Not all test that
passed for the first time will necessary passed for the second one.
2. What will passed in the
mind of developers can fail in the real world.
3. A computer lets you
make more mistakes faster than any other invention in human history.
4. If you can't test the
software that you build, you shouldn't build it�
5. Testing never ends it
just stops.
6. There are always
circumstances under which software will fail
7. Any non-trivial program
that contains a significant number of low-severity non-critical bugs has evidence
for the existence of a critical number at which the limit of these bugs makes
this application unusable.
8. Given
infinite time, a thousand monkeys with typewriters would eventually write all
possible test cases.
9. Any non-trivial program
contains at least one bug
10.
There's
always one more bug.
11.
Every
program has at least one bug.
Programmers also know that every program has at least one line of unnecessary source code. By combining these two rules and using logical induction, it's a simple matter to prove that any program could be reduced to a single line of code with a bug.
Programmers also know that every program has at least one line of unnecessary source code. By combining these two rules and using logical induction, it's a simple matter to prove that any program could be reduced to a single line of code with a bug.
12.
Undetectable
errors are infinite in variety, in contrast to detectable errors, which by
definition are limited.
13.
In
any program, any error which can creep in will eventually do so.
14.
Not
until the program has been in production for at least six months will the most
harmful error be discovered.
15.
Murphy's
law says: The information item that indicates the irrelevance of the contained
information is visible only after you've retrieved the whole information.
Risk Analysis in Software
Testing
Risk Analysis is very essential for software testing. In software testing, risk analysis is the process of identifying risks in applications and prioritizing them to test. A risk is a potential for loss or damage to an organization from materialized threats. Risk Analysis attempts to identify all the risks and then quantify the severity of the risks. A threat as we have seen is a possible damaging event. If it occurs, it exploits vulnerability in the security of a computer based system.
Items with higher risk values should be tested early and often. Items with lower risk value can be tested later, or not at all. It can also be used with defects.
How to perform Risk Analysis during software testing
When a test plan has been created, risks involved in testing the product are to be taken into consideration along with the possibility of their occurrence and the damage they may cause along with solutions; if any. Detailed study of this is called Risk Analysis.
Some of the risks could be:
Risk Analysis is very essential for software testing. In software testing, risk analysis is the process of identifying risks in applications and prioritizing them to test. A risk is a potential for loss or damage to an organization from materialized threats. Risk Analysis attempts to identify all the risks and then quantify the severity of the risks. A threat as we have seen is a possible damaging event. If it occurs, it exploits vulnerability in the security of a computer based system.
Items with higher risk values should be tested early and often. Items with lower risk value can be tested later, or not at all. It can also be used with defects.
How to perform Risk Analysis during software testing
When a test plan has been created, risks involved in testing the product are to be taken into consideration along with the possibility of their occurrence and the damage they may cause along with solutions; if any. Detailed study of this is called Risk Analysis.
Some of the risks could be:
1. New Hardware.
2. New Technology.
3. New Automation Tool.
4. Sequence of code
delivery.
5. Availability of
application test resources.
In Software Testing some unavoidable risk might takes place like:
- Change
in requirements or incomplete requirements.
- Time
allocation for testing.
- Developers
delaying to deliver the build for testing.
- Urgency
from client for delivery.
- Defect
Leakage due to application size or complexity.
To overcome these risks, the following activities can be done.
- Conducting
Risk Assessment review meeting with the development team.
- Profile
for Risk coverage is created by mentioning the importance of each area.
- Using
maximum resources to work on High Risk areas like allocating more testers
for High risk areas and minimum resources for Medium and Low risk areas.
- Creation
of Risk assessment database for future maintenance and management review.
- Identify
and describe the risk magnitude indicators: High, Medium and Low
High magnitude means the effect of the risk would be very high and non-tolerable. Company may face severe loss and its reputation is at risk. It must be tested.
Medium: tolerable but not desirable. Company may suffer financially but there is limited liability or loss of reputation. It should be tested.
Low: tolerable. Little or no external exposure or no financial loss. Company's reputation is unaffected. It might be tested.
Three perspectives of Risk Assessment
- Effect.
- Cause.
- Likelihood.
Effect - To assess risk by Effect, identify a condition, event or action and try to determine its impact.
Cause - To asses risk by Cause is opposite of by Effect. Begin by stating an undesirable event or condition and identify the set of events that could have permitted the condition to exist.
Likelihood - To asses risk by Likelihood is to determine the probability that a requirement will not be satisfied.
Risk Identification
There can be different type of risks include as follows-
1. Software Risks:
Knowledge of the most common risks associated with Software development, and
the platform you are working on.
2. Business Risks: Most
common risks associated with the business using the Software.
3. Testing Risks:
Knowledge of the most common risks associated with Software Testing for the
platform you are working on, tools being used, and test methods being applied.
4. Premature Release
Risk: Ability to determine the risk associated with releasing unsatisfactory or
untested Software Products.
5. Risk Methods: Strategies
and approaches for identifying risks or problems associated with implementing
and operating information technology, products and process; assessing their
likelihood, and initiating strategies to test those risks.
What is Schedule Risk
In your project, you have to estimate how long it takes to complete a certain task. You estimate that it usually takes 15 days to complete. If things go well it may take 12 days but if things go badly it may take 20 days.
In your project plan you enter 15 days against the task. The other information, the best case estimate of 12 days and the worst case estimate of 20 days, is not entered into the project at all. If this seems familiar, then you already go through the process of identifying uncertainty or risk. By entering only the most likely duration a great deal of additional information is lost. But with Schedule Risk this extra information is used to help produce a much more realistic project. And you are not just limited to durations. Uncertainty in resources and costs can also be modeled in your project to produce an even greater depth and accuracy to the information available to you.
Who should use Schedule Risk Analysis
The simple answer is - anyone who manages a project! If you are running projects that are time and/or cost critical, risk analysis will help you manage your projects more effectively and help reduce the chances of your project being late and over budget.
Pert master is used by project planners of all levels, from those just entering into the Schedule Risk arena to the world's leading risk experts.
How easy is it to use?
It is very easy. You do not need to be an expert in risk and statistics to be able to use schedule risk. With normal project planning, the level of detail and complexity that you build into the project is up to you and your requirements. This is the same with Schedule Risk. Very little extra information is required as a minimum but you have the ability to provide a great deal of very specific additional information if you require it. Pert master is acclaimed as being very easy to use. By simply following the tutorials and examples you will be able to incorporate risk into your project with ease. Pert master includes a Quick Risk (link) facility that lets you add risk to your project in seconds.
Risk Assessment
Risk assessment may be the most important step in the risk management process, and may also be the most difficult and prone to error. Once risks have been identified and assessed, the steps to properly deal with them are much more programmatically.
Part of the difficulty of risk management is that measurement of both of the quantities in which risk assessment is concerned can be very difficult itself. Uncertainty in the measurement is often large in both cases. Also, risk management would be simpler if a single metric could embody all of the information in the measurement. However, since two quantities are being measured, this is not possible. A risk with a large potential loss and a low probability of occurring must be treated differently than one with a low potential loss but a high likelihood of occurring. In theory both are of nearly equal priority in dealing with first, but in practice it can be very difficult to manage when faced with the scarcity of resources, especially time, in which to conduct the risk management process. Expressed mathematically,
Financial decisions, such as insurance, often express loss terms in dollars. When risk assessment is used for public health or environmental decisions, there are differences of opinions as to whether the loss can be quantified in a common metric such as dollar values or some numerical measure of quality of life. Often for public health and environmental decisions, the loss term is simply a verbal description of the outcome, such as increased cancer incidence or incidence of birth defects. In that case, the "risk" is expressed.
If the risk estimate takes into account information on the number of individuals exposed, it is termed a "population risk" and is in units of expected increased cases per a time period. If the risk estimate does not take into account the number of individuals exposed, it is termed an "individual risk" and is in units of incidence rate per a time period. Population risks are of more use for cost/benefit analysis; individual risks are of more use for evaluating whether risks to individuals are "acceptable".
Risk Management
Risk management is a structured approach to managing uncertainty through, risk assessment, developing strategies to manage it, and mitigation of risk using managerial resources. The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Some traditional risk managements are focused on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments.
The objective of risk management is to reduce different risks related to a pre-selected domain to the level accepted by society. It may refer to numerous types of threats caused by environment, technology, humans, organizations and politics. On the other hand it involves all means available for humans, or in particular, for a risk management entity (person, staff, and organization).
In your project, you have to estimate how long it takes to complete a certain task. You estimate that it usually takes 15 days to complete. If things go well it may take 12 days but if things go badly it may take 20 days.
In your project plan you enter 15 days against the task. The other information, the best case estimate of 12 days and the worst case estimate of 20 days, is not entered into the project at all. If this seems familiar, then you already go through the process of identifying uncertainty or risk. By entering only the most likely duration a great deal of additional information is lost. But with Schedule Risk this extra information is used to help produce a much more realistic project. And you are not just limited to durations. Uncertainty in resources and costs can also be modeled in your project to produce an even greater depth and accuracy to the information available to you.
Who should use Schedule Risk Analysis
The simple answer is - anyone who manages a project! If you are running projects that are time and/or cost critical, risk analysis will help you manage your projects more effectively and help reduce the chances of your project being late and over budget.
Pert master is used by project planners of all levels, from those just entering into the Schedule Risk arena to the world's leading risk experts.
How easy is it to use?
It is very easy. You do not need to be an expert in risk and statistics to be able to use schedule risk. With normal project planning, the level of detail and complexity that you build into the project is up to you and your requirements. This is the same with Schedule Risk. Very little extra information is required as a minimum but you have the ability to provide a great deal of very specific additional information if you require it. Pert master is acclaimed as being very easy to use. By simply following the tutorials and examples you will be able to incorporate risk into your project with ease. Pert master includes a Quick Risk (link) facility that lets you add risk to your project in seconds.
Risk Assessment
Risk assessment may be the most important step in the risk management process, and may also be the most difficult and prone to error. Once risks have been identified and assessed, the steps to properly deal with them are much more programmatically.
Part of the difficulty of risk management is that measurement of both of the quantities in which risk assessment is concerned can be very difficult itself. Uncertainty in the measurement is often large in both cases. Also, risk management would be simpler if a single metric could embody all of the information in the measurement. However, since two quantities are being measured, this is not possible. A risk with a large potential loss and a low probability of occurring must be treated differently than one with a low potential loss but a high likelihood of occurring. In theory both are of nearly equal priority in dealing with first, but in practice it can be very difficult to manage when faced with the scarcity of resources, especially time, in which to conduct the risk management process. Expressed mathematically,
Financial decisions, such as insurance, often express loss terms in dollars. When risk assessment is used for public health or environmental decisions, there are differences of opinions as to whether the loss can be quantified in a common metric such as dollar values or some numerical measure of quality of life. Often for public health and environmental decisions, the loss term is simply a verbal description of the outcome, such as increased cancer incidence or incidence of birth defects. In that case, the "risk" is expressed.
If the risk estimate takes into account information on the number of individuals exposed, it is termed a "population risk" and is in units of expected increased cases per a time period. If the risk estimate does not take into account the number of individuals exposed, it is termed an "individual risk" and is in units of incidence rate per a time period. Population risks are of more use for cost/benefit analysis; individual risks are of more use for evaluating whether risks to individuals are "acceptable".
Risk Management
Risk management is a structured approach to managing uncertainty through, risk assessment, developing strategies to manage it, and mitigation of risk using managerial resources. The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Some traditional risk managements are focused on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments.
The objective of risk management is to reduce different risks related to a pre-selected domain to the level accepted by society. It may refer to numerous types of threats caused by environment, technology, humans, organizations and politics. On the other hand it involves all means available for humans, or in particular, for a risk management entity (person, staff, and organization).
Categories of risks:
Schedule Risk:
Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:
Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect on project and finally on company economy and may lead to project failure.
Schedules often slip due to following reasons:
- Wrong
time estimation
- Resources
are not tracked properly. All resources like staff, systems, skills of
individuals etc.
- Failure
to identify complex functionalities and time required to develop those
functionalities.
- Unexpected
project scope expansions.
Budget Risk:
- Wrong
budget estimation.
- Cost
overruns
- Project
scope expansion
Operational Risks:
Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:
Risks of loss due to improper process implementation, failed system or some external events risks.
Causes of Operational risks:
- Failure
to address priority conflicts
- Failure
to resolve the responsibilities
- Insufficient
resources
- No
proper subject training
- No
resource planning
- No
communication in team.
Technical risks:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:
Technical risks generally leads to failure of functionality and performance.
Causes of technical risks are:
- Continuous
changing requirements
- No
advanced technology available or the existing technology is in initial
stages.
- Product
is complex to implement.
- Difficult
project modules integration.
Programmatic Risks:
These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:
These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.
These external events can be:
-
Running out of fund.
-
Market development
-
Changing customer product strategy and priority
-
Government rule changes.
No comments:
Post a Comment