TESTING & MAINTENANCE

Software testing is an important process in the Software Development Lifecycle(SDLC). It

involves verifying and validating that a Software Application is free of bugs, meets the technical
requirements set by its Design and Development, and satisfies user requirements efficiently and
effectively. Software Testing is a process of verifying and validating whether the Software
Product or Application is working as expected. Complete testing includes identifying errors and bugs
that cause future problems for an application's performance.

Software Testing Can be Divided into Two Steps:

Software testing mainly divides into the two parts, which is used in the Software Development
Process:

1. Verification: This step involves checking if the software is doing what is supposed to do. Its like
asking, “Are we building the product the right way?“

2. Validation: This step verifies that the software actually meets the customer’s needs and
requirements. Its like asking, “Are we building the right product?“

The pictorial graph through which every part of software testing is represented.

1. Manual Testing
Manual Testing is a technique to test the software that is carried out using the functions and features
of an application. Which means manual testing will check the defect manually with trying one by one
function is working as expected.
2.Automation Testing
Automation Testing It is a technique where the Tester writes scripts independently and uses suitable
Software or Automation Tools to test the software. It is an Automation Process of a Manual Process.
It allows for executing repetitive tasks without the use of a Manual Tester.
Types of Manual Testing
Manual testing will be divided into further types :-
1. White Box Testing
White Box Testing is a software testing technique that involves testing the internal structure
and workings of a software application. The tester has access to the source code and uses
this knowledge to design test cases that can verify the correctness of the software at the code
level.
2. Black Box Testing
Black-Box Testing is a type of software testing in which the tester is not concerned with the
internal knowledge or implementation details of the software but rather focuses on
validating the functionality based on the provided specifications or requirements.
3. Gray Box Testing
Gray Box Testing is a software testing technique that is a combination of the Black Box
Testing technique and the White Box Testing technique. In the Black Box Testing technique,
the tester is unaware of the internal structure of the item being tested and in White Box Testing
the internal structure is known to the tester.

(Refer the above pictorial figure of types of software testing, accordingly, the following
names are mentioned.)

Types of Black Box Testing

Black Box Testing will be divided into further types which is following:
1. Functional Testing
Functional Testing is a type of Software Testing in which the system is tested against the
functional requirements and specifications. Functional testing ensures that the requirements
or specifications are properly satisfied by the application.
2. Non-Functional Testing
 Non-Functional Testing is a type of Software Testing that is performed to verify the non-
functional requirements of the application. It verifies whether the behavior of the system is as
per the requirement or not. It tests all the aspects that are not tested in functional testing.
Types of Functional Testing
Functional Testing will be divided into further types which is following:
1. Unit Testing
Unit Testing is a method of testing individual units or components of a software application.
It is typically done by developers and is used to ensure that the individual units of the
software are working as intended.
2. Integration Testing
Integration Testing is a method of testing how different units or components of a software
application interact with each other. It is used to identify and resolve any issues that may
arise when different units of the software are combined.
3. 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.
Types of Non-functional Testing
Here are the Types of Non-Functional Testing
1. Performance Testing
Performance Testing is a type of software testing that ensures software applications perform
properly under their expected workload. It is a testing technique carried out to determine
system performance in terms of sensitivity, reactivity, and stability under a particular
workload.
2. Usability Testing
Usability Testing in software testing is a type of testing, that is done from an end user’s
perspective to determine if the system is easily usable. Usability testing is generally the
practice of testing how easy a design is to use on a group of representative users.
3. Compatibility Testing
Compatibility Testing is software testing that comes under the non functional
testing category, and it is performed on an application to check its compatibility (running
capability) on different platforms/environments. This testing is done only when the application
becomes stable.

Different Levels of Software Testing

In Software testing there are Different Levels of Testing can be majorly classified into 4 levels:
1. Unit Testing: In this type of testing, errors are detected individually from every component or
unit by individually testing the components or units of software to ensure that they are fit for
use by the developers. It is the smallest testable part of the software.
2. Integration Testing: In this testing, two or more modules which are unit tested are integrated
to test i.e., technique interacting components, and are then verified if these integrated
modules work as per the expectation or not, and interface errors are also detected.
3. System Testing: In system testing, complete and integrated Software are tested i.e., all the
system elements forming the system are tested as a whole to meet the requirements of the
system.
4. Acceptance Testing: This is a kind of testing conducted to ensure that the requirements of the
users are fulfilled before its delivery and that the software works correctly in the user’s
working environment.
 Regression testing, refactoring, Business Process Reengineering (BPR), and model
