System configuration management –

Software Engineering



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:
 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.
3. 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.
4. 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.
5. 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.

SCM Process
It uses the tools which keep that the necessary change has been implemented
adequately to the appropriate component. The SCM process defines a number of
tasks:
 o Identification of objects in the software configuration
o Version Control
o Change Control
o Configuration Audit
o Status Reporting

Identification

Basic Object: Unit of Text created by a software engineer during analysis, design,
code, or test.

Aggregate Object: A collection of essential objects and other aggregate objects.

Design Specification is an aggregate object.

Each object has a set of distinct characteristics that identify it uniquely: a name, a
description, a list of resources, and a "realization."

The interrelationships between configuration objects can be described with a

Module Interconnection Language (MIL).

Version Control
Version Control combines procedures and tools to handle different version of
configuration objects that are generated during the software process.

Clemm defines version control in the context of SCM: Configuration management

allows a user to specify the alternative configuration of the software system through
the selection of appropriate versions. This is supported by associating attributes with
each software version, and then allowing a configuration to be specified [and
constructed] by describing the set of desired attributes.

Change Control

James Bach describes change control in the context of SCM is: Change Control is
Vital. But the forces that make it essential also make it annoying.

We worry about change because a small confusion in the code can create a big
failure in the product. But it can also fix a significant failure or enable incredible new
capabilities.

We worry about change because a single rogue developer could sink the project, yet
brilliant ideas originate in the mind of those rogues, and

A burdensome change control process could effectively discourage them from doing
creative work.

A change request is submitted and calculated to assess technical merit; potential side
effects, the overall impact on other configuration objects and system functions, and
projected cost of the change.

The results of the evaluations are presented as a change report, which is used by a
change control authority (CCA) - a person or a group who makes a final decision on
the status and priority of the change.

The "check-in" and "check-out" process implements two necessary elements of

change control-access control and synchronization control.

AD

Access Control governs which software engineers have the authority to access and
modify a particular configuration object.

Synchronization Control helps to ensure that parallel changes, performed by two

different people, don't overwrite one another.

Configuration Audit
SCM audits to verify that the software product satisfies the baselines requirements
and ensures that what is built and what is delivered.

SCM audits also ensure that traceability is maintained between all CIs and that all
work requests are associated with one or more CI modification.

AD

SCM audits are the "watchdogs" that ensures that the integrity of the project's scope
is preserved.

Status Reporting

Configuration Status reporting (sometimes also called status accounting) providing

accurate status and current configuration data to developers, testers, end users,
customers and stakeholders through admin guides, user guides, FAQs, Release
Notes, Installation Guide, Configuration Guide, etc.

Software Quality Assurance

What is Quality?
Quality defines to any measurable characteristics such as correctness, maintainability,
portability, testability, usability, reliability, efficiency, integrity, reusability, and
interoperability.

There are two kinds of Quality:

Quality of Design: Quality of Design refers to the characteristics that designers

specify for an item. The grade of materials, tolerances, and performance
specifications that all contribute to the quality of design.
Quality of conformance: Quality of conformance is the degree to which the design
specifications are followed during manufacturing. Greater the degree of
conformance, the higher is the level of quality of conformance.

Software Quality: Software Quality is defined as the conformance to explicitly state

functional and performance requirements, explicitly documented development
standards, and inherent characteristics that are expected of all professionally
developed software.

Quality Control: Quality Control involves a series of inspections, reviews, and tests
used throughout the software process to ensure each work product meets the
requirements place upon it. Quality control includes a feedback loop to the process
that created the work product.

Quality Assurance: Quality Assurance is the preventive set of activities that provide
greater confidence that the project will be completed successfully.

Quality Assurance focuses on how the engineering and management activity will be
done?

As anyone is interested in the quality of the final product, it should be assured that
we are building the right product.

It can be assured only when we do inspection & review of intermediate products, if

there are any bugs, then it is debugged. This quality can be enhanced.

Importance of Quality
We would expect the quality to be a concern of all producers of goods and services.
However, the distinctive characteristics of software and in particular its intangibility
and complexity, make special demands.

Increasing criticality of software: The final customer or user is naturally concerned

about the general quality of software, especially its reliability. This is increasing in the
case as organizations become more dependent on their computer systems and
software is used more and more in safety-critical areas. For example, to control
aircraft.

The intangibility of software: This makes it challenging to know that a particular

task in a project has been completed satisfactorily. The results of these tasks can be
made tangible by demanding that the developers produce 'deliverables' that can be
examined for quality.
Accumulating errors during software development: As computer system
development is made up of several steps where the output from one level is input to
the next, the errors in the earlier ?deliverables? will be added to those in the later
stages leading to accumulated determinable effects. In general the later in a project
that an error is found, the more expensive it will be to fix. In addition, because the
number of errors in the system is unknown, the debugging phases of a project are
particularly challenging to control.

Software Quality Assurance

Software quality assurance is a planned and systematic plan of all actions necessary
to provide adequate confidence that an item or product conforms to establish
technical requirements.

A set of activities designed to calculate the process by which the products are
developed or manufactured.

AD

SQA Encompasses

o A quality management approach

