Unit 3 Software Testing

Download as pdf or txt
Download as pdf or txt
You are on page 1of 21

Unit Testing

Unit Testing is a software testing technique by means of which individual units of software
i.e. group of computer program modules, usage procedures, and operating procedures are
tested to determine whether they are suitable for use or not.The purpose of unit testing is to
validate that each unit of the software works as intended and meets the requirements. Unit
testing is typically performed by developers, and it is performed early in the development
process before the code is integrated and tested as a whole system.
Unit tests are automated and are run each time the code is changed to ensure that new code
does not break existing functionality. Unit tests are designed to validate the smallest
possible unit of code, such as a function or a method, and test it in isolation from the rest of
the system. This allows developers to quickly identify and fix any issues early in the
development process, improving the overall quality of the software and reducing the time
required for later testing.
It is a testing method using which every independent module is tested to determine if there
is an issue by the developer himself. It is correlated with the functional correctness of the
independent modules. Unit Testing of the software product is carried out during the
development of an application. An individual component may be either an individual
function or a procedure. Unit Testing is typically performed by the developer. In SDLC or
V Model, Unit testing is the first level of testing done before integration testing.

Why Unit Testing?

In a testing level hierarchy, unit testing is the first level of testing done before integration and
other remaining levels of the testing. It uses modules for the testing process which reduces the
dependency of waiting for Unit testing frameworks, stubs, drivers and mock objects are used
for assistance in unit testing.

Generally, the software goes under four level of testing: Unit Testing, Integration Testing,
System Testing, and Acceptance Testing but sometimes due to time consumption software
testers does minimal unit testing but skipping of unit testing may lead to higher defects during
Integration Testing, System Testing, and Acceptance Testing or even during Beta Testing
which takes place after the completion of software application.

Some crucial reasons are listed below:

o Unit testing helps tester and developers to understand the base of code that makes them
able to change defect causing code quickly.
o Unit testing helps in the documentation.
o Unit testing fixes defects very early in the development phase that's why there is a
possibility to occur a smaller number of defects in upcoming testing levels.
o It helps with code reusability by migrating code and test cases.

Types of Unit Testing:

There are 2 types of Unit Testing: Manual, and Automated.

Objective of Unit Testing:

The objective of Unit Testing is:


1. To isolate a section of code.
2. To verify the correctness of the code.
3. To test every function and procedure.
4. To fix bugs early in the development cycle and to save costs.
5. To help the developers to understand the code base and enable them to make changes
quickly.
6. To help with code reuse.

Workflow of Unit
Testing:

Unit Testing Techniques:


There are 3 types of Unit Testing Techniques. They are
1. Black Box Testing: This testing technique is used in covering the unit tests for input,
user interface, and output parts.
2. White Box Testing: This technique is used in testing the functional behavior of the
system by giving the input and checking the functionality output including the internal
design structure and code of the modules.
3. Gray Box Testing: This technique is used in executing the relevant test cases, test
methods, test functions, and analyzing the code performance for the modules.

Unit Testing Tools:

Here are some commonly used Unit Testing tools:


1. Jtest
2. Junit
3. NUnit

Advantages of Unit Testing:


1. Unit Testing allows developers to learn what functionality is provided by a unit and
how to use it to gain a basic understanding of the unit API.
2. Unit testing allows the programmer to refine code and make sure the module works
properly.
3. Unit testing enables testing parts of the project without waiting for others to be
completed.
4. Early Detection of Issues: Unit testing allows developers to detect and fix issues early
in the development process, before they become larger and more difficult to fix.
5. Improved Code Quality: Unit testing helps to ensure that each unit of code works as
intended and meets the requirements, improving the overall quality of the software.

Disadvantages of Unit Testing:

1. The process is time-consuming for writing the unit test cases.


2. Unit Testing will not cover all the errors in the module because there is a chance of
having errors in the modules while doing integration testing.
3. Unit Testing is not efficient for checking the errors in the UI(User Interface) part of the
module.
4. It requires more time for maintenance when the source code is changed frequently.
5. It cannot cover the non-functional testing parameters such as scalability, the
performance of the system, etc.

