359211075011999

7388345364 Aditi

UNIT TESTING is a level of software testing where individual units/

components of a software are tested. The purpose is to validate that each
unit of the software performs as designed. A unit is the smallest testable
part of any software. It usually has one or a few inputs and usually a
single output. In procedural programming, a unit may be an individual
program, function, procedure, etc. In object-oriented programming, the
smallest unit is a method, which may belong to a base/ super class,
abstract class or derived/ child class. (Some treat a module of an
application as a unit. This is to be discouraged as there will probably be
many individual units within that module.) Unit testing frameworks,
drivers, stubs, and mock/ fake objects are used to assist in unit testing.

Unit Testing - Advantages:

 Reduces Defects in the Newly developed features or reduces bugs when
changing the existing functionality.

 Reduces Cost of Testing as defects are captured in very early phase.

 Improves design and allows better refactoring of code.

 Unit Tests, when integrated with build gives the quality of the build as well.

Unit Testing Life Cycle:

Unit Testing Techniques:
 Black Box Testing - Using which the user interface, input and output are
tested.

 White Box Testing - used to test each one of those functions behaviour is
tested.

 Gray Box Testing - Used to execute tests, risks and assessment methods.
WHITE BOX TESTING (also known as Clear Box Testing, Open
Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based
Testing or Structural Testing) is a software testing method in which the
internal structure/design/implementation of the item being tested is
known to the tester. The tester chooses inputs to exercise paths through
the code and determines the appropriate outputs. Programming know-
how and the implementation knowledge is essential. White box testing is
testing beyond the user interface and into the nitty-gritty of a system.
This method is named so because the software program, in the eyes of
the tester, is like a white/transparent box; inside which one clearly sees.
Thus, structural testing is an approach where the tests are derived from the
knowledge of the software's structure or internal implementation
Definition by ISTQB

 white-box testing: Testing based on an analysis of the internal

structure of the component or system.
 white-box test design technique: Procedure to derive and/or
select test cases based on an analysis of the internal structure of a
component or system.

Structural Testing Techniques:

 Statement Coverage - This technique is aimed at exercising all
programming statements with minimal tests.
 Branch Coverage - This technique is running a series of tests to ensure that
all branches are tested at least once.
 Path Coverage - This technique corresponds to testing all possible paths
which means that each statement and branch are covered

Example
A tester, usually a developer as well, studies the implementation code of
a certain field on a webpage, determines all legal (valid and invalid) AND
illegal inputs and verifies the outputs against the expected outcomes,
which is also determined by studying the implementation code.
White Box Testing is like the work of a mechanic who examines the
engine to see why the car is not moving.

Levels Applicable To
White Box Testing method is applicable to the following levels of software
testing:

 Unit Testing: For testing paths within a unit.

 Integration Testing: For testing paths between units.
 System Testing: For testing paths between subsystems.

However, it is mainly applied to Unit Testing.

Advantages
 Testing can be commenced at an earlier stage. One need not wait
for the GUI to be available.
 Testing is more thorough, with the possibility of covering most
paths.

Disadvantages
 Since tests can be very complex, highly skilled resources are
required, with a thorough knowledge of programming and
implementation.
 Test script maintenance can be a burden if the implementation
changes too frequently.
 Since this method of testing is closely tied to the application being
tested, tools to cater to every kind of implementation/platform may
not be readily available.
Integration Testing
INTEGRATION TESTING is a level of software testing where individual
units are combined and tested as a group. The purpose of this level of
testing is to expose faults in the interaction between integrated
units. Test drivers and test stubs are used to assist in Integration Testing.

Definition by ISTQB

 integration testing: Testing performed to expose defects in the

interfaces and in the
interactions between integrated components or systems. See also
component integration
testing, system integration testing.
 component integration testing: Testing performed to expose defects in
the interfaces and
interaction between integrated components.
 system integration testing: Testing the integration of systems and
packages; testing
interfaces to external organizations (e.g. Electronic Data Interchange,
Internet).

Analogy
During the process of manufacturing a ballpoint pen, the cap, the body,
the tail and clip, the ink cartridge and the ballpoint are produced
separately and unit tested separately. When two or more units are ready,
they are assembled and Integration Testing is performed. For example,
whether the cap fits into the body or not.