o Effective Software engineering technology (methods and tools)
o Formal technical reviews that are tested throughout the software process
o A multitier testing strategy
o Control of software documentation and the changes made to it.
o A procedure to ensure compliances with software development standards
o Measuring and reporting mechanisms.

SQA Activities
Software quality assurance is composed of a variety of functions associated with two
different constituencies ? the software engineers who do technical work and an SQA
group that has responsibility for quality assurance planning, record keeping, analysis,
and reporting.

AD

Following activities are performed by an independent SQA group:

1. Prepares an SQA plan for a project: The program is developed during

project planning and is reviewed by all stakeholders. The plan governs quality
 assurance activities performed by the software engineering team and the SQA
group. The plan identifies calculation to be performed, audits and reviews to
be performed, standards that apply to the project, techniques for error
reporting and tracking, documents to be produced by the SQA team, and
amount of feedback provided to the software project team.
2. Participates in the development of the project's software process
description: The software team selects a process for the work to be
performed. The SQA group reviews the process description for compliance
with organizational policy, internal software standards, externally imposed
standards (e.g. ISO-9001), and other parts of the software project plan.
3. Reviews software engineering activities to verify compliance with the
defined software process: The SQA group identifies, reports, and tracks
deviations from the process and verifies that corrections have been made.
4. Audits designated software work products to verify compliance with
those defined as a part of the software process: The SQA group reviews
selected work products, identifies, documents and tracks deviations, verify that
corrections have been made, and periodically reports the results of its work to
the project manager.
5. Ensures that deviations in software work and work products are
documented and handled according to a documented
procedure: Deviations may be encountered in the project method, process
description, applicable standards, or technical work products.
6. Records any noncompliance and reports to senior management: Non-
compliance items are tracked until they are resolved.

Quality Assurance v/s Quality control

Quality Assurance Quality Control

Quality Assurance (QA) is the set of actions Quality Control (QC) is described as
including facilitation, training, measurement, the processes and methods used to
and analysis needed to provide adequate compare product quality to
confidence that processes are established and requirements and applicable standards,
continuously improved to produce products or and the actions are taken when a
services that conform to specifications and are nonconformance is detected.
fit for use.
 QA is an activity that establishes and calculates QC is an activity that demonstrates
the processes that produce the product. If there whether or not the product produced
is no process, there is no role for QA. met standards.

QA helps establish process QC relates to a particular product or

service

QA sets up a measurement program to QC verified whether particular attributes

evaluate processes exist, or do not exist, in a explicit
product or service.

QA identifies weakness in processes and QC identifies defects for the primary

improves them goals of correcting errors.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Verification is an example of QA. Validation is an example of QC.

Software Quality Assurance (SQA) Set 2 –

Software Engineering
Last Updated : 08 Jan, 2024



Software Quality Assurance (SQA) consists of a set of activities that monitor the
software engineering processes and methods used to ensure quality.
Software Quality Assurance (SQA) Encompasses
1. A quality management approach.
2. Effective software engineering technology (methods and tools).
3. Some formal technical reviews are applied throughout the software
process.
4. A multi-tiered testing strategy.
5. Controlling software documentation and the changes made to it.
6. Procedure to ensure compliance with software development standards
(when applicable).
7. Measurement and reporting mechanisms.
Software Quality
Software quality is defined in different ways but here it means the conformance to
explicitly stated functional and performance requirements, explicitly documented
development standards, and implicit characteristics that are expected of all
professionally developed software.
Following are the quality management system models under which the software
system is created is normally based:
1. CMMI
2. Six Sigma
3. ISO 9000
Note: There may be many other models for quality management, but the ones
mentioned above are the most popular.
Software Quality Assurance (SQA) Activities
Software Quality Assurance is composed of a variety of tasks associated with two
different fields:
1. The software engineers who do technical work.
2. SQA group that has responsibility for quality assurance planning,
oversight, record keeping, analysis, and reporting.
Basically, software engineers address quality (and perform quality assurance and
quality control activities) by applying solid technical methods and measures,
conducting formal technical reviews, and performing well-planned software
testing.
Prepares an SQA Plan for a Project
This type of plan is developed during project planning and is reviewed by all
interested parties. The quality assurance activities performed by the software
engineering team and the SQA group are governed by the plan. The plan
identifies:
 Evaluations to be performed.
 Audits and reviews to be performed.
 Standards that are applicable to the project.
 Procedures for error reporting and tracking.
 All the documents to be produced by the SQA group.
 The total amount of feedback provided to the software project team.
Every Participant in the Development of the Project’s Software Process
Description
The software team has to select a process for the work to be performed. The
process description is reviewed by the SQA group for conformance with
organizational policy, internal software standards, externally imposed standards,
and other parts of the software project plan.
Software Engineering Activities are Reviewed to Verify Compliance with the
Defined Software Process
The work of the SQA group is to identify documents and to track deviations from
the process and verify that corrections have been made.
Financial Inspection Designated Software Work Products to Verify
Conformance with those Defined as Part of the Software Process
1. The SQA group reviews selected work products; identifies, documents,
and tracks deviations.
2. Verifies that corrections have been made.
 3. Periodically reports the results of its work to the project manager.