Levels of testing :
Software Testing is an activity performed to identify errors so that errors can be removed to
obtain a product with greater quality. To assure and maintain the quality of software and to
represents the ultimate review of specification, design, and coding, Software testing is
required. There are different levels of testing :

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

Level1: Unit Testing

Unit testing is the first level of software testing, which is used to test if software modules are
satisfying the given requirement or not.The first level of testing involves analyzing each unit
or an individual component of the software application.

Unit testing is also the first level of functional testing. The primary purpose of executing unit
testing is to validate unit components with their performance.A unit component is an individual
function or regulation of the application, or we can say that it is the smallest testable part of the
software. The reason of performing the unit testing is to test the correctness of inaccessible
code.Unit testing will help the test engineer and developers in order to understand the base of
code that makes them able to change defect causing code quickly.
Level2: Integration Testing

The second level of software testing is the integration testing. The integration testing process
comes after unit testing. It is mainly used to test the data flow from one module or
component to other modules. In integration testing, the test engineer tests the units or
separate components or modules of the software in a group.The primary purpose of executing
the integration testing is to identify the defects at the interaction between integrated
components or units.

When each component or module works separately, we need to check the data flow between
the dependent modules, and this process is known as integration testing.

Level3: System Testing

The third level of software testing is system testing, which is used to test the software's
functional and non-functional requirements. It is end-to-end testing where the testing
environment is parallel to the production environment. In the third level of software testing, we
will test the application as a whole system.

To check the end-to-end flow of an application or the software as a user is known as System
testing.In system testing, we will go through all the necessary modules of an application and
test if the end features or the end business works fine, and test the product as a complete system.

we can say that System testing is a sequence of different types of tests to implement and
examine the entire working of an integrated software computer system against requirements.

Level4: Acceptance Testing

The last and fourth level of software testing is acceptance testing, which is used to evaluate
whether a specification or the requirements are met as per its delivery. The software has passed
through three testing levels (Unit Testing, Integration Testing, System Testing).

The acceptance testing is also known as User acceptance testing (UAT) and is done by the
customer before accepting the final product.Usually, UAT is done by the domain expert
(customer) for their satisfaction and checks whether the application is working according to
given business scenarios and real-time scenarios

These testing can be conducted at various stages of software development. The levels of
testing along with the corresponding software development phase is shown by the
following diagram –
Integration testing
Integration testing is a software testing technique that focuses on verifying the interactions
and data exchange between different components or modules of a software application. The
goal of integration testing is to identify any problems or bugs that arise when different
components are combined and interact with each other. Integration testing is typically
performed after unit testing and before system testing. It helps to identify and resolve
integration issues early in the development cycle, reducing the risk of more severe and
costly problems later on.
Integration testing can be done by picking module by module. This can be done so that
there should be proper sequence to be followed. And also if you don’t want to miss out on
any integration scenarios then you have to follow the proper sequence. Exposing the defects
is the major focus of the integration testing and the time of interaction between the
integrated units.
Let us see one sample example of a banking application, as we can see in the below image of
amount transfer.

o First, we will login as a user P to amount transfer and send Rs200 amount, the
confirmation message should be displayed on the screen as amount transfer
successfully. Now logout as P and login as user Q and go to amount balance page and
check for a balance in that account = Present balance + Received Balance. Therefore,
the integration test is successful.
o Also, we check if the amount of balance has reduced by Rs200 in P user account.
o Click on the transaction, in P and Q, the message should be displayed regarding the
data and time of the amount transfer.

Integration test approaches – There are four types of integration testing approaches.
Those approaches are the following:

1. Big-Bang Integration Testing – It is the simplest integration testing approach, where all
the modules are combined and the functionality is verified after the completion of
individual module testing. In simple words, all the modules of the system are simply put
together and tested. This approach is practicable only for very small systems. If an error is
found during the integration testing, it is very difficult to localize the error as the error may
potentially belong to any of the modules being integrated. So, debugging errors reported
during big bang integration testing is very expensive to fix.
Big-Bang integration testing is a software testing approach in which all components or
modules of a software application are combined and tested at once. This approach is
typically used when the software components have a low degree of interdependence or
when there are constraints in the development environment that prevent testing individual
components. The goal of big-bang integration testing is to verify the overall functionality of
the system and to identify any integration problems that arise when the components are
combined. While big-bang integration testing can be useful in some situations, it can also
be a high-risk approach, as the complexity of the system and the number of interactions
between components can make it difficult to identify and diagnose problems.
Advantages:
 It is convenient for small systems.
 Simple and straightforward approach.
 Can be completed quickly.
 Does not require a lot of planning or coordination.
 May be suitable for small systems or projects with a low degree of interdependence
between components.

Disadvantages:
 There will be quite a lot of delay because you would have to wait for all the modules to
be integrated.
 High risk critical modules are not isolated and tested on priority since all modules are
tested at once.
 Not Good for long Projects.
 High risk of integration problems that are difficult to identify and diagnose.

2. Bottom-Up Integration Testing – In bottom-up testing, each module at lower levels is


tested with higher modules until all modules are tested. The primary purpose of this
integration testing is that each subsystem tests the interfaces among various modules
making up the subsystem. This integration testing uses test drivers to drive and pass
appropriate data to the lower level modules.

Advantages:
 In bottom-up testing, no stubs are required.
 A principle advantage of this integration testing is that several disjoint subsystems can
be tested simultaneously.
 It is easy to create the test conditions.
 Best for the applications that uses bottom up design approach.
 It is Easy to observe the test results.

Disadvantages:
 Driver modules must be produced.
 In this testing, the complexity that occurs when the system is made up of a large number
of small subsystems.
 As Far modules have been created, there is no working model can be represented.

3. Top-Down Integration Testing – Top-down integration testing technique is used in


order to simulate the behaviour of the lower-level modules that are not yet integrated. In
this integration testing, testing takes place from top to bottom. First, high-level modules are
tested and then low-level modules and finally integrating the low-level modules to a high
level to ensure the system is working as intended.

Advantages:
 Separately debugged module.
 Few or no drivers needed.
 It is more stable and accurate at the aggregate level.
 Easier isolation of interface errors.
 In this, design defects can be found in the early stages.

Disadvantages:
 Needs many Stubs.
 Modules at lower level are tested inadequately.
 It is difficult to observe the test output.
 It is difficult to stub design.

4. Mixed Integration Testing – A mixed integration testing is also called sandwiched


integration testing. A mixed integration testing follows a combination of top down and
bottom-up testing approaches. In top-down approach, testing can start only after the top-
level module have been coded and unit tested. In bottom-up approach, testing can start only
after the bottom level modules are ready. This sandwich or mixed approach overcomes this
shortcoming of the top-down and bottom-up approaches. It is also called the hybrid
integration testing. also, stubs and drivers are used in mixed integration testing.

Advantages:
 Mixed approach is useful for very large projects having several sub projects.
 This Sandwich approach overcomes this shortcoming of the top-down and bottom-up
approaches.
 Parallel test can be performed in top and bottom layer tests.

Disadvantages:
 For mixed integration testing, it requires very high cost because one part has Top-down
approach while another part has bottom-up approach.
 This integration testing cannot be used for smaller systems with huge interdependence
between different modules.

System Testing
System testing is a type of software testing that evaluates the overall functionality and
performance of a complete and fully integrated software solution. It tests if the system
meets the specified requirements and if it is suitable for delivery to the end-users. This type
of testing is performed after the integration testing and before the acceptance testing.
System Testing is a type of software testing that is performed on a complete integrated
system to evaluate the compliance of the system with the corresponding requirements. In
system testing, integration testing passed components are taken as input. The goal of
integration testing is to detect any irregularity between the units that are integrated together.
System testing detects defects within both the integrated units and the whole system. The
result of system testing is the observed behavior of a component or a system when it is
tested. System Testing is carried out on the whole system in the context of either system
requirement specifications or functional requirement specifications or in the context of
both. System testing tests the design and behavior of the system and also the expectations
of the customer. It is performed to test the system beyond the bounds mentioned in
the software requirements specification (SRS). System Testing is basically performed by a
testing team that is independent of the development team that helps to test the quality of the
system impartial. It has both functional and non-functional testing. System Testing is a
black-box testing. System Testing is performed after the integration testing and before the
acceptance testing.

