Software Testing

What is Testing?
Testing is the process of evaluating a system or its component(s) with the intent to find whether it
satisfies the specified requirements or not. In simple words, testing is executing a system in order to
identify any gaps, errors, or missing requirements in contrary to the actual requirements.
According to ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing a
software item to detect the differences between existing and required conditions (that is
defects/errors/bugs) and to evaluate the features of the software item.

Who does Testing?

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

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

When to Start Testing?

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

It also depends on the development model that is being used. For example, in the Waterfall model,
formal testing is conducted in the testing phase; but in the incremental model, testing is performed at
the end of every increment/iteration and the whole application is tested at the end.
Testing is done in different forms at every phase of SDLC −
 During the requirement gathering phase, the analysis and verification of requirements are also
considered as testing.
 Reviewing the design in the design phase with the intent to improve the design is also
considered as testing.
 Testing performed by a developer on completion of the code is also categorized as testing.
When to Stop Testing?
It is difficult to determine when to stop testing, as testing is a never-ending process and no one can
claim that a software is 100% tested. The following aspects are to be considered for stopping the
testing process −
 Testing Deadlines
 Completion of test case execution
 Completion of functional and code coverage to a certain point
 Bug rate falls below a certain level and no high-priority bugs are identified
 Management decision

Verification & Validation

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

Sr.No Verification Validation

.

1 Verification addresses the concern: "Are Validation addresses the concern:

you building it right?" "Are you building the right thing?"

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

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

4 Done by developers. Done by testers.

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

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

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

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

Software Testing - Myths

Given below are some of the most common myths about software testing.

Myth 1: Testing is Too Expensive

Reality − There is a saying, pay less for testing during software development or pay more for
maintenance or correction later. Early testing saves both time and cost in many aspects, however
reducing the cost without testing may result in improper design of a software application rendering
the product useless.
Myth 2: Testing is Time-Consuming
Reality − During the SDLC phases, testing is never a time-consuming process. However diagnosing
and fixing the errors identified during proper testing is a time-consuming but productive activity.

Myth 3: Only Fully Developed Products are Tested

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

Myth 4: Complete Testing is Possible

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

Myth 5: A Tested Software is Bug-Free

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

Myth 6: Missed Defects are due to Testers

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

Myth 7: Testers are Responsible for Quality of Product

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

Myth 8: Test Automation should be used wherever possible to

Reduce Time
Reality − Yes, it is true that Test Automation reduces the testing time, but it is not possible to start
test automation at any time during software development. Test automaton should be started when
the software has been manually tested and is stable to some extent. Moreover, test automation can
never be used if requirements keep changing.
Myth 9: Anyone can Test a Software Application
Reality − People outside the IT industry think and even believe that anyone can test a software and
testing is not a creative job. However testers know very well that this is a myth. Thinking alternative
scenarios, try to crash a software with the intent to explore potential bugs is not possible for the
person who developed it.

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

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

Software Testing - QA, QC & Testing

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

Quality Assurance Quality Control Testing

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

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

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

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

activities.

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

It is a subset of Software Test QC can be considered as the Testing is the subset of

Life Cycle (STLC). subset of Quality Assurance. Quality Control.

Audit and Inspection

Audit − It is a systematic process to determine how the actual testing process is conducted within an
organization or a team. Generally, it is an independent examination of processes involved during the
testing of a software. As per IEEE, it is a review of documented processes that organizations
implement and follow. Types of audit include Legal Compliance Audit, Internal Audit, and System
Audit.
Inspection − It is a formal technique that involves formal or informal technical reviews of any artifact
by identifying any error or gap. As per IEEE94, inspection is a formal evaluation technique in which
software requirements, designs, or codes are examined in detail by a person or a group other than
the author to detect faults, violations of development standards, and other problems.
Formal inspection meetings may include the following processes: Planning, Overview Preparation,
Inspection Meeting, Rework, and Follow-up.

Testing and Debugging

Testing − It involves identifying bug/error/defect in a software without correcting it. Normally
professionals with a quality assurance background are involved in bugs identification. Testing is
performed in the testing phase.
Debugging − It involves identifying, isolating, and fixing the problems/bugs. Developers who code
the software conduct debugging upon encountering an error in the code. Debugging is a part of
White Box Testing or Unit Testing. Debugging can be performed in the development phase while
conducting Unit Testing or in phases while fixing the reported bugs.

Software Testing - Methods

There are different methods that can be used for software testing. This chapter briefly describes the
methods available.

Black-Box Testing
The technique of testing without having any knowledge of the interior workings of the application is
called black-box testing. The tester is oblivious to the system architecture and does not have access
to the source code. Typically, while performing a black-box test, a tester will interact with the
system's user interface by providing inputs and examining outputs without knowing how and where
the inputs are worked upon.
The following table lists the advantages and disadvantages of black-box testing.

Advantages Disadvantages

Well suited and efficient for large code segments. Limited coverage, since only a
selected number of test scenarios is
actually performed.

Code access is not required. Inefficient testing, due to the fact that
the tester only has limited knowledge
about an application.

Clearly separates user's perspective from the Blind coverage, since the tester
developer's perspective through visibly defined roles. cannot target specific code segments
or errorprone areas.

Large numbers of moderately skilled testers can test The test cases are difficult to design.
the application with no knowledge of implementation,
 programming language, or operating systems.

White-Box Testing
White-box testing is the detailed investigation of internal logic and structure of the code. White-box
testing is also called glass testing or open-box testing. In order to perform white-box testing on
an application, a tester needs to know the internal workings of the code.
The tester needs to have a look inside the source code and find out which unit/chunk of the code is
behaving inappropriately.
The following table lists the advantages and disadvantages of white-box testing.