Ensures that Deviations in Products are Documented and Handled According to
a Documented Procedure
Deviations in software work and work products may be faced in the project plan,
process description, applicable standards, or technical work products.
Records Reports to Senior Management and Non-compliance
Noncompliance items are tracked until they are resolved.

Software Reliability
Software Reliability means Operational reliability. It is described as the ability of a
system or component to perform its required functions under static conditions for a
specific period.

Software reliability is also defined as the probability that a software system fulfills its
assigned task in a given environment for a predefined number of input cases,
assuming that the hardware and the input are free of error.

Software Reliability is an essential connect of software quality, composed with

functionality, usability, performance, serviceability, capability, installability,
maintainability, and documentation. Software Reliability is hard to achieve because
the complexity of software turn to be high. While any system with a high degree of
complexity, containing software, will be hard to reach a certain level of reliability,
system developers tend to push complexity into the software layer, with the speedy
growth of system size and ease of doing so by upgrading the software.

For example, large next-generation aircraft will have over 1 million source lines of
software on-board; next-generation air traffic control systems will contain between
one and two million lines; the upcoming International Space Station will have over
two million lines on-board and over 10 million lines of ground support software;
several significant life-critical defense systems will have over 5 million source lines of
software. While the complexity of software is inversely associated with software
reliability, it is directly related to other vital factors in software quality, especially
functionality, capability, etc.

ISO 9000 Certification

ISO (International Standards Organization) is a group or consortium of 63 countries
established to plan and fosters standardization. ISO declared its 9000 series of
standards in 1987. It serves as a reference for the contract between independent
parties. The ISO 9000 standard determines the guidelines for maintaining a quality
system. The ISO standard mainly addresses operational methods and organizational
methods such as responsibilities, reporting, etc. ISO 9000 defines a set of guidelines
for the production process and is not directly concerned about the product itself.

Types of ISO 9000 Quality Standards

The ISO 9000 series of standards is based on the assumption that if a proper stage is
followed for production, then good quality products are bound to follow
automatically. The types of industries to which the various ISO standards apply are as
follows.

1. ISO 9001: This standard applies to the organizations engaged in design,

development, production, and servicing of goods. This is the standard that
applies to most software development organizations.
2. ISO 9002: This standard applies to those organizations which do not design
products but are only involved in the production. Examples of these category
industries contain steel and car manufacturing industries that buy the product
and plants designs from external sources and are engaged in only
manufacturing those products. Therefore, ISO 9002 does not apply to
software development organizations.
3. ISO 9003: This standard applies to organizations that are involved only in the
installation and testing of the products. For example, Gas companies.

How to get ISO 9000 Certification?

An organization determines to obtain ISO 9000 certification applies to ISO registrar
office for registration. The process consists of the following stages:
 1. Application: Once an organization decided to go for ISO certification, it
applies to the registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of
the organization.
3. Document review and Adequacy of Audit: During this stage, the registrar
reviews the document submitted by the organization and suggest an
improvement.
4. Compliance Audit: During this stage, the registrar checks whether the
organization has compiled the suggestion made by it during the review or
not.
5. Registration: The Registrar awards the ISO certification after the successful
completion of all the phases.
6. Continued Inspection: The registrar continued to monitor the organization
time by time.

What is an SQA plan?

Software quality assurance (SQA) is a method of ensuring that all software engineering
processes, methods, activities and work items are monitored and conform to established
standards. Standards may include ISO 9000, CMMI model, ISO15504, or a combination of
these standards along with others.
SQA strives to encompass all software development processes and activities, from defining
requirements, coding, debugging, and all other activities until release. As the name suggests,
it focuses on preserving and delivering quality for a software product.

Software Quality Assurance (SQA) plan

A Software Quality Assurance Plan revolves around making sure that the product or service
reaches the market trouble and bug-free. It should also meet the requirements defined in the
SRS (software requirement specification).

The purpose of an SAQ plan is three-fold. It comprises the following:

 Establishing the QA responsibilities of the team in question

 Listing areas of concern that need to be reviewed, audited and looked at
 Identifies the SQA work products
An SQA plan will work alongside the standard development, prototyping, design,
production, and release cycle for a software product or service. For easy documentation and
referencing, an SQA plan will have different sections like purpose, references, configuration
and management, problem reporting and corrective actions, tools, code controls, testing
methodology, and more.

SQA activities
These are, quite simply put, a set of activities common to normal SQA operations.

1. Creating the plan

It consists of the engineering activities to be carried out, and ensuring the right skill mix in the
team. It also lays out the specifics of the actions to be taken in different situations as well as
the tools and procedures specific to the plan.
2. Checkpoint lists
Evaluation of quality of activities at each project stage. This means that there are regularly
scheduled inspections and adherence to the schedule.
3. Executing formal technical reviews
FTRs are used to evaluate the design and quality of the product prototype. Quality
requirements and design quality for the prototype are discussed in meetings with the technical
staff.
4. Multi-testing strategy
Adopting multiple testing approaches to cover all bases and ensure the best possible quality.
5. Process adherence
Designers, developers, and other technical staff must conform to established processes and
employ defined procedures. It comprises the following:

Product Evaluation – the product is evaluated against the specifications laid out in the project
management plan.Process Monitoring – verifies that the steps taken in software development
are correct and match the steps against the documentation.
6. Control changes
Manual and automated control tools are used for validating change requests, evaluating the
 nature of change, controlling and if required, arresting the change effect. In effect, this makes
sure that the software being developed does not stray too far from the outlines.
7. Measuring Change Impact
If defects are found, the concerned department issues a fix. The QA team then determines the
change and the extent of the change brought by the fix. The change should be stable and
should be compatible with the whole project. There are software quality metrics that allow
managers and developers to observe these activities and monitor changes throughout the
SDLC of the product or service.
8. SQA Audits
The audit inspects the entire SDLC process to the established procedure laid out in the SQA
plan. Non-compliance and missed faults can be unearthed and fixed due to this.
9. Record and report keeping
Keeping SQA documentation and information with associated stakeholders. This includes
audit reports, test results, reviews, change request documentation, and other documentation
generated during the entire SDLC.
10. Relationship management
Managing and interfacing between the QA and the development team, thus keeping roles in
check and responsibilities ahead of the individual.

Automated software engineering techniques

There are a number of open source testing tools as well as commercially used tools available
for this purpose. Here are the most used examples.

1. Selenium
A portable software testing tool and automation tool for web applications. A test domain-
specific language is also provided. To write test cases one can use programming languages
including C#, Java, Perl, PHP, Python, Ruby, Scala, and Groovy. Selenium is a product suite
of software consist of the following components:

2. HP UFT
HPE Unified Functional Testing was previously known as HP QuickTest Professional. It
offers testing automation for functional and regression testing for software applications. It is a
user-friendly IDE that provides the best sort of API and GUI testing.
SQA implementation phase
Before building an application, developers and the SQA team create a development plan. To
ensure that the SDLC plan gets executed, the developers write the SDLC plan while the SQA
team writes the Software Quality Assurance plan. The application that is about to be
developed is already halfway done if the documents by the developers and the SQA is well
written and organised.

In this phase, the SQA team’s responsibility is to ensure the implementation of the proposed
features of the intended application. Along with the implementation, the method of
developing the application will also be tracked by the application. There are some design
methods that can be used such as language or framework. The SQA team helps the
development team in selecting the proper framework or language.

The most important task of the SQA team at this stage is to implement clarity of the coding.
Developers could easily write the code of the application but there is a tendency to overdo the
coding. The SQA team emphasises the organisation of the coding which should be
understood easily. Aside from the coding, the comments within the language are also checked
thoroughly. The comments should clearly define each function.

The SQA team checks the software’s documentation. The documentation clearly states the
function of the application.

SQA standards
In a typical SQA, compliance is demanded against the following standards. This may be a
single standard, more than one standard, or a mix of these standards.
  ISO9000
 CMMI level (Capability maturity model Integration)
 TMMi (Test Maturity Model Integration)
 ISO15504
To remain compliant with the above-listed standards, there are a few techniques that are
listed in the SQA plan. These SQA techniques include auditing, reviews, code inspections,
design inspections, simulations, functional testing, walkthroughs, static analysis,
standardizations, stress testing, path testing, Six Sigma principles, and more.

These techniques when used in conjunction with the defined SQA plan save development
costs, time, and maintenance costs, boost reputations, increase product safety and give more
benefits.

SQA is an interconnected, inter-reliant, and overarching umbrella activity that remains of

paramount importance through the SDLC. To say the least, it is a prerequisite for market
success and keeping up investor and consumer confidence. It ensures high quality and makes
sure that the software product or service remains aligned with the business needs and
functions as required when deployed.

Software Testing Tutorial

What is Software Testing
Software testing is a process of identifying the correctness of software by considering its all
attributes (Reliability, Scalability, Portability, Re-usability, Usability) and evaluating the
execution of software components to find the software bugs or errors or defects.
Software testing provides an independent view and objective of the software and gives surety
of fitness of the software. It involves testing of all components under the required services to
confirm that whether it is satisfying the specified requirements or not. The process is also
providing the client with information about the quality of the software.

Testing is mandatory because it will be a dangerous situation if the software fails any of time
due to lack of testing. So, without testing software cannot be deployed to the end user.

What is Testing
Testing is a group of techniques to determine the correctness of the application under the
predefined script but, testing cannot find all the defect of application. The main intent of
testing is to detect failures of the application so that failures can be discovered and corrected.
It does not demonstrate that a product functions properly under all conditions but only that it
is not working in some specific conditions.

Testing furnishes comparison that compares the behavior and state of software against
mechanisms because the problem can be recognized by the mechanism. The mechanism may
include past versions of the same specified product, comparable products, and interfaces of
expected purpose, relevant standards, or other criteria but not limited up to these.
Testing includes an examination of code and also the execution of code in various
environments, conditions as well as all the examining aspects of the code. In the current
scenario of software development, a testing team may be separate from the development team
so that Information derived from testing can be used to correct the process of software
development.

The success of software depends upon acceptance of its targeted audience, easy graphical
user interface, strong functionality load test, etc. For example, the audience of banking is
totally different from the audience of a video game. Therefore, when an organization
develops a software product, it can assess whether the software product will be beneficial to
its purchasers and other audience.