System Testing Process: System Testing is performed in the following steps:


 Test Environment Setup: Create testing environment for the better quality testing.
 Create Test Case: Generate test case for the testing process.
 Create Test Data: Generate the data that is to be tested.
 Execute Test Case: After the generation of the test case and the test data, test cases are
executed.
 Defect Reporting: Defects in the system are detected.
 Regression Testing: It is carried out to test the side effects of the testing process.
 Log Defects: Defects are fixed in this step.
 Retest: If the test is not successful then again test is performed.

Types of System Testing:

 Performance Testing: Performance Testing is a type of software testing that is carried


out to test the speed, scalability, stability and reliability of the software product or
application.
 Load Testing: Load Testing is a type of software Testing which is carried out to
determine the behavior of a system or software product under extreme load.
 Stress Testing: Stress Testing is a type of software testing performed to check the
robustness of the system under the varying loads.
 Scalability Testing: Scalability Testing is a type of software testing which is carried
out to check the performance of a software application or system in terms of its
capability to scale up or scale down the number of user request load.
Tools used for System Testing :
1. JMeter
2. Gallen Framework
3. Selenium

Advantages of System Testing :


 The testers do not require more knowledge of programming to carry out this testing.
 It will test the entire product or software so that we will easily detect the errors or
defects which cannot be identified during the unit testing and integration testing.
 The testing environment is similar to that of the real time production or business
environment.
 It checks the entire functionality of the system with different test scripts and also it
covers the technical and business requirements of clients.
 After this testing, the product will almost cover all the possible bugs or errors and hence
the development team will confidently go ahead with acceptance testing.

Disadvantages of System Testing :


 Can be time-consuming and expensive.
 Requires adequate resources and infrastructure.
 Can be complex and challenging, especially for large and complex systems.
 Dependent on the quality of requirements and design documents.
 Limited visibility into the internal workings of the system.

Debugging
Debugging is the process of identifying and resolving errors, or bugs, in a software system.
It is an important aspect of software engineering because bugs can cause a software system
to malfunction, and can lead to poor performance or incorrect results. Debugging can be a
time-consuming and complex task, but it is essential for ensuring that a software system is
functioning correctly.

Steps involved in Debugging

Following are the different steps that are involved in debugging:


1. Identify the Error: Identifying an error in a wrong may result in the wastage of time.
It is very obvious that the production errors reported by users are hard to interpret, and
sometimes the information we receive is misleading. Thus, it is mandatory to identify
the actual error.
2. Find the Error Location: Once the error is correctly discovered, you will be required
to thoroughly review the code repeatedly to locate the position of the error. In general,
this step focuses on finding the error rather than perceiving it.
3. Analyze the Error: The third step comprises error analysis, a bottom-up approach that
starts from the location of the error followed by analyzing the code. This step makes it
easier to comprehend the errors. Mainly error analysis has two significant goals, i.e.,
evaluation of errors all over again to find existing bugs and postulating the uncertainty
of incoming collateral damage in a fix.
4. Prove the Analysis: After analyzing the primary bugs, it is necessary to look for some
extra errors that may show up on the application. By incorporating the test framework,
the fourth step is used to write automated tests for such areas.
5. Cover Lateral Damage: The fifth phase is about accumulating all of the unit tests for
the code that requires modification. As when you run these unit tests, they must pass.
6. Fix & Validate: The last stage is the fix and validation that emphasizes fixing the bugs
followed by running all the test scripts to check whether they pass.

Debugging Approaches/Strategies:

