Software Testing

Testing is the process of evaluating a system or its component(s) with the intent to find whether
it satisfies the specified requirements or not.

Testing is executing a system in order to identify any gaps, errors, or missing requirements in
contrary to the actual requirements.

What is Testing?
Testing is the process of evaluating a system or its component(s) with the intent to find whether
it satisfies the specified requirements or not. In simple words, testing is executing a system in
order to identify any gaps, errors, or missing requirements in contrary to the actual
requirements.

According to ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing a

software item to detect the differences between existing and required conditions (that is
defects/errors/bugs) and to evaluate the features of the software item.

Who does Testing?

It depends on the process and the associated stakeholders of the project(s). In the IT industry,
large companies have a team with responsibilities to evaluate the developed software in context
of the given requirements. Moreover, developers also conduct testing which is called Unit
Testing. In most cases, the following professionals are involved in testing a system within their
respective capacities −

 Software Tester

 Software Developer

 Project Lead/Manager

 End User

Different companies have different designations for people who test the software on the basis of
their experience and knowledge such as Software Tester, Software Quality Assurance Engineer,
QA Analyst, etc.
It is not possible to test the software at any time during its cycle. The next two sections state
when testing should be started and when to end it during the SDLC.

When to Start Testing?

An early start to testing reduces the cost and time to rework and produce error-free software that
is delivered to the client. However in Software Development Life Cycle (SDLC), testing can be
started from the Requirements Gathering phase and continued till the deployment of the
software.

It also depends on the development model that is being used. For example, in the Waterfall
model, formal testing is conducted in the testing phase; but in the incremental model, testing is
performed at the end of every increment/iteration and the whole application is tested at the end.

Testing is done in different forms at every phase of SDLC −

 During the requirement gathering phase, the analysis and verification of requirements are
also considered as testing.

 Reviewing the design in the design phase with the intent to improve the design is also
considered as testing.

 Testing performed by a developer on completion of the code is also categorized as

testing.

When to Stop Testing?

It is difficult to determine when to stop testing, as testing is a never-ending process and no one
can claim that a software is 100% tested. The following aspects are to be considered for
stopping the testing process −

 Testing Deadlines

 Completion of test case execution

 Completion of functional and code coverage to a certain point

 Bug rate falls below a certain level and no high-priority bugs are identified

 Management decision
Verification & Validation
These two terms are very confusing for most people, who use them interchangeably. The
following table highlights the differences between verification and validation.

Sr.No. Verification Validation

1 Verification addresses the concern: "Are you Validation addresses the concern: "Are
building it right?" you building the right thing?"

2 Ensures that the software system meets all Ensures that the functionalities meet
the functionality. the intended behavior.

3 Verification takes place first and includes Validation occurs after verification and
the checking for documentation, code, etc. mainly involves the checking of the
overall product.

4 Done by developers. Done by testers.

5 It has static activities, as it includes It has dynamic activities, as it includes

collecting reviews, walkthroughs, and executing the software against the
inspections to verify a software. requirements.

6 It is an objective process and no subjective It is a subjective process and involves

decision should be needed to verify a subjective decisions on how well a
software. software works.

Myth 1: Testing is Too Expensive

Reality − There is a saying, pay less for testing during software development or pay more for
maintenance or correction later. Early testing saves both time and cost in many aspects,
however reducing the cost without testing may result in improper design of a software
application rendering the product useless.

Myth 2: Testing is Time-Consuming

Reality − During the SDLC phases, testing is never a time-consuming process. However
diagnosing and fixing the errors identified during proper testing is a time-consuming but
productive activity.

Myth 3: Only Fully Developed Products are Tested

Reality − No doubt, testing depends on the source code but reviewing requirements and
developing test cases is independent from the developed code. However iterative or incremental
approach as a development life cycle model may reduce the dependency of testing on the fully
developed software.

Myth 4: Complete Testing is Possible