Advantages Disadvantages

As the tester has knowledge of the source Due to the fact that a skilled tester is needed
code, it becomes very easy to find out which to perform white-box testing, the costs are
type of data can help in testing the increased.
application effectively.

It helps in optimizing the code. Sometimes it is impossible to look into every

nook and corner to find out hidden errors that
may create problems, as many paths will go
untested.

Extra lines of code can be removed which It is difficult to maintain white-box testing, as it
can bring in hidden defects. requires specialized tools like code analyzers
and debugging tools.

Due to the tester's knowledge about the

code, maximum coverage is attained during
test scenario writing.

A Comparison of Testing Methods

The following table lists the points that differentiate black-box testing, grey-box testing, and white-
box testing.

Black-Box Testing White-Box Testing

The internal workings of an Tester has full knowledge

application need not be of the internal workings of
known. the application.

Also known as closed-box Also known as clear-box

testing, data-driven testing, or testing, structural testing,
functional testing. or code-based testing.

Performed by end-users and Normally done by testers

also by testers and and developers.
developers.
 Testing is based on external Internal workings are fully
expectations - Internal known and the tester can
behavior of the application is design test data
unknown. accordingly.

It is exhaustive and the least The most exhaustive and

time-consuming. time-consuming type of
testing.

Not suited for algorithm Suited for algorithm

testing. testing.

This can only be done by Data domains and internal

trial-and-error method. boundaries can be better
tested.

Software Testing - Levels

There are different levels during the process of testing. In this chapter, a brief description is provided
about these levels.
Levels of testing include different methodologies that can be used while conducting software testing.
The main levels of software testing are −
 Functional Testing
 Non-functional Testing

Functional Testing
This is a type of black-box testing that is based on the specifications of the software that is to be
tested. The application is tested by providing input and then the results are examined that need to
conform to the functionality it was intended for. Functional testing of a software is conducted on a
complete, integrated system to evaluate the system's compliance with its specified requirements.
There are five steps that are involved while testing an application for functionality.

Steps Description

I The determination of the functionality that the intended application is meant to

perform.

II The creation of test data based on the specifications of the application.

III The output based on the test data and the specifications of the application.

IV The writing of test scenarios and the execution of test cases.

V The comparison of actual and expected results based on the executed test cases.

An effective testing practice will see the above steps applied to the testing policies of every
organization and hence it will make sure that the organization maintains the strictest of standards
when it comes to software quality.
Unit Testing
This type of testing is performed by developers before the setup is handed over to the testing team
to formally execute the test cases. Unit testing is performed by the respective developers on the
individual units of source code assigned areas. The developers use test data that is different from
the test data of the quality assurance team.
The goal of unit testing is to isolate each part of the program and show that individual parts are
correct in terms of requirements and functionality.

Limitations of Unit Testing

Testing cannot catch each and every bug in an application. It is impossible to evaluate every
execution path in every software application. The same is the case with unit testing.
There is a limit to the number of scenarios and test data that a developer can use to verify a source
code. After having exhausted all the options, there is no choice but to stop unit testing and merge
the code segment with other units.

Integration Testing
Integration testing is defined as the testing of combined parts of an application to determine if they
function correctly. Integration testing can be done in two ways: Bottom-up integration testing and
Top-down integration testing.

Sr.No Integration Testing Method

.

1
Bottom-up integration
This testing begins with unit testing, followed by tests of progressively higher-
level combinations of units called modules or builds.

2
Top-down integration
In this testing, the highest-level modules are tested first and progressively, lower-
level modules are tested thereafter.

In a comprehensive software development environment, bottom-up testing is usually done first,

followed by top-down testing. The process concludes with multiple tests of the complete application,
preferably in scenarios designed to mimic actual situations.

System Testing
System testing tests the system as a whole. Once all the components are integrated, the application
as a whole is tested rigorously to see that it meets the specified Quality Standards. This type of
testing is performed by a specialized testing team.
System testing is important because of the following reasons −
 System testing is the first step in the Software Development Life Cycle, where the application
is tested as a whole.
  The application is tested thoroughly to verify that it meets the functional and technical
specifications.
 The application is tested in an environment that is very close to the production environment
where the application will be deployed.
 System testing enables us to test, verify, and validate both the business requirements as well
as the application architecture.

Regression Testing
Whenever a change in a software application is made, it is quite possible that other areas within the
application have been affected by this change. Regression testing is performed to verify that a fixed
bug hasn't resulted in another functionality or business rule violation. The intent of regression testing
is to ensure that a change, such as a bug fix should not result in another fault being uncovered in the
application.
Regression testing is important because of the following reasons −
 Minimize the gaps in testing when an application with changes made has to be tested.
 Testing the new changes to verify that the changes made did not affect any other area of the
application.
 Mitigates risks when regression testing is performed on the application.
 Test coverage is increased without compromising timelines.
 Increase speed to market the product.

Acceptance Testing
This is arguably the most important type of testing, as it is conducted by the Quality Assurance
Team who will gauge whether the application meets the intended specifications and satisfies the
client’s requirement. The QA team will have a set of pre-written scenarios and test cases that will be
used to test the application.
More ideas will be shared about the application and more tests can be performed on it to gauge its
accuracy and the reasons why the project was initiated. Acceptance tests are not only intended to
point out simple spelling mistakes, cosmetic errors, or interface gaps, but also to point out any bugs
in the application that will result in system crashes or major errors in the application.
By performing acceptance tests on an application, the testing team will reduce how the application
will perform in production. There are also legal and contractual requirements for acceptance of the
system.