1. Brute Force: Study the system for a larger duration in order to understand the system.
It helps the debugger to construct different representations of systems to be debugging
depending on the need. A study of the system is also done actively to find recent
changes made to the software.
2. Backtracking: Backward analysis of the problem which involves tracing the program
backward from the location of the failure message in order to identify the region of
faulty code. A detailed study of the region is conducted to find the cause of defects.
3. Forward analysis of the program involves tracing the program forwards using
breakpoints or print statements at different points in the program and studying the
results. The region where the wrong outputs are obtained is the region that needs to be
focused on to find the defect.
4. Using the past experience of the software debug the software with similar problems in
nature. The success of this approach depends on the expertise of the debugger.
5. Cause elimination: it introduces the concept of binary partitioning. Data related to the
error occurrence are organized to isolate potential causes.

Debugging Tools:
Debugging tool is a computer program that is used to test and debug other programs. A lot
of public domain software like gdb and dbx are available for debugging. They offer
console-based command-line interfaces. Examples of automated debugging tools include
code based tracers, profilers, interpreters, etc. Some of the widely used debuggers are:
 Radare2
 WinDbg
 Valgrind

Advantages of Debugging :

1. Improved system quality: By identifying and resolving bugs, a software system can be
made more reliable and efficient, resulting in improved overall quality.

2. Reduced system downtime: By identifying and resolving bugs, a software system can
be made more stable and less likely to experience downtime, which can result in
improved availability for users.

3. Increased user satisfaction: By identifying and resolving bugs, a software system can
be made more user-friendly and better able to meet the needs of users, which can result
in increased satisfaction.

4. Reduced development costs: By identifying and resolving bugs early in the


development process, it can save time and resources that would otherwise be spent on
fixing bugs later in the development process or after the system has been deployed.

Disadvantages of Debugging:

1. Time-consuming: Debugging can be a time-consuming process, especially if the bug is


difficult to find or reproduce. This can cause delays in the development process and add
to the overall cost of the project.

2. Requires specialized skills: Debugging can be a complex task that requires specialized
skills and knowledge. This can be a challenge for developers who are not familiar with
the tools and techniques used in debugging.

3. Can be difficult to reproduce: Some bugs may be difficult to reproduce, which can
make it challenging to identify and resolve them.

4. Can be difficult to diagnose: Some bugs may be caused by interactions between


different components of a software system, which can make it challenging to identify
the root cause of the problem.

Domain Testing :
It is a software testing technique where minimum numbers of inputs are used to access
appropriate output of a system, to ensure the system does not accept invalid input values.
The system is expected to give required outputs blocking the invalid inputs.

Structure of Domain Testing :


The process is quite similar everywhere when it comes to build the strategy, where the
following step-by-structure is used that suits most of the scenarios:
 Think what can go wrong.
 Find a solution to handle each case.
 Pick several points to test each error.
 Take one test point to examine adjacent domains
 Then start running the test
 Check if the boundaries are faulty in nature
 Inspect boundaries of all domains

Domain Knowledge :
Domain knowledge is the good understanding of particular sphere i.e. a person is
acquainted with particular term of discipline. It helps to minimize delivery cycle, improve
customer service reduce development time.

Domain Testing Strategy :


We know that every domain has a boundary from which it is been defined, points near the
boundaries are checked during tests. A testing process every time begins with a question.
The domain testing strategy is an experiment by a QA specialist to find the solutions to
these answers:
 What domain should be tested ?
 How to group values into classes ?
 What value should I test ?
 How am I going to get the results ?

Real-life example of Domain testing :


Let there be a group of students in a study tour. For entertainment purpose they have been
given a ticket to perform a specific activity based on gender and age inputs. Here the
entertainment facility act as the test, age groups will be boundary values with numerous
possible scenarios. Students perform activities in following manner:
 Children less than 5 years old are to tell a poem
 Boys 5>=10 are to draw
 Girls 5>=10 are to sing a song
 Boys >10 are to compete in a sport
 Girls >10 are to participate in quiz
 Remaining children >15 are to participate in essay competition
On the basis of given algorithm, specialist groups the values into classes i.e. age groups,
then boundary values is picked i.e. highest and lowest age value in a group. Then different
scenarios are built with expected results for each.
Domain testing requires knowledge of providing correct input to get necessary output. It is
also equivalent to boundary analysis testing, where input variables examined and taken as
boundary values and equivalence class values to get desired result.

