Software Risks

Are you developing any Test plan or test strategy for your project? Have you addressed all risks properly in your test plan or test strategy?

As testing is the last part of the project, it’s always under pressure and time constraint. To save time and money you should be able to prioritize your testing work. How will prioritize testing work? For this you should be able to judge more important and less important testing work. How will you decide which work is more or less important? Here comes need of risk-based testing.


What is Risk?
“Risk are future uncertain events with a probability of occurrence and a potential for loss”

Risk identification and management are the main concerns in every software project. Effective analysis of software risks will help to effective planning and assignments of work.

In this article I will cover what are the “types of risks”. In next articles I will try to focus on risk identification, risk management and mitigation.

Risks are identified, classified and managed before actual execution of program. These risks are classified in different categories.

Categories of risks:

1. 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:
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.

2. Budget Risk:
Wrong budget estimation.
Cost overruns
Project scope expansion

3. 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.

4. Technical risks:
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.

5. 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:
Running out of fund.
Market development
Changing customer product strategy and priority
Government rule changes.
These are all common categories in which software project risks can be classified. I will cover in detail “How to identify and manage risks” in next article.

End to End Testing

Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Fuzz Testing

Fuzz testing or fuzzing is a software testing technique that provides invalid, unexpected, or random data to the inputs of a program. If the program fails (for example, by crashing or failing built-in code assertions), the defects can be noted.

File formats and network protocols are the most common targets of fuzz testing, but any type of program input can be fuzzed. Interesting inputs include environment variables, keyboard and mouse events, and sequences of API calls. Even items not normally considered "input" can be fuzzed, such as the contents of databases, shared memory, or the precise interleaving of threads.

Monkey Testing

In computer science, a monkey test is a unit test that runs with no specific test in mind. The monkey in this case is the producer of any input. For example, a monkey test can enter random strings into text boxes to ensure handling of all possible user input or provide garbage files to check for loading routines that have blind faith in their data.

Testers use the term monkey when referring to a fully automated testing tool. This tool doesn’t know how to use any application, so it performs mouse clicks on the screen or keystrokes on the keyboard randomly. The test monkey is technically known to conduct stochastic testing, which is in the category of black-box testing. There are different types of monkey testing.[

scope of Test Plan

The scope of testing also covers the type of testing one needs to do like load testing stress testing for load and stress how many users test one is going to simulate. also what hardware it is going to use.
if requred one can also provide the schedule and what are elimiated in the testing how many test cycle what is bug reporting and fixing work flow. etc.

Defect Density

Defect Density

Defect Density Definition
Defect Density is the number of confirmed defects detected in software/component during a defined period of development/operation divided by the size of the software/component.

Elaboration
The 'defects' are:

confirmed and agreed upon (not just reported).
Dropped defects are not counted.

The ‘period’ might be for one of the following:

for a duration (say, the first month, the quarter, or the year).
for each phase of the software life cycle.
for the whole of the software life cycle.
The ‘size’ is measured in one of the following:

Function Points (FP)
Source Lines of Code


Defect Density Formula


Defect Density Uses
For comparing the relative number of defects in various software components so that high-risk components can be identified and resources focused towards them
For comparing software/products so that ‘quality’ of each software/product can be quantified and resources focused towards those with low quality.

Defect Injection / Defect Seeding

Defect Injection is also known as 'Defect Seeding', 'Fault injection'. The
Process of adding known defects to the existing ones is
called as Defect Seeding. The Idea is while detecting the
known bugs unknown bugs might be detected. The goal is to
determine the Bug Detection Rate.

What is Defect Seeding?
Answer
# 1 Defect Seeding : For identify the Capability of tester
team , One Group will insert Defect in appliaction ,This
Bug will found by another Group

Example : In Real Appliaction this group will find 650 bug
but in defect seeding software they will find 30 bug out of
50 Bug total Bug in real appliaction 50*650/30 = 1084 bug
is available in Appliaction



What is Defect Seeding?
Answer
# 2 In this method, intentionally the developer/lead will
introduce the bugs in to product... we dont know in which
module they will occur.. So we have to do regression
testing to identify that bugs as well as residual bugs(more
bugs). The main intention of this is to get more bugs.