Reality − It becomes an issue when a client or tester thinks that complete testing is possible. It
is possible that all paths have been tested by the team but occurrence of complete testing is
never possible. There might be some scenarios that are never executed by the test team or the
client during the software development life cycle and may be executed once the project has
been deployed.

Myth 5: A Tested Software is Bug-Free

Reality − This is a very common myth that the clients, project managers, and the management
team believes in. No one can claim with absolute certainty that a software application is 100%
bug-free even if a tester with superb testing skills has tested the application.

Myth 6: Missed Defects are due to Testers

Reality − It is not a correct approach to blame testers for bugs that remain in the application
even after testing has been performed. This myth relates to Time, Cost, and Requirements
changing Constraints. However the test strategy may also result in bugs being missed by the
testing team.

Myth 7: Testers are Responsible for Quality of Product

Reality − It is a very common misinterpretation that only testers or the testing team should be
responsible for product quality. Testers’ responsibilities include the identification of bugs to the
stakeholders and then it is their decision whether they will fix the bug or release the software.
Releasing the software at the time puts more pressure on the testers, as they will be blamed for
any error.

Myth 8: Test Automation should be used wherever possible to Reduce Time

Reality − Yes, it is true that Test Automation reduces the testing time, but it is not possible to
start test automation at any time during software development. Test automaton should be started
when the software has been manually tested and is stable to some extent. Moreover, test
automation can never be used if requirements keep changing.

Myth 9: Anyone can Test a Software Application

Reality − People outside the IT industry think and even believe that anyone can test a software
and testing is not a creative job. However testers know very well that this is a myth. Thinking
alternative scenarios, try to crash a software with the intent to explore potential bugs is not
possible for the person who developed it.

Myth 10: A Tester's only Task is to Find Bugs

Reality − Finding bugs in a software is the task of the testers, but at the same time, they are
domain experts of the particular software. Developers are only responsible for the specific
component or area that is assigned to them but testers understand the overall workings of the
software, what the dependencies are, and the impacts of one module on another module.

Testing, Quality Assurance,and Quality Control

Most people get confused when it comes to pin down the differences among Quality Assurance,
Quality Control, and Testing. Although they are interrelated and to some extent, they can be
considered as same activities, but there exist distinguishing points that set them apart. The
following table lists the points that differentiate QA, QC, and Testing.

Quality Assurance Quality Control Testing

QA includes activities that ensure It includes activities that It includes activities that
the implementation of processes, ensure the verification of a ensure the identification
procedures and standards in developed software with of bugs/error/defects in a
context to verification of respect to documented (or not software.
developed software and intended in some cases) requirements.
requirements.

Focuses on processes and Focuses on actual testing by Focuses on actual testing.

procedures rather than conducting executing the software with an
actual testing on the system. aim to identify bug/defect
through implementation of
procedures and process.

Process-oriented activities. Product-oriented activities. Product-oriented

activities.

Preventive activities. It is a corrective process. It is a preventive process.

It is a subset of Software Test Life QC can be considered as the Testing is the subset of
Cycle (STLC). subset of Quality Assurance. Quality Control.

Audit and Inspection

Audit − It is a systematic process to determine how the actual testing process is conducted
within an organization or a team. Generally, it is an independent examination of processes
involved during the testing of a software. As per IEEE, it is a review of documented processes
that organizations implement and follow. Types of audit include Legal Compliance Audit,
Internal Audit, and System Audit.

Inspection − It is a formal technique that involves formal or informal technical reviews of any
artifact by identifying any error or gap. As per IEEE94, inspection is a formal evaluation
technique in which software requirements, designs, or codes are examined in detail by a person
or a group other than the author to detect faults, violations of development standards, and other
problems.

Formal inspection meetings may include the following processes: Planning, Overview
Preparation, Inspection Meeting, Rework, and Follow-up.

Testing and Debugging

