Software Quality CONCEPTS

What is Software Quality?

Software Quality shows how good and reliable a product is. To convey an associate degree
example, think about functionally correct software. It performs all functions as laid out in
the SRS document. But, it has an associate degree virtually unusable program. even though
it should be functionally correct, we tend not to think about it to be a high-quality product.
Another example is also that of a product that will have everything that the users need but
has an associate degree virtually incomprehensible and not maintainable code. Therefore,
the normal construct of quality as “fitness of purpose” for code merchandise isn’t
satisfactory.
Factors of Software Quality
The modern read of high-quality associates with software many quality factors like the
following:

1. Portability: A software is claimed to be transportable, if it may be simply created

to figure in several package environments, in several machines, with alternative code
merchandise, etc.
2. Usability: A software has smart usability if completely different classes of users
(i.e. knowledgeable and novice users) will simply invoke the functions of the
merchandise.
3. Reusability: A software has smart reusability if completely different modules of
the merchandise will simply be reused to develop new merchandise.
4. Correctness: Software is correct if completely different needs as laid out in the
SRS document are properly enforced.
5. Maintainability: A software is reparable, if errors may be simply corrected as and
once they show up, new functions may be simply added to the merchandise, and
therefore the functionalities of the merchandise may be simply changed, etc
6. Reliability: Software is more reliable if it has fewer failures. Since software
engineers do not deliberately plan for their software to fail, reliability depends on the
number and type of mistakes they make. Designers can improve reliability by ensuring
the software is easy to implement and change, by testing it thoroughly, and also by
ensuring that if failures occur, the system can handle them or can recover easily.
7. Efficiency. The more efficient software is, the less it uses of CPU-time, memory,
disk space, network bandwidth, and other resources. This is important to customers in
order to reduce their costs of running the software, although with today’s powerful
 computers, CPU time, memory and disk usage are less of a concern than in years gone
by.

Software Quality Management System

Software Quality Management System contains the methods that are used by the authorities
to develop products having the desired quality.
Some of the methods are:
 Managerial Structure: Quality System is responsible for managing the structure as
a whole. Every Organization has a managerial structure.
 Individual Responsibilities: Each individual present in the organization must have
some responsibilities that should be reviewed by the top management and each
individual present in the system must take this seriously.
 Quality System Activities: The activities which each quality system must have
been
o Project Auditing.
o Review of the quality system.
o It helps in the development of methods and guidelines.
Evolution of Quality Management System
Quality Systems are basically evolved over the past some years. The evolution of a Quality
Management System is a four-step process.
1. Inception: Product inspection task provided an instrument for quality control (QC).
2. Quality Control: The main task of quality control is to detect defective devices,
and it also helps in finding the cause that leads to the defect. It also helps in the
correction of bugs.
3. Quality Assurance: Quality Assurance helps an organization in making good
quality products. It also helps in improving the quality of the product by passing the
products through security checks.
4. Total Quality Management (TQM): Total Quality Management(TQM) checks
and assures that all the procedures must be continuously improved regularly through
process measurements.

Cost of Quality in Software Testing

There is cost of activity in every project, it should have business value and software
testing is no exception. To optimize its business value, test managers should optimize
testing appropriately. There should not be unnecessary testing otherwise it causes
unnecessary delays and ends up incurring more costs. Also, there should not be incomplete
or too less testing otherwise, there may be a chance of defective products to be handed to
the end users. Therefore, software testing should be done appropriately.
Cost of Quality :
It is the most established, effective measure of quantifying and calculating the business
value of testing. There are four categories to measure cost of quality: Prevention costs,
Detection costs, Internal failure costs, and External failure costs.
These are explained as follows below.
1. Prevention costs include cost of training developers on writing secure and easily
maintainable code
2. Detection costs include the cost of creating test cases, setting up testing
environments, revisiting testing requirements.
3. Internal failure costs include costs incurred in fixing defects just before delivery.
4. External failure costs include product support costs incurred by delivering poor
quality software.
Major parts of total cost are detecting defects and internal failure cost. But, these costs less
than external failure costs. That’s why testing provides good business value.
Business value of software testing :
Test manager has responsibility to identify the business value and provide communications
between teams and senior management. It concerns the cost of quality.
To deliver business value, these are some of the measurable ways, like
1. Detecting defects
2. Documenting defects
3. Status reports and test metrics on project progress
4. Status reports on process implementation and product development
5. Increasing confidence in product quality
6. Legal liabilities
7. Decreasing risks
8. Ensuring predictable product
9. Enhancing reputation for product
10. Enhancing reputation for process quality
11. Testing can prevent mission failure

Roles and Responsibilities of SQA Group:

Software quality is always a challenge, and it becomes difficult when the QA roles and

responsibilities are not satisfied. You should understand the role QA plays throughout the

development lifecycle whether you manage software development or run a software business.

Quality assurance is the process of evaluating a system by applying proper testing procedures

to provide confidence to achieve an appropriate level of quality. Quality Assurance helps the

software development team to recognize the problems early by performing rigorous testing, to

guarantee a high-quality product to the end user.

So Who performs this role?? With no startle “Quality Analyst ” is the one…

The software quality analyst is an individual who is responsible for applying the principles

