What is Code Review

Code review is a systematic and collaborative process in software development where one or more developers

examine and evaluate another developer’s code to identify any issues, provide any feedback, and ensure that the

code meets quality standards. The primary goal is to improve the maintainability, quality, and reliability of the

codebase resulting in the overall success of a project while also promoting knowledge sharing and learning

among team members.

Why is Code Review important?

Code review is crucial in software development due to the following aspects:

 Bug Detection and Prevention: Code review helps detect and address errors, bugs, and issues in the

code before they propagate to production. This early detection significantly helps in reducing the cost

and effort required to fix problems later in the development process or after deployment.

 Improved Quality of Code: Code review encourages writing of clean, maintainable, and efficient code.

Reviewers can suggest enhancements, recommend best practices, and ensure that the code aligns with

the established coding standards and guidelines.

 Consistency: Code review enforces consistency in coding style and practices across the team which

makes the codebase easier to maintain and understand.

 Knowledge Sharing and Learning: Code reviews offer opportunities for knowledge sharing among

team members to learn from one another. Discussions during these reviews can help spread domain

knowledge and best practices.

 Code Ownership: Code reviewers take partial ownership of the code they review thereby encouraging

collective responsibility for the software’s quality.

  Collaboration: Reviewers can collaborate during the review process, discussing design decisions,

trade-offs, and alternative solutions which can lead to improved design decisions and more robust

solutions.

 Documentation: Code reviews can also serve as a form of documentation. Review comments and

discussions capture insights and decisions that may not be noticeable from the code itself.

 Quality Assurance: Code review is a critical part of quality assurance processes. By thoroughly

analyzing the code changes, teams can ensure that the software meets the functional requirements and

user expectations.

 Continuous Improvement: Teams can often use code review as a tool for continuous improvement. By

analyzing the patterns of the feedback of code review, teams can identify recurring issues and work on

addressing them through training or process improvements.

Software documentation
Software documentation is an essential component of every software project, but it may
be a difficult undertaking. It is time-consuming, and tiresome occasionally, yet not an
exciting aspect of developing new software. Nonetheless, it is critical for getting your
business off onto the ground.

Don't rely on guessing or replicating what others have done when creating your
company's first or hundred pieces of software documentation. Poor documentation for
software can turn off potential clients while also wasting corporate resources. Instead,
use best practices such as utilizing inside experience and minimizing jargon to create
technical documentation that elevates rather than degrades your program.

Unit Testing
Unit testing involves the testing of each unit or an individual component of the software
application. It is the first level of functional testing. The aim behind unit testing is to
validate unit components with its performance.

A unit is a single testable part of a software system and tested during the development
phase of the application software.

The purpose of unit testing is to test the correctness of isolated code. A unit component
is an individual function or code of the application. White box testing approach used for
unit testing and usually done by the developers.

Whenever the application is ready and given to the Test engineer, he/she will start
checking every component of the module or module of the application independently or
one by one, and this process is known as Unit testing or components testing
Black box testing
Black box testing is a technique of software testing which examines the functionality of
software without peering into its internal structure or coding. The primary source of black
box testing is a specification of requirements that is stated by the customer.

In this method, tester selects a function and gives input value to examine its
functionality, and checks whether the function is giving expected output or not. If the
function produces correct output, then it is passed in testing, otherwise failed. The test
team reports the result to the development team and then tests the next function. After
completing testing of all functions if there are severe problems, then it is given back to
the development team for correction.

Generic steps of black box testing

o The black box test is based on the specification of requirements, so it is examined

in the beginning.
o In the second step, the tester creates a positive test scenario and an adverse test
scenario by selecting valid and invalid input values to check that the software is
processing them correctly or incorrectly.
o In the third step, the tester develops various test cases such as decision table, all
pairs test, equivalent division, error estimation, cause-effect graph, etc.
o The fourth phase includes the execution of all test cases.
o In the fifth step, the tester compares the expected output against the actual
output.
o In the sixth and final step, if there is any flaw in the software, then it is cured and
tested again.

White Box Testing

The box testing approach of software testing consists of black box testing and white box
testing. We are discussing here white box testing which also known as glass box
is testing, structural testing, clear box testing, open box testing and
transparent box testing. It tests internal coding and infrastructure of a software focus
on checking of predefined inputs against expected and desired outputs. It is based on
inner workings of an application and revolves around internal structure testing. In this
type of testing programming skills are required to design test cases. 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.

The term 'white box' is used because of the internal perspective of the system. The clear
box or white box or transparent box name denote the ability to see through the
software's outer shell into its inner workings

he white box testing contains various tests, which are as follows:

o Path testing
o Loop testing
o Condition testing
o Testing based on the memory perspective
o Test performance of the program