Type of Software testing

We have various types of testing available in the market, which are used to test the
application or the software.

With the help of below image, we can easily understand the type of software testing:

Manual testing
The process of checking the functionality of an application as per the customer needs without
taking any help of automation tools is known as manual testing. While performing the
manual testing on any application, we do not need any specific knowledge of any testing tool,
rather than have a proper understanding of the product so we can easily prepare the test
document.

Manual testing can be further divided into three types of testing, which are as follows:

o White box testing

o Black box testing
o Gray box testing

Automation testing
Automation testing is a process of converting any manual test cases into the test
scripts with the help of automation tools, or any programming language is known as
automation testing. With the help of automation testing, we can enhance the speed
of our test execution because here, we do not require any human efforts. We need to
write a test script and execute those scripts.

Difference between White Box

testing and Black Box testing
In this article, we will discuss white box testing and black box testing, along with the
comparison between them. In Black box testing (or "behavioral testing"), the tester
understands what the program is supposed to do, rather than its internal working.
Whereas, in White box testing, there is a testing of internal coding and infrastructure
of software.

Before jumping directly to the comparison, let's first see a brief description of white-
box and black-box testing.

White Box testing

The term 'white box' is used because of the internal perspective of the system.
The clear box or white box, or transparent box name denotes the ability to see
through the software's outer shell into its inner workings.
It is performed by Developers, and then the software will be sent to the testing team,
where they perform black-box testing. The main objective of white-box testing is to
test the application's infrastructure. It is done at lower levels, as it includes unit
testing and integration testing. It requires programming knowledge, as it majorly
focuses on code structure, paths, conditions, and branches of a program or software.
The primary goal of white-box testing is to focus on the flow of inputs and outputs
through the software and strengthening the security of the software.

It is also known as structural testing, clear box testing, code-based testing, and
transparent testing. It is well suitable and recommended for algorithm testing.

To read more about white box testing, you can refer to the following link – White box
testing.

Black Box testing

The primary source of black-box testing is a specification of requirements that are
stated by the customer. It is another type of manual testing. It is a software testing
technique that examines the functionality of the software without knowing its
internal structure or coding. It does not require programming knowledge of the
software. All test cases are designed by considering the input and output of a
particular function. In this testing, the test engineer analyzes the software against
requirements, identifies the defects or bugs, and sends it back to the development
team.
In this method, the tester selects a function and gives input value to examine its
functionality, and checks whether the function is giving the expected output or not. If
the function produces the correct output, then it is passed in testing, otherwise
failed.

Black box testing is less exhaustive than White Box and Grey Box testing methods. It
is the least time-consuming process among all the testing processes. The main
objective of implementing black box testing is to specify the business needs or the
customer's requirements.

In other words, we can say that black box testing is a process of checking the
functionality of an application as per the customer's requirement. Mainly, there are
three types of black-box testing: functional testing, Non-Functional
testing, and Regression testing. Its main objective is to specify the business needs
or the customer's requirements.
S.no On the basis of Black Box testing White Box testing
.

1. Basic It is a software testing technique that In white-box testing, the internal

examines the functionality of software structure of the software is known
without knowing its internal structure to the tester.
or coding.

2. Also known as Black Box Testing is also known as It is also known as structural
functional testing, data-driven testing, testing, clear box testing, code-
and closed-box testing. based testing, and transparent
testing.

3. Programming In black-box testing, there is less In white-box testing, there is a

knowledge programming knowledge is required. requirement of programming
knowledge.

4. Algorithm testing It is not well suitable for algorithm It is well suitable and
testing. recommended for algorithm
testing.

5. Usage It is done at higher levels of testing It is done at lower levels of testing

that are system testing and acceptance that are unit testing and
testing. integration testing.

6. Automation It is hard to automate black-box It is easy to automate the white

testing due to the dependency of box testing.
testers and programmers on each
other.

7. Tested by It is mainly performed by the software It is mainly performed by

testers. developers.

8. Time-consuming It is less time-consuming. In Black box It is more time-consuming. It

testing, time consumption depends takes a long time to design test
upon the availability of the functional cases due to lengthy code.
specifications.

9. Base of testing The base of this testing is external The base of this testing is coding
expectations. which is responsible for internal
working.

10. Exhaustive It is less exhaustive than White Box It is more exhaustive than Black
testing. Box testing.

11. Implementation In black-box testing, there is no In white-box testing, there is a

knowledge implementation knowledge is required. requirement of implementation
knowledge.

12. Aim The main objective of implementing Its main objective is to check the
black box testing is to specify the code quality.
AD Conclusion
So, both white box testing and black box testing are required for the successful
delivery of software. But 100% testing is not possible with both cases. Tester is
majorly responsible for finding the maximum defects to improve the application's
efficiency. Both black box testing and white box testing are done to certify that an
application is working as expected.

Hence, it is necessary to understand both testing techniques. It will also be helpful to

learn the difference between both terms to effectively pick up the right option.

So, that's all about the article. Hope you find the article helpful and informative.

Object Oriented Testing in Software Testing

Last Updated : 08 Jan, 2024