and best practices of software quality assurance throughout the software development life

cycle.

QA is an essential part of the Software development process, as they test and assess the

quality of the software to reduce the risk of software failure in operation.

As John Ruskin says, “Quality is never an accident; it is always the

result of intelligent effort”

What are QA roles?

Quality assurance (QA) roles are responsible for creating and performing tests, identifying

errors, and providing feedback to verify that a final product meets a company’s quality

requirements. This profession has become more common in the technology sector depending

on the kind of work a company does, it frequently calls for various levels of extensive

experience or specialization. Video games, websites, and applications are examples of

common development projects that call for QA roles.

Because they ensure users enjoy a seamless, error-free experience while using a product, QA

jobs are crucial. A company that hires these people can consistently create high-quality

products. It helps to maintain the brand reputation and customer satisfaction.

The QA analyzes and executes the products in all possible logical ways for a quality product,

As the Software testers do not make software; they make them better. So a QA

performs software testing where they evaluate the functionality of a software application to

find whether the developed software is error-free.

But testing is not the only part of QA, it analyses whether the software follows all business

requirements, and functionality offering an easy and secure user interface that facilitates

effortless workflows for the end-users.

The Role of Quality Assurance (QA) in Deployment

During a deployment, QA typically needs to be on call. These occur frequently late at night

(most probably) when users are less likely to be affected. QA is on standby during a

deployment. As soon as the release goes live, QA gets to work, undergoing smoke testing to

ensure that the deployment went smoothly.

The Role of Quality Assurance (QA ) in Maintenance

Bugs do occasionally slip through, even the best automation or manual testing cannot find all

the bugs on browser plugins all of the time. QA can be on hand to test the feature updates or

bug fixes.

Different Roles and Responsibility In The Quality Assurance Team

The following is a list of important QA positions to hire if you want to develop a functional

software testing team, along with the various responsibilities and abilities each role typically

handles:

QA Engineer

Quality assurance engineers examine programs to identify bugs and defects, especially when

they appear unexpectedly. To evaluate the effectiveness of various product functionalities and

aspects, they frequently use a variety of tests. Senior QA engineers perform some tests

through automation testing whereas others are through manual testing.

Test Analyst

Test analysts support the test engineer by developing test plans and reviewing the most

crucial features and functionalities to test. Usually, they document the testing process. To

support the entire QA team, they record the goals, progress, and outcomes of tests.

QA Lead
The QA lead is a team leader who is in charge of overseeing the testing process. They plan to

make sure testing is efficient and completed on schedule. Additionally, QA team leads may

define the single project specifications, supervise engineers and quality assurance analysts,

and takes part in the recruitment and training of QA professionals.

QA Manager

QA test managers manage the communication between the customers and the QA team. In

addition to working with the customer to produce standards and specifications, they would

deliver reports and updates. They might also collaborate with analysts or account managers to

evaluate product quality and ensure it lives up to customer expectations.

Test Architect

The tests used by the QA team are designed and built by test architects. Typically, their goals

are to create tests that the team may reuse on future projects and to create automation

frameworks that define the best quality assurance process for automated tests. Test architects

can also need analysis to ensure that the tests they create address organizational priorities and

concerns.

Roles And Responsibilities Of QA :

The role of quality assurance (QA) in testing may appear obvious. But during the testing

phase, QA performs more than just testing. A tester’s time is mostly spent on specific tasks,

such as writing test cases and bug reports. Of course, QA will (or should) test the app or

website thoroughly. But other activities consist of:

• Test planning – Which involves activities of defining the objectives of testing and the

approach for meeting test objectives.

• Test Strategy – Create a test strategy based on project requirements and schedules.

• Early testing to eliminate defects at an early stage reduces the bug fixing cost and time.

• Executing tests with appropriate techniques (manually or by using test execution tools) and

documenting testing failures.

• Analyze the Defects and identify the root cause.

• Troubleshoot defects, such that it does not affect the product quality.
• Report defects to software developers by recording software defects with a bug-tracking

system. (e.g Bugzilla, mantis, QA Touch, etc.)

• Inform the test progress against a schedule of the quality management.

• Interact with BA, project manager, development team, and client as per need.

• Conduct different test procedures, report issues, and follow up on the status of the issues.

• Collaborate with the software testing team to assess or diagnose problems and suggest

possible solutions.

• Monitor and analyze the performance using tools for efficient and problem-free operations.

• Uncover vulnerabilities in the system and determine that its data and resources are protected

from intruders.

• Provides a test summary report that reflects the software under the test’s top-notch quality.

• Manage the entire testing activity with different test management tools. (eg. QA Touch)

Formal Technical Review (FTR) in Software Engineering

Formal Technical Review (FTR) is a software quality control activity performed by software
engineers. It is an organized, methodical procedure for assessing and raising the standard of
any technical paper, including software objects. Finding flaws, making sure standards are
followed, and improving the product or document under review’s overall quality are the main
objectives of a formal technical review (FTR). Although FTRs are frequently utilized in
software development, other technical fields can also employ the concept.
Objectives of formal technical review (FTR)
 Detect Identification: Identify defects in technical objects by finding and fixing
mistakes, inconsistencies, and deviations.
 Quality Assurance: To ensure high-quality deliverables, and confirm compliance