Method
Any of Black Box Testing, White Box Testing and Gray Box
Testing methods can be used. Normally, the method depends on your
definition of ‘unit’.

Tasks
 Integration Test Plan
o Prepare
o Review
o Rework
o Baseline
 Integration Test Cases/Scripts
o Prepare
o Review
o Rework
o Baseline
 Integration Test
o Perform

When is Integration Testing performed?

Integration Testing is the second level of testing performed after Unit
Testing and before System Testing.
Who performs Integration Testing?
Developers themselves or independent testers perform Integration
Testing.

Approaches
 Big Bang is an approach to Integration Testing where all or most of the
units are combined together and tested at one go. This approach is taken
when the testing team receives the entire software in a bundle. So what is
the difference between Big Bang Integration Testing and System Testing?
Well, the former tests only the interactions between the units while the
latter tests the entire system.
 Top Down is an approach to Integration Testing where top-level units are
tested first and lower level units are tested step by step after that. This
approach is taken when top-down development approach is followed. Test
Stubs are needed to simulate lower level units which may not be available
during the initial phases.
 Bottom Up is an approach to Integration Testing where bottom level units
are tested first and upper-level units step by step after that. This
approach is taken when bottom-up development approach is followed.
Test Drivers are needed to simulate higher level units which may not be
available during the initial phases.
 Sandwich/Hybrid is an approach to Integration Testing which is a
combination of Top Down and Bottom Up approaches.
 Software Maintenance Overview
Software Maintenance is the process of modifying a software product
after it has been delivered to the customer. The main purpose of
software maintenance is to modify and update software application after
delivery to correct faults and to improve performance. There are number
of reasons, why modifications are required, some of them are briefly
mentioned below:

 Market Conditions - Policies, which changes over the time, such as taxation
and newly introduced constraints like, how to maintain bookkeeping, may
trigger need for modification.

 Client Requirements - Over the time, customer may ask for new features
or functions in the software.

 Host Modifications - If any of the hardware and/or platform (such as

operating system) of the target host changes, software changes are needed
to keep adaptability.

 Organization Changes - If there is any business level change at client end,

such as reduction of organization strength, acquiring another company,
organization venturing into new business, need to modify in the original
software may arise.

Maintenance Activities
IEEE provides a framework for sequential maintenance process activities.
It can be used in iterative manner and can be extended so that
customized items and processes can be included.
These activities go hand-in-hand with each of the following phase:

 Identification & Tracing - It involves activities pertaining to identification

of requirement of modification or maintenance. It is generated by user or
system may itself report via logs or error messages. Here, the maintenance
type is classified also.
 Analysis - The modification is analysed for its impact on the system
including safety and security implications. If probable impact is severe,
alternative solution is looked for. A set of required modifications is then
materialized into requirement specifications. The cost of
modification/maintenance is analysed and estimation is concluded.
 Design - New modules, which need to be replaced or modified, are designed
against requirement specifications set in the previous stage. Test cases are
created for validation and verification.
 Implementation - The new modules are coded with the help of structured
design created in the design step
 System Testing - Integration testing is done among newly created modules.
Integration testing is also carried out between new modules and the system.
Finally, the system is tested as a whole, following regressive testing
procedures.
 Acceptance Testing - After testing the system internally, it is tested for
acceptance with the help of users. If at this state, user complaints some
issues they are addressed or noted to address in next iteration.
 Delivery - After acceptance test, the system is deployed all over the
organization either by small update package or fresh installation of the
system. The final testing takes place at client end after the software is
delivered.

Training facility is provided if required, in addition to the hard copy of user

manual.

 Maintenance management - Configuration management is an essential

part of system maintenance. It is aided with version control tools to control
versions, semi-version or patch management.

 Corrective Maintenance 
 Corrective maintenance deals with the repair of faults or defects found in day-