Prerequisite – Software Testing
Software typically undergoes many levels of testing, from unit testing to system or
acceptance testing. Typically, in-unit testing, small “units”, or modules of the
software, are tested separately with a focus on testing the code of that module. In
higher-order testing (e.g, acceptance testing), the entire system (or a subsystem) is
tested with a focus on testing the functionality or external behavior of the system.
As information systems are becoming more complex, the object-oriented paradigm
is gaining popularity because of its benefits in analysis, design, and coding.
Conventional testing methods cannot be applied for testing classes because of
problems involved in testing classes, abstract classes, inheritance, dynamic
binding, message, passing, polymorphism, concurrency, etc.
Testing classes is a fundamentally different issue than testing functions. A function
(or a procedure) has a clearly defined input-output behavior, while a class does not
have an input-output behavior specification. We can test a method of a class using
approaches for testing functions, but we cannot test the class using these
approaches.
 Data dependencies between variables
 Calling dependencies between modules
 Functional dependencies between a module and the variable it computes
 Definitional dependencies between a variable and its types.
But in Object-Oriented systems, there are the following additional dependencies:
 Class-to-class dependencies
 Class to method dependencies
 Class to message dependencies
 Class to variable dependencies
  Method to variable dependencies
 Method to message dependencies
 Method to method dependencies
Issues in Testing Classes:
Additional testing techniques are, therefore, required to test these dependencies.
Another issue of interest is that it is not possible to test the class dynamically, only
its instances i.e, objects can be tested. Similarly, the concept of inheritance opens
various issues e.g., if changes are made to a parent class or superclass, in a larger
system of a class it will be difficult to test subclasses individually and isolate the
error to one class. In object-oriented programs, control flow is characterized by
message passing among objects, and the control flow switches from one object to
another by inter-object communication. Consequently, there is no control flow
within a class like functions. This lack of sequential control flow within a class
requires different approaches for testing. Furthermore, in a function, arguments
passed to the function with global data determine the path of execution within the
procedure. But, in an object, the state associated with the object also influences the
path of execution, and methods of a class can communicate among themselves
through this state because this state is persistent across invocations of methods.
Hence, for testing objects, the state of an object has to play an important role.
Techniques of object-oriented testing are as follows:
1. Fault Based Testing: This type of checking permits for coming up with
test cases supported the consumer specification or the code or both. It
tries to identify possible faults (areas of design or code that may lead to
errors.). For all of these faults, a test case is developed to “flush” the
errors out. These tests also force each time of code to be executed. This
method of testing does not find all types of errors. However, incorrect
specification and interface errors can be missed. These types of errors
can be uncovered by function testing in the traditional testing model. In
the object-oriented model, interaction errors can be uncovered by
scenario-based testing. This form of Object oriented-testing can only test
against the client’s specifications, so interface errors are still missed.
2. Class Testing Based on Method Testing: This approach is the simplest
approach to test classes. Each method of the class performs a well
defined cohesive function and can, therefore, be related to unit testing of
the traditional testing techniques. Therefore all the methods of a class
can be involved at least once to test the class.
3. Random Testing: It is supported by developing a random test sequence
that tries the minimum variety of operations typical to the behavior of the
categories
4. Partition Testing: This methodology categorizes the inputs and outputs
of a category so as to check them severely. This minimizes the number
of cases that have to be designed.
 5. Scenario-based Testing: It primarily involves capturing the user actions
then stimulating them to similar actions throughout the test. These tests
tend to search out interaction form of error.
Purpose of Object Oriented Testing
1. Object Interaction Validation: Check to make sure objects interact
with one another appropriately in various situations. Testing makes
ensuring that the interactions between objects in object-oriented systems
result in the desired results.
2. Determining Design Errors: Find the object-oriented design’s
limitations and design faults. Testing ensures that the design complies
with the desired architecture by assisting in the identification of
problems with inheritance, polymorphism, encapsulation and other OOP
concepts.
3. Finding Integration Problems: Evaluate an object’s ability to integrate
and communicate with other objects when it is part of a bigger
component or subsystem. This helps in locating integration difficulties,
such improper method calls or issues with data exchange.
4. Assessment of Reusable Code: Evaluate object-oriented code’s
reusability. Code reuse is promoted by object-oriented programming via
features like inheritance and composition. Testing ensures that reusable
parts perform as intended in various scenarios.
5. Verification of Handling Exceptions: Confirm that objects respond
correctly to error circumstances and exceptions. The purpose of object-
oriented testing is to make sure that the software responds carefully and
is durable in the face of unforeseen occurrences or faults.
6. Verification of Uniformity: Maintain uniformity inside and between
objects and the object-oriented system as a whole. Maintainability and
readability are enhanced by consistency in naming standards, coding
styles and compliance to design patterns.

Testing Documentation
Testing documentation is the documentation of artifacts that are created during or
before the testing of a software application. Documentation reflects the importance
of processes for the customer, individual and organization.

Projects which contain all documents have a high level of maturity. Careful
documentation can save the time, efforts and wealth of the organization.
There is the necessary reference document, which is prepared by every test engineer
before stating the test execution process. Generally, we write the test document
whenever the developers are busy in writing the code.