Path testing
In the path testing, we will write the flow graphs and test all independent
paths. Here writing the flow graph implies that flow graphs are
 representing the flow of the program and also show how every program is
added with one another as we can see in the below image:

And test all the independent paths implies that suppose a path from
main() to function G, first set the parameters and test if the program is
correct in that particular path, and in the same way test all other paths
and fix the bugs.

Loop testing
In the loop testing, we will test the loops such as while, for, and do-while,
etc. and also check for ending condition if working correctly and if the size
of the conditions is enough.

For example: we have one program where the developers have given
about 50,000 loops.

1. {
2. while(50,000)
3. ……
4. ……
5. }
We cannot test this program manually for all the 50,000 loops cycle. So
we write a small program that helps for all 50,000 cycles, as we can see in
the below program, that test P is written in the similar language as the
source code program, and this is known as a Unit test. And it is written by
the developers only.

1. Test P
2. {
3. ……
4. …… }
As we can see in the below image that, we have various requirements
such as 1, 2, 3, 4. And then, the developer writes the programs such as
program 1,2,3,4 for the parallel conditions. Here the application contains
the 100s line of codes.
The developer will do the white box testing, and they will test all the five
programs line by line of code to find the bug. If they found any bug in any
of the programs, they will correct it. And they again have to test the
system then this process contains lots of time and effort and slows down
the product release time.

Now, suppose we have another case, where the clients want to modify the
requirements, then the developer will do the required changes and test all
four program again, which take lots of time and efforts.

These issues can be resolved in the following ways:

In this, we will write test for a similar program where the developer writes
these test code in the related language as the source code. Then they
execute these test code, which is also known as unit test programs.
These test programs linked to the main program and implemented as
programs.
 Therefore, if there is any requirement of modification or bug in the code,
then the developer makes the adjustment both in the main program and
the test program and then executes the test program.

Condition testing
In this, we will test all logical conditions for both true and false values;
that is, we will verify for both if and else condition.

For example:

1. if(condition) - true
2. {
3. …..
4. ……
5. ……
6. }
7. else - false
8. {
9. …..
10.……
11.……
12.}
The above program will work fine for both the conditions, which means
that if the condition is accurate, and then else should be false and
conversely.

Cyclomatic Complexity
Cyclomatic complexity is a software metric used to measure the complexity of a
program. Thomas J. McCabe developed this metric in 1976.McCabe interprets a computer
program as a set of a strongly connected directed graph. Nodes represent parts of the
source code having no branches and arcs represent possible control flow transfers during
program execution. The notion of program graph has been used for this measure, and it
is used to measure and control the number of paths through a program. The complexity
of a computer program can be correlated with the topological complexity of a graph.

How to Calculate Cyclomatic Complexity?

McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of
software complexity. The cyclomatic number is equal to the number of linearly
independent paths through a program in its graphs representation. For a program control
graph G, cyclomatic number, V (G), is given as:

V (G) = E - N + 2 * P

E = The number of edges in graphs G

N = The number of nodes in graphs G

P = The number of connected components in graph G.

Example:

Properties of Cyclomatic complexity:

Following are the properties of Cyclomatic complexity:

1. V (G) is the maximum number of independent paths in the graph

2. V (G) >=1
3. G will have one path if V (G) = 1
4. Minimize complexity to 10
5.

What is Code Coverage?

Code coverage is a metric that measures the percentage of a codebase executed during testing. It

helps to identify untested areas and improve software quality.In other words, it describes the degree

to which the coding of an application has been tested when a particular test suite runs. It is

considered one of the forms of White Box Testing and is usually performed by Developers during Unit
Testing.Code coverage scripts generate a report that lists how much of the application code has been

executed.

What is mutation testing?

Mutation testing is a white box method in software testing where we insert errors
purposely into a program (under test) to verify whether the existing test case can detect
the error or not. In this testing, the mutant of the program is created by making some
modifications to the original program.

What is mutation?

The mutation is a small modification in a program; these minor modifications are planned
to typical low-level errors which are happened at the time of coding process.

Generally, we deliberate the mutation operators in the form of rules which match the
data and also generate some efficient environment to produce the mutant.

Types of mutation testing

Mutation testing can be classified into three parts, which are as follows:

o Decision mutations
o value mutations
o Statement mutations

Debugging Techniques in Software Testing

Successful and efficient debugging not only requires technical proficiency, but it also requires you to apply the
right debugging technique to get the job done. Let’s explore some fundamental debugging techniques that play a
pivotal role in the software development process.

Backtracking
This technique involves the meticulous process of revisiting your code step by step to identify the sequence of
actions that led to a bug. Backtracking is particularly useful when the cause of the bug is unclear. By retracing
their steps, developers can gain insights into the code’s execution and understand the root of the issue.