to-day system functions. A defect can result due to errors in software design,
logic and coding. Design errors occur when changes made to the software are
incorrect, incomplete, wrongly communicated, or the change request is
misunderstood. Logical errors result from invalid tests and conclusions,
incorrect implementation of design specifications, faulty logic flow, or
incomplete test of data. All these errors, referred to as residual errors, prevent
the software from conforming to its agreed specifications. Note that the need
for corrective maintenance is usually initiated by bug reports drawn by the
users.

                   
  
 In the event of a system failure due to an error, actions are taken to restore the
operation of the software system. The approach in corrective maintenance is
to locate the original specifications in order to determine what the system was
originally designed to do. However, due to pressure from management, the
 maintenance team sometimes resorts to emergency fixes known as patching.
Corrective maintenance accounts for 20% of all the maintenance activities.

 Adaptive Maintenance 
 Adaptive maintenance is the implementation of changes in a part of the
system, which has been affected by a change that occurred in some other part
of the system. Adaptive maintenance consists of adapting software to changes
in the environment such as the hardware or the operating system. The term
environment in this context refers to the conditions and the influences which
act (from outside) on the system. For example, business rules, work patterns,
and government policies have a significant impact on the software system.
 For instance, a government policy to use a single 'European currency' will
have a significant effect on the software system. An acceptance of this change
will require banks in various member countries to make significant changes in
their software systems to accommodate this currency. Adaptive maintenance
accounts for 25% of all the maintenance activities.

 Perfective Maintenance 
 Perfective maintenance mainly deals with implementing new or changed user
requirements. Perfective maintenance involves making functional
enhancements to the system in addition to the activities to increase the
system's performance even when the changes have not been suggested by
faults. This includes enhancing both the function and efficiency of the code
and changing the functionalities of the system as per the users' changing
needs.
 Examples of perfective maintenance include modifying the payroll program to
incorporate a new union settlement and adding a new report in the sales
analysis system. Perfective maintenance accounts for 50%, that is, the largest
of all the maintenance activities.

 Preventive Maintenance
 Preventive maintenance involves performing activities to prevent the
occurrence of errors. It tends to reduce the software complexity thereby
improving program understandability and increasing software
maintainability. It comprises documentation updating, code optimization, and
code restructuring. Documentation updating involves modifying the
documents affected by the changes in order to correspond to the present state
of the system. Code optimization involves modifying the programs for faster
execution or efficient use of storage space. Code restructuring involves
transforming the program structure for reducing the complexity in source
code and making it easier to understand.
 Preventive maintenance is limited to the maintenance organization only and
no external requests are acquired for this type of maintenance. Preventive
maintenance accounts for only 5% of all the maintenance activities.

Why developers (usually) suck at testing?

1. “Parental feelings” towards their code
Developers are emotionally linked to the stuff they write.  It may sound silly but it is
hard to be objective towards the stuff you create.
For example, I know my kids are not perfect and still I am sure I would have a hard
time if someone would come to me and starts criticizing them in any way (after all

they are perfect, right?   ) .

2. Focus on the “Positive Paths”

Development work is based on taking positive scenarios and enabling them on the
product.  Most of their efforts are concentrated on how to make things work right,
effectively, efficiently, etc.  The mental switch required to move them from a
positive/building mind-set to a negative/what-can-go-wrong mind-set is not trivial and
very hard to achieve in a short time.

3. Work based on the principle of simplifying of complex scenarios

One of the basic things a tester does as part of his work is to look for complex
scenarios (e.g. do multiple actions simultaneously, or make an operation over and
over again, etc.) in order to break the system and find the bugs.  So we basically
take a simple thing and look for ways in which we can complicate it.

On the other hand, our developer counterparts are trained into taking a complex
process or project and breaking it down into the smallest possible components that
will allow them to create a solution (I still remember my shock in college the first time
I understood that all a computer could do was work with AND, OR, NOT, NAND,
NOR, XOR and XNOR operations on Zeros & Ones).

4. Inability to catch small things in big pictures

I can’t really explain the reason behind this one, but I have seen it many times in my
testing lifetime.
One of the side-effects from becoming a good tester is to develop a sense to (almost
unconsciously) detect what “doesn’t fit” in the picture.  The best way to describe it is
by the feeling one gets when something “doesn’t fit” in the picture but we just can’t
put our hand on it; then by applying some systematic processes we are able to find
the specific problem.
 Where’s Waldo??