Once the test document is ready, the entire test execution process depends on the
test document. The primary objective for writing a test document is to decrease or
eliminate the doubts related to the testing activities.

Types of test document

In software testing, we have various types of test document, which are as follows:

o Test scenarios
o Test case
o Test plan
o Requirement traceability matrix(RTM)
o Test strategy
o Test data
o Bug report
o Test execution report
Test Scenarios
It is a document that defines the multiple ways or combinations of testing the
application. Generally, it is prepared to understand the flow of an application. It does
not consist of any inputs and navigation steps.

For more information about test scenario, refers to the below link:

https://www.javatpoint.com/test-scenario

Test case
It is an in-details document that describes step by step procedure to test an
application. It consists of the complete navigation steps and inputs and all the
scenarios that need to be tested for the application. We will write the test case to
maintain the consistency, or every tester will follow the same approach for
organizing the test document.

For more information about test case, refers to the below link:

https://www.javatpoint.com/test-case

Test plan
It is a document that is prepared by the managers or test lead. It consists of all
information about the testing activities. The test plan consists of multiple
components such as Objectives, Scope, Approach, Test Environments, Test
methodology, Template, Role & Responsibility, Effort estimation, Entry and Exit
criteria, Schedule, Tools, Defect tracking, Test Deliverable, Assumption,
Risk, and Mitigation Plan or Contingency Plan.

For more information about the test plan, refers to the below link:

https://www.javatpoint.com/test-plan

Requirement Traceability Matrix (RTM)

The Requirement traceability matrix [RTM] is a document which ensures that all the
test case has been covered. This document is created before the test execution
process to verify that we did not miss writing any test case for the particular
requirement.

For more information about RTM, refers to the below link:

https://www.javatpoint.com/traceability-matrix

AD

Test strategy
The test strategy is a high-level document, which is used to verify the test types
(levels) to be executed for the product and also describe that what kind of technique
has to be used and which module is going to be tested. The Project Manager can
approve it. It includes the multiple components such as documentation formats,
objective, test processes, scope, and customer communication strategy, etc. we
cannot modify the test strategy.
Test data
It is data that occurs before the test is executed. It is mainly used when we are
implementing the test case. Mostly, we will have the test data in the Excel sheet
format and entered manually while performing the test case.

The test data can be used to check the expected result, which means that when the
test data is entered, the expected outcome will meet the actual result and also check
the application performance by entering the in-correct input data.

Bug report
The bug report is a document where we maintain a summary of all the bugs which
occurred during the testing process. This is a crucial document for both the
developers and test engineers because, with the help of bug reports, they can easily
track the defects, report the bug, change the status of bugs which are fixed
successfully, and also avoid their repetition in further process.

Test execution report

It is the document prepared by test leads after the entire testing execution process is
completed. The test summary report defines the constancy of the product, and it
contains information like the modules, the number of written test cases, executed,
pass, fail, and their percentage. And each module has a separate spreadsheet of their
respective module.

AD

Why documentation is needed

If the testing or development team gets software that is not working correctly and
developed by someone else, so to find the error, the team will first need a document.
Now, if the documents are available then the team will quickly find out the cause of
the error by examining documentation. But, if the documents are not available then
the tester need to do black box and white box testing again, which will waste the
time and money of the organization.More than that, Lack of documentation becomes
a problem for acceptance.

Example
Let's take a real-time example of Microsoft, Microsoft launch every product with
proper user guidelines and documents, which are very explanatory, logically
consistent and easy to understand for any user. These are all the reasons behind their
successful products.

AD

Benefits of using Documentation

o Documentation clarifies the quality of methods and objectives.
o It ensures internal coordination when a customer uses software application.
o It ensures clarity about the stability of tasks and performance.
o It provides feedback on preventive tasks.
o It provides feedback for your planning cycle.
o It creates objective evidence for the performance of the quality management system.
o If we write the test document, we can't forget the values which we put in the first
phase.
o It is also a time-saving process because we can easily refer to the text document.
o It is also consistent because we will test on the same value.

AD

The drawback of the test document

o It is a bit tedious because we have to maintain the modification provided by the

customer and parallel change in the document.
o If the test documentation is not proper, it will replicate the quality of the application.
o Sometimes it is written by that person who does not have the product knowledge.
o Sometimes the cost of the document will be exceeding its value.

Risk Management Activities

Risk management consists of three main activities, as shown in fig:
Risk Assessment
The objective of risk assessment is to division the risks in the condition of their loss,
causing potential. For risk assessment, first, every risk should be rated in two
methods:

o The possibility of a risk coming true (denoted as r).

o The consequence of the issues relates to that risk (denoted as s).

Based on these two methods, the priority of each risk can be estimated:

p=r*s

Where p is the priority with which the risk must be controlled, r is the probability of
the risk becoming true, and s is the severity of loss caused due to the risk becoming
true. If all identified risks are set up, then the most likely and damaging risks can be
controlled first, and more comprehensive risk abatement methods can be designed
for these risks.

1. Risk Identification: The project organizer needs to anticipate the risk in the
project as early as possible so that the impact of risk can be reduced by making
effective risk management planning.