Testing − It involves identifying bug/error/defect in a software without correcting it. Normally
professionals with a quality assurance background are involved in bugs identification. Testing is
performed in the testing phase.

Debugging − It involves identifying, isolating, and fixing the problems/bugs. Developers who
code the software conduct debugging upon encountering an error in the code. Debugging is a
part of White Box Testing or Unit Testing. Debugging can be performed in the development
phase while conducting Unit Testing or in phases while fixing the reported bugs.

Software Testing Hierarchy

As with almost any technical process, software testing has a prescribed order in which things
should be done. The following is a list of software testing categories arranged in chronological
order. These are the steps taken to fully test new software in preparation for marketing it:

 Unit testing - testing performed on each module or block of code during

development. Unit Testing is normally done by the programmer who writes the code.
 Integration testing - testing done before, during and after integration of a new module
into the main software package. This involves testing of each individual code module.
One piece of software can contain several modules which are often created by several
different programmers. It is crucial to test each module's effect on the entire program
model.
 System testing - testing done by a professional testing agent on the completed software
product before it is introduced to the market.
 Acceptance testing - beta testing of the product done by the actual end users.
Different Types of System Testing

There are more than 50 types of System Testing. For an exhaustive list of software testing types
click here. Below we have listed types of system testing a large software development company
would typically use

1. Usability Testing - Usability Testing mainly focuses on the user's ease to use the
application, flexibility in handling controls and ability of the system to meet its objectives
2. Load Testing - Load Testing is necessary to know that a software solution will perform
under real-life loads.
3. Regression Testing- - Regression Testing involves testing done to make sure none of the
changes made over the course of the development process have caused new bugs. It also
makes sure no old bugs appear from the addition of new software modules over time.
4. Recovery Testing - Recovery testing is done to demonstrate a software solution is
reliable, trustworthy and can successfully recoup from possible crashes.
5. Migration Testing - Migration testing is done to ensure that the software can be moved
from older system infrastructures to current system infrastructures without any issues.
6. Functional Testing - Also known as functional completeness testing, Functional
Testinginvolves trying to think of any possible missing functions. Testers might make a
list of additional functionalities that a product could have to improve it during functional
testing.
7. Hardware/Software Testing - IBM refers to Hardware/Software testing as "HW/SW
Testing". This is when the tester focuses his/her attention on the interactions between the
hardware and software during system testing.

Mutation testing

Structural testing is the type of testing carried out to test the structure of code. It is also known

as White Box testing or Glass Box testing. This type of testing requires knowledge of the code,

so, it is mostly done by the developers. It is more concerned with how system does it rather than

the functionality of the system. It provides more coverage to the testing. For ex, to test certain

error message in an application, we need to test the trigger condition for it, but there must be
many trigger for it. It is possible to miss out one while testing the requirements drafted in SRS.

But using this testing, the trigger is most likely to be covered since structural testing aims to

cover all the nodes and paths in the structure of code.

What is Special Value Testing?

Identical to any other software testing techniques, Special Value is defined and applied form

of Functional Testing, which is a type of testing that verifies whether each function of the

software application operates in conformance with the required specification. Each and every

functionality of the system is tested by providing appropriate input, verifying the output and

comparing the actual results with the expected results.

Special Value Testing, is probably the most extensively practiced form of functional testing

which is most intuitive, and least uniform. This technique is performed by experienced

professionals who are experts in this field and have profound knowledge about the test and the

data required for it. They continuously participate and apply tremendous efforts to deliver

appropriate test results to suit the client’s requested demands.

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 fault in the program

What Types of System Testing Should Testers Use?

There are over 50 different types of system testing. The specific types used by a tester depend on
several variables. Those variables include:

Who the tester works for - This is a major factor in determining the types of system testing a
tester will use. Methods used by large companies are different than that used by medium and
small companies.

 Time available for testing - Ultimately, all 50 testing types could be used. Time is often
what limits us to using only the types that are most relevant for the software project.
 Resources available to the tester - Of course some testers will not have necessary
