SE REVIEWER

M6 – CI
Continuous Integration (CI)- is a development practice that requires developers to integrate
code into a shared repository several times a day. Each check-in is then verified by an automated
build, allowing teams to detect problems early.
Solve problems quickly
Because you’re integrating so frequently, there is significantly less back-tracking to discover
where things went wrong, so you can spend more time building features. Continuous Integration
is cheap. Not integrating continuously is expensive. If you don’t follow a continuous approach,
you’ll have longer periods between integrations. This makes it exponentially more difficult to
find and fix problems. Such integration problems can easily knock a project off-schedule, or
cause it to fail altogether. Continuous Integration brings multiple benefits to your organization:
• Say goodbye to long and tense integrations
• Increase visibility enabling greater communication
• Catch issues early and nip them in the bud
• Spend less time debugging and more time adding features
• Build a solid foundation
• Stop waiting to find out if your code’s going to work
• Reduce integration problems allowing you to deliver software more rapidly
Team responsibilities
• Check in frequently
• Don’t check in broken code
• Don’t check in untested code
• Don’t check in when the build is broken
• Don’t go home after checking in until the system builds
Many teams develop rituals around these policies, meaning the teams effectively manage
themselves, removing the need to enforce policies from on high.
Continuous Deployment - is closely related to Continuous Integration and refers to the release
into production of software that passes the automated tests. "Essentially, it is the practice of
releasing every good build to users”, explains Jez Humble, author of Continuous Delivery. By
adopting both Continuous Integration and Continuous Deployment, you not only reduce risks
and catch bugs quickly, but also move rapidly to working software.
With low-risk releases, you can quickly adapt to business requirements and user needs. This
allows for greater collaboration between ops and delivery, fueling real change in your
organization, and turning your release process into a business advantage.

M7 – CODE INSPECTION
What is Code Inspection in Software Engineering?
The development of any software application/product goes through SDLC (Software
Development Life Cycle) where each and every phasis are very important and needs to followed
accordingly to develop a quality software product. Inspection is such an important element which
have a great impact on the software development process.
Software developer team not only develops the software application rather during the coding
phase of software development they check for any error in the code of software which is called
code verification. This code verification actually checks the software code in all aspects and find
out the errors that exit in the code. Generally there are two types of code verification techniques
available i.e.
Dynamic technique – It is performed by executing some test data and the outputs of the
program are monitored to find errors in the software code.
Static technique - It is performed by executing the program conceptually and without any data.
Code reading, static analysis, symbolic execution, and code inspection and reviews etc. are some
of the commonly used static techniques.
Code inspection is a type of Static testing which aims in reviewing the software code and
examining for any error in that. It helps in reducing the ratio of defect multiplication and avoids
later stage error detection by simplifying all the initial error detection process. Actually this code
inspection comes under review process of any application.
How it works?
• Moderator, Reader, Recorder, Author are the key members of an Inspection team.
• Related documents are provided to the inspection team and then plans the inspection meeting
and
coordinate with inspection team members.
• If inspection team is not aware about the project, author provides an overview of project and
code to inspection team members.
• Then each inspection team performs code inspection by following some inspection checklists.
• After completion of code inspection, conduct meeting with all team members and analyze about
the reviewed code.
Advantages Of Code Inspection:
• Improves overall product quality.
• Discovers the bugs/defects in software code.
• Marks any process enhancement in any case.
• Finds and removes defective efficiently and quickly.
• Helps to learn from previous defects.
Disadvantages of Code inspection:
• Requires extra time and planning.
• Process is little slower.

M8- REGRESSION TESTING

Regression Testing - is defined as a type of software testing to confirm that a recent program or
code change has not adversely affected existing features. Regression Testing is nothing but a full
or partial selection of already executed test cases which are re-executed to ensure existing
functionalities work fine. This testing is done to make sure that new code changes should not
have side effects on the existing functionalities. It ensures that the old code still works once the
latest code changes are done.
The Need of Regression Testing mainly arises whenever there is requirement to change the code
and we need to test whether the modified code affects the other part of software application or
not. Moreover, regression testing is needed, when a new feature is added to the software
application and for defect fixing as well as performance issue fixing.
In order to do Regression Testing process, we need to first debug the code to identify the bugs.
Once the bugs are identified, required changes are made to fix it, then the regression testing is
done by selecting relevant test cases from the test suite that covers both modified and affected
parts of the code. Software maintenance is an activity which includes enhancements, error
corrections, optimization and deletion of existing features. These modifications may cause the
system to work incorrectly. Therefore, Regression Testing becomes necessary. Regression
Testing can be carried out using the following techniques:
Regression Test Selection -is a technique in which some selected test cases from test suite are
executed to test whether the modified code affects the software application or not. Test cases are
categorized into two parts, reusable test cases which can be used in further regression cycles and
obsolete test cases which cannot be used in succeeding cycles.
Prioritizing test cases - depending on business impact, critical & frequently used functionalities.
Selection of test cases based on priority will greatly reduce the regression test suite.
Selecting test cases for regression testing It was found from industry data that a good number of
the defects reported by customers were due to last minute bug fixes creating side effects and
hence selecting the Test Case for regression testing is an art and not that easy. Effective
Regression Tests can be done by selecting the following test cases –
• Test cases which have frequent defects
• Functionalities which are more visible to the users
• Test cases which verify core features of the product
• Test cases of Functionalities which has undergone more and recent changes
• All Integration Test Cases
• All Complex Test Cases
• Boundary value test cases
• A sample of Successful test cases
• A sample of Failure test cases

M9 – COVERAGE TESTING
What Test Coverage does?
• Finding the area of a requirement not implemented by a set of test cases
• Helps to create additional test cases to increase coverage
• Identifying a quantitative measure of test coverage, which is an indirect method for quality
check
• Identifying meaningless test cases that do not increase coverage
Benefits of Test Coverage
• It can assure the quality of the test
• It can help identify what portions of the code were actually touched for the release or fix
• It can help to determine the paths in your application that were not tested
• Time, scope and cost can be kept under control
• Defect prevention at an early stage of the project lifecycle
• It can determine all the decision points and paths used in the application, which allows you to
increase
test coverage
• Gaps in requirements, test cases and defects at the unit level and code level can be found in an
easy way
What Are Main Differences Between Code Coverage And Test Coverage?
Code coverage and test coverage are measurement techniques which allow you to assess the
quality of your application code.
Formula to calculate Test Coverage
To calculate test coverage, you need to follow the below-given steps:
Step 1) The total lines of code in the piece of software quality you are testing
Step 2) The number of lines of code all test cases currently execute
Now, you need to find (X divided by Y) multiplied by 100. The result of this calculation is your
test coverage %.
For example:
If the number of lines of code in a system component is 500 and the number of lines executed
across all existing
test cases is 50, then your test coverage is:
(50 / 500) * 100 = 10%

DRAWBACKS :
• Most of the tasks in the test coverage manual as there are no tools to automate. Therefore, it
takes lots of
effort to analyze the requirements and create test cases.
• Test coverage allows you to count features and then measure against several tests. However,
there is
always space for judgment errors.