with project specifications and standards.
 Risk Mitigation: To stop risks from getting worse, proactively identify and manage
possible threats.
 Knowledge Sharing: Encourage team members to work together and build a
common knowledge base.
 Consistency and Compliance: Verify that all procedures, coding standards, and
policies are followed.
 Learning and Training: Give team members the chance to improve their abilities
through learning opportunities.
In addition, the purpose of FTR is to enable junior engineers to observe the analysis, design,
coding, and testing approach more closely. FTR also works to promote backup and continuity
to become familiar with parts of the software they might not have seen otherwise. FTR is a
class of reviews that include walkthroughs, inspections, round-robin reviews, and other small-
group technical assessments of software. Each FTR is conducted as a meeting and is
considered successful only if it is properly planned, controlled, and attended.
Example
Suppose during the development of the software without FTR design cost 10 units, coding
cost 15 units and testing cost 10 units then the total cost till now is 35 units without
maintenance but there was a quality issue because of bad design so to fix it we have to
redesign the software and final cost will become 70 units. that is why FTR is so helpful while
developing the software.
The Review Meeting
Each review meeting should be held considering the following constraints- Involvement of
people:
1. Between 3, 4, and 5 people should be involved in the review.
2. preparation should occur, but it should be very short that is at the most 2 hours of
work for every person.
3. The short duration of the review meeting should be less than two hours. Given these
constraints, it should be clear that an FTR focuses on specific (and small) parts of the
overall software.
At the end of the review, all attendees of FTR must decide what to do.
1. Accept the product without any modification.
2. Reject the project due to serious error (Once corrected, another app needs to be
reviewed), or
3. Accept the product provisional (minor errors are encountered and should be corrected,
but no additional review will be required).
The decision was made, with all FTR attendees completing a sign indicating their
participation in the review and their agreement with the findings of the review team.

Review reporting and record-keeping:

1. During the FTR, the reviewer actively records all issues that have been raised.
2. At the end of the meeting all these issues raised are consolidated and a review list is
prepared.
3. Finally, a formal technical review summary report is prepared.

A review summary report answers three questions:

1. What was reviewed?

2. Who reviewed it?
3. What were the findings and conclusions?
Review Guidelines
Guidelines for the conducting of formal technical reviews should be established in advance.
These guidelines must be distributed to all reviewers, agreed upon, and then followed. An
unregistered review can often be worse than a review that does not minimum set of guidelines
for FTR.
1. Review the product, not the manufacturer (producer): FTR includes people and
egos. while properly conducted FTR will give all participants a good feeling of
accomplishment, and when conducted improperly, the FTR team will be pointed out
clearly. the meeting tone will be only loose and constructive, the review team leader will
ensure that the proper way of communication will be happening or not into the team or it
will get out of control.
2. Set an agenda and maintain it: one of the measure keys in the meeting is drift. FTR
will always keep on track and schedule. the review leader is making and maintaining the
meeting schedule and should not be afraid that many people drift sets in.
3. Limit debate and rebuttal: whenever the issue is raised by the reviewer there will
not be an impact on a universal agreement. rather than spending time with the questions,
then issues will be further discussed off-line.
4. Enunciate problem areas, but don’t attempt to solve every problem noted: A
review is not a problem-solving session. The solution to a problem can often be
accomplished for the producer alone or with the help of only one other individual.
problem-solving should be postponed for a while until after the review meeting.
5. Take written notes (record purpose): it is a good idea to take notes on the
wallboard so that will be wording, and priorities can be assessed by other reviewers as
information is recorded.
6. Limit the number of participants and insist upon preparation: two heads are
better than one, but 14 are not needed to be better than 4. We will keep the number of
people involved to a minimum, all review teams must prepare in advance, and written
comments will be requested by the review leader.
7. Develop a checklist for each product that is likely to be reviewed: A checklist will
help to structure of Review meeting and for the review leader and help to focus the
reviewer on the important issues. checklist should be developed by the analysis, design,
code, and even test documents.
8. Allocate resources and schedule for FTRs to maintain schedule: it’s effective to
review, they should be effective and it should be a task during the software engineering
process. In addition, the time should be scheduled for modification that occurs as a result
of an FTR.
9. Conduct meaningful training for all reviewers to make reviews effective: To be
effective for all the reviews at first some have received formal training. it will stress both
process-related and the human psychological side of the reviews. for every person who is
to participate in reviews which is a one-month learning curve of 20 people.
10. Review earlier reviews that serve as the base for the current review being
conducted: it can be beneficial in uncovering problems with the review process itself. the
first product to be reviewed should be the guidelines themselves because many variables
have a successful review, a software organization should experiment to find approaches
that work best in a local context. porter and his colleagues provide excellent guidance for
this type of experiment.
Conclusion
Organizations can create and follow standardized procedures since the formalized nature of
FTR guarantees consistency in the review process. This helps with continuous improvement
and gives teams a foundation for metrics and analysis so they can monitor the effectiveness of
their reviews over time.
Want to learn Software Testing and Automation to help give a kickstart to your career? Any
student or professional looking to excel in Quality Assurance should enroll in our
course, Complete Guide to Software Testing and Automation, only on GeeksforGeeks. Get
hands-on learning experience with the latest testing methodologies, automation tools, and
industry best practices through practical projects and real-life scenarios. Whether you are a
beginner or just looking to build on existing skills, this course will give you the competence
necessary to ensure the quality and reliability of software products. Ready to be a Pro in
Software Testing? Enroll now and Take Your Career to a Whole New Level!