resources to conduct a testing type. For example if you are a tester working for a large
software development firm, you are likely to have expensive automated testing software
not available to others.
 Software Tester's Education - There is a certain learning curve for each type of
software testing available. To use some of the software involved, a tester has to learn how
to use it.
 Testing Budget - Money becomes a factor not just for smaller companies and individual
software developers but large companies as well.

Differences Between Black Box Testing and White Box Testing

The Differences Between Black Box Testing and White Box Testing are listed below.

Criteria Black Box Testing White Box Testing

White Box Testing is a software

Black Box Testing is a software testing
testing method in which the internal
method in which the internal structure/
Definition structure/ design/ implementation of
design/ implementation of the item being
the item being tested is known to the
tested is NOT known to the tester
tester.

Levels Mainly applicable to higher levels of Mainly applicable to lower levels of

Applicable To testing:Acceptance Testing testing:Unit Testing
 System Testing Integration Testing

Responsibility Generally, independent Software Testers Generally, Software Developers

Programming
Not Required Required
Knowledge

Implementation
Not Required Required
Knowledge

Basis for Test

Requirement Specifications Detail Design
Cases

Testing Limitations

You cannot test a program completely

We can only test against system requirements

– May not detect errors in the requirements.

– Incomplete or ambiguous requirements may lead to inadequate or incorrect testing.

Exhaustive (total) testing is impossible in present scenario.

Time and budget constraints normally require very careful planning of the testing effort.

Compromise between thoroughness and budget

Test results are used to make business decisions for release dates.

Even if you do find the last bug, you’ll never know it

You will run out of time before you run out of test cases

You cannot test every path

You cannot test every valid input

 You cannot test every invalid input

What is Software Quality Management?

Software Quality Management ensures that the required level of quality is achieved by
submitting improvements to the product development process. SQA aims to develop a culture
within the team and it is seen as everyone's responsibility.

Software Quality management should be independent of project management to ensure

independence of cost and schedule adherences. It directly affects the process quality and
indirectly affects the product quality.

Activities of Software Quality Management:

 Quality Assurance - QA aims at developing Organizational procedures and standards
for quality at Organizational level.

 Quality Planning - Select applicable procedures and standards for a particular project
and modify as required to develop a quality plan.

 Quality Control - Ensure that best practices and standards are followed by the software
development team to produce quality products.

Software reliability Reliability of a software product essentially denotes its trustworthiness or

dependability. Alternatively, reliability of a software product can also be defined as the
probability of the product working “correctly” over a given period of time. It is obvious that a
software product having a large number of defects is unreliable. It is also clear that the reliability
of a system improves, if the number of defects in it is reduced. However, there is no simple
relationship between the observed system reliability and the number of latent defects in the
system. For example, removing errors from parts of a software which are rarely executed makes
little difference to the perceived reliability of the product. It has been experimentally observed by
analyzing the behavior of a large number of programs that 90% of the execution time of a typical
program is spent in executing only 10% of the instructions in the program. These most used 10%
instructions are often called the core of the program. The rest 90% of the program statements are
called non-core and are executed only for 10% of the total execution time. It therefore may not
be very surprising to note that removing 60% product defects from the least used parts of a
system would typically lead to only 3% improvement to the product reliability. It is clear that the
quantity by which the overall reliability of a program improves due to the correction of a single
error depends on how frequently is the corresponding instruction executed. Thus, reliability of a
product depends not only on the number of latent errors but also on the exact location of the
errors. Apart from this, reliability also depends upon how the product is used, i.e. on its
execution profile. If it is selected input data to the system such that only the “correctly”
implemented functions are executed, none of the errors will be exposed and the perceived
reliability of the product will be high. On the other hand, if the input data is selected such that
only those functions which contain errors are invoked, the perceived reliability of the system will
be very low.

Reasons for software reliability being difficult to measure The reasons why software reliability
is difficult to measure can be summarized as follows:

• The reliability improvement due to fixing a single bug depends on where the bug is located in
the code.

• The perceived reliability of a software product is highly observer dependent.

• The reliability of a product keeps changing as errors are detected and fixed.

What is Software Technical review?

A Technical review is a static white-box testing technique which is conducted to spot the
defects early in the life cycle that cannot be detected by black box testing techniques.

Technical Review - Static Testing:

Technical Review Characteristics:
 Technical Reviews are documented and uses a defect detection process that has peers
and technical specialist as part of the review process.

 The Review process doesn't involve management participation.

 It is usually led by trained moderator who is NOT the author.

 The report is prepared with the list of issues that needs to be addressed.

Test Approach:
A test approach is the test strategy implementation of a project, defines how testing would be
carried out. Test approach has two techniques:

 Proactive - An approach in which the test design process is initiated as early as possible
in order to find and fix the defects before the build is created.

 Reactive - An approach in which the testing is not started until after design and coding
are completed.

Formal Technical Review: Reviews that include walkthroughs, inspection, ....

Formal Technical Review
Reviews that include walkthroughs, inspection, round-robin reviews and other small group
technical assessment of software. It is a planned and control meeting attended by the analyst,
programmers and people involve in the software development.

 Uncover errors in logic, function or implementation for any representation of software

 To verify that the software under review meets the requirements

 To ensure that the software has been represented according to predefined standards

 To achieve software that is developed in a uniform manner.

 To make project more manageable.

 Early discovery of software defects, so that in the development and maintenance phase
the errors are substantially reduced. " Serves as a training ground, enabling junior
members to observe the different approaches in the software development phases (gives
them helicopter view of what other are doing when developing the software).

 Allows for continuity and backup of the project. This is because a number of people are
become familiar with parts of the software that they might not have otherwise seen,

 Greater cohesion between different developers.

Software Quality Assurance (SQA) is a set of activities for ensuring quality in software
engineering processes. It ensures that developed software meets and complies with the defined
or standardized quality specifications. SQA is an ongoing process within the Software
Development Life Cycle (SDLC) that routinely checks the developed software to ensure it
meets the desired quality measures.

SQA practices are implemented in most types of software development, regardless of the
underlying software development model being used. SQA incorporates and implements
software testing methodologies to test the software. Rather than checking for quality after
completion, SQA processes test for quality in each phase of development, until the software is
complete. With SQA, the software development process moves into the next phase only once
the current/previous phase complies with the required quality standards. SQA generally works
on one or more industry standards that help in building software quality guidelines and
implementation strategies.
It includes the following activities −

 Process definition and implementation

 Auditing

 Training

Processes could be −

 Software Development Methodology

 Project Management

 Configuration Management

 Requirements Development/Management

 Estimation

 Software Design

 Testing, etc.

Once the processes have been defined and implemented, Quality Assurance has the
following responsibilities −

 Identify the weaknesses in the processes

 Correct those weaknesses to continually improve the process

Components of SQA System

An SQA system always combines a wide range of SQA components. These components can be
classified into the following six classes −

Pre-project components
This assures that the project commitments have been clearly defined considering the resources
required, the schedule and budget; and the development and quality plans have been correctly
determined.

Components of project life cycle activities assessment

The project life cycle is composed of two stages: the development life cycle stage and the
operation–maintenance stage.
The development life cycle stage components detect design and programming errors. Its
components are divided into the following sub-classes: Reviews, Expert opinions, and Software
testing.

The SQA components used during the operation–maintenance phase include specialized
maintenance components as well as development life cycle components, which are applied
mainly for functionality to improve the maintenance tasks.

Components of infrastructure error prevention and improvement

The main objective of these components, which is applied throughout the entire organization, is
to eliminate or at least reduce the rate of errors, based on the organization’s accumulated SQA
experience.

Components of software quality management