Domain knowledge is crucial as each industry or field is unique and has specific requirements.
 Retail − In retail domains, the workflow runs at different levels. Therefore, testing
engineers looking forward to running domain testing in retail must know how things
work in warehouse management, in-store solutions, and so on.
 Online Banking − Online backing consists of several crucial internet-dependent
activities such as login, money transfer, bill payment, etc., which is quite different than
retails.
 Healthcare − Handling healthcare domains is quite critical as it holds a huge risk to
someone's life. Besides, it includes numerous menial yet time-consuming tasks like
patient's entry, health history, prescriptions, setting & modifying schedules, insurance,
etc.

Regression Testing
Regression Testing is the process of testing the modified parts of the code and the parts
that might get affected due to the modifications to ensure that no new errors have been
introduced in the software after the modifications have been made. Regression means return
of something and in the software field, it refers to the return of a bug.

When to do regression testing?


 When a new functionality is added to the system and the code has been modified to
absorb and integrate that functionality with the existing code.
 When some defect has been identified in the software and the code is debugged to fix it.
 When the code is modified to optimize its working.

Process of Regression testing:


Firstly, whenever we make some changes to the source code for any reasons like adding
new functionality, optimization, etc. then our program when executed fails in the
previously designed test suite for obvious reasons. After the failure, the source code is
debugged in order to identify the bugs in the program. After identification of the bugs in the
source code, appropriate modifications are made. Then appropriate test cases are selected
from the already existing test suite which covers all the modified and affected parts of the
source code. We can add new test cases if required. In the end regression testing is
performed using the selected test cases.
Techniques for the selection of Test cases for Regression Testing:

 Select all test cases: In this technique, all the test cases are selected from the already
existing test suite. It is the most simple and safest technique but not much efficient.

 Select test cases randomly: In this technique, test cases are selected randomly from the
existing test-suite but it is only useful if all the test cases are equally good in their fault
detection capability which is very rare. Hence, it is not used in most of the cases.

 Select modification traversing test cases: In this technique, only those test cases are
selected which covers and tests the modified portions of the source code the parts which
are affected by these modifications.

 Select higher priority test cases: In this technique, priority codes are assigned to each
test case of the test suite based upon their bug detection capability, customer
requirements, etc. After assigning the priority codes, test cases with highest priorities
are selected for the process of regression testing.
Test case with highest priority has highest rank. For example, test case with priority
code 2 is less important than test case with priority code 1.
Tools for regression testing: In regression testing, we generally select the test cases form
the existing test suite itself and hence, we need not to compute their expected output and it
can be easily automated due to this reason. Automating the process of regression testing
will be very much effective and time saving.
Most commonly used tools for regression testing are:
 Selenium
 WATIR (Web Application Testing In Ruby)
 QTP (Quick Test Professional)
 RFT (Rational Functional Tester)
 Winrunner
 Silktest

Advantages of Regression Testing:


 It ensures that no new bugs has been introduced after adding new functionalities to the
system.
 As most of the test cases used in Regression Testing are selected from the existing test
suite and we already know their expected outputs. Hence, it can be easily automated by
the automated tools.
 It helps to maintain the quality of the source code.

Disadvantages of Regression Testing:


 It can be time and resource consuming if automated tools are not used.
 It is required even after very small changes in the code.

Slice Based Testing


 Prioritize test cases based on the coverage requirements present in the relevant slices of
the outputs of test cases.
 Originally proposed by [Weiser 88] and [Gallagher 91] in software maintenance
 Useful for
o Software Debugging
o Software Maintenance
o Program understanding
o Quantification of functional cohesion
Comparison
 The test case prioritization techniques discussed before this, are primarily based on
variations of various structural elements in a program.
o The total requirement coverage
 orders test cases in decreasing order of the number of statements they exercise
o The additional requirement coverage
 orders test cases in decreasing order of the number of additional statements they