A project can be of use by a large variety of risk. To identify the significant risk, this
might affect a project. It is necessary to categories into the different risk of classes.
There are different types of risks which can affect a software project:

1. Technology risks: Risks that assume from the software or hardware

technologies that are used to develop the system.
2. People risks: Risks that are connected with the person in the development
team.
3. Organizational risks: Risks that assume from the organizational environment
where the software is being developed.
4. Tools risks: Risks that assume from the software tools and other support
software used to create the system.
5. Requirement risks: Risks that assume from the changes to the customer
requirement and the process of managing the requirements change.
6. Estimation risks: Risks that assume from the management estimates of the
resources required to build the system

2. Risk Analysis: During the risk analysis process, you have to consider every
identified risk and make a perception of the probability and seriousness of that risk.

There is no simple way to do this. You have to rely on your perception and
experience of previous projects and the problems that arise in them.

It is not possible to make an exact, the numerical estimate of the probability and
seriousness of each risk. Instead, you should authorize the risk to one of several
bands:

1. The probability of the risk might be determined as very low (0-10%), low (10-
25%), moderate (25-50%), high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the
survival of the plan), serious (would cause significant delays), tolerable (delays
are within allowed contingency), or insignificant.

Risk Control
It is the process of managing risks to achieve desired outcomes. After all, the
identified risks of a plan are determined; the project must be made to include the
most harmful and the most likely risks. Different risks need different containment
methods. In fact, most risks need ingenuity on the part of the project manager in
tackling the risk.

There are three main methods to plan for risk management:

 1. Avoid the risk: This may take several ways such as discussing with the client
to change the requirements to decrease the scope of the work, giving
incentives to the engineers to avoid the risk of human resources turnover, etc.
2. Transfer the risk: This method involves getting the risky element developed
by a third party, buying insurance cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk.
For instance, if there is a risk that some key personnel might leave, new
recruitment can be planned.

Risk Leverage: To choose between the various methods of handling risk, the project
plan must consider the amount of controlling the risk and the corresponding
reduction of risk. For this, the risk leverage of the various risks can be estimated.

Risk leverage is the variation in risk exposure divided by the amount of reducing the
risk.

Risk leverage = (risk exposure before reduction - risk exposure after

reduction) / (cost of reduction)

1. Risk planning: The risk planning method considers each of the key risks that have
been identified and develop ways to maintain these risks.

AD

For each of the risks, you have to think of the behavior that you may take to
minimize the disruption to the plan if the issue identified in the risk occurs.

You also should think about data that you might need to collect while monitoring
the plan so that issues can be anticipated.

Again, there is no easy process that can be followed for contingency planning. It rely
on the judgment and experience of the project manager.

2. Risk Monitoring: Risk monitoring is the method king that your assumption about
the product, process, and business risks has not changed.

Risk Mitigation, Monitoring, and

Management (RMMM) plan
Last Updated : 22 Mar, 2021



RMMM Plan :
A risk management technique is usually seen in the software Project plan. This can
be divided into Risk Mitigation, Monitoring, and Management Plan (RMMM). In
this plan, all works are done as part of risk analysis. As part of the overall project
plan project manager generally uses this RMMM plan.
In some software teams, risk is documented with the help of a Risk Information
Sheet (RIS). This RIS is controlled by using a database system for easier
management of information i.e creation, priority ordering, searching, and other
analysis. After documentation of RMMM and start of a project, risk mitigation and
monitoring steps will start.
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

1. To check if predicted risks occur or not.

2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the
project.
Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This task is
done by Project manager when risk becomes reality and causes severe problems. If
the project manager effectively uses project mitigation to remove risks successfully
then it is easier to manage the risks. This shows that the response that will be taken
for each risk by a manager. The main objective of the risk management plan is the
risk register. This risk register describes and focuses on the predicted threats to a
software project.

Example:
Let us understand RMMM with the help of an example of high staff turnover.
Risk Mitigation:
To mitigate this risk, project management must develop a strategy for reducing
turnover. The possible steps to be taken are:
 Meet the current staff to determine causes for turnover (e.g., poor
working conditions, low pay, competitive job market).
 Mitigate those causes that are under our control before the project starts.
  Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
 Organize project teams so that information about each development
activity is widely dispersed.
 Define documentation standards and establish mechanisms to ensure that
documents are developed in a timely manner.
 Assign a backup staff member for every critical technologist.
Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project manager
monitors factors that may provide an indication of whether the risk is becoming
more or less likely. In the case of high staff turnover, the following factors can be
monitored:
 General attitude of team members based on project pressures.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
Risk Management:
Risk management and contingency planning assumes that mitigation efforts have
failed and that the risk has become a reality. Continuing the example, the project is
well underway, and a number of people announce that they will be leaving. If the
mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team. In addition, the
project manager may temporarily refocus resources (and readjust the project
schedule) to those functions that are fully staffed, enabling newcomers who must
be added to the team to “get up to the speed“.
Drawbacks of RMMM:
 It incurs additional project costs.
 It takes additional time.
 For larger projects, implementing an RMMM may itself turn out to be
another tedious project.
 RMMM does not guarantee a risk-free project, infact, risks may also
come up after the project is delivered.