reengineering are distinct concepts that play a crucial role in software development and
business operations. Regression testing ensures code changes don't break existing
functionality, while refactoring improves code quality and maintainability without altering its
external behavior. BPR involves redesigning business processes for efficiency, and model
reengineering focuses on improving the structure and implementation of software models,
like machine learning models.
1. Regression Testing:
Definition: A type of software testing that ensures new code changes haven't introduced
defects in previously working parts of the software.
Purpose: To maintain the stability and reliability of the system after changes.
Process: Re-running existing tests after code changes to verify that the system continues to
behave as expected.
2. Refactoring:
Definition: The process of restructuring existing code without changing its external behavior.
Purpose: To improve code quality, readability, and maintainability.
Examples: Renaming variables, simplifying code, and restructuring code blocks.
3. Business Process Reengineering (BPR):
Definition: A radical redesign of business processes to achieve dramatic improvements in
performance, efficiency, and effectiveness.
Purpose: To streamline operations, reduce costs, and improve customer satisfaction.
Process: Involves analyzing current processes, identifying areas for improvement, designing
new processes, and implementing changes.
4. Model Reengineering:
Definition: The process of redesigning or restructuring a software model (e.g., a machine
learning model) to improve its performance, accuracy, or maintainability.
Purpose: To enhance the model's capabilities and ensure its long-term usability.
Examples: Refactoring the model's code, optimizing its architecture, or adjusting its training
process.
Software Project Management (SPM) is a proper way of planning and leading software
projects. It is a part of project management in which software projects are planned,
implemented, monitored, and controlled. This article focuses on discussing Software Project
Management (SPM). The most important is that basic technology changes and advances so
frequently and rapidly that the experience of one product may not be applied to the other
one. Such types of business and environmental constraints increase risk in software
development hence it is essential to manage software projects efficiently. It is necessary for
an organization to deliver quality products, keep the cost within the client’s budget constraint,
and deliver the project as per schedule.
COCOMO (Constructive Cost Model) is a software estimation technique used to predict the
effort, cost, and schedule of software development projects. It comes in two versions,
COCOMO I and COCOMO II, with COCOMO I being suitable for smaller projects and COCOMO
II for larger, more complex projects, including those with significant reuse.
COCOMO I (Basic, Intermediate, and Detailed)
 Basic COCOMO:
Provides a simple estimation based on lines of code (LOC) and project type (organic, semi-
detached, embedded).
 Intermediate COCOMO:
 Refines estimates using cost drivers, which are factors that influence effort, such as product,
computer, personnel, and project characteristics.
 Detailed COCOMO:
Further divides the project into phases and modules to provide more granular estimates,
suitable for larger projects.
COCOMO II (Application Composition, Early Design, Post-Architecture)
 Application Composition: Focuses on estimating effort based on reusable components and
modules.
 Early Design: Estimates effort during the initial phases of the project, considering factors like
project requirements and system design.
 Post-Architecture: Provides estimates for the later phases, including detailed design, coding,
and testing.
Key Differences and Applications
 Scope:
COCOMO I is primarily used for smaller projects under 300 KLOC, while COCOMO II is better
suited for larger, more complex projects, including those involving significant reuse.
 Complexity:
COCOMO II is more comprehensive and detailed than COCOMO I, addressing estimation needs
during different project stages and considering a broader range of cost drivers.
 Project Types:
COCOMO I categorizes projects as organic (simple, well-understood), semi-detached
(moderate complexity), and embedded (highly complex). COCOMO II uses object points,
function points, or lines of code to size projects.
 Estimation Accuracy:
COCOMO II provides more accurate estimates by considering a wider range of factors and
using more detailed models.
COCOMO Model is a procedural cost estimate model for Software Projects and is often used
as a process of reliably predicting the various parameters associated with making a project
such as size, effort, cost, time, and quality.
The key parameters that define the quality of any Software Product, which are also an
outcome of COCOMO, are primarily effort and schedule.
Types of Projects in COCOMO Model
In the COCOMO model, software projects are categorized into three types based on their
complexity, size, and the development environment. These types are:
1. Organic
A software project is said to be an organic type if the team size required is adequately small,
the problem is well understood and has been solved in the past and also the team members
have a nominal experience regarding the problem.
2. Semi-detached
A software project is said to be a Semi-detached type if the vital characteristics such as team
size, experience, and knowledge of the various programming environments lie in between
organic and embedded.
The projects classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience better guidance and
creativity. Eg: Compilers or different Embedded Systems can be considered Semi-Detached
types.
3. Embedded
A software project requiring the highest level of complexity, creativity, and experience
requirement falls under this category. Such software requires a larger team size than the other
 two models and also the developers need to be sufficiently experienced and creative to
develop such complex models.
Importance of the COCOMO Model
1. Cost Estimation: To help with resource planning and project budgeting, COCOMO offers a
methodical approach to software development cost estimation.
2. Resource Management: By taking team experience, project size, and complexity into account,
the model helps with efficient resource allocation.
3. Project Planning: COCOMO assists in developing practical project plans that include attainable
objectives, due dates, and benchmarks.
4. Risk management: Early in the development process, COCOMO assists in identifying and
mitigating potential hazards by including risk elements.
5. Support for Decisions: During project planning, the model provides a quantitative foundation
for choices about scope, priorities, and resource allocation.
Basic COCOMO Model
The Basic COCOMO model is a straightforward way to estimate the effort needed for a software
development project. It uses a simple mathematical formula to predict how many person-months of
work are required based on the size of the project, measured in thousands of lines of code (KLOC).
It estimates effort and time required for development using the following expression:
E = a*(KLOC)b PM
Tdev = c*(E)d
Person required = Effort/ Time
Where,
E is effort applied in Person-Months
KLOC is the estimated size of the software product indicate in Kilo Lines of Code
Tdev is the development time in months

Suppose that a Basic project was estimated to be 400 KLOC (kilo lines of code). Calculate
effort and time for each of the three modes of development. All the constants value
provided in the following table:
Solution: From the above table we take the value of constant a,b,c and d.
1. For organic mode,
 effort = 2.4 × (400)1.05 ≈ 1295 person-month.
 dev. time = 2.5 × (1295)0.38 ≈ 38 months.
2. For semi-detach mode,
 effort = 3 × (400)1.12 ≈ 2462 person-month.
 dev. time = 2.5 × (2462)0.35 ≈ 38 months.
3. For Embedded mode,
 effort = 3.6 × (400)1.20 ≈ 4772 person-month.
 dev. time = 2.5 × (4772)0.32 ≈ 38 months.