Logging
Logging is a technique that incorporates strategically placed log statements within the code to capture the
program’s state, variable values, and execution flow. This method provides developers with a valuable tool for
understanding the sequence of events leading up to a bug. Analyzing logs can pinpoint the specific location of an
unexpected behavior, allowing your staff to find the right solution quickly.

Rubber Ducking
The name “rubber ducking” comes from the story of a programmer who would try to find the solution by
explaining his code to a rubber duck. Fortunately, you don’t need an actual rubber duck to use this strategy.
Instead, you can run through the exercise of explaining the code or problem aloud to an inanimate object or a
colleague. This method forces you to articulate your understanding of the problem, which can break you out of
your usual thought processes and take an objective view of the situation—which often leads to a solution.

Binary Search
Binary search is a powerful algorithmic technique that systematically narrows down the search space for a bug.
By strategically selecting test cases or input data, developers can efficiently identify the region of the code where
the bug is likely to be located. This technique is especially effective when dealing with large codebases.

Brute Force
Often used as a last resort debugging technique, brute force is a systematic approach that requires exhaustive
testing of different inputs or scenarios to identify the conditions triggering a bug. By continuously trying different
possibilities, developers can narrow down potential sources of the bug and eventually arrive at a solution.
However, this is typically the most tedious and time-consuming debugging technique in software testing.
Integration testing
Integration testing is the second level of the software testing process comes after unit
testing. In this testing, units or individual components of the software are tested in a
group. The focus of the integration testing level is to expose defects at the time of
interaction between integrated components or units.

Unit testing uses modules for testing purpose, and these modules are combined and
tested in integration testing. The Software is developed with a number of software
modules that are coded by different coders or programmers. The goal of integration
testing is to check the correctness of communication among all the modules.

System Testing
System Testing includes testing of a fully integrated software system. Generally, a
computer system is made with the integration of software (any software is only a single
element of a computer system). The software is developed in units and then interfaced
with other software and hardware to create a complete computer system. In other words,
a computer system consists of a group of software to perform the various tasks, but only
software cannot perform the task; for that software must be interfaced with compatible
hardware. System testing is a series of different type of tests with the purpose to
exercise and examine the full working of an integrated software computer system
against requirements.

Example of System testing

Suppose we open an application, let say www.rediff.com, and there we can see that an
advertisement is displayed on the top of the homepage, and it remains there for a few
seconds before it disappears. These types of Ads are done by the Advertisement
Management System (AMS). Now, we will perform system testing for this type of field.

The below application works in the following manner:

o Let's say that Amazon wants to display a promotion ad on January 26 at precisely

10:00 AM on the Rediff's home page for the country India.
o Then, the sales manager logs into the website and creates a request for an
advertisement dated for the above day.
o He/she attaches a file that likely an image files or the video file of the AD and
applies.
o The next day, the AMS manager of Rediffmail login into the application and
verifies the awaiting Ad request.
o The AMS manager will check those Amazons ad requests are pending, and then
he/she will check if the space is available for the particular date and time.
o If space is there, then he/she evaluate the cost of putting up the Ad at 15$ per
second, and the overall Ad cost for 10 seconds is approximate 150$.
o The AMS manager clicks on the payment request and sends the estimated value
along with the request for payment to the Amazon manager.
o Then the amazon manager login into the Ad status and confirms the payment
request, and he/she makes the payment as per all the details and clicks on
the Submit and Pay
o As soon as Rediff's AMs manager gets the amount, he/she will set up the
Advertisement for the specific date and time on the Rediffmail's home page.

What is Regression Testing?

Regression testing is a black box testing techniques. It is used to authenticate a code
change in the software does not impact the existing functionality of the product.
Regression testing is making sure that the product works fine with new
functionality, bug fixes, or any change in the existing feature.

Regression testing is a type of software testing. Test cases are re-executed to check the
previous functionality of the application is working fine, and the new changes have not
produced any bugs.

Regression testing can be performed on a new build when there is a significant change in
the original functionality. It ensures that the code still works even when the changes are
occurring. Regression means Re-test those parts of the application, which are
unchanged.

Regression tests are also known as the Verification Method. Test cases are often
automated. Test cases are required to execute many times and running the same test
case again and again manually, is time-consuming and tedious too.

Example of Regression testing

Here we are going to take a case to define the regression testing efficiently:

Consider a product Y, in which one of the functionality is to trigger confirmation,

acceptance, and dispatched emails. It also needs to be tested to ensure that the change
in the code not affected them. Regressing testing does not depend on any programming
language like Java, C++, C#, etc. This method is used to test the product for
modifications or any updates done. It ensures that any change in a product does not
affect the existing module of the product. Verify that the bugs fixed and the newly added
features not created any problem in the previous working version of the Software.

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.