This class of components deal with several goals, such as the control of development and
maintenance activities, and the introduction of early managerial support actions that mainly
prevent or minimize schedule and budget failures and their outcomes.

Components of standardization, certification, and SQA system assessment

These components implement international professional and managerial standards within the
organization. The main objectives of this class are utilization of international professional
knowledge, improvement of coordination of the organizational quality systems with other
organizations, and assessment of the achievements of quality systems according to a common
scale. The various standards may be classified into two main groups: quality management
standards and project process standards.

Organizing for SQA – the human components

The SQA organizational base includes managers, testing personnel, the SQA unit and the
persons interested in software quality such as SQA trustees, SQA committee members, and
SQA forum members. Their main objectives are to initiate and support the implementation of
SQA components, detect deviations from SQA procedures and methodology, and suggest
improvements.

Pre-project Software Quality Components

These components help to improve the preliminary steps taken before starting a project. It
includes −

 Contract Review

 Development and Quality Plans

Contract Review
Normally, a software is developed for a contract negotiated with a customer or for an internal
order to develop a firmware to be embedded within a hardware product. In all these cases, the
development unit is committed to an agreed-upon functional specification, budget and schedule.
Hence, contract review activities must include a detailed examination of the project proposal
draft and the contract drafts.

Specifically, contract review activities include −

 Clarification of the customer’s requirements

 Review of the project’s schedule and resource requirement estimates

 Evaluation of the professional staff’s capacity to carry out the proposed project

 Evaluation of the customer’s capacity to fulfil his obligations

 Evaluation of development risks

Development and Quality Plans

After signing the software development contract with an organization or an internal department
of the same organization, a development plan of the project and its integrated quality assurance
activities are prepared. These plans include additional details and needed revisions based on
prior plans that provided the basis for the current proposal and contract.

Most of the time, it takes several months between the tender submission and the signing of the
contract. During these period, resources such as staff availability, professional capabilities may
get changed. The plans are then revised to reflect the changes that occurred in the interim.

The main issues treated in the project development plan are −

 Schedules
  Required manpower and hardware resources

 Risk evaluations

 Organizational issues: team members, subcontractors and partnerships

 Project methodology, development tools, etc.

 Software reuse plans

The main issues treated in the project’s quality plan are −

 Quality goals, expressed in the appropriate measurable terms

 Criteria for starting and ending each project stage

 Lists of reviews, tests, and other scheduled verification and validation activities

What is Capability Maturity Model?

The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an
increasing series of levels of a software development organization. The higher the level, the
better the software development process, hence reaching each level is an expensive and time-
consuming process.
Levels of CMM
 Level One :Initial - The software process is characterized as inconsistent, and
occasionally even chaotic. Defined processes and standard practices that exist are
abandoned during a crisis. Success of the organization majorly depends on an individual
effort, talent, and heroics. The heroes eventually move on to other organizations taking
their wealth of knowledge or lessons learnt with them.

 Level Two: Repeatable - This level of Software Development Organization has a basic
and consistent project management processes to track cost, schedule, and functionality.
The process is in place to repeat the earlier successes on projects with similar
applications. Program management is a key characteristic of a level two organization.

 Level Three: Defined - The software process for both management and engineering
activities are documented, standardized, and integrated into a standard software process
 for the entire organization and all projects across the organization use an approved,
tailored version of the organization's standard software process for developing,testing
and maintaining the application.

 Level Four: Managed - Management can effectively control the software development
effort using precise measurements. At this level, organization set a quantitative quality
goal for both software process and software maintenance. At this maturity level, the
performance of processes is controlled using statistical and other quantitative
techniques, and is quantitatively predictable.

 Level Five: Optimizing - The Key characteristic of this level is focusing on continually
improving process performance through both incremental and innovative technological
improvements. At this level, changes to the process are to improve the process
performance and at the same time maintaining statistical probability to achieve the
established quantitative process-improvement objectives.

Difference