QUALITY Standards in Software Engineering

Overview :
The mission of the International Standard Organization is to market the development of
standardization and its related activities to facilitate the international exchange of products
and services. It also helps to develop cooperation within the different activities like spheres
of intellectual, scientific, technological, and economic activity.
ISO 9000 Quality Standards :
It is defined as the quality assurance system in which quality components can be
organizational structure, responsibilities, procedures, processes, and resources for
implementing quality management. Quality assurance systems are created to help
organizations ensure their products and services satisfy customer expectations by meeting
their specifications.
Different types of ISO standards :
Here, you will see different types of ISO standards as follows.
 ISO 9000: 2000 –
ISO 9000: 2000: contains Quality management systems, fundamentals, and vocabulary.

 ISO 9000-1: 1994 –

This series of standards includes Quality management systems and Quality assurance
standards. It also includes some guidelines for selection and use.

 ISO 9000-2: 1997 –

 This series of standards also includes Quality management systems and Quality
assurance standards. It also includes some guidelines for the application of ISO 9001,
ISO 9002, and ISO 9003.

 ISO 9000-3: 1997 –

This series contains Quality management systems, Quality assurance standards and also
includes guidelines for the application of ISO 9001 to 1994 to the development, supply,
installation, and maintenance of computer installation.

 ISO 9001: 1994 –

This series of standards has Quality systems and a Quality assurance model. This model
helps in design, development, production, installation, and service.

 ISO 9001: 2000 –

This series of standards also includes Quality management systems.
 ISO 9002: 1994 –
This series of standards also includes some Quality systems. This Quality assurance
model used in production, installation, and servicing.

 ISO 9003: 1994 –

This series of standards also includes some Quality systems. This Quality assurance
model used in the final inspection and test.

 ISO 9004: 2000 –

This series of standards include some Quality management systems. It also includes
some guidelines for performance improvements.

 ISO 9039: 1994 –

This series of standards include some Optics and Optical Instruments. It includes
quality evaluation of optical systems and determination of distortion.

 ISO/IEC 9126-1: 2001 –

This series of standards has information technology. It also includes some software
products, quality models.

 ISO/IEC 9040: 1997 –

This series of standards has information technology. It also includes open system
interconnection and Virtual terminal basic class service.

 ISO/IEC 9041-1: 1997 –

This series of standards has information technology. It also includes open system
interconnection, Virtual terminal basic class service protocol, and specification.

 ISO/IEC 9041-2: 1997 –

This series of standards include information technology, open system interconnection,
Virtual terminal basic class protocol, and Protocol implementation conformance
statement (PICS) proforma.

 ISO/IEC 9075-9: 2001 –

This series of standards has information technology, Database languages, and
SQL/MED(Management of External Data).

 ISO/IEC 9075-10: 2000 -|

This series of standards has information technology, Database languages, and
SQL/OLB (Object Language Bindings).

 ISO/IEC 9075-13: 2002 –

This series of standards has information technology, Database languages, SQL routines,
and Java Programming language. (SQL/JRT).

System configuration management – Software Engineering

(SCM PROCESS)
Whenever software is built, there is always scope for improvement and those improvements
bring picture changes. Changes may be required to modify or update any existing solution or
to create a new solution for a problem. Requirements keep on changing daily so we need to
keep on upgrading our systems based on the current requirements and needs to meet desired
outputs. Changes should be analyzed before they are made to the existing system, recorded
before they are implemented, reported to have details of before and after, and controlled in a
manner that will improve quality and reduce error. This is where the need for System
Configuration Management comes. System Configuration Management (SCM) is an
arrangement of exercises that controls change by recognizing the items for change, setting up
connections between those things, making/characterizing instruments for overseeing diverse
variants, controlling the changes being executed in the current framework, inspecting and
revealing/reporting on the changes made. It is essential to control the changes because if the
changes are not checked legitimately then they may wind up undermining a well-run
programming. In this way, SCM is a fundamental piece of all project management activities.
Processes involved in SCM – Configuration management provides a disciplined
environment for smooth control of work products. It involves the following activities:
1. Identification and Establishment – Identifying the configuration items from
products that compose baselines at given points in time (a baseline is a set of mutually
consistent Configuration Items, which has been formally reviewed and agreed upon, and
serves as the basis of further development). Establishing relationships among items,
creating a mechanism to manage multiple levels of control and procedure for the change
management system.
2. Version control – Creating versions/specifications of the existing product to build
new products with the help of the SCM system. A description of the version is given

below:
3. Suppose after some changes, the version of the configuration object changes from 1.0
to 1.1. Minor corrections and changes result in versions 1.1.1 and 1.1.2, which is followed
by a major update that is object 1.2. The development of object 1.0 continues through 1.3
and 1.4, but finally, a noteworthy change to the object results in a new evolutionary path,
version 2.0. Both versions are currently supported.
4. Change control – Controlling changes to Configuration items (CI). The change
control process is explained in Figure below:
 A change request (CR) is submitted and evaluated to assess technical merit, potential side