Alpha Testing
This test is the first stage of testing and will be performed amongst the teams (developer and QA
teams). Unit testing, integration testing and system testing when combined together is known as
alpha testing. During this phase, the following aspects will be tested in the application −
 Spelling Mistakes
 Broken Links
 Cloudy Directions
 The Application will be tested on machines with the lowest specification to test loading times
and any latency problems.
Beta Testing
This test is performed after alpha testing has been successfully performed. In beta testing, a sample
of the intended audience tests the application. Beta testing is also known as pre-release testing.
Beta test versions of software are ideally distributed to a wide audience on the Web, partly to give
the program a "real-world" test and partly to provide a preview of the next release. In this phase, the
audience will be testing the following −
 Users will install, run the application and send their feedback to the project team.
 Typographical errors, confusing application flow, and even crashes.
 Getting the feedback, the project team can fix the problems before releasing the software to
the actual users.
 The more issues you fix that solve real user problems, the higher the quality of your
application will be.
 Having a higher-quality application when you release it to the general public will increase
customer satisfaction.

Non-Functional Testing
This section is based upon testing an application from its non-functional attributes. Non-functional
testing involves testing a software from the requirements which are nonfunctional in nature but
important such as performance, security, user interface, etc.
Some of the important and commonly used non-functional testing types are discussed below.

Performance Testing
It is mostly used to identify any bottlenecks or performance issues rather than finding bugs in a
software. There are different causes that contribute in lowering the performance of a software −
 Network delay
 Client-side processing
 Database transaction processing
 Load balancing between servers
 Data rendering
Performance testing is considered as one of the important and mandatory testing type in terms of
the following aspects −
 Speed (i.e. Response Time, data rendering and accessing)
 Capacity
 Stability
 Scalability
Performance testing can be either qualitative or quantitative and can be divided into different sub-
types such as Load testing and Stress testing.

Load Testing
It is a process of testing the behavior of a software by applying maximum load in terms of software
accessing and manipulating large input data. It can be done at both normal and peak load
conditions. This type of testing identifies the maximum capacity of software and its behavior at peak
time.
Most of the time, load testing is performed with the help of automated tools such as Load Runner,
AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load
Test, etc.
Virtual users (VUsers) are defined in the automated testing tool and the script is executed to verify
the load testing for the software. The number of users can be increased or decreased concurrently
or incrementally based upon the requirements.

Stress Testing
Stress testing includes testing the behavior of a software under abnormal conditions. For example, it
may include taking away some resources or applying a load beyond the actual load limit.
The aim of stress testing is to test the software by applying the load to the system and taking over
the resources used by the software to identify the breaking point. This testing can be performed by
testing different scenarios such as −
 Shutdown or restart of network ports randomly
 Turning the database on or off
 Running different processes that consume resources such as CPU, memory, server, etc.

Usability Testing
Usability testing is a black-box technique and is used to identify any error(s) and improvements in
the software by observing the users through their usage and operation.
According to Nielsen, usability can be defined in terms of five factors, i.e. efficiency of use, learn-
ability, memory-ability, errors/safety, and satisfaction. According to him, the usability of a product will
be good and the system is usable if it possesses the above factors.
Nigel Bevan and Macleod considered that usability is the quality requirement that can be measured
as the outcome of interactions with a computer system. This requirement can be fulfilled and the
end-user will be satisfied if the intended goals are achieved effectively with the use of proper
resources.
Molich in 2000 stated that a user-friendly system should fulfill the following five goals, i.e., easy to
Learn, easy to remember, efficient to use, satisfactory to use, and easy to understand.
In addition to the different definitions of usability, there are some standards and quality models and
methods that define usability in the form of attributes and sub-attributes such as ISO-9126, ISO-
9241-11, ISO-13407, and IEEE std.610.12, etc.

UI vs Usability Testing
UI testing involves testing the Graphical User Interface of the Software. UI testing ensures that the
GUI functions according to the requirements and tested in terms of color, alignment, size, and other
properties.
On the other hand, usability testing ensures a good and user-friendly GUI that can be easily
handled. UI testing can be considered as a sub-part of usability testing.

Security Testing
Security testing involves testing a software in order to identify any flaws and gaps from security and
vulnerability point of view. Listed below are the main aspects that security testing should ensure −
  Confidentiality
 Integrity
 Authentication
 Availability
 Authorization
 Non-repudiation
 Software is secure against known and unknown vulnerabilities
 Software data is secure
 Software is according to all security regulations
 Input checking and validation
 SQL insertion attacks
 Injection flaws
 Session management issues
 Cross-site scripting attacks
 Buffer overflows vulnerabilities
 Directory traversal attacks

Portability Testing
Portability testing includes testing a software with the aim to ensure its reusability and that it can be
moved from another software as well. Following are the strategies that can be used for portability
testing −
 Transferring an installed software from one computer to another.
 Building executable (.exe) to run the software on different platforms.
Portability testing can be considered as one of the sub-parts of system testing, as this testing type
includes overall testing of a software with respect to its usage over different environments. Computer
hardware, operating systems, and browsers are the major focus of portability testing. Some of the
pre-conditions for portability testing are as follows −
 Software should be designed and coded, keeping in mind the portability requirements.
 Unit testing has been performed on the associated components.
 Integration testing has been performed.
 Test environment has been established.