exercise,
 That has not yet been covered by the tests earlier in the prioritized sequence.

Drawback of Prior Techniques


 These prioritization techniques do not take into consideration
o the statements or branches that actually influenced, or
o could potentially influence, the values of the program output
 Neither do they take into consideration whether
o a test case traverses
o a modified statement or not while prioritizing the test cases
Informal Definition of SBT
 Slice-based Testing technique
o divides a program into components (or slices)
 A program slice?
o Refers to a set of program statements that may affect
 the computation of variable v at statement s

Risk Analysis
The probability of any unwanted incident is defined as Risk. In Software Testing, risk
analysis is the process of identifying the risks in applications or software that you built and
prioritizing them to test.
Why use Risk Analysis?

In any software, using risk analysis at the beginning of a project highlights the potential
problem areas. After knowing about the risk areas, it helps the developers and managers to
mitigate the risks. When a test plan has been created, risks involved in testing the product are
to be taken into consideration along with the possibility of the damage they may cause to your
software along with solutions.

the possible risks that you could encounter are :

1. Use of new hardware


2. Use of new technology
3. Use of new automation tool
4. The sequence of code
5. Availability of test resources for the application

there are certain risks that are unavoidable are:


1. The time that you allocated for testing
2. A defect leakage due to the complexity or size of the application
3. Urgency from the clients to deliver the project
4. Incomplete requirements

In such cases, you have to tackle the situation with care. Following points can be taken care of:

 Conduct Risk Assessment review meeting


 Use maximum resources to work on high-risk areas
 Create a Risk Assessment database for future use
 Identify and notice the risk magnitude indicators: high, medium, low.

These risk magnitude indicators are:

High: means the effect of the risk would be very high and non-tolerable. The company might
face loss.

Medium: it is tolerable but not desirable. The company may suffer financially but there is a
limited risk.

Low: it is tolerable. There lies little or no external exposure or no financial loss.

Moving on! Our next topic queued is as follows:

Risk Identification

There are different sets of risks included in the risk identification process. Those are as follows:

1. Business Risks: This risk is the most common risk associated with our topic. It is the
risk that may come from your company or your customer, not from your project.
2. Testing Risks: You should be well acquainted with the platform you are working on,
along with the software testing tools being used.
3. Premature Release Risk: a fair amount of knowledge to analyze the risk associated
with releasing unsatisfactory or untested software is required
4. Software Risks: You should be well versed with the risks associated with the software
development process.

After identifying the risks associated with your software, the next step is to assess the risks; i.e,
Risk Assessment.

Risk Assessment

In the risk analysis process, these steps prove to be the most important one. It is said that this
step is way too complex and should be tackled with the utmost care. After risk identification,
assessment has to be dealt programmatically. There are a few perspectives on risk assessment.
Read on!
The perspective of Risk Assessment

There are three perspectives of Risk Assessment:

 Effect
 Cause
 Likelihood

Effect – To assess risk by Effect. In case you identify a condition, event or action and try to
determine its impact.

Cause – To assess risk by Cause is opposite of by Effect. Initialize scanning the problem and
reach to the point that could be the most probable reason behind that.

Likelihood – To assess risk by Likelihood is to say that there is a probability that a requirement
won’t be satisfied.

How to perform Risk Analysis?

There are three steps:

1. Searching the risk


2. Analyzing the impact of each individual risk
3. Measures for the risk identified

Prioritization

Prioritization refers to prioritizing test cases in test suite on basis of different factors. Factors
could be code coverage, risk/critical modules, functionality, features, etc.
Why should test cases be prioritized?
As the size of software increases, test suite also grows bigger and also requires more efforts
to maintain test suite. In order to detect bugs in software as early as possible, it is important
to prioritize test cases so that important test cases can be executed first.
Types of Test Case Prioritization :
 General Prioritization :
In this type of prioritization, test cases that will be useful for the subsequent modified
versions of product are prioritized. It does not require any information regarding
modifications made in the product.
 Version – Specific Prioritization :
Test cases can also be prioritized such that they are useful on specific version of
product. This type of prioritization requires knowledge about changes that have been
introduced in product.