effects, the overall impact on other configuration objects and system functions, and the
projected cost of the change. The results of the evaluation are presented as a change
report, which is used by a change control board (CCB) —a person or group who makes a
final decision on the status and priority of the change. An engineering change Request
(ECR) is generated for each approved change. Also, CCB notifies the developer in case
the change is rejected with proper reason. The ECR describes the change to be made, the
constraints that must be respected, and the criteria for review and audit. The object to be
changed is “checked out” of the project database, the change is made, and then the object
is tested again. The object is then “checked in” to the database and appropriate version
control mechanisms are used to create the next version of the software.
5. Configuration auditing – A software configuration audit complements the formal
technical review of the process and product. It focuses on the technical correctness of the
configuration object that has been modified. The audit confirms the completeness,
correctness, and consistency of items in the SCM system and tracks action items from the
audit to closure.
6. Reporting – Providing accurate status and current configuration data to developers,
testers, end users, customers, and stakeholders through admin guides, user guides, FAQs,
Release notes, Memos, Installation Guide, Configuration guides, etc.
System Configuration Management (SCM) is a software engineering practice that focuses on
managing the configuration of software systems and ensuring that software components are
properly controlled, tracked, and stored. It is a critical aspect of software development, as it
helps to ensure that changes made to a software system are properly coordinated and that the
system is always in a known and stable state.
SCM involves a set of processes and tools that help to manage the different components of a
software system, including source code, documentation, and other assets. It enables teams to
track changes made to the software system, identify when and why changes were made, and
manage the integration of these changes into the final product.
Importance of Software Configuration Management
1. Effective Bug Tracking: Linking code modifications to issues that have been reported,
makes bug tracking more effective.
2. Continuous Deployment and Integration: SCM combines with continuous processes
to automate deployment and testing, resulting in more dependable and timely software
delivery.
3. Risk management: SCM lowers the chance of introducing critical flaws by assisting
in the early detection and correction of problems.
4. Support for Big Projects: Source Code Control (SCM) offers an orderly method to
handle code modifications for big projects, fostering a well-organized development
process.
5. Reproducibility: By recording precise versions of code, libraries, and dependencies,
source code versioning (SCM) makes builds repeatable.
6. Parallel Development: SCM facilitates parallel development by enabling several
developers to collaborate on various branches at once.
Why need for System configuration management?
1. Replicability: Software version control (SCM) makes ensures that a software system
can be replicated at any stage of its development. This is necessary for testing, debugging,
and upholding consistent environments in production, testing, and development.
2. Identification of Configuration: Source code, documentation, and executable files are
examples of configuration elements that SCM helps in locating and labeling. The
management of a system’s constituent parts and their interactions depend on this
identification.
3. Effective Process of Development: By automating monotonous processes like
managing dependencies, merging changes, and resolving disputes, SCM simplifies the
development process. Error risk is decreased and efficiency is increased because of this
automation.
Key objectives of SCM
1. Control the evolution of software systems: SCM helps to ensure that changes to a
software system are properly planned, tested, and integrated into the final product.
2. Enable collaboration and coordination: SCM helps teams to collaborate and
coordinate their work, ensuring that changes are properly integrated and that everyone is
working from the same version of the software system.
3. Provide version control: SCM provides version control for software systems,
enabling teams to manage and track different versions of the system and to revert to
earlier versions if necessary.
4. Facilitate replication and distribution: SCM helps to ensure that software systems
can be easily replicated and distributed to other environments, such as test, production,
and customer sites.
5. SCM is a critical component of software development, and effective SCM practices
can help to improve the quality and reliability of software systems, as well as increase
efficiency and reduce the risk of errors.
The main advantages of SCM
1. Improved productivity and efficiency by reducing the time and effort required to
manage software changes.
2. Reduced risk of errors and defects by ensuring that all changes were properly tested
and validated.
3. Increased collaboration and communication among team members by providing a
central repository for software artifacts.
4. Improved quality and stability of software systems by ensuring that all changes are
properly controlled and managed.
The main disadvantages of SCM
1. Increased complexity and overhead, particularly in large software systems.
2. Difficulty in managing dependencies and ensuring that all changes are properly
integrated.
3. Potential for conflicts and delays, particularly in large development teams with
multiple contributors.

Want to learn Software Testing and Automation to help give a kickstart to your career? Any
student or professional looking to excel in Quality Assurance should enroll in our
course, Complete Guide to Software Testing and Automation, only on GeeksforGeeks. Get
hands-on learning experience with the latest testing methodologies, automation tools, and
industry best practices through practical projects and real-life scenarios. Whether you are a
beginner or just looking to build on existing skills, this course will give you the competence
necessary to ensure the quality and reliability of software products. Ready to be a Pro in
Software Testing? Enroll now and Take Your Career to a Whole New Level!