Software Testing - Documentation
Testing documentation involves the documentation of artifacts that should be developed before or
during the testing of Software.
Documentation for software testing helps in estimating the testing effort required, test coverage,
requirement tracking/tracing, etc. This section describes some of the commonly used documented
artifacts related to software testing such as −

 Test Plan
 Test Scenario
 Test Case
 Traceability Matrix
Test Plan
A test plan outlines the strategy that will be used to test an application, the resources that will be
used, the test environment in which testing will be performed, and the limitations of the testing and
the schedule of testing activities. Typically the Quality Assurance Team Lead will be responsible for
writing a Test Plan.
A test plan includes the following −

 Introduction to the Test Plan document

 Assumptions while testing the application
 List of test cases included in testing the application
 List of features to be tested
 What sort of approach to use while testing the software
 List of deliverables that need to be tested
 The resources allocated for testing the application
 Any risks involved during the testing process
 A schedule of tasks and milestones to be achieved

Test Scenario
It is a one line statement that notifies what area in the application will be tested. Test scenarios are
used to ensure that all process flows are tested from end to end. A particular area of an application
can have as little as one test scenario to a few hundred scenarios depending on the magnitude and
complexity of the application.
The terms 'test scenario' and 'test cases' are used interchangeably, however a test scenario has
several steps, whereas a test case has a single step. Viewed from this perspective, test scenarios
are test cases, but they include several test cases and the sequence that they should be executed.
Apart from this, each test is dependent on the output from the previous test.
Test Case
Test cases involve a set of steps, conditions, and inputs that can be used while performing testing
tasks. The main intent of this activity is to ensure whether a software passes or fails in terms of its
functionality and other aspects. There are many types of test cases such as functional, negative,
error, logical test cases, physical test cases, UI test cases, etc.
Furthermore, test cases are written to keep track of the testing coverage of a software. Generally,
there are no formal templates that can be used during test case writing. However, the following
components are always available and included in every test case −

 Test case ID
 Product module
 Product version
 Revision history
 Purpose
 Assumptions
 Pre-conditions
 Steps
 Expected outcome
 Actual outcome
 Post-conditions
Many test cases can be derived from a single test scenario. In addition, sometimes multiple test
cases are written for a single software which are collectively known as test suites.

Test Case
The test case is defined as a group of conditions under which a tester determines whether a software
application is working as per the customer's requirements or not. Test case designing includes
preconditions, case name, input conditions, and expected result. A test case is a first level action and
derived from test scenarios.
It is an in-details document that contains all possible inputs (positive as well as negative) and the
navigation steps, which are used for the test execution process. Writing of test cases is a one-time
attempt that can be used in the future at the time of regression testing.

Test case gives detailed information about testing strategy, testing process, preconditions, and
expected output. These are executed during the testing process to check whether the software
application is performing the task for that it was developed or not.

Test case helps the tester in defect reporting by linking defect with test case ID. Detailed test case
documentation works as a full proof guard for the testing team because if developer missed
something, then it can be caught during execution of these full-proof test cases.

To write the test case, we must have the requirements to derive the inputs, and the test scenarios
must be written so that we do not miss out on any features for testing. Then we should have the test
case template to maintain the uniformity, or every test engineer follows the same approach to
prepare the test document.

Generally, we will write the test case whenever the developer is busy in writing the code.

When do we write a test case?

We will write the test case when we get the following:

o When the customer gives the business needs then, the developer starts developing and says
that they need 3.5 months to build this product.
o And In the meantime, the testing team will start writing the test cases.
o Once it is done, it will send it to the Test Lead for the review process.
o And when the developers finish developing the product, it is handed over to the testing
team.
o The test engineers never look at the requirement while testing the product document
because testing is constant and does not depends on the mood of the person rather than the
quality of the test engineer.

Note: When writing the test case, the actual result should never be written as the product is still being in
the development process. That?s why the actual result should be written only after the execution of the
test cases.

Why we write the test cases?

We will write the test for the following reasons:

o To require consistency in the test case execution

 o To make sure a better test coverage
o It depends on the process rather than on a person
o To avoid training for every new test engineer on the product

To require consistency in the test case execution: we will see the test case and start testing the
application.

To make sure a better test coverage: for this, we should cover all possible scenarios and document
it, so that we need not remember all the scenarios again and again.

It depends on the process rather than on a person: A test engineer has tested an application
during the first release, second release, and left the company at the time of third release. As the test
engineer understood a module and tested the application thoroughly by deriving many values. If the
person is not there for the third release, it becomes difficult for the new person. Hence all the
derived values are documented so that it can be used in the future.

To avoid giving training for every new test engineer on the product: When the test engineer
leaves, he/she leaves with a lot of knowledge and scenarios. Those scenarios should be documented
so that the new test engineer can test with the given scenarios and also can write the new scenarios.

Note: when the developers are developing the first product for the First release, the test engineer writes
the test cases. And in the second release, when the new features are added, the test engineer writes the
test cases for that also, and in the next release, when the elements are modified, the test engineer will
change the test cases or writes the new test cases as well.

Types of test cases

We have a different kind of test cases, which are as follows:

o Function test cases

o Integration test cases
o System test cases

The functional test cases

Firstly, we check for which field we will write test cases and then describe accordingly.

In functional testing or if the application is data-driven, we require the input column else; it is a bit
time-consuming.

Rules to write functional test cases:

o In the expected results column, try to use should be or must be.

 o Highlight the Object names.
o We have to describe only those steps which we required the most; otherwise, we do not need
to define all the steps.
o To reduce the excess execution time, we will write steps correctly.
o Write a generic test case; do not try to hard code it.

Integration test case