ISO 900(INTERNATIONAL STANDARD CMM (CABABILITY MATURITY MODEL)

ORGANISATION)

It applies to any type of industry . CMM is specially developed for software industry

ISO 9000 addresses corporate business process CMM focuses on the software Engineering
activities.

ISO 9000 specifies minimum requirement. CMM gets nto technical aspect of software
engineering.

ISO 9000 restricts itself to what is required. It suggests how to fulfill the requirements.

ISO 9000 provides pass or fail criteria. It provides grade for process maturity.

ISO 9000 has no levels. CMM has 5 levels:

Initial
Repeatable
Defined
Managed
Optimization

ISO 9000 does not specifies sequence of steps It reconnects the mechanism for step by step
required to establish the quality system. progress through its successive maturity levels.

Certain process elements that are in ISO are not
included in CMM like:
1. Contract management
2. Purchase and customer supplied components
3. Personal issue management
4. Packaging ,delivery, and installation
management
Similarly other process in CMM are not included in
ISO 9000
1. Project tracking
2. Process and technology change management
3. Intergroup coordinating to meet customer’s
requirements
4. Organization level process focus, process
development and integrated management.

Software maintenance

Software maintenance is widely accepted part of SDLC now a days. It stands for all the
modifications and updations done after the delivery of software product. 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.

Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be just a
routine maintenance tasks as some bug discovered by some user or it may be a large event in
itself based on maintenance size or nature. Following are some types of maintenance based on
their characteristics:
  Corrective Maintenance - This includes modifications and updations done in order to
correct or fix problems, which are either discovered by user or concluded by user error
reports.

 Adaptive Maintenance - This includes modifications and updations applied to keep the
software product up-to date and tuned to the ever changing world of technology and
business environment.

 Perfective Maintenance - This includes modifications and updates done in order to keep
the software usable over long period of time. It includes new features, new user
requirements for refining the software and improve its reliability and performance.

 Preventive Maintenance - This includes modifications and updations to prevent future

problems of the software. It aims to attend problems, which are not significant at this
moment but may cause serious issues in future.

Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software
maintenance found that the cost of maintenance is as high as 67% of the cost of entire software
process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC phases. There
are various factors, which trigger maintenance cost go high, such as:

Real-world factors affecting Maintenance Cost

 The standard age of any software is considered up to 10 to 15 years.

 Older softwares, which were meant to work on slow machines with less memory and
storage capacity cannot keep themselves challenging against newly coming enhanced
softwares on modern hardware.

 As technology advances, it becomes costly to maintain old software.

 Most maintenance engineers are newbie and use trial and error method to rectify
problem.

 Often, changes made can easily hurt the original structure of the software, making it hard
for any subsequent changes.

 Changes are often left undocumented which may cause more conflicts in future.

Software-end factors affecting Maintenance Cost

 Structure of Software Program

 Programming Language

 Dependence on external environment

 Staff reliability and availability

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 analyzed 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 analyzed 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.Every programmer is expected to do unit testing in parallel.
  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.

Software Re-engineering
When we need to update the software to keep it to the current market, without impacting its
functionality, it is called software re-engineering. It is a thorough process where the design of
software is changed and programs are re-written.

Legacy software cannot keep tuning with the latest technology available in the market. As the
hardware become obsolete, updating of software becomes a headache. Even if software grows
old with time, its functionality does not.

For example, initially Unix was developed in assembly language. When language C came into
existence, Unix was re-engineered in C, because working in assembly language was difficult.

Other than this, sometimes programmers notice that few parts of software need more
maintenance than others and they also need re-engineering.
Re-Engineering Process

 Decide what to re-engineer. Is it whole software or a part of it?

 Perform Reverse Engineering, in order to obtain specifications of existing software.

 Restructure Program if required. For example, changing function-oriented programs

into object-oriented programs.

 Re-structure data as required.

 Apply Forward engineering concepts in order to get re-engineered software.