Baseline items
In software development, baseline items are important factors that serve as reference factors
throughout the project lifecycle. These objects, including requirements, layout documents,
and code variations, help to ensure consistency and traceability. Establishing baselines
enables effective project management, permitting teams to monitor progress and manage
adjustments systematically.
IEEE
(IEEE Std. No. 610.12-1990) defines baseline as an agreed description and review of product
attributes, that afterwards serve as the basis for further development and defining change, and
this changing can be done only through formal change control procedures”. A baseline is a
milestone and a reference point in software development marked by completion or delivery of
one or more software configuration items and formal approval of a set of predefined products
is obtained through formal technical review. The baseline is a shared project database. It is the
task of Software Configuration Management (SCM) that is used to maintain the integrity of a
set of products. The main aim of the baseline is to reduce and control vulnerability i.e.
Weakness of projects that can easily affect projects and lead to uncontrollable changes. This
can be achieved by fixing and changing configuration items (various key deliverables) in
the product’s development life cycle at some critical points. Each element that is associated
with the baseline needs to be kept under formal change control.
Process :
1. Elements need to be documented properly and reviewed to find if there is an issue
with the design model. If any error or defect is found, then these errors and defects are
corrected and fixed.
2. All parts of the model are being reviewed properly and all problems found are being
fixed and approved.
3. The design base model is now the Baseline.
4. Any further changes in the program architecture that are documented in the design
model can be allowed to be done only after each has been evaluated and approved.
Baseline Components :
A typical baseline includes the following components :
1. Functional Baseline – Operation Document, System Requirements.
2. Allocated Baseline – High-level document, Preliminary Design, Interface control
documents.
3. Design Baseline – Detailed design documents.
4. Product Baseline – Source and executable code units, final system specifications,
user and maintenance manuals, Hardware and software specifications,
5. Operational Baseline – Source and executable code units, final system specifications,
user and maintenance manuals, acceptance test plans, test procedures, site integration test
cases and data sets and test reports
6. Acceptance Test – Source and executable code units, integration test plans, test
procedures, test cases, and data sets and test reports
7. Integration Test – Source and executable code units, unit test plans, test procedures,
test cases, and data sets and test reports
8. Unit Test – Source and executable code modules
Example :
Version Control Systems
What is a “version control system”?
Version control systems are a category of software tools that helps in recording changes made
to files by keeping a track of modifications done in the code.
Why Version Control system is so Important?
As we know that a software product is developed in collaboration by a group of developers
they might be located at different locations and each one of them contributes to some specific
kind of functionality/features. So in order to contribute to the product, they made
modifications to the source code(either by adding or removing). A version control system is a
kind of software that helps the developer team to efficiently communicate and manage(track)
all the changes that have been made to the source code along with the information like who
made and what changes have been made. A separate branch is created for every contributor
who made the changes and the changes aren’t merged into the original source code unless all
are analyzed as soon as the changes are green signaled they merged to the main source code.
It not only keeps source code organized but also improves productivity by making the
development process smooth.
Basically Version control system keeps track on changes made on a particular software and
take a snapshot of every modification. Let’s suppose if a team of developer add some new
functionalities in an application and the updated version is not working properly so as the
version control system keeps track of our work so with the help of version control system we
can omit the new changes and continue with the previous version.
Benefits of the version control system:
 Enhances the project development speed by providing efficient collaboration,
 Leverages the productivity, expedites product delivery, and skills of the employees
through better communication and assistance,
 Reduce possibilities of errors and conflicts meanwhile project development through
traceability to every small change,
 Employees or contributors of the project can contribute from anywhere irrespective of
the different geographical locations through this VCS,
 For each different contributor to the project, a different working copy is maintained
and not merged to the main file unless the working copy is validated. The most popular
example is Git, Helix core, Microsoft TFS,
 Helps in recovery in case of any disaster or contingent situation,
 Informs us about Who, What, When, Why changes have been made.
Use of Version Control System:
 A repository: It can be thought of as a database of changes. It contains all the edits
and historical versions (snapshots) of the project.
 Copy of Work (sometimes called as checkout): It is the personal copy of all the
files in a project. You can edit to this copy, without affecting the work of others and you
can finally commit your changes to a repository when you are done making your changes.
 Working in a group: Consider yourself working in a company where you are asked
to work on some live project. You can’t change the main code as it is in production, and
any change may cause inconvenience to the user, also you are working in a team so you
need to collaborate with your team to and adapt their changes. Version control helps you
with the, merging different requests to main repository without making any undesirable
changes. You may test the functionalities without putting it live, and you don’t need to
download and set up each time, just pull the changes and do the changes, test it and merge
it back. It may be visualized as.
Types of Version Control Systems:
 Local Version Control Systems
 Centralized Version Control Systems
 Distributed Version Control Systems
Local Version Control Systems: It is one of the simplest forms and has a database that kept
all the changes to files under revision control. RCS is one of the most common VCS tools. It
keeps patch sets (differences between files) in a special format on disk. By adding up all the
patches it can then re-create what any file looked like at any point in time.
Centralized Version Control Systems: Centralized version control systems contain just one
repository globally and every user need to commit for reflecting one’s changes in the
repository. It is possible for others to see your changes by updating.
Two things are required to make your changes visible to others which are:
 You commit
 They update