I had a developer once tell me that good testers can “smell bugs”, and maybe he
was not very far from the truth.

5. Lack of end-to-end & real-user perspective

Do the nature of their tasks most developers concentrate on a single component or
feature in their product, while they still maintain a vague idea of how their users work
with their end-to-end system.
Testers need to have a much broader perspective of our products, we are required
to understand and test them as a whole while using techniques that allow us to
simulate the way users will eventually work in the real world.

6. Less experience with common bugs & application pitfalls

Again something that comes with time and experience is our knowledge of the
common bugs and application pitfalls.  Obviously as a developer accumulates
KLOCs on his keyboard he will also get to meet many bugs and pitfalls, but as a
tester we are going to gain this experience faster and in a deeper sense.

An experienced tester sees a form and automatically starts thinking about the
common bugs and failures he may find in it and starts testing for them.

7. Complexity of modern software systems 

These days programmers simply do not know everything about how the code they
write will be used – and, therefore, have to rely on their assumptions. 
Plus, complexity and a vast number of code modules create new, unintentional
relationships within the code. “Quantitative change leads to qualitative change” – 3rd
concept of Dialectics.
8. Involvement of 3rd party frameworks and libraries
Each code unit is written with certain assumptions. This could be, for example,
relying upon verification of boundary cases made in the calling functions, or exit
codes convention. While using 3rd party code modules, developers are naturally not
completely aware of those assumptions, and thus how “bug shelters” appear.

What is System Testing?

System Testing (ST) is a black box testing technique performed to
evaluate the complete system's compliance against specified
requirements. In System testing, the functionalities of the system are
tested from an end-to-end perspective.

System Testing is usually carried out by a team that is independent of

the development team in order to measure the quality of the system
unbiased.

In this, software is tested such that it works fine for different operating
system. Here we just focus on required input and output without focusing
on internal working.

The software is compiled as product and then it is tested as a whole. This

can be accomplished using one or more of the following tests:

 Functionality testing - Tests all functionalities of the software against the

requirement.

 Performance testing - This test proves how efficient the software is. It
tests the effectiveness and average time taken by the software to do desired
task. Performance testing is done by means of load testing and stress testing
where the software is put under high user and data load under various
environment conditions.

 Security & Portability - These tests are done when the software is meant
to work on various platforms and accessed by number of persons.
Function Point Analysis
 Function Point Analysis: In this method, the number and type of functions
supported by the software are utilized to find FPC(function point count). The steps in
function point analysis are:
 Count the number of functions of each proposed type.
 Compute the Unadjusted Function Points(UFP).
 Find Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).
The explanation of above points given below:
 Count the number of functions of each proposed type: Find the number of
functions belonging to the following types:
 External Inputs: Functions related to data entering the system.
 External outputs:Functions related to data exiting the system.
 External Inquiries: They leads to data retrieval from system but don’t
change the system.
 Internal Files: Logical files maintained within the system. Log files are
not included here.
 External interface Files: These are logical files for other applications
which are used by our system.
 Compute the Unadjusted Function Points(UFP): Categorise each of the
five function types as simple, average or complex based on their complexity.
Multiply count of each function type with its weighting factor and find the
weighted sum. The weighting factors for each type based on their complexity
are as follows:
FUNCTION TYPE SIMPLE AVERAGE COMPLEX

External Inputs 3 4 6

External Output 4 5 7

External Inquiries 3 4 6

Internal Logical Files 7 10 15

External Interface Files 5 7 10

 Find Total Degree of Influence: Use the ’14 general characteristics’ of a
system to find the degree of influence of each of them. The sum of all 14
degrees of influences will give the TDI. The range of TDI is 0 to 70. The 14
general characteristics are: Data Communications, Distributed Data Processing,
Performance, Heavily Used Configuration, Transaction Rate, On-Line Data
Entry, End-user Efficiency, Online Update, Complex Processing Reusability,
Installation Ease, Operational Ease, Multiple Sites and Facilitate Change.
Each of above characteristics is evaluated on a scale of 0-5.
  Compute Value Adjustment Factor(VAF): Use the following formula to