There are few important terms used in Software re-engineering

Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing, understanding the
existing system. This process can be seen as reverse SDLC model, i.e. we try to get higher
abstraction level by analyzing lower abstraction levels.

An existing system is previously implemented design, about which we know nothing. Designers
then do reverse engineering by looking at the code and try to get the design. With design in
hand, they try to conclude the specifications. Thus, going in reverse from code to system
specification.
Program Restructuring
It is a process to re-structure and re-construct the existing software. It is all about re-arranging
the source code, either in same programming language or from one programming language to a
different one. Restructuring can have either source code-restructuring and data-restructuring or
both.

Re-structuring does not impact the functionality of the software but enhance reliability and
maintainability. Program components, which cause errors very frequently can be changed, or
updated with re-structuring.

The dependability of software on obsolete hardware platform can be removed via re-structuring.

Forward Engineering
Forward engineering is a process of obtaining desired software from the specifications in hand
which were brought down by means of reverse engineering. It assumes that there was some
software engineering already done in the past.

Forward engineering is same as software engineering process with only one difference – it is
carried out always after reverse engineering.

Component reusability
A component is a part of software program code, which executes an independent task in the
system. It can be a small module or sub-system itself.
Example
The login procedures used on the web can be considered as components, printing system in
software can be seen as a component of the software.

Components have high cohesion of functionality and lower rate of coupling, i.e. they work
independently and can perform tasks without depending on other modules.

In OOP, the objects are designed are very specific to their concern and have fewer chances to be
used in some other software.

In modular programming, the modules are coded to perform specific tasks which can be used
across number of other software programs.

There is a whole new vertical, which is based on re-use of software component, and is known as
Component Based Software Engineering (CBSE).

Re-use can be done at various levels

 Application level - Where an entire application is used as sub-system of new software.

 Component level - Where sub-system of an application is used.

 Modules level - Where functional modules are re-used.

Software components provide interfaces, which can be used to establish communication

among different components.

Reuse Process
Two kinds of method can be adopted: either by keeping requirements same and adjusting
components or by keeping components same and modifying requirements.
  Requirement Specification - The functional and non-functional requirements are
specified, which a software product must comply to, with the help of existing system,
user input or both.

 Design - This is also a standard SDLC process step, where requirements are defined in
terms of software parlance. Basic architecture of system as a whole and its sub-systems
are created.

 Specify Components - By studying the software design, the designers segregate the
entire system into smaller components or sub-systems. One complete software design
turns into a collection of a huge set of components working together.

 Search Suitable Components - The software component repository is referred by

designers to search for the matching component, on the basis of functionality and
intended software requirements..

 Incorporate Components - All matched components are packed together to shape them
as complete software.

Software Maintenance Models

To overcome internal as well as external problems of the software, Software maintenance models
are proposed. These models use different approaches and techniques to simplify the process of
maintenance as well as to make is cost effective. Software maintenance models that are of most
importance are:

Quick-Fix Model:

This is an ad hoc approach used for maintaining the software system. The objective of this model
is to identify the problem and then fix it as quickly as possible. The advantage is that it performs
its work quickly and at a low cost. This model is an approach to modify the software code with
little consideration for its impact on the overall structure of the software system.

Iterative Enhancement Model:

Iterative enhancement model considers the changes made to the system are iterative in nature.
This model incorporates changes in the software based on the analysis of the existing system. It
assumes complete documentation of the software is available in the beginning. Moreover, it
attempts to control complexity and tries to maintain good design.

Iterative Enhancement Model is divided into three stages:

1. Analysis of software system.

2. Classification of requested modifications.

3. Implementation of requested modifications.

The Re-use Oriented Model:

The parts of the old/existing system that are appropriate for reuse are identified and understood,
in Reuse Oriented Model. These parts are then go through modification and enhancement, which
are done on the basis of the specified new requirements. The final step of this model is the
integration of modified parts into the new system.