In this, we should not write something which we already covered in the functional test cases, and
something we have written in the integration test case should not be written in the system test case
again.

Rules to write integration test cases

o Firstly, understand the product

o Identify the possible scenarios
o Write the test case based on the priority

When the test engineer writing the test cases, they may need to consider the following aspects:

If the test cases are in details:

o They will try to achieve maximum test coverage.

o All test case values or scenarios are correctly described.
o They will try to think about the execution point of view.
o The template which is used to write the test case must be unique.

Note: when we involve fewer numbers of steps or coverage is more, it should be the best test case, and
when these test cases are given to anyone, they will understand easily.

System test cases

We will write the system test cases for the end-to-end business flows. And we have the entire
modules ready to write the system test cases.

The process to write test cases

The method of writing a test case can be completed into the following steps, which are as below:
System study

In this, we will understand the application by looking at the requirements or the SRS, which is given
by the customer.

Identify all scenarios:

o When the product is launched, what are the possible ways the end-user may use the software
to identify all the possible ways.
 o I have documented all possible scenarios in a document, which is called test design/high-
level design.
o The test design is a record having all the possible scenarios.

Write test cases

Convert all the identified scenarios to test claims and group the scenarios related to their features,
prioritize the module, and write test cases by applying test case design techniques and use the
standard test case template, which means that the one which is decided for the project.

Review the test cases

Review the test case by giving it to the head of the team and, after that, fix the review feedback given
by the reviewer.

Test case approval

After fixing the test case based on the feedback, send it again for the approval.

Functional Testing:
It is a type of software testing which is used to verify the functionality of the software application,
whether the function is working according to the requirement specification. In functional testing,
each function tested by giving the value, determining the output, and verifying the actual output
with the expected value. Functional testing performed as black-box testing which is presented to
confirm that the functionality of an application or system behaves as we are expecting. It is done to
verify the functionality of the application.

Functional testing also called as black-box testing, because it focuses on application specification
rather than actual code. Tester has to test only the program rather than the system.

Goal of functional testing

The purpose of the functional testing is to check the primary entry function, necessarily usable
function, the flow of screen GUI. Functional testing displays the error message so that the user can
easily navigate throughout the application.

What is the process of functional testing?

Testers follow the following steps in the functional testing:

o Tester does verification of the requirement specification in the software application.

o After analysis, the requirement specification tester will make a plan.
 o After planning the tests, the tester will design the test case.
o After designing the test, case tester will make a document of the traceability matrix.
o The tester will execute the test case design.
o Analysis of the coverage to examine the covered testing area of the application.
o Defect management should do to manage defect resolving.

What to test in functional testing? Explain

The main objective of functional testing is checking the functionality of the software system. It
concentrates on:

o Basic Usability: Functional Testing involves the usability testing of the system. It checks
whether a user can navigate freely without any difficulty through screens.
o Accessibility: Functional testing test the accessibility of the function.
o Mainline function: It focuses on testing the main feature.
o Error Condition: Function

Explain the complete process to perform functional testing.

There are the following steps to perform functional testing:

o There is a need to understand the software requirement.

o Identify test input data
o Compute the expected outcome with the selected input values.
o Execute test cases
o Comparison between the actual and the computed result
o Here are the following types of functional testing.
o
 o

Introduction of Structural Testing

Another type of software testing technique is Structural testing, which is used to test
the internal design of the software or structure of the coding for the particular software.

In this testing, the development team members are included in the testing team to
execute the software's internal design. The working of structural testing is opposite
to Behavioral testing.

In other words, we can say that structural testing tests the different features of an application based
on its types.
Structural testing is also known as white-box testing, glass box testing, and clear-box testing.
Developers mostly implement it to identify the issue and fix them quickly.

The structural testing process requires an in-depth knowledge of the programming language and is
opposite to Functional Testing.

The knowledge of the code's internal executions and how the software is implemented is a necessity
for the test engineer to implement the structural testing.

Throughout the structural testing, the test engineer intends on how the software performs, and it can
be used at all levels of testing.

Types of Structural Testing

Structural testing is divided into four different categories, which are as follows:

o Mutation testing
o Data flow testing
o Control flow testing
o Slice-based testing

Advantages of Structural Testing

The benefits of Structural testing are as follows:

o Structural testing does not require a lot of manual work as it is an automated process.
o Structural testing is not a time-consuming process.
o All the early defects can easily be identified
o It removes the dead code (extra code) or statements easily.
o It provides easy coding and implementation.
o It delivers detailed testing of the software.

Disadvantages of Structural Testing

The drawback of the structural testing are as follows:

o To perform structural testing, in-depth knowledge of programming languages is required.

o Even though structural testing is automatic, it might turn out very difficult because it involves
training in the tool used for testing.
 o It is expensive in respect of money because sometimes resources are necessary to efficiently
perform structural testing.
o There is also a small chance that some commands, statements or branches could be missed
unintentionally.

Debugging
To launch an application into the market, it is very necessary to cross-check it multiple times so as to
deliver an error-free product.

When we talk about delivering a bug-free product, then our main concern is all about customer
satisfaction because if you are application is not up to the mark, then eventually it will demolish the
company's reputation in the market.

In this article, we are going to see what makes debugging stand out of the queue and how it is
different from software testing.

We will be discussing the following topics:

o What is Debugging
o Why do we need debugging?
o Steps involved in debugging
o Debugging strategies
o Tools required to debug

What is Debugging?

In the development process of any software, the software program is religiously tested, troubleshot,
and maintained for the sake of delivering bug-free products. There is nothing that is error-free in the
first go.