The benefit of CVCS (Centralized Version Control Systems) makes collaboration amongst
developers along with providing an insight to a certain extent on what everyone else is doing
on the project. It allows administrators to fine-grained control over who can do what.
It has some downsides as well which led to the development of DVS. The most obvious is the
single point of failure that the centralized repository represents if it goes down during that
period collaboration and saving versioned changes is not possible. What if the hard disk of the
central database becomes corrupted, and proper backups haven’t been kept? You lose
absolutely everything.
Distributed Version Control Systems: Distributed version control systems contain multiple
repositories. Each user has their own repository and working copy. Just committing your
changes will not give others access to your changes. This is because commit will reflect those
changes in your local repository and you need to push them in order to make them visible on
the central repository. Similarly, When you update, you do not get others’ changes unless you
have first pulled those changes into your repository.
To make your changes visible to others, 4 things are required:
 You commit
 You push
 They pull
 They update
The most popular distributed version control systems are Git, and Mercurial. They help us
overcome the problem of single point of failure.

Purpose of Version Control:

 Multiple people can work simultaneously on a single project. Everyone works on and
edits their own copy of the files and it is up to them when they wish to share the changes
made by them with the rest of the team.
 It also enables one person to use multiple computers to work on a project, so it is
valuable even if you are working by yourself.
 It integrates the work that is done simultaneously by different members of the team.
In some rare cases, when conflicting edits are made by two people to the same line of a
file, then human assistance is requested by the version control system in deciding what
should be done.
 Version control provides access to the historical versions of a project. This is
insurance against computer crashes or data loss. If any mistake is made, you can easily
roll back to a previous version. It is also possible to undo specific edits that too without
losing the work done in the meanwhile. It can be easily known when, why, and by whom
any part of a file was edited.

Software Configuration Audits

An audit is a planned and independent evaluation of one or more products, processes, projects,
or systems to determine conformance or compliance to a set of agreed to requirements.
Auditing is an “objective assurance and consulting activity designed to add value and improve
an organization’s operations.” [Hutchins-03] Audits provide assurance by validating that the
product, process, project and/or system are implemented in accordance with their
requirements and objectives. Audits are management information activities because they
provide ongoing analysis of the degree to which those implementations are effective and
efficient, and they identify opportunities for continuous improvement. Audits also visibly
demonstrate management’s support for the quality program.

In the case of Software Configuration Management (SCM) audits, three types of audits are
typically performed:

 Functional Configuration Audit (FCA), which is an evaluation of the completed

software products to determine their conformance, in terms of completeness,
performance, and functional characteristics, to their requirements
specification(s).

 Physical Configuration Audit (PCA), which is an evaluation of each

configuration item to determine its conformance to the technical documentation
that defines it.

 In-Process SCM Audits, which are ongoing evaluations conducted throughout

the life cycle to provide management with information about compliance to
SCM policies, plans, processes, and systems, and about the conformance of
software products to their requirements and workmanship standards.

Parts 2 through 4 of this article will discuss the purpose of each of these three types of SCM
audits. They will also provide examples of checklist items that could be used during audit
evaluations and suggests evidence-gathering techniques for each item in those checklists.

When Are Configuration Audits Conducted

At a minimum, FCA and PCA should be conducted just before the final Ready to Beta Test or
Ready to Ship review to provide input information into those reviews. In addition, these
audits can also be conducted at other major milestones throughout the software development
cycle as inputs into milestone reviews or other management oversite activities.

In traditional software development, as illustrated in Figure 1, the FCA and PCA activities
should be conducted as part of creating the Product Baseline. Depending on the level of rigor,
FCA and PCA activities could also be conducted at other major milestones (baselines),
including:

 The Functional Baseline

  One or More Allocated Baselines

 One or More Development Baselines

Figure 1: FCA and PCA Audits in Traditional Software Development

In agile software development, as illustrated in Figure 2, the FCA and PCA activities should
be conducted as part of the software release milestone. Depending on the level of rigor, FCA
and PCA activities could also be conducted at the end of each sprint (iteration).
 Figure 2: FCA and PCA Audits in Agile Software Development

In-process SCM audits can be conducted throughout development as needed. Plans for any in-
process SCM audits should be specified in the Software Quality Assurance (SQA) plans.

Software Maintenance
What is Software Maintenance?
Software maintenance is a continuous process that occurs throughout the entire life cycle of
the software system.
 The goal of software maintenance is to keep the software system working correctly,
efficiently, and securely, and to ensure that it continues to meet the needs of the users.
 This can include fixing bugs, adding new features, improving performance, or
updating the software to work with new hardware or software systems.
 It is also important to consider the cost and effort required for software maintenance
when planning and developing a software system.
 It is important to have a well-defined maintenance process in place, which
includes testing and validation, version control, and communication with stakeholders.
 It’s important to note that software maintenance can be costly and complex,
especially for large and complex systems. Therefore, the cost and effort of maintenance
should be taken into account during the planning and development phases of a software
project.
 It’s also important to have a clear and well-defined maintenance plan that includes