Prioritization Techniques :

1. Coverage – based Test Case Prioritization :


This type of prioritization is based on code coverage i.e. test cases are prioritized on basis
of their code coverage.

 Total Statement Coverage Prioritization –


In this technique, total number of statements covered by test case is used as factor to
prioritize test cases. For example, test case covering 10 statements will be given higher
priority than test case covering 5 statements.

 Additional Statement Coverage Prioritization –


This technique involves iteratively selecting test case with maximum statement
coverage, then selecting test case which covers statements that were left uncovered by
previous test case. This process is repeated till all statements have been covered.

 Total Branch Coverage Prioritization –


Using total branch coverage as factor for ordering test cases, prioritization can be
achieved. Here, branch coverage refers to coverage of each possible outcome of
condition.

 Additional Branch Coverage Prioritization –


Similar to additional statement coverage technique, it first selects text case with
maximum branch coverage and then iteratively selects test case which covers branch
outcomes that were left uncovered by previous test case.

 Total Fault-Exposing-Potential Prioritization –


Fault-exposing-potential (FEP) refers to ability of test case to expose fault. Statement
and Branch Coverage Techniques do not take into account fact that some bugs can be
more easily detected than others and also that some test cases have more potential to
detect bugs than others. FEP depends on :
1. Whether test cases cover faulty statements or not.
2. Probability that faulty statement will cause test case to fail.

2. Risk – based Prioritization :


This technique uses risk analysis to identify potential problem areas which if failed, could
lead to bad consequences. Therefore, test cases are prioritized keeping in mind potential
problem areas. In risk analysis, following steps are performed :
 List potential problems.
 Assigning probability of occurrence for each problem.
 Calculating severity of impact for each problem.
After performing above steps, risk analysis table is formed to present results. The table
consists of columns like Problem ID, Potential problem identified, Severity of Impact, Risk
exposure, etc.

3. Prioritization using Relevant Slice :


In this type of prioritization, slicing technique is used – when program is modified, all
existing regression test cases are executed in order to make sure that program yields same
result as before, except where it has been modified. For this purpose, we try to find part of
program which has been affected by modification, and then prioritization of test cases is
performed for this affected part. There are 3 parts to slicing technique :
 Execution slice –
The statements executed under test case form execution slice.
 Dynamic slice –
Statements executed under test case that might impact program output.
 Relevant Slice –
Statements that are executed under test case and don’t have any impact on the program
output but may impact output of test case.

4. Requirements – based Prioritization :


Some requirements are more important than others or are more critical in nature, hence test
cases for such requirements should be prioritized first. The following factors can be
considered while prioritizing test cases based on requirements :
 Customer assigned priority –
The customer assigns weight to requirements according to his need or understanding of
requirements of product.
 Developer perceived implementation complexity –
Priority is assigned by developer on basis of efforts or time that would be required to
implement that requirement.
 Requirement volatility –
This factor determines frequency of change of requirement.
 Fault proneness of requirements –
Priority is assigned based on how error-prone requirement has been in previous versions
of software.

Scheme
 Prioritization can be done by assigning high to low priority for test cases
 This priority assignment can be done by using a methodology
o That addresses features facing highest to lowest risk
o That addresses features with highest to lowest complexity
o Is based on the priority given to features after considering:
 Customer needs
 Budget constraints
 Time constraints
 Personnel constraints

Prioritization Guidelines
 Test case prioritization techniques aim at
o scheduling test cases for execution
o In an order that attempts to increase their effectiveness
o At meeting some performance goal.
 Various approaches are possible
o Rate of fault detection:
 A measure of how quickly faults are detected while testing.
 Faster fault detection during testing can provide
o Faster feedback on the system under test and
o Let software engineers begin correcting faults earlier than might otherwise be
possible.
o Rate of code coverage

Problem Sources
 Problems associated with the test-program
o Assumptions
o Prerequisites, and
o Risk
 Problems associated with the process
o Events
o Actions or
o Circumstances that might prevent the test plan to be executed on schedule.

You might also like