So, it's an obvious thing to which everyone will relate that as when the software is created, it contains
a lot of errors; the reason being nobody is perfect and getting error in the code is not an issue, but
avoiding it or not preventing it, is an issue!

All those errors and bugs are discarded regularly, so we can conclude that debugging is nothing but
a process of eradicating or fixing the errors contained in a software program.
Debugging works stepwise, starting from identifying the errors, analyzing followed by removing the
errors. Whenever a software fails to deliver the result, we need the software tester to test the
application and solve it.

Since the errors are resolved at each step of debugging in the software testing, so we can conclude
that it is a tiresome and complex task regardless of how efficient the result was.

Why do we need Debugging?

Debugging gets started when we start writing the code for the software program. It progressively
starts continuing in the consecutive stages to deliver a software product because the code gets
merged with several other programming units to form a software product.

Following are the benefits of Debugging:

o Debugging can immediately report an error condition whenever it occurs. It prevents

hampering the result by detecting the bugs in the earlier stage, making software
development stress-free and smooth.
o It offers relevant information related to the data structures that further helps in easier
interpretation.
o Debugging assist the developer in reducing impractical and disrupting information.
o With debugging, the developer can easily avoid complex one-use testing code to save time
and energy in software development.

Steps involved in Debugging

Following are the different steps that are involved in debugging:
1. Identify the Error: Identifying an error in a wrong may result in the wastage of time. It is
very obvious that the production errors reported by users are hard to interpret, and
sometimes the information we receive is misleading. Thus, it is mandatory to identify the
actual error.
2. Find the Error Location: Once the error is correctly discovered, you will be required to
thoroughly review the code repeatedly to locate the position of the error. In general, this
step focuses on finding the error rather than perceiving it.
3. Analyze the Error: The third step comprises error analysis, a bottom-up approach that starts
from the location of the error followed by analyzing the code. This step makes it easier to
comprehend the errors. Mainly error analysis has two significant goals, i.e., evaluation of
errors all over again to find existing bugs and postulating the uncertainty of incoming
collateral damage in a fix.
4. Prove the Analysis: After analyzing the primary bugs, it is necessary to look for some extra
errors that may show up on the application. By incorporating the test framework, the fourth
step is used to write automated tests for such areas.
5. Cover Lateral Damage: The fifth phase is about accumulating all of the unit tests for the
code that requires modification. As when you run these unit tests, they must pass.
6. Fix & Validate: The last stage is the fix and validation that emphasizes fixing the bugs
followed by running all the test scripts to check whether they pass.
Debugging Strategies
o For a better understanding of a system, it is necessary to study the system in depth. It makes
it easier for the debugger to fabricate distinct illustrations of such systems that are needed to
be debugged.
o The backward analysis analyzes the program from the backward location where the failure
message has occurred to determine the defect region. It is necessary to learn the area of
defects to understand the reason for defects.
o In the forward analysis, the program tracks the problem in the forward direction by utilizing
the breakpoints or print statements incurred at different points in the program. It emphasizes
those regions where the wrong outputs are obtained.
o To check and fix similar kinds of problems, it is recommended to utilize past experiences. The
success rate of this approach is directly proportional to the proficiency of the debugger.

Debugging Tools

The debugging tool can be understood as a computer program that is used to test and debug
several other programs. Presently, there are many public domain software such as gdb and dbx in
the market, which can be utilized for debugging. These software offers console-based command-line
interfaces. Some of the automated debugging tools include code-based tracers, profilers,
interpreters, etc.

Here is a list of some of the widely used debuggers:

o Radare2
o WinDbg
o Valgrind

Radare2

Radare2 is known for its reverse engineering framework as well as binary analysis. It is made up of a
small set of utilities, either utilized altogether or independently from the command line. It is also
known as r2.
It is constructed around disassembler for computer software for generating assembly language
source code from machine-executable code. It can support a wide range of executable formats for
distinct architectures of processors and operating systems.

WinDbg

WinDbg is a multipurpose debugging tool designed for Microsoft Windows operating system. This
tool can be used to debug the memory dumps created just after the Blue Screen of Death that
further arises when a bug check is issued. Besides, it is also helpful in debugging the user-mode
crash dumps, which is why it is called post-mortem debugging.

Valgrind

The Valgrind exist as a tool suite that offers several debugging and profiling tools to facilitate users
in making faster and accurate program. Memcheck is one of its most popular tools, which can
successfully detect memory-related errors caused in C and C++ programs as it may crash the
program and result in unpredictable behavior.

Software Reverse Engineering is a process of recovering the design, requirement

specifications, and functions of a product from an analysis of its code. It builds a program
database and generates information from this.
The purpose of reverse engineering is to facilitate the maintenance work by improving the
understandability of a system and producing the necessary documents for a legacy
system.
Reverse Engineering Goals:

 Cope with Complexity.

 Recover lost information.
 Detect side effects.
 Synthesise higher abstraction.
 Facilitate Reuse.
Steps of Software Reverse Engineering:

1. Collection Information:
This step focuses on collecting all possible information (i.e., source design documents,
etc.) about the software.

2. Examining the information:

The information collected in step-1 is studied so as to get familiar with the system.
3. Extracting the structure:
This step concerns identifying program structure in the form of a structure chart where
each node corresponds to some routine.

4. Recording the functionality:

During this step processing details of each module of the structure, charts are recorded
using structured language like decision table, etc.

5. Recording data flow:

From the information extracted in step-3 and step-4, a set of data flow diagrams is
derived to show the flow of data among the processes.

6. Recording control flow:

The high-level control structure of the software is recorded.

7. Review extracted design:

The design document extracted is reviewed several times to ensure consistency and
correctness. It also ensures that the design represents the program.

8. Generate documentation:
Finally, in this step, the complete documentation including SRS, design document,
history, overview, etc. is recorded for future use.
Software Re-engineering
Software Re-engineering is a process of software development which is done to improve the
maintainability of a software system. Re-engineering is the examination and alteration of a
system to reconstitute it in a new form. This process encompasses a combination of sub-
processes like reverse engineering, forward engineering, reconstructing etc.
Re-engineering, also known as reverse engineering or software re-engineering, is the process
of analyzing, designing, and modifying existing software systems to improve their quality,
performance, and maintainability. This can include updating the software to work with new
hardware or software platforms, adding new features, or improving the software’s overall
design and architecture.
Software re-engineering, also known as software restructuring or software renovation, refers
to the process of improving or upgrading existing software systems to improve their quality,
maintainability, or functionality. It involves reusing the existing software artifacts, such as
code, design, and documentation, and transforming them to meet new or updated
requirements.
The primary goal of software re-engineering is to improve the quality and maintainability of
the software system, while minimizing the risks and costs associated with the redevelopment
of the system from scratch. Software re-engineering can be initiated for various reasons, such
as:
1. Improving software quality: Re-engineering can help improve the quality of software by
eliminating defects, improving performance, and enhancing reliability and
maintainability.
2. Updating technology: Re-engineering can help modernize the software system by
updating the technology used to develop, test, and deploy the system.
3. Enhancing functionality: Re-engineering can help enhance the functionality of the
software system by adding new features or improving existing ones.
4. Resolving issues: Re-engineering can help resolve issues related to scalability,
security, or compatibility with other systems.
The process of software re-engineering involves the following steps:
1. Planning: The first step is to plan the re-engineering process, which involves identifying
the reasons for re-engineering, defining the scope, and establishing the goals and
objectives of the process.
2. Analysis: The next step is to analyze the existing system, including the code,
documentation, and other artifacts. This involves identifying the system’s strengths and
weaknesses, as well as any issues that need to be addressed.
3. Design: Based on the analysis, the next step is to design the new or updated software
system. This involves identifying the changes that need to be made and developing a
plan to implement them.
4. Implementation: The next step is to implement the changes by modifying the existing
code, adding new features, and updating the documentation and other artifacts.
5. Testing: Once the changes have been implemented, the software system needs to be
tested to ensure that it meets the new requirements and specifications.
6. Deployment: The final step is to deploy the re-engineered software system and make it
available to end-users.
Overall, software re-engineering can be a cost-effective way to improve the quality and
functionality of existing software systems, while minimizing the risks and costs associated
with starting from scratch.
Re-engineering can be done for a variety of reasons, such as:
To improve the software’s performance and scalability: By analyzing the existing code and
identifying bottlenecks, re-engineering can be used to improve the software’s performance
and scalability.
1. To add new features: Re-engineering can be used to add new features or
functionality to existing software.
2. To support new platforms: Re-engineering can be used to update existing software
to work with new hardware or software platforms.
3. To improve maintainability: Re-engineering can be used to improve the software’s
overall design and architecture, making it easier to maintain and update over time.
4. To meet new regulations and compliance: Re-engineering can be done to ensure
that the software is compliant with new regulations and standards.
5. Re-engineering can be a complex and time-consuming process, and it requires a
thorough understanding of the existing software system. It also requires a structured
and disciplined approach to software development, similar to software engineering.
6. Re-engineering can be beneficial in many cases, it can help to improve the quality,
performance, and maintainability of existing software systems, but it also has its own
drawbacks, such as:
7. High costs: Re-engineering can be a resource-intensive process and can require a
significant investment in tools and training.
8. Risk of introducing new bugs: Changing existing code can introduce new bugs and
compatibility issues.
9. High learning curve: Re-engineering can be complex, and it requires a lot of learning
and training, which can be challenging for new developers.
Software re-engineering, also known as software system re-engineering or software
renovation, is the process of transforming an existing software system into a new system
that meets the changing needs of users or business requirements. Re-engineering
involves analyzing the existing system, identifying its strengths and weaknesses, and
making changes to improve its overall quality, maintainability, and functionality.
The goals of software re-engineering include improving the maintainability, reliability, and
performance of the software system, reducing the cost of maintenance and support, and
extending the useful life of the system. Re-engineering can also involve updating the
technology stack or migrating the system to a new platform or architecture.

The process of software re-engineering typically involves the following

steps:

1. Assessment: The existing software system is analyzed to identify its strengths and
weaknesses, and to determine the extent of the required re-engineering effort.
2. Planning: A plan is developed to guide the re-engineering effort, including the
identification of goals, objectives, and performance metrics.
3. Requirements analysis: The requirements of the new system are defined based on
user needs and business requirements.
4. Architecture and design: The architecture and design of the new system are
developed, taking into account the requirements of the new system and the limitations
of the existing system.
5. Implementation: The new system is developed and implemented, either by modifying
the existing system or by developing a new system from scratch.
6. Testing: The new system is tested to ensure that it meets the requirements of the new
system and is free from errors and defects.
7. Maintenance: The new system is maintained over time to ensure that it remains
reliable, performant, and secure.

Advantages of software re-engineering include:

1. Improved system performance and reliability: Re-engineering can improve the

performance and reliability of the software system, making it more efficient and less
prone to errors or failures.
2. Reduced maintenance costs: Re-engineering can reduce the cost of maintaining and
supporting the software system over time, by improving its maintainability and reducing
the frequency of required maintenance activities.
3. Increased user satisfaction: Re-engineering can improve the usability and functionality
of the software system, enhancing user satisfaction and increasing adoption rates.