calculate VAF
VAF = (TDI * 0.01) + 0.65
 Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF
Advantages:
 It can be easily used in the early stages of project planning.
 It is independent of the programming language.
 It can be used to compare different projects even if they use different
technologies (database, language etc.).
Disadvantages:
 It is not good for real time systems and embedded systems.
 Many cost estimation models like COCOMO uses LOC and hence FPC must
be converted to LOC.

What is Mutation Testing?

Mutation Testing is a type of software testing where we mutate (change)
certain statements in the source code and check if the test cases are able
to find the errors. It is a type of White Box Testing which is mainly used
for Unit Testing. The changes in mutant program are kept extremely small,
so it does not affect the overall objective of the program.

The goal of Mutation Testing is to assess the quality of the test cases which
should be robust enough to fail mutant code. This method is also called as
Fault-based testing strategy as it involves creating a fault in the program

Mutation was originally proposed in 1971 but lost fervor due to the high
costs involved. Now, again it has picked steam and is widely used for
languages such as Java and XML.

How to execute Mutation Testing?

Following are the steps to execute mutation testing(mutation analysis):

Step 1: Faults are introduced into the source code of the program by
creating many versions called mutants. Each mutant should contain a
single fault, and the goal is to cause the mutant version to fail which
demonstrates the effectiveness of the test cases.

Step 2: Test cases are applied to the original program and also to the
mutant program. A Test Case should be adequate, and it is tweaked to
detect faults in a program.

Step 3: Compare the results of an original and mutant program.

Step 4: If the original program and mutant programs generate the different
output, then that the mutant is killed by the test case. Hence the test case
is good enough to detect the change between the original and the mutant
program.

Step 5: If the original program and mutant program generate the same
output, Mutant is kept alive. In such cases, more effective test cases need
to be created that kill all mutants.
 What to change in a Mutant Program?
There are several techniques that could be used to generate mutant
programs. Let's look at them

Operand replacement Expression Modification Statement modification

operators
Replace the operand with
another operand (x with y or y
with x) or with the constant value.
Example-
If(x>y) replace x and y values
If(5>y) replace x by constant 5
Operators Operators
Replace an operator or Programmatic statements
insertion of new operators in are modified to create
a program statement. mutant programs.
Example-
Example-
If(x==y)
Delete the else part in an if-
We can replace == into >=
else statement
and have mutant program as
Delete the entire if-else
If(x>=y) and inserting ++ in
statement to check how a
the statement
program behaves
If(x==++y)

Types of Mutation Testing

In Software Engineering, Mutation testing could be fundamentally
categorized into 3 types– statement mutation, decision mutation, and value
mutation.

1. Statement Mutation - developer cut and pastes a part of a code of

which the outcome may be a removal of some lines
2. Value Mutation- values of primary parameters are modified
3. Decision Mutation- control statements are to be changed

Mutation Score:
The mutation score is defined as the percentage of killed mutants with the
total number of mutants.
  Mutation Score = (Killed Mutants / Total number of Mutants) * 100

Test cases are mutation adequate if the score is 100%. Experimental

results have shown that mutation testing is an effective approach for
measuring the adequacy of the test cases. But, the main drawback is that
the high cost of generating the mutants and executing each test case
against that mutant program.

Advantages of Mutation Testing:

Following are the advantages of Mutation Testing:

 It is a powerful approach to attain high coverage of the source

program.
 This testing is capable comprehensively testing the mutant program.
 Mutation testing brings a good level of error detection to the software
developer.
 This method uncovers ambiguities in the source code and has the
capacity to detect all the faults in the program.
 Customers are benefited from this testing by getting a most reliable
and stable system.

Disadvantages of Mutation Testing:

On the other side, the following are the disadvantages of Mutant testing:

 Mutation testing is extremely costly and time-consuming since there

are many mutant programs that need to be generated.
 Since its time consuming, it's fair to say that this testing cannot be
done without an automation tool.
 Each mutation will have the same number of test cases than that of
the original program. So, a large number of mutant programs may
need to be tested against the original test suite.
 As this method involves source code changes, it is not at all
applicable for Black Box Testing.