regular maintenance activities, such as testing, backup, and bug fixing.
Several Key Aspects of Software Maintenance
1. Bug Fixing: The process of finding and fixing errors and problems in the software.
2. Enhancements: The process of adding new features or improving existing features
to meet the evolving needs of the users.
3. Performance Optimization: The process of improving the speed, efficiency, and
reliability of the software.
4. Porting and Migration: The process of adapting the software to run on new
hardware or software platforms.
5. Re-Engineering: The process of improving the design and architecture of the
software to make it more maintainable and scalable.
6. Documentation: The process of creating, updating, and maintaining the
documentation for the software, including user manuals, technical specifications, and
design documents.
Several Types of Software Maintenance
1. Corrective Maintenance: This involves fixing errors and bugs in the software
system.
2. Patching: It is an emergency fix implemented mainly due to pressure from
management. Patching is done for corrective maintenance but it gives rise to unforeseen
future errors due to lack of proper impact analysis.
3. Adaptive Maintenance: This involves modifying the software system to adapt it to
changes in the environment, such as changes in hardware or software, government
policies, and business rules.
4. Perfective Maintenance: This involves improving functionality, performance, and
reliability, and restructuring the software system to improve changeability.
5. Preventive Maintenance: This involves taking measures to prevent future
problems, such as optimization, updating documentation, reviewing and testing the
system, and implementing preventive measures such as backups.
Maintenance can be categorized into proactive and reactive types. Proactive maintenance
involves taking preventive measures to avoid problems from occurring, while reactive
maintenance involves addressing problems that have already occurred.
Maintenance can be performed by different stakeholders, including the original
development team, an in-house maintenance team, or a third-party maintenance provider.
Maintenance activities can be planned or unplanned. Planned activities include regular
maintenance tasks that are scheduled in advance, such as updates and backups. Unplanned
activities are reactive and are triggered by unexpected events, such as system crashes or
security breaches. Software maintenance can involve modifying the software code, as well
as its documentation, user manuals, and training materials. This ensures that the software is
up-to-date and continues to meet the needs of its users.
Software maintenance can also involve upgrading the software to a new version or platform.
This can be necessary to keep up with changes in technology and to ensure that the software
remains compatible with other systems. The success of software maintenance depends on
effective communication with stakeholders, including users, developers, and management.
Regular updates and reports can help to keep stakeholders informed and involved in the
maintenance process.
Software maintenance is also an important part of the Software Development Life Cycle
(SDLC). To update the software application and do all modifications in software
application so as to improve performance is the main focus of software maintenance.
Software is a model that runs on the basis of the real world. so, whenever any change
requires in the software that means the need for real-world changes wherever possible.
Need for Maintenance
Software Maintenance must be performed in order to:
 Correct faults.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system features, and
telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.
 Requirement of user changes.
 Run the code fast
Challenges in Software Maintenance
The various challenges in software maintenance are given below:
 The popular age of any software program is taken into consideration up to ten to
fifteen years. As software program renovation is open-ended and might maintain for
decades making it very expensive.
 Older software programs, which had been intended to paint on sluggish machines
with much less reminiscence and garage ability can not maintain themselves tough in
opposition to newly coming more advantageous software programs on contemporary-
day hardware.
 Changes are frequently left undocumented which can also additionally reason
greater conflicts in the future.
 As the era advances, it turns into high prices to preserve vintage software programs.
 Often adjustments made can without problems harm the authentic shape of the
software program, making it difficult for any next adjustments.
 There is a lack of Code Comments.
 Lack of documentation: Poorly documented systems can make it difficult to
understand how the system works, making it difficult to identify and fix problems.
 Legacy code: Maintaining older systems with outdated technologies can be
difficult, as it may require specialized knowledge and skills.
 Complexity: Large and complex systems can be difficult to understand and modify,
making it difficult to identify and fix problems.
 Changing requirements: As user requirements change over time, the software
system may need to be modified to meet these new requirements, which can be difficult
and time-consuming.
 Interoperability issues: Systems that need to work with other systems or software
can be difficult to maintain, as changes to one system can affect the other systems.
 Lack of test coverage: Systems that have not been thoroughly tested can be
difficult to maintain as it can be hard to identify and fix problems without knowing how
the system behaves in different scenarios.
 Lack of personnel: A lack of personnel with the necessary skills and knowledge to
maintain the system can make it difficult to keep the system up-to-date and running
smoothly.
 High-Cost: The cost of maintenance can be high, especially for large and complex
systems, which can be difficult to budget for and manage.
To overcome these challenges, it is important to have a well-defined maintenance process
in place, which includes testing and validation, version control, and communication with
stakeholders. It is also important to have a clear and well-defined maintenance plan that
includes regular maintenance activities, such as testing, backup, and bug fixing.
Additionally, it is important to have personnel with the necessary skills and knowledge to
maintain the system.
Categories of Software Maintenance
Maintenance can be divided into the following categories.
 Corrective maintenance: Corrective maintenance of a software product may be
essential either to rectify some bugs observed while the system is in use, or to enhance
the performance of the system.
 Adaptive maintenance: This includes modifications and updations when the
customers need the product to run on new platforms, on new operating systems, or
when they need the product to interface with new hardware and software.
 Perfective maintenance: A software product needs maintenance to support the
new features that the users want or to change different types of functionalities of the
system according to the customer’s demands.
 Preventive maintenance: This type of maintenance includes modifications and
updations to prevent future problems with the software. It goals to attend to problems,
which are not significant at this moment but may cause serious issues in the future.