Disadvantages of software re-engineering include:

1. Increased development time and cost: Re-engineering requires significant time and
resources, which can increase development costs and delay time-to-market.
2. Risk of introducing new errors or defects: Re-engineering can introduce new errors or
defects into the software system if not done carefully and thoroughly.
3. Overall, software re-engineering can be an effective way to improve the quality and
functionality of an existing software system. However, it is important to carefully assess
the risks and benefits of re-engineering and to plan and execute the re-engineering
effort carefully to ensure a successful outcome.

Software Configuration Management

When we develop software, the product (software) undergoes many changes in their maintenance
phase; we need to handle these changes effectively.

Several individuals (programs) works together to achieve these common goals. This individual
produces several work product (SC Items) e.g., Intermediate version of modules or test data used
during debugging, parts of the final product.

The elements that comprise all information produced as a part of the software process are
collectively called a software configuration.

As software development progresses, the number of Software Configuration elements (SCI's) grow
rapidly.

These are handled and controlled by SCM. This is where we require software configuration
management.

A configuration of the product refers not only to the product's constituent but also to a particular
version of the component.

Therefore, SCM is the discipline which

o Identify change
o Monitor and control change
o Ensure the proper implementation of change made to the item.
o Auditing and reporting on the change made.

Configuration Management (CM) is a technic of identifying, organizing, and controlling modification

to software being built by a programming team.

The objective is to maximize productivity by minimizing mistakes (errors).

CM is used to essential due to the inventory management, library management, and updation
management of the items essential for the project.
Why do we need Configuration Management?
Multiple people are working on software which is consistently updating. It may be a method where
multiple version, branches, authors are involved in a software project, and the team is geographically
distributed and works concurrently. It changes in user requirements, and policy, budget, schedules
need to be accommodated.

Importance of SCM
It is practical in controlling and managing the access to various SCIs e.g., by preventing the two
members of a team for checking out the same component for modification at the same time.

It provides the tool to ensure that changes are being properly implemented.

It has the capability of describing and storing the various constituent of software.

SCM is used in keeping a system in a consistent state by automatically producing derived version
upon modification of the same component.

Software documentation is a written piece of text that is often accompanied by a

software program. This makes the life of all the members associated with the project
easier. It may contain anything from API documentation, build notes or just help content. It
is a very critical process in software development. It’s primarily an integral part of any
computer code development method. Moreover, computer code practitioners are a unit
typically concerned with the worth, degree of usage, and quality of the actual
documentation throughout the development and its maintenance throughout the total
method. Motivated by the requirements of Novatel opposition, a world-leading company
developing package in support of worldwide navigation satellite system, and based mostly
on the results of a former systematic mapping studies area unit aimed at a higher
understanding of the usage and therefore the quality of varied technical documents
throughout computer code development and their maintenance.
For example, before the development of any software product requirements are
documented which is called Software Requirement Specification (SRS). Requirement
gathering is considered a stage of Software Development Life Cycle (SDLC).
Another example can be a user manual that a user refers to for installing, using, and
providing maintenance to the software application/product.
Types Of Software Documentation :
1. Requirement Documentation: It is the description of how the software shall perform
and which environment setup would be appropriate to have the best out of it. These
are generated while the software is under development and is supplied to the tester
groups too.
2. Architectural Documentation: Architecture documentation is a special type of
documentation that concerns the design. It contains very little code and is more
focused on the components of the system, their roles, and working. It also shows the
data flow throughout the system.
3. Technical Documentation: These contain the technical aspects of the software like
API, algorithms, etc. It is prepared mostly for software devs.
4. End-user Documentation: As the name suggests these are made for the end user. It
contains support resources for the end user.
Purpose of Documentation :
Due to the growing importance of computer code necessities, the method of crucial them
needs to be effective so as to notice desired results. As the such determination of
necessities is often beneath sure regulation and pointers that area unit core in getting a
given goal.
These all imply that computer code necessities area unit expected to alter thanks to the
ever ever-changing technology within the world. however, the very fact that computer
code information id obtained through development has to be modified within the wants of
users and the transformation of the atmosphere area unit is inevitable.
what is more, computer code necessities ensure that there’s a verification and therefore
the testing method, in conjunction with prototyping and conferences there are focus teams
and observations?
For a software engineer reliable documentation is often a should the presence of
documentation helps keep track of all aspects of associate applications and it improves
the standard of wares, it’s the most focused area of unit development, maintenance, and
information transfer to alternative developers. productive documentation can build info
simply accessible, offer a restricted range of user entry purposes, facilitate new users to
learn quickly, alter the merchandise and facilitate chopping out the price.
Importance of software documentation :
For a programmer reliable documentation is always a must the presence keeps track of all
aspects of an application and helps in keeping the software updated.
Advantages of software documentation :
 The presence of documentation helps in keeping the track of all aspects of an
application and also improves the quality of the software product.
 The main focus is based on the development, maintenance, and knowledge transfer to
other developers.
 Helps development teams during development.
 Helps end-users in using the product.
 Improves overall quality of software product
 It cuts down duplicative work.
 Makes easier to understand code.
 Helps in establishing internal coordination in work.
Disadvantages of software documentation :
 The documenting code is time-consuming.
 The software development process often takes place under time pressure, due to
which many times the documentation updates don’t match the updated code.
 The documentation has no influence on the performance of an application.
 Documenting is not so fun, it’s sometimes